Os 6 princípios mais importantes do Scrum

chicken-n-pigTrabalho com métodos ágeis desde 2010. De lá pra cá, nestes 7 anos de estrada, vejo muitas equipes falharem na adoção do framework, seja pela disciplina inerentemente necessária à essa tarefa, seja pela displicência das equipes em realmente “fazer acontecer”.

Sinceramente não acredito que o “Scrum flácido” seja o principal causador dessas falhas, mas sim uma “mentalidade flácida”. Não são raros os times que acham que colocar o Scrum Guide embaixo do braço vai resolver todos os seus problemas de entregas fora do prazo, escopo indefinido, falta de comprometimento e muito mais.

Muito mais do que decorar as regras do Scrum, neste post sugiro que você se foque em entender os 6 princípios mais importantes por trás dessa famosa metodologia. O Scrum não funciona apenas por ter reuniões de 15 minutos em pé todos os dias. Ele funciona por causa dos princípios por trás de cada um dos seus eventos, papéis e, porque não dizer, “excentricidades”.

Resumidamente, os princípios são:

  1. Empirismo
  2. Auto-organização
  3. Colaboração
  4. Priorização baseada em valor
  5. Time-boxing
  6. Iterativo-incremental

Princípio 1: Empirismo

Você sabe o que é algo ‘empírico’?

É algo advindo do conhecimento prático, o oposto de algo que só funciona na teoria, entende?

Scrum é um framework empírico, criado com base em décadas de experiência dos seus fundadores à frente de projetos de software e essa é a filosofia central dele. Não apenas você deve acreditar nos anos de experiência dos srs. Ken Schwaber e Jeff Sutherland como Scrum enfatiza que você aprenda com a sua experiência ao longo das sprints.

Transparência, inspeção e adaptação, os três pilares do Scrum, lembra?.

Após rodar algumas sprints (da maneira correta, fazendo reviews e retrospectivas), você começará a gerar o seu próprio conhecimento empírico, realimentado o framework e aumentado a qualidade dos seus processos.

Princípio 2: Auto-organização

Esse aqui talvez seja o ponto mais falho, uma vez que nem todo mundo tem a disciplina de se auto-organizar. O fato é que as pessoas entregam significativamente um maior valor quando são auto-organizadas e isto resulta em times mais satisfeitos e responsabilidade compartilhada; e em um ambiente inovador e criativo que é mais propício ao crescimento.

Lembra da fábula da “galinha e o porco” (ilustrada no início desse post)? #oldbutgold

A galinha queria abrir um restaurante com o porco, sugerindo o nome “Ovos com Presunto”. No entanto o porco recusou. Isso porque ele estaria comprometido, enquanto a galinha estaria meramente envolvida.

Auto-organização requer um comprometimento altíssimo com os demais membros do time e com a empresa. É um princípio fundamental não apenas para o Scrum, mas para a vida da gente.

Princípio 3: Colaboração

Esse princípio concentra-se nas três dimensões básicas relacionadas com o trabalho colaborativo: consciência, articulação e apropriação. Também defende o gerenciamento de projetos como um processo de criação de valor compartilhado, com times trabalhando e interagindo em conjunto para atingirem melhores resultados.

No livro As 17 incontestáveis leis do trabalho em equipe, de John Maxwell, a primeira lei é a Lei do Monte Everest. Ninguém jamais conseguiu subir o monte Everest sozinho. Sabe por quê? Porque quanto maior o objetivo, maior a necessidade de se trabalhar em equipe, de maneira colaborativa.

Quando o time é competitivo e/ou quando os membros são egoístas, o objetivo do grupo não é alcançado, e muitas vezes os pessoais também não.

Princípio 4: Priorização Baseada em Valor

Esse princípio destaca o foco do Scrum em entregar o máximo de valor de negócio possível, durante todo o projeto.

Quando falamos que Scrum é um framework para desenvolvimento de produtos complexos, que seu cerne é entregar valor de maneira frequente e com qualidade, não estamos falando necessariamente de software. Esse é apenas o uso mais comum do framework.

Entregar valor é atender a demanda do seu mercado. É resolver o problema do seu cliente.

Não tem nada a ver com fazer over-engineering ou escovar bits. Lembra-se do Manifesto Ágil? Software funcionando é mais importante do que documentação abrangente. Eu diria mais, cliente satisfeito é mais importante que usar a linguagem de programação da moda. Que valor é mais importante que tecnologia.

Para aprender mais sobre priorização de backlog, leia este post.

Princípio 5: Time-boxing

