No artigo anterior vimos que a Retrospectiva é uma reunião facilitada pelo Scrum Master em que a equipe do projeto discute a Sprint recém concluída e determina o que pode ser mudado e que pode tornar a Sprint seguinte mais legal de ser trabalhada e também mais produtiva.

A Retrospectiva é um momento para se inspecionar e adaptar, para aprender sobre o que funciona e o que não funciona, achar melhores meios de se trabalhar em conjunto, com toda a equipe seguindo o conceito de aperfeiçoamento contínuo.

Não existe uma fórmula única de como se fazer uma retrospectiva. Os profissionais de metodologias ágeis, chamados de agilistas, tem utilizado diferentes formas de se inspecionar o trabalho realizado para identificar aspetos a serem aperfeiçoados.

Aqui está um exemplo:

Introdução:

1)      Agradecer a participação de todos na reunião de retrospectiva.
2)      Pedir a todos que tenham a mente aberta, entusiasmo para participar juntos para aperfeiçoar o desempenho geral da equipe
3)      Apresentar o planejamento da reunião de retrospectiva com um esboço da linha de tempo
4)      Pedir a cada um dos participantes que diga em uma palavra 1) sua percepção do projeto OU 2) o sentimento; 3) participação no projeto OU no mínimo que digam seu nome
5)      Reforçar a todos a as diretivas:

1. Ter liberdade para citar aspectos que julgar relevante, independente do julgamento dos demais participantes. Deve ser um local para comunicação aberta e honesta.
2. Não usar o momento para lavar roupa suja, mas para críticas construtivas
3. O que for falado na reunião, permanece somente com os presentes e não é divulgado para outros

6)      Finalmente o facilitador irá conduzir os participantes através de um breve flashback a relembrar os eventos ocorridos na última sprint a partir da memória dos membros da equipe do projeto. Isto permitirá que a equipe se recorde do que aconteceu no projeto, os bons e maus aspectos. Preferencialmente deve-se escrever em um quadro escrevendo os eventos na linha do tempo.

Material:

• Post Its
• Caneta
• Quadro dividido em:

1)      O que foi bem
2)      O que pode ser melhorado

Como fazer:

1)      Distribuição dos post-its
2)      Pedir que cada um anote um item em post-its separados durante 5 min para coisas boas e que devem ser mantidas e 5 min para coisas que precisam ser melhoradas
3)      Pedir para cada um do grupo explicar brevemente seu post-it e auxiliar no agrupamento dos assuntos
4)      Pedir para cada um votar em três de cada grupo, separando o que pode ser melhorado em Empresa ou Equipe
5)      Agrupar por temas e separar os mais relevantes
6)      Montar o Plano de Ação da Equipe
7)      Entregar lista dos assuntos a melhorar da Empresa para o Scrum Master

Plano de ação

O plano de ação é uma pequena checklist, lista de idéias sugeridas para aperfeiçoamento da performance da equipe.

Esta lista é derivada de um subconjunto de todos os itens descobertos na reunião de retrospectiva. A lista de itens é condensada em uma lista de alta prioridade de cerca de 3 itens. Não adianta fazer uma lista imensa, pois na prática somente alguns serão atingidos.

Até mais

Eduardo Kurita Yoshinaga

Todos sabemos que precisamos estar sempre em buscar da excelência nos processos de trabalho. Isto requer que seja investido tempo para refletir sobre os problemas e buscar soluções, mas a rotina pesada do dia-a-dia geralmente se impõe de tal modo que acabamos priorizando o dia-a-dia e deixando a melhoria em segundo plano.

A retrospectiva é um dos eventos do Scrum, que ocorre após a entrega do trabalho e antes do planejamento da próxima entrega. Esta é uma oportunidade formal para que todo o time Scrum (Scrum Master, Product Owner, Dev Team) inspecione a si próprio e crie um plano de ações com melhorias a serem implementadas no próximo trabalho a ser entregue.

O ScrumGuide indica que o timebox (tempo máximo) não deve ultrapassar 3 horas para uma Sprint de 1 mês e deve ser proporcionalmente menor, conforme o tamanho da Sprint.

O propósito da Retrospectiva da Sprint é:
- Inspecionar como foi a última Sprint em relação as pessoas e suas relações, processos e ferramentas;
- Identificar e ordenar os principais itens que foram bem e que devem ser mantidas, e as potenciais melhorias; e,
- Criar um plano de ações para implementar as melhorias no modo como a própria equipe faz seu trabalho;

Após a retrospectiva deve-se buscar a implementação das ações, pois caso isto não aconteça a reunião pode cair em descrédito e consequentemente a equipe não irá mais querer perder tempo em participar de reuniões de retrospectivas.

