Determinação do custo de impedimentos (desperdício)

5

Já há algum tempo, nossas equipes Scrum têm experimentado impedimentos recorrentes causados por fatores externos à equipe. As equipes discutiram os impedimentos em suas retrospectivas e também o trouxeram em "Scrum of Scrum". Parece que os impedimentos podem requerer o envolvimento da administração, uma vez que isso requer algumas mudanças bastante significativas na forma como fazemos as coisas e na maneira como nossos ambientes técnicos foram configurados. Em um cenário pequeno, esse tipo de problema provavelmente teria sido fácil de lidar porque a equipe teria mais controle, mas nesse cenário há várias equipes, partes interessadas e partes. Eu gostaria de ouvir sua experiência em tornar o desperdício e os custos visíveis. Você simplesmente estima as horas desperdiçadas nos impedimentos recorrentes (como “perdemos 10 horas em cada sprint aguardando no servidor de compilação) ou você tem uma maneira mais sistemática de coletar e mostrar os resíduos?

Eu gostaria de coletar resíduos com base no Seis Sigma (e Desenvolvimento de Software Lean) e estimar o custo do desperdício em termos de pontos de história. Por exemplo. em cada retrospectiva, destacam-se os desperdícios em sete categorias com o número de pontos de história desperdiçados em cada categoria. As sete categorias seriam: Trabalho parcialmente feito, Recursos extras, Reaprendizagem, Transferências, Troca de tarefas, Atrasos e Defeitos.

No final da Retrospectiva, haveria uma indicação clara do custo dos impedimentos externos nos quais a gerência poderia facilmente agir. O que você acha?

    
por Allan Lykke Christensen 02.06.2013 / 16:27
fonte

1 resposta

1

Talvez você receba mais adesão da administração se mudar completamente seu problema e apresentá-lo dessa maneira; "Se consertarmos este problema, o que podemos ganhar ?" Aproxime-se do problema pelo lado positivo e, na minha experiência, você obterá uma resposta melhor em todos os aspectos. Então, ao invés de destacar os problemas (que todos nós podemos fazer até ficarmos de cara feia), aponte soluções e benefícios para a mudança.

Você pode fazer uma lista das coisas que sua equipe vê como impedimentos e criar uma lista de pendências de "melhorias" em separado. Estime cada item como você faria com qualquer outra história de usuário. Em seguida, em sua reunião de planejamento com seus stakeholders, você poderá apresentar suas diversas propostas com um custo-benefício claro para elas.

"Então, Gary, se incluirmos essa história de 'consertar o servidor de compilação' neste sprint de semanas, que estimamos ter 6 pontos, pensamos que, no futuro, poderemos melhorar a velocidade em cerca de 4 pontos por sprint ".

Algumas notas extras sobre essa abordagem;

1) essas histórias são efetivamente cruciais que precisam acontecer (eu esqueci completamente o termo 'scrummy' para isso); e os pontos da história não devem contribuir para a sua velocidade de sprint, pois são um custo e não progridem em si mesmos o projeto real

2) Se você tiver sucesso com uma pequena história de impedimento primeiro, você poderá obter mais buy-in para os itens maiores na sua lista de impedimentos

    
por 03.06.2013 / 12:34
fonte