Executando Agile Após Demissões

Adrian Carr escreveu sobre a adaptação da implementação de Scrum da sua equipe após demissões. Originalmente, a equipe era um grupo de quatro desenvolvedores, um testador, um Product Owner e o Scrum Master. Após os cortes, a equipe foi reduzida para quatro membros com Adrian como Scrum Master em meio período e nenhum Product Owner dedicado. A unidade de negócios teve o mesmo problema de pessoal que o grupo de desenvolvimento e portanto foi capaz de providenciar apenas um "ponto de contato senior que entende do negócio e está autorizado a tomar decisões sobre o projeto". Então a questão que ficou para ele foi: Quais partes do Scrum manter? A primeira tentativa de Adrian incluiu:

• Manter apenas as partes do Scrum que fazem sentido em um grupo menor: reuniões em pé diárias, sprints curtos, revisões, retrospectivas, project burndowns visíveis.
• Todo mundo na equipe faz parte do papel de Product Owner se reunindo com clientes, usuários finais etc, mas Adrian manteve o product backlog e tomava decisões finais etc.
• Eliminar desperdício.
• Manter as coisas o mais simples possível.
• Creditar pontos de histórias apenas para funcionalidades colocadas em produção, a expectativa é que isso iria forçar a equipe a criar funcionalidades menores e mais fáceis de gerenciar. Isto deveria levar a uma redução no tempo das iterações e gerar mais feedback.
• Trabalhar em blocos muito pequenos de trabalho – apenas dois ou três itens por vez.
• Focar em entregar os itens de maior valor primeiro.
• Conhecer para quem o software estava sendo desenvolvido. Conhecer seus nomes, seus papéis e porque eles faziam o que fazem.
• Vigiar por fatores externos que freiem a equipe e tirá-los do caminho.

Robin Dymond, da Innovel, tem uma preocupação maior: a ausência de um Product Owner dedicado. Ele diz que para um desenvolvedor fazer esse papel ele irá ter que se tornar um expert no negócio, diminuindo o tempo que ele tem para desenvolver. Ao invés disso, ele recomenda:

Se o pessoal de negócios está pressionado por tempo então a equipe de desenvolvimento pode fazer reuniões pequenas e frequentes com eles, eles podem aprovar os critérios de aceitação ao invés de escrevê-los, e eles podem focar em prioridades. No entanto eles precisam estar no seu papel, e ter a responsabilidade. A equipe não pode fazer isso por eles, porque a equipe irá inevitavelmente interpretar as coisas de modo diferente, escolhendo prioridades diferentes e tomando decisões diferentes das que o pessoal de negócio iria.

Em uma opinião de Mary Poppendieck's (autor do Implementing Lean Software Development (implementando desenvolvimento de software enxuto)), o Product Owner não é sempre necessário ou até mesmo desejável, já que ela considera que se os desenvolvedores entendem o que o cliente quer o product owner adiciona uma nova camada e é provável que haja informação perdida devido a intermediações. Para Mary, a chave é ter uma medida boa e simples na qual todos concordem como o objetivo, então todas as funcionalidades podem ser medidas contra o valor entregue para esse objetivo.

Ron Jeffries avisa quanto a possível falta de clareza entre a equipe, como Product Owners, e a Unidade de Negócios. Se o produto acaba não sendo exatamento o que o cliente precisa, a unidade provavelmente irá culpar a equipe de desenvolvimento por suas decisões. Ron aponta que uma das vantagens do papel Product Owner/Customer tradicional é que a unidade de negócios então não tem quem culpar além de si mesmos, se o produto não realizar as expectativas dos usuários finais.