O tempo é considerado uma restrição limitada em Scrum, e que ele deve ser usado para ajudar a gerenciar o planejamento e execução do projeto com eficácia. Os elementos Time-boxed em Scrum incluem os Sprints, as Reuniões Diárias, a Reunião de Planejamento da Sprint, e a Reunião de Revisão da Sprint.

Na verdade não só no Scrum, mas o conceito de time-boxing deve ser levado para toda a vida, se você deseja ser mais produtivo.

O princípio de eventos com prazo e duração limitados norteia-nos para que os objetivos sejam atingidos de maneira eficaz e eficiente.

É duro dizer a um colega do time que ele estourou o tempo que tinha para falar na reunião diária. Mas tenha a certeza que da próxima vez ele será mais objetivo, se quiser ser ouvido por completo.

É triste muitas vezes o time falhar na entrega porque faltava “apenas” mais um dia para terminarem as features. Mas tenha a certeza que na próxima sprint eles aprenderão com esse erro e estimarão melhor as tarefas. Ou se descuidarão menos com distrações e imprevistos.

Princípio 6: Iterativo-Incremental

Muita gente confunde iterativo com interativo. E não é um typo, existe um ‘n’ a mais na segunda palavra.

Iteração é uma execução de um laço, uma repetição. Um desenvolvimento iterativo-incremental é aquele cujas etapas se repetem indefinidamente, e a cada iteração, um novo incremento do produto é entregue pronto.

Mesmo que não use Scrum, desenvolver produtos de maneira iterativa-incremental é sempre uma boa ideia. Iterações e colaboração com o cliente garantem uma entrega alinhada com a percepção de valor do cliente, o que por sua vez gera uma maior qualidade no projeto como um todo.

Mesmo que não use Scrum, aplicar estes princípios em seus projetos não faz mal à ninguém, muito pelo contrário, faz muito bem.

Até a próxima!

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!

Como contratar um profissional ágil para sua empresa? – 11 perguntas

Desde que conheci Scrum em 2010, vejo um grande movimento no mercado de desenvolvimento de software em torno da adoção de metodologias ágeis e cada vez mais a procura por profissionais com o mesmo mindset e até mesmo experiência com Scrum e cia. Vagas para Scrum Master, principalmente, mas para outros papéis do Scrum, têm aparecido em sites de empregos com cada vez mais frequência, embora o próprio framework diga que Product Owner, Scrum Master e o Developer Team são papéis e não cargos.

Mas aí surge uma dúvida, como descobrir se a pessoa que estou entrevistando tem perfil ágil para trabalhar em meu time? Claro, dependendo de qual papel ela irá assumir no time, existem diferentes características desejáveis, como a figura abaixo ilustra bem (acho que tirei do SBOK, não lembro).

Capturar

E, para ajudar a identificar candidatos que possuam o potencial ágil que você busca, as perguntas abaixo podem ser realizadas durante a entrevista. Note que  a maioria delas não possui uma única resposta correta, mas todas ajudam a entender como o candidato raciocina sobre agilidade.

As perguntas são:

  1. Em primeiro lugar, qual o propósito de ser ágil?
  2. Como você caracterizaria o seu papel como______?
  3. Quando foi a última vez que você disse ‘não’ para outro membro de equipe? Como você lidou com a situação? Qual a razão disso?
  4. Como seu papel se relaciona com os demais do time Scrum?
  5. Sua organização recentemente decidiu implantar o uso de metodologias ágeis no desenvolvimento de produtos. Que implicações isso pode trazer aos stakeholders?
  6. Como você organiza/gerencia a colaboração entre o time e os stakeholders?
  7. Uma nova feature atrasou drasticamente devido a um débito técnico. Os stakeholders querem-na entregue mesmo assim, devido à quantia que já foi investida. Como você lida com isso?
  8. O departamento de vendas têm vendido novas features sem falar com seu time, responsável pelo produto, primeiro. Como você lida com isso?
  9. Como é sua abordagem para lidar com roadmaps de produto?
  10. Como você refina a si mesmo e o seu papel dentro do time?
  11. Como você lida com bugs + débito técnico vs novas features no dia-a-dia?

#1 – Em primeiro lugar, qual o propósito de ser ágil?

A resposta mais comum aqui, e a mais errada também, é: entregar os projetos mais rápido. Pessoas leigas no assunto tendem a confundir agilidade com velocidade. Ser ágil não é programar mais em menos tempo, isso é ser eficiente. Ser ágil é realizar entregas de maneira mais frequente e com mais qualidade.

#2 – Como você caracterizaria o seu papel como __________?

A lacuna que deixei na pergunta é para você colocar o papel que o candidato irá assumir: Scrum Master, Product Owner ou Team Dev. Você pode emendar outras perguntas na sequência, dependendo do papel, como segue:

