Aplicação de uma abordagem uniforme do Scrum a todas as equipes de um departamento

Onde trabalho, recentemente mudamos o desenvolvimento Agile usando Scrum. Passamos pelas dores típicas do crescimento, mas chegamos a uma abordagem que parece funcionar por enquanto (se funcionará a longo prazo é outra questão!).

Obviamente, a gerência do departamento está feliz por a transição para o Scrum estar funcionando. Mas eles começaram a fazer algo que, para mim, parece errado.

A gerência observará uma equipe, verá o que funciona para eles e a prescreverá para todo o departamento. Coisas como:

• A definição de "Concluído"
• Quais valores do ponto da história podem ser usados ​​para apontar uma história (por exemplo, omitir 8 da sequência fib. Porque 1, 2, 3, 5, 13 etc. foram os únicos usados ​​durante um sprint que eles observaram)
• Dizendo às equipes que elas devem calibrar o valor de 1 da história para "atualizar um rótulo da interface do usuário" e limitá-las a um limite superior de 20
  • (embora nem todos os nossos projetos tenham clientes e nem todos os desenvolvedores tenham experiência na interface do usuário)
• Dizendo às equipes que usem estimativas de pontos da história de 100 para significar "vamos dividir essa história mais tarde"
• Dizendo às equipes para usar estimativas de pontos da história do infinito para significar "este é um épico" ou "precisamos de mais informações"

Entendo que eles estão tentando ser úteis, mas todas as coisas acima não devem ser específicas da equipe Scrum? Ou seja, o que funciona para um grupo de indivíduos em um projeto pode não fazer sentido para outro grupo em outro projeto.

Estou preocupado com o fato de estarmos adotando uma abordagem ágil muito prescritiva e rígida. Estou justificado em pensar isso ou estou exagerando?

Editar

Só para esclarecer ... por "Gerenciamento" e "Gerente", não quero dizer o Dono do Produto. Quero dizer, qualquer gerente fora da equipe Scrum, mas dentro do departamento de software.

Claro que você está justificado em pensar isso. O fato de você estar falando sobre "impor o Scrum" é uma sirene de alarme estridente.
O Scrum é, acima de tudo, a auto-organização da equipe; eles escolhem como fazer seu trabalho e como se organizar. A gerência tem apenas uma opinião sobre o trabalho que precisa ser feito.
A razão pela qual as equipes devem se organizar é que elas são sempre únicas, devido às diferentes naturezas de cada membro da equipe (e as pessoas com quem trabalham) e às diferenças dos produtos em que trabalham. Uma prática que funciona perfeitamente bem para uma equipe pode ter efeitos adversos em outra equipe. É por isso que, dentro de um certo escopo (geralmente é usado um metaphore de área restrita), eles precisam experimentar, aprender e descobrir o que funciona melhor para eles.
O que você precisa é de um Scrum master muito competente (um por equipe), que possa guiar uma equipe nessa descoberta, mas, ao mesmo tempo, também pode trabalhar com a gerência para obter a liberdade de a equipe prosseguir nessa descoberta.

Bem-vindo a um dos piores pesadelos do scrum. Você encontrou um dos motivos pelos quais o scrum falha em fornecer as melhores coisas que todo mundo tem em mente ao adotá-lo.

Infelizmente, o scrum não é compatível com a alta gerência que tende a centralizar e criar processos de gerenciamento na organização e nas equipes. Para ter sucesso, a gerência superior precisa mudar de mentalidade e se concentrar no que precisa das equipes. Eles não devem se concentrar em como as equipes trabalham. O único momento em que eles devem se envolver é se uma equipe não estiver atuando para descobrir o motivo.

Acredito que você precisa se sentar com a gerência e conversar sobre os requisitos deles e o que eles querem que as equipes cumpram. Isso pode ser um requisito global para todas as equipes. Pode-se estimar que eles entendem, duração, etc. Essas coisas não devem ditar os processos das equipes. É importante que você separe as expectativas de gerenciamento da maneira como executa o scrum. Cada equipe precisa encontrar seu próprio ritmo e sua própria maneira de conduzir os projetos, que os tornarão bem-sucedidos, produtivos e fornecerão o que a gerência precisa. Se, por exemplo, você tem uma estimativa de 15 pontos da história, a equipe deve poder calcular esses pontos em dias (ou horas) de homens com base na velocidade média da equipe. Mas será exclusivo para a equipe.

