Checklist para Scrum Master

Um bom Scrum Master pode cuidar de duas ou três equipes ao mesmo tempo. Se você se contentar em limitar seu papel a organizar reuniões, garantir o cumprimento de prazos e resolver os problemas da equipe, o papel de Scrum Master pode funcionar em tempo parcial. A equipe certamente ainda vai superar as expectativas que existiam na sua organização antes do Scrum, e provavelmente também não haverá grandes catástrofes.

Mas se você consegue imaginar uma equipe que se diverte criando coisas que ninguém achava possíveis antes, então você também deveria ter a vontade de ser um Scrum Master excelente.

Um Scrum Master excelente só consegue cuidar de uma equipe de cada vez.

Por isso, especialmente na fase inicial, recomendamos um Scrum Master motivado e dedicado para uma equipe de aproximadamente sete pessoas.

Se você ainda não tem uma visão geral de todo o trabalho a ser feito, tente descobrir mais sobre o Product Owner, a equipe, os métodos de desenvolvimento da equipe e a organização como um todo. Embora não exista uma receita mágica, listei aqui algumas coisas às quais um Scrum Master deve prestar atenção:

Checklist do Scrum Master para o Product Owner

Você pode aumentar a eficácia do Product Owner ajudando-o a cuidar do Product Backlog e do plano de release. (Mas lembre-se de que apenas o Product Owner deve priorizar o backlog.)

• A priorização do Product Backlog corresponde às reflexões e ideias mais atuais do Product Owner?

• Todos os requisitos e desejos de todos os stakeholders foram incluídos no backlog? Lembre-se de que o backlog pode mudar constantemente.

• O Product Backlog tem um tamanho gerenciável? Para manter uma quantidade de itens que seja fácil de administrar, os itens detalhados devem estar no topo do backlog e os temas mais gerais mais para o final. É contraproducente detalhar demais além dos itens do topo, pois os requisitos vão mudar permanentemente com a evolução do produto e a troca constante com clientes/stakeholders.

• Existem requisitos (especialmente os do topo do backlog) que poderiam ser escritos como User Stories independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis (critérios INVEST)?

• Você informou seu Product Owner sobre dívida técnica e como evitá-la? Pode ser útil adicionar testes automatizados e refatoração à Definition of Done de cada item do backlog.

• O backlog está visível como fonte de informação para todos os stakeholders?

• Você tem uma ferramenta automatizada para gerenciar o backlog? E se sim, ela realmente traz benefícios? Essas ferramentas trazem o risco de dificultar encontrar as informações procuradas se o Scrum Master não comunicar ativamente essas informações.

• Você pode ajudar a comunicar as informações imprimindo-as e distribuindo para todos os envolvidos?

• Você pode ajudar a comunicar essas informações criando gráficos e diagramas grandes e bem visíveis?

• Você ajudou o Product Owner a dividir os itens do backlog em releases adequados? (Por exemplo, em trabalhos atuais (Front Burner), trabalhos pendentes (Back Burner) e coisas que foram incluídas no backlog, mas ainda não foram preparadas (Fridge).)

• Todos os stakeholders (incluindo o time) sabem se o plano de release – medido pela velocity atual (por exemplo, Story Points por Sprint) – ainda corresponde à realidade?

• O Product Owner atualizou o plano de release após a última Sprint Review? Poucos Product Owners que entregam produtos suficientemente testados no prazo atualizam o plano de release a cada Sprint. Frequentemente eles adiam alguns trabalhos para releases futuros quando surgem trabalhos mais importantes. Experimente os Product/Release Burndown Charts de Mike Cohn, que você pode apresentar a todos os envolvidos após a confirmação de que os itens estão "done" nas Sprint Reviews. Isso ajuda a identificar mudanças no escopo ou cronograma precocemente.

Checklist do Scrum Master para a Equipe

1.) Os membros da equipe estão a maior parte do tempo em "Flow"? Algumas características desse estado são: Objetivos claros (expectativas e regras são reconhecíveis; os objetivos são alcançáveis e correspondem às habilidades de cada pessoa); Concentração e foco (focalização em um ponto específico); Incerteza reduzida (ações e consciência se fundem); A noção de tempo se perde (a percepção subjetiva do tempo se altera); Feedback direto e imediato (sucessos e fracassos durante a ação são bem reconhecíveis, portanto o comportamento pode ser ajustado quando necessário); Equilíbrio entre habilidades e desafio (não é nem muito difícil nem muito fácil); Uma sensação de controle pessoal sobre a situação/ação (a ação é uma tarefa intrinsecamente recompensadora e, portanto, sem esforço).

1.) Os membros da equipe parecem se dar bem uns com os outros? Eles fazem coisas juntos? Celebram juntos os sucessos dos colegas?

2.) Os membros da equipe cuidam para que todos mantenham os padrões elevados? Eles se encorajam mutuamente a melhorar?

3.) Existem problemas ou oportunidades sobre os quais a equipe não fala porque não se sentem confortáveis o suficiente? Você pode consultar um profissional que pode ajudar a tornar conversas desconfortáveis mais agradáveis. (Ou leia mais sobre o tema no livro Crucial Conversations: Tools for Talking When Stakes are High)