Scrum Master: qual a diferença entre um Scrum Master e um gerente de projetos tradicional? Como seria um dia típico nessa função? E qual a diferença de um Agile Coach?

Product Owner: qual a diferença entre um PO e um gerente de produtos? Como você gerencia seu product backlog? Qual a melhor ferramenta para gerenciar um product backlog?

Team Dev: qual a diferença entre um dev Scrum e um dev “normal”? À quem você deve reportar suas atividades? Como que as tarefas devem ser distribuídas entre os desenvolvedores?

Nestas perguntas, a ideia é ver se o candidato realmente sabe do que se trata o papel ao qual ele está se candidatando. Essa pergunta é mais importante para o Scrum Master e o PO, mas entender o quão auto-gerenciável é um Dev no momento da contratação também pode ser muito útil.

#3 – Quando foi a última vez que você disse ‘não’ para outro membro de equipe? Como você lidou com a situação? Qual a razão disso?

Novamente uma pergunta importantíssima para entender se os candidatos a PO e Scrum Master possuem as virtudes necessárias para esses papéis, como foco e disciplina. Dizer ‘não’ é importantíssimo dentro de times Scrum para garantir que os objetivos serão atingidos.

Existe um artigo muito bom que li recentemente que dá dicas de como dizer ‘não’ sem se indispor com os stakeholders.

#4 – Como o seu papel se relaciona com os demais do time Scrum?



Essa é mais uma pergunta para entender se o candidato tem o perfil colaborativo necessário para que um time Scrum funcione, bem como se ele domina o Scrum em sua plenitude, não apenas o seu ‘quadrado’.

#5 – Sua organização recentemente decidiu implantar o uso de metodologias ágeis no desenvolvimento de produtos. Que implicações isso pode trazer aos stakeholders?

Essa pergunta é decisiva para a contratação de um Scrum Master. Toda implantação de métodos ágeis implica em mudança cultural na empresa e, principalmente, afeta a forma como os stakeholders interagem com o time de desenvolvimento de produto, o que nem sempre é visto com ‘bons olhos’. Como Scrum Masters são responsáveis pela implantação do Scrum nas empresas, é dever deles saber do impacto que isso causa.

#6 – Como você organiza/gerencia a colaboração entre o time e os stakeholders?




Colaboração é a chave para o sucesso dos projetos, seja entre os membros do time entre si e os membros do time com os stakeholders. Lembra da pergunta #3? Essa tem um pouco a ver também.

#7 – Uma nova feature atrasou drasticamente devido a um débito técnico. Os stakeholders querem-na entregue mesmo assim, devido à quantia que já foi investida. Como você lida com isso?

Essa é a clássica pergunta sem resposta, mas que mostrará o raciocínio do candidato em situações complicadas como essa. Deve ele abrir mão da qualidade em prol do prazo? Deve dizer não aos stakeholders em prol da qualidade? O que o Scrum diz sobre isso?

#8 – O departamento de vendas têm vendido novas features sem falar com seu time, responsável pelo produto, primeiro. Como você lida com isso?



E nesse caso? O time de vendas “serve” ao time de produto, o contrário ou nenhum dos dois? Quem está certo e quem está errado? Perguntas complicadas, que o candidato não espera ter de responder, são as melhores para mostrar quem realmente ele é e como encara questões como trabalho em equipe, agile, etc.

#9 – Como é sua abordagem para lidar com roadmaps de produtos?

Uma questão muito boa para Product Owners e Scrum Masters, mas que pode ser usada também em devs, embora com propósito diferente. Tente descobrir que ferramentas o candidato já usou, como é um dia típico dele em relação ao roadmap de produto.

#10 – Como você refina a si mesmo e o seu papel dentro do time?

Os 3 pilares do Scrum são transparência, inspeção e adaptação e não podemos esperar menos do que isso em um candidato. Como que o candidato inspeciona seu desempenho e adapta-se visando melhoria contínua?

#11 – Como você lida com bugs + débito técnico vs novas features no dia-a-dia?

Outra pergunta essencial para Scrum Masters e POs, que geralmente lidam no dia-a-dia com esse conflito de aperfeiçoar o que já existe vs criar coisas novas. Como que o candidato ‘descobre’ o que é realmente mais importante nesse momento para a empresa?

O que achou? Tem alguma dúvida sobre alguma pergunta? Gostaria de adicionar alguma outra? Eu ia adicionar uma pergunta #12, sobre qual o melhor livro sobre Scrum do mercado, mas essa todo mundo ia acertar, não é mesmo?! 😉

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis clicando no banner abaixo pra aprender muito mais!