Observadores “Agile Coach” em um workshop de Scrum

De 2010 pra cá, venho conduzindo treinamentos introdutórios e práticos sobre Scrum. Recentemente venho proporcionando a experiência de ter pessoas observando nestes workshops pois esta é uma das habilidades necessárias para os famigerados Agile Coaches (entender o contexto de uma  ou mais equipes e pensar em um potencial plano de ação para que o time consiga evoluir).

No último workshop, após apenas duas iterações, foram observados os seguintes pontos de melhoria:

Processo:

  • Faltou disciplina dos membros do time para seguir o método (corrigi aqui pois Scrum não é um método, e sim um framework) e os pedidos do PO.
  • Foi possível observar os benefícios do Design evolutivo da solução.
  • Algumas opiniões/sugestões de algumas pessoas foram ignoradas.
  • Problemas de integração na hora de juntar os “módulos” das entregas da equipe.
  • Em algumas equipes, nenhum membro do time controlou o tempo, mesmo sabendo que haviam timeboxes pré-definidos.
  • Membros da equipe desempenhando as mesmas atividades gerando desperdício.
  • Equipes não pensaram em MVPs. Qual o conjunto mínimo de requisitos que entregaria a visão de negócio para o PO dar feedback?
  • Equipe considerou inviável entregar um requisito sem efetuar o entendimento sobre o que estava sendo solicitado pelo PO.

Refinamento:

  • Falta de foco durante o refinamento (refinamento sendo misturado com planejamento).
  • Nenhuma pergunta feita para o PO durante o refinamento.
  • Muitas suposições criadas sobre os requisitos sem validar com o PO.

Planejamento:

  • Boa parte do planejamento, foi gasto com discussões fora do objetivo proposto (foi solicitado que cada equipe deveria informar quantas tarefas e quanto de valor seria entregue).
  • Durante o planejamento, houve um foco excessivo em discussões sobre “como fazer” quando deveria ter um foco maior sobre “o que fazer”
  • Planejamentos sem considerar a expectativa do cliente (que era a entrega de 9 requisitos na primeira iteração).

Retrospectiva:

  • Times não fizeram retrospectiva.
  • Time não anotou as ações criadas durante a retrospectiva.
  • Ficou perceptível a evolução dos times, mesmo tendo trabalhado apenas 2 iterações.

Apesar de ser um jogo, lúdico, é interessante ver como os pontos acima se repetem nos nossos ambientes de trabalho e no dia a dia.

Um dos pontos mais interessante é que as iterações tinham menos de 20 minutos. Em apenas 2 iterações já foi possível ver uma melhoria no entendimento do processo e na quantidade/qualidade das entregas.

E aí, os seus times de desenvolvimento de software passam por alguns desses problemas no dia a dia?

Publicidade

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s