4.) Você já experimentou diferentes formatos e locais para suas reuniões de Sprint Review? Algumas ideias podem ser encontradas no livro Agile Retrospectives: Making Good Teams Great de Esther Derby e Diana Larsen.

5.) A equipe seguiu os Critérios de Aceitação? Talvez você precise revisar novamente os critérios de aceitação dos itens do Product Backlog durante o Sprint.

6.) O Sprint Backlog reflete realmente o que a equipe está trabalhando no momento? Interrupções e distrações que não contribuem para alcançar o objetivo do Sprint são impedimentos.

7.) As estimativas para as tasks ou o taskboard estão atualizadas?

8.) Os artefatos para a autogestão da equipe (taskboard, Sprint Burndown Chart etc.) estão bem visíveis, práticos e úteis para toda a equipe?

9.) Esses artefatos estão suficientemente protegidos contra microgerenciamento?

10.) Os membros da equipe se voluntariam para determinadas tarefas?

11.) Itens para pagar dívidas técnicas foram incluídos no backlog (para resolver problemas que prejudicam a velocity) ou pelo menos discutidos com o Product Owner?

12.) Os membros da equipe deixam seus títulos de cargo fora da sala da equipe?

13.) Toda a equipe se sente responsável por testes, documentação do usuário etc.?

Checklist para o desenvolvimento do produto

1.) O seu sistema de desenvolvimento tem um botão "push-to-test", para que qualquer pessoa (na mesma equipe ou em outra) possa facilmente descobrir se quebrou alguma coisa? Isso normalmente é alcançado com o framework xUnit (JUnit, NUnit etc.).

2.) Você tem um equilíbrio adequado entre testes automatizados de ponta a ponta do sistema (testes funcionais) e testes unitários automatizados?

3.) A equipe escreve tanto "testes funcionais" quanto testes unitários na linguagem do sistema que está desenvolvendo (em vez de linguagens de script proprietárias ou ferramentas de Capture & Playback que apenas uma pequena parte da equipe consegue usar)? Isso é possível!

4.) A sua equipe já descobriu a zona cinzenta extremamente útil entre testes de sistema e testes unitários?

5.) Um servidor de Integração Contínua dispara automaticamente um alerta dentro de uma hora (ou alguns minutos) assim que alguém causa um erro de regressão?

6.) Todos os testes são agregados no resultado do servidor de Integração Contínua?

7.) Os membros da equipe já descobriram os benefícios do design evolutivo (Continuous Design) e do "refactoring implacável" como alternativa ao Big Design Upfront (BDUF)? Refactoring tem uma definição clara: alteração da estrutura interna de um sistema sem mudar o comportamento externamente visível. Em casos de código redundante, lógica complexa, convenções de nomenclatura ruins, acoplamento excessivo entre objetos etc., o refactoring deveria ser realizado várias vezes por hora. Uma cobertura de testes automatizada é muito adequada como rede de segurança para o refactoring. Lacunas na cobertura de testes e refactoring adiado são doenças que também chamamos de dívida técnica.

8.) A sua Definition of Done para cada Product Backlog Item funcional inclui cobertura de testes totalmente automatizada e refactoring? É improvável que você consiga desenvolver um produto potencialmente entregável em cada Sprint sem aprender métodos de eXtreme Programming (como descrito por Kent Beck, Ron Jeffries etc.).

9.) Os membros da equipe trabalham majoritariamente com Pair-Programming? Pair-Programming pode melhorar drasticamente a manutenibilidade do código e reduzir o número de bugs. No entanto, pode levar você aos seus limites e às vezes parece demorar um pouco mais (quando priorizamos quantidade sobre qualidade). Em vez de forçar os membros da equipe, lidere pelo exemplo e sugira trabalhar em pares em certos dias da semana. Alguns dos membros da equipe logo preferirão essa forma de trabalhar.

Checklist do Scrum Master para o Desenvolvimento Organizacional

1.) Existe uma coordenação suficiente entre as diferentes equipes? Um Scrum of Scrums é a única forma de alcançar isso. Além disso, você pode enviar representantes da sua equipe para as Daily Standup-Meetings de outras equipes.

2.) A coordenação dentro da equipe é realmente feita – como recomendado – por aqueles que executam o trabalho diariamente?

3.) Os diferentes Scrum Masters se reúnem para trabalhar na lista de impedimentos organizacionais?

4.) Os impedimentos são comunicados ao gerente de desenvolvimento quando apropriado? O custo pode ser medido em termos monetários ou com base no tempo perdido de lançamento do produto, qualidade perdida ou oportunidades perdidas para o cliente?

5.) A sua organização é uma das poucas cujas oportunidades de carreira são compatíveis com os objetivos coletivos das equipes? Não é o caso se existem incentivos que levam a programar ou trabalhar na arquitetura às custas de testes, automação de testes ou documentação do usuário.

6.) Você está ajudando a criar uma organização de aprendizado?

7.) A sua organização é conhecida na imprensa especializada ou em outras fontes independentes como um local de trabalho popular ou líder de mercado?

O medo é seu amigo

Assim que você perceber tudo o que pode fazer para mudar as coisas, talvez sinta medo. Mas isso é apenas um sinal de que você está no caminho certo.

Este texto é do blog da Scrum Alliance e foi traduzido por nós para o alemão.