Como empresa, equilibrar seus recursos deve ser uma vantagem competitiva. Caso contrário, basta criar várias empresas de software individuais que perdem esse tipo de alavancagem. Uma organização com várias equipes e projetos deve se preocupar com a rotatividade e o equilíbrio da equipe. Eu não acho que seja uma boa idéia para cada combinação de equipe única reescrever o livro sobre como eles vão fazer o scrum.

Sempre que você estiver tentando agregar itens para medir algo, a consistência é importante, ou seja, não compare maçãs e laranjas. A gerência deve se concentrar nessas necessidades de nível superior, mas certifique-se de que elas não se envolvam demais nos detalhes de como as equipes operam. Tente aplicar suas sugestões, mas esteja preparado para defender por que uma equipe pode ser a exceção. Qualquer pessoa que não goste de uma maneira particular de fazer as coisas precisa vestir a calça adulta e lidar com isso.

Tem que haver alguma flexibilidade, para que você possa fazer o trabalho. Deve haver consistência quando necessário. Se a participação na equipe for alterada, todos não devem sentir que é o primeiro dia de trabalho.

Talvez suas equipes nunca mudem, mas você deve dar uma chance a essa escolha com alguma consistência.

Não, você não está exagerando e você tem um bom motivo para se preocupar. A gestão deve se concentrar na mudança de cultura. A gerência precisa definir a direção certa e apresentar o contexto para as equipes, usando as cerimônias ágeis que funcionam bem para que a equipe seja produtiva.

Sinto-me com sorte por trabalhar em uma organização que está passando por uma transformação ágil da cascata há mais de um ano e começou no portfólio em que trabalho. Eles começaram originalmente com um projeto em que uma equipe ágil era formada. O sucesso da entrega por meio de cerimônias ágeis, como retrospectivas, estimativa relativa, previsão histórica usando velocidade, levou todo o portfólio a formar equipes adicionais com sua própria lista de pendências.

Por experiência, o Agile não é prescritivo e você não pode implementar uma abordagem de cortador de biscoitos. Só porque funcionou em uma equipe, não significa que funcionará em outra. Eu sei disso por experiência própria, porque originalmente pensávamos que poderíamos iniciar novas equipes aplicando as mesmas coisas como DoD, o que significa 1 ponto, o que significa 8 pontos. Mas não funciona como contextualmente, eles têm pouco significado quando aplicados a uma equipe diferente. Aliás, para uma história de equipe acima de 8 pontos significava que era muito grande e precisava ser dividida.

O que funcionou foi o estabelecimento de diretrizes para as equipes, como elas precisam fazer stand-ups, retros, mostras ao mesmo tempo e em cada ação retro, realizada e implementada para melhorar as novas equipes. Outras coisas, como definição de feito e dimensionamento de pontos da história, foram introduzidas após alguns sprints, à medida que a equipe se familiarizou com o conceito de narração de histórias e preenchimento de cartas, e não com a entrada na próxima sprint.

Sei que essa é uma tarefa difícil para a gerência, pois eles querem saber quando os projetos serão entregues e, ao formar novas equipes ágeis, é difícil dar uma ideia inicial. Mas agora o portfólio tem a reputação de ter forte capacidade de entrega ágil. Ainda estaríamos tropeçando se a abordagem do cortador de biscoitos continuasse sendo levada para as outras equipes.

Inconsistência na prática entre equipes do Scrum pode realmente ser um problema, por exemplo, se os membros da equipe se moverem entre as equipes.

Seria melhor tentar resolver esses tipos de problemas de compartilhamento de conhecimento entre equipes de uma maneira mais ágil - talvez algo como executar sessões Lean Coffee ou Scrum-of-Scrum envolvendo seus mestres de scrum. Esperamos que sua gerência perceba que está tomando posse dessa área e pare de tentar gerenciar os problemas de maneira descendente.