Até mais

Eduardo Kurita Yoshinaga

Hoje eu obtive a certificação Professional Scrum Master pela Scrum.Org. Algumas pessoas me perguntaram sobre o processo de estudos para obtenção da certificação de Scrum Master e este seria o momento ideal para compartilhar como obtive esta certificação.

Eu segui uma rotina de estudos que compartilho abaixo. Pode parecer exagerado, mas eu não gostaria de perder US$ 100,00 cobrados como taxa para realização da prova.

As etapas obrigatórias são as seguintes:

• Leia o manual do Scrum. Para quem não tem familiaridade com o inglês é importante ler o ScrumGuide em português e também em inglês.
• Estude e compreenda o Scrum Guide. Em meus estudos eu montei uma tabela em planilha Excel classificando os itens estudados, separei as frases do Scrum Guide de cada um dos eventos. Nos dias em que não estava conseguindo me concentrar eu utilizei o estudo indutivo sobre o Scrum Guide em inglês.
• Faça várias vezes o simulado Scrum Open assessment disponível no site da Scrum.org. O simulado é uma versão mais light da prova, com tempo mais alongado e menos questões, por isso somente experimente fazer a prova quando estiver alcançando mais de 90% de acerto. Eu só fiz a prova depois de acertar 100% das questões.
• Antes da prova revisite todos os simulados, anotações e manuais.

• Obtenha alguma experiência real em uma equipe Scrum. É possível passar na prova somente com o conteúdo teórico, mas a vivência prática ajuda na compreensão dos conceitos.
• Faça um treinamento. Devido ao pouco tempo que tenho disponível eu optei por realizar o treinamento online da TiExames. Gostei muito deste treinamento e recomendo a todos que queiram obter esta certificação. Outro treinamento muito bom, que é bem elogiado é o curso presencial ministrado pela AdaptWorks.
• Assista aos vídeos disponíveis no YouTube sobre as práticas do Scrum. Há vários vídeos simulando eventos Scrum, explicando várias das práticas, o uso de burndown, planning poker, test driven development, etc.Isto não é estritamente obrigatório para passar no teste, mas é muito recomendável saber. Neste blog eu já publiquei vários artigos com vídeos sobre Scrum.
• Participe de congressos e encontros de eventos ágeis. A participação nos eventos Agile Brazil 2012 e Agile Café 2013 me ajudou a ganhar mais familiaridade com as terminologias e também a compreender a aplicação do Scrum através dos diversos relatos de implantação que pude assistir.
• Leia bastante. Há muitos livros, sites e blogs sobre Scrum que podem acrescentar vários conceitos importantes na prova de certificação.

Até mais

Eduardo Kurita Yoshinaga

Nos posts anteriores já foram vistos a alteração e cancelamento de Sprint e hoje pretendo começar o ano de 2013 com o assunto do aceite ou rejeição de Sprint.

Vamos recordar que uma Sprint possui a seguinte composição:

Na reunião de Sprint Planning a equipe de desenvolvimento selecionou os itens do backlog do produto que julgou ser capaz de transformar em funcionalidades prontas e nas reuniões diárias (Daily Meeting), houve o acompanhamento das atividades diárias.

Ao término do Sprint, na reunião de Sprint Review, a equipe de desenvolvimento apresenta os itens do backlog que estão prontos ao Product Owner.

Neste momento o Product Owner deve indicar se aceita ou rejeita o resultado da Sprint.

Esta avaliação não é realizada com base em questões subjetivas do PO, se gostou ou não do trabalho, mas a análise deve ser realizada com base no acordado no Sprint Planning, entre a equipe de desenvolvimento e o Product Owner, e na definição de quais etapas são necessárias para se considerar um item pronto.

Caso a Sprint seja aceita os itens prontos poderão compor o produto final e serem instalados no ambiente produtivo. Caso a Sprint não seja aceita, os itens rejeitados deverão voltar ao backlog do produto.

Até mais

Eduardo Kurita Yoshinaga

Este assunto está relacionado com o post anterior e trata da questão do cancelamento de Sprint.

Algumas das dúvidas comuns são:

• Uma Sprint iniciada pode ser cancelada?
• Quem pode cancelar a Sprint?
• Qual é o critério para se identificar se uma Sprint pode ser cancelada?

Apesar de traumático, uma Sprint já em andamento, com a equipe de desenvolvedores em pleno vapor pode ser cancelada em qualquer momento.

Somente o Product Owner pode autorizar o cancelamento da Sprint. Os usuários, Scrum Master, o comitê gestor, stakeholders ou a equipe de desenvolvimento podem chegar a conclusão de que a Sprint precisa ser cancelada, mas em todos os casos a última palavra é sempre do Product Owner, que é o responsável pelo projeto e por maximizar o Retorno sobre o Investimento.

O cancelamento pode ser necessário quando ocorre alguma mudança no processo, negócio, mercado, tecnologia, legislação ou estratégia da empresa que impacte diretamente na meta/objetivo da Sprint ou que a torne desnecessária.

Quando o cancelamento ocorre o Product Owner revisa todos os itens do backlog da Sprint que estiverem prontos e planeja o momento em que estes itens entrarã em produção. Os demais itens voltam para o backlog do produto para serem re-priorizados e re-estimados.

Um cancelamento impacta no planejamento das releases e sprints do produto, no índice de produtividade da equipe de desenvolvimento (pois menos itens serão produzidos na Sprint cancelada) e se os cancelamentos forem contínuos, pode afetar na motivação da equipe.

Além disso os cancelamentos de Sprint também consomem recursos, pois a equipe de trabalho (Scrum Master, Product Owner, Development Team) tem que se reunir para recomeçar outra Sprint.

Por isso não é muito comum haver cancelamentos de Sprints e, para minimizar o risco, em ambientes muito voláteis os seguintes cuidados podem ser tomados:

1. Sprints pequenas de 2 semanas, com apoio do Scrum Master
2. Meta da Sprint menor que o plano total da Sprint, de modo a ter certa flexibilidade no ajuste das entregas
3. Melhoria no aprofundamento e detalhamento dos itens do backlog do produto pelo Product Owner
Até mais

Eduardo Kurita Yoshinaga

Uma Sprint é corresponde ao período de tempo em que a equipe de desenvolvimento estará trabalhando para transformar itens do backlog do produto em funcionalidade pronta.

De acordo com o Scrum Guide, uma Sprint é composta por “uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint”. Na reunião de planejamento são utilizadas 8 hrs, para uma Sprint de 1 mês, em que são determinadas a meta da Sprint, o backlog da Sprint (funcionalidades que serão desenvolvidas) e como o trabalho será realizado.  Após esta etapa de planejamento é iniciado o trabalho de desenvolvimento, que é acompanhado das reuniões diárias.

A questão que foi levantada é se neste momento, durante a execução da Sprint, pode-se realizar quaisquer alterações no backlog da Sprint.

Esta é uma questão interessante, pois após o planejamento a equipe de desenvolvimento já está trabalhando a todo vapor na transformação dos itens de backlog em funcionalidades de produto e alterações podem impactar na performance do grupo. Porém para manter a agilidade e adaptabilidade, deve-se permitir a adequação do backlog da Sprint.

No Scrum Guide, da Scrum.org, está escrito que durante a Sprint:

• “Não são feitas mudanças que podem afetar o objetivo da Sprint”;
• “A composição da Equipe de Desenvolvimento permanecem constantes”;
• “As metas de qualidade não diminuem”; e,
• “O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido”.

Ainda conforme o Scrum Guide, “após a Equipe de Desenvolvimento prever os itens de Backlog do Produto que irá entregar na Sprint, o Time Scrum determina a meta da Sprint. A meta da Sprint é um objetivo que será conhecido dentro da Sprint através da implementação do Backlog do Produto, fornecendo orientação do porque a Equipe de Desenvolvimento está trabalhando no incremento. O objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em relação as funcionalidades a serem implementadas dentro da Sprint. O objetivo da Sprint pode ser um marco contido no propósito maior no roteiro do produto.”

Segundo a Scrum Alliance, o ideal é que a meta da Sprint seja menor que o planejamento total da Sprint, de modo que haja flexibilidade para adequação de itens na Sprint, desde que a meta não seja alterada.

Por isso chegamos a conclusão de que no planejamento da Sprint é importante definir a meta da Sprint com um conjunto de itens de backlog com esforço de desenvolvimento menor que o tempo total da Sprint, e preencher este tempo restante com outros itens de backlog, para que seja possível ter a flexibilidade de incluir ou remover itens do backlog da Sprint, desde que não afetem a meta ou o prazo de conclusão da Sprint. Esta inclusão ou remoção de itens do backlog da Sprint devem ser negociados entre o Product Owner e a Equipe de Desenvolvimento.

Obs: No Scrum Open Assessment da Scrum.Org há uma questão sobre este assunto e é considerada resposta correta quando “o Sprint Backlog e seu conteúdo são totalmente planejados na Sprint Planning meeting e não mudam durante a Sprint”

Até mais

Eduardo Kurita Yoshinaga