Várias equipes de scrum mudando para um único backlog

Atualmente, temos 5 equipes de scrum que trabalham com seu próprio estoque de produtos no ano passado. Cada equipe trabalha em seu próprio sistema dedicado, mas a tecnologia subjacente é a mesma .Net.

Tem havido muita discussão sobre a mudança para equipes baseadas em recursos que trabalham com uma única lista de pendências. O motivo é que um de nossos principais sistemas tem uma quantidade significativa de trabalho chegando e sua capacidade não é suficiente para entregar todo o trabalho no ano. A outra razão que acredito ser significativa é que ela oferece maior flexibilidade para se adaptar rapidamente às mudanças no portfólio.

Foi tomada a decisão de mudar duas equipes para trabalhar em uma única lista de pendências, mas os desenvolvedores não têm experiência nos outros sistemas. Uma coisa que estamos fazendo é a habilidade cruzada, movendo um desenvolvedor de sistemas de experiência para a equipe.

Minha pergunta é: você já passou pela mudança para o backlog único para dois ou mais sistemas diferentes. Quais foram seus desafios? O que você precisava fazer para que funcionasse?

Gerenciamos cerca de meia dúzia de projetos usando uma única lista de pendências. Eu digo "sobre" porque depende de como você deseja diferenciar projetos.

Vagamente, temos cinco ou seis proprietários de produtos, alguns dos quais possuem mais de um produto. Temos uma equipe razoavelmente pequena com sete desenvolvedores e um líder de equipe que também codifica quando ele tem tempo. E temos alguns evangelizadores que trabalham com nosso pessoal do processo para mover idéias para o pipeline. É claro que várias pessoas usam vários chapéus que confundem as coisas, mas eu vou ignorar isso como resposta. Curiosamente, não temos um scrum master formal.

Não tivemos que juntar backlogs, mas parece uma tarefa simples do seu lado.

Manter as coisas organizadas pode ser uma verdadeira dor de cabeça, então, aqui estão alguns pontos que você deve considerar.

• Governança é a chave. Todo mundo que tem um dedo administrativo na torta deve se comunicar com outras pessoas antes de fazer alterações significativas. E / ou aqueles que fazem alterações devem estar à vontade com sua autoridade para fazê-lo (e estar preparado para enfrentar uma mudança ruim). Nossos criadores de mudanças têm forte apoio executivo e as linhas são claramente traçadas em torno das áreas. Mas quando há uma dúvida, perguntamos antes de mudar.

• Pode haver mais sobrecarga envolvida com limpeza, priorização e kick-offs. A priorização como ritual sofre mais porque é difícil reunir todos os proprietários regularmente. Usamos vários intermediários para negociar prioridade e / ou entregar as más notícias de não fazer o corte de prioridade.

• Muito do nosso trabalho é impulsionado por um compromisso externo. Isso tira parte da autonomia de nossas decisões, mas essa é a realidade dos negócios. Seus desenvolvedores precisam estar cientes dessa mudança. As penas podem ficar irritadas se houver uma perda de controle percebida. Porém, tentamos não se comprometer demais e tivemos que dizer "não" a alguns proprietários de produtos que estavam à beira de fazê-lo no sprint.

• Geralmente, usamos dois métodos para marcar a qual produto um item de backlog do produto pertence. Usamos os dois simplesmente porque facilita a preparação e outras tarefas.

  1. Precederemos o título do PBI com o nome do produto ou a versão abreviada.
  2. Temos um campo separado que indica o produto em geral e que também deve ser preenchido.

• Temos que fazer um esforço consciente no treinamento cruzado e garantir que todos tenham uma mão nas várias áreas. Temos uma base de código muito grande em relação à nossa equipe de desenvolvimento. Alguns dos códigos que fazemos também são muito especializados. O líder da nossa equipe é incrível nesse sentido e ele reduzirá nosso nível de comprometimento um pouco para que possamos pagar as ineficiências resultantes do treinamento cruzado. Ter uma forte liderança de equipe é fundamental nesse sentido.

• Fazemos o possível para manter nossos prazos de sprint. Projetos complexos com membros mais novos da equipe se traduzem em sangramentos incomuns com compromissos. O processo em torno de sua ramificação realmente ajudará aqui. Todo o nosso trabalho é realizado em uma ramificação que é mesclada novamente para uma liberação de tronco. Também temos um servidor de compilação que funciona todas as noites, além de gatilhos ad-hoc. Os desenvolvedores que quebram a compilação sabem e resolvem o problema em 24 horas. Período. Se você não resolver dentro de 24 horas, seu commit será revertido e os desenvolvedores seniores sentirão dor. E os desenvolvedores seniores são mais exigentes quando se trata de manter a compilação.

• Revisões e revisões de código tornam-se ainda mais críticas. Ajuda a manter todos atualizados sobre o que está mudando nas várias áreas.

• Da mesma forma, o standup diário envolve todos os desenvolvedores e o pessoal da interface do usuário. Estamos à beira da comunicação colaborativa benéfica e da ineficiência de muitas pessoas. Mas mantemos o stand-up por menos de 15 minutos e passamos rapidamente a discussões secundárias. Geralmente terminamos em 5 a 10 minutos.

• Não posso falar sobre os efeitos em métricas como velocidade ou comprometimento geral e taxas de burndown. Esses aspectos simplesmente não foram importantes o suficiente para seguirmos de perto. YMMV, então leve isso em consideração. Isso também pressupõe que cada equipe tenha uma definição razoavelmente semelhante do ponto da história. Caso contrário, isso vai atrapalhar as estimativas iniciais após a mesclagem. Isso também gerará alguns problemas para comparações históricas, pois você não está usando a mesma unidade de medida que antes. O caminho mais fácil é declarar uma "nova equipe" para as métricas e começar a coletar dados após a mesclagem.

• Vimos benefícios significativos dessa abordagem. Tivemos alguns sprints em que todas as mãos estão focadas em uma área e podemos fazer muitas mudanças em um curto período de tempo. Você não deve subestimar o valor resultante de poder aplicar rapidamente o dobro do número normal de desenvolvedores em um projeto específico. Mas você precisa fazer o treinamento cruzado antes do tempo. Isso também significa que nunca temos desenvolvedores com "nada a fazer" por causa de ciclos de teste ou preparação ou algo assim. Temos sempre uma lista de pendências para resolver.

• Dedique tempo para projetos de P&D. Caso contrário, é muito fácil para eles escaparem das rachaduras e você perde a oportunidade de investir nessas áreas.

• Realmente trabalhe na codificação sem ego e que, embora você possa ter especialistas em uma área, não possui proprietários de uma área de código. Impedir a oportunidade de egos feridos é importante quando estilos diferentes são introduzidos em uma área. Contanto que o novo código atenda aos padrões da equipe e seja funcional, deve ser bom. Só porque não é como o especialista teria feito, não importa.

• Verifique se as equipes envolvidas estão usando as mesmas convenções e estilo de codificação. Nada como inconsistência aqui para causar estragos em suas tentativas de integração.

• Continue segurando suas retrospectivas e mantenha-as como um grupo. É importante obter o feedback de todos sobre o que está funcionando, o que não está funcionando e o que precisa ser tentado de maneira diferente. Isso ajuda a gerar um senso de camaradagem dentro da equipe e dá uma sensação de propriedade em todo o processo de desenvolvimento.

A resposta correta do Scrum é "Pergunte ao (s) time (s)". Esse é o princípio da auto-organização, onde eles devem ser capazes de se reestruturar para fazer o trabalho rapidamente. Você vê que muitas pessoas nas equipes têm mais conhecimento de contexto do que alguém de fora e sabem o que é melhor. Isso também inclui o Dono do produto.

Suponho que você veio aqui e fez a pergunta, pois há algo que não parece certo e você tem preocupações ocultas. Então, eu vou lhe dar algumas dicas para discutir com a equipe para chegar à decisão certa.

Proprietário do produto

Existe apenas um proprietário do produto para uma lista de pendências e essa deve ser uma pessoa de negócios ou uma pessoa que representa uma empresa. Não deve ser gerenciamento de TI. Uma grande carteira de pedidos possui muitos itens e, com várias equipes, pode ser demais para um único pedido. Convém manter os registros em atraso separados por esse motivo.

Se houver vários pedidos de compra, você definitivamente precisará de vários pedidos em atraso, pois as equipes devem ser dedicadas em um sprint a um único pedido e pedido em atraso. O motivo é que uma equipe não precisa gerenciar conflitos entre as prioridades dos proprietários do produto.

Desenvolvimento de produtos versus manutenção

As equipes de manutenção trabalham com muitas pequenas melhorias, erros em vários produtos diferentes e, possivelmente, com vários proprietários de produtos. Essas equipes da BAU precisam do suporte do gerenciamento de TI para ajudar a agendar e gerenciar os conflitos entre vários proprietários de produtos.

As equipes de projeto devem se concentrar em um produto por vez para minimizar a alternância de contexto e fornecer um ótimo produto por vez. A troca de contexto pode resultar na entrega de muitos produtos medíocres com algum grau de dívida técnica.

Troca de Contexto

Trabalhar em vários produtos ou recursos diferentes causa a alternância de contexto, o que diminui a produtividade das equipes. O OP deve levar isso em consideração ao elaborar o que vem a seguir e qual equipe deve estar trabalhando em qual parte do trabalho. A quantidade de comutação não é insignificante e não é apenas uma questão teórica, é real e eu testemunhei a equipe reduzir até 80% em produtividade devido a isso.

Um bom PO tentará recursos de grupo e tipo de trabalho para ajudar as equipes a fazer menos alternância de contexto, melhorando assim seu desempenho.

Risco

Infelizmente, a gerência tenta colocar em risco o tempo, dinheiro, orçamento e pressões comerciais sobre a equipe; e as equipes aceitam isso concordando com isso. Como profissional de desenvolvimento, você deve simplesmente declarar os fatos e impactos das decisões e fazer com que a empresa possua seu próprio risco.

Exemplos

• Concordando com um tempo ridículo. Em vez disso, diga que esforço será necessário para fazer o trabalho corretamente e faça com que os negócios gerenciem o problema do tempo

• Estimativas. Os negócios esperam que as equipes calculem com precisão em um mundo de complexidade e incerteza. As equipes devem perguntar às empresas o que estão fazendo para mitigar se as estimativas são excedidas devido a desafios imprevistos, que são altamente prováveis. As equipes não devem levar em consideração a gordura, mas sim os negócios.

• Dívida Técnica. As equipes devem estimar a execução de um código de alta qualidade que seja totalmente testado e avaliar isso, ou seja, parar de escrever defeitos devido a pressões. Se os negócios querem qualidade inferior, é o risco deles correrem riscos e, quando as coisas dão errado, é problema deles.

Profissionalismo

Seja um profissional, afirmando construir as coisas certas com a qualidade acordada. Faça uma estimativa da sua melhor capacidade com base nos fatos em questão. Quando esses fatos mudarem, comunique-o e ajuste a estimativa. Como equipe de desenvolvimento, construa ótimos produtos e não corra riscos de negócios. Comunicar e gerenciar expectativas.

Inspecionar e adaptar

As equipes devem sempre procurar maneiras de melhorar e, se acharem que isso vai melhorar as coisas, devem tentar. Depois, verifique se há melhorias. Finalmente, eles devem se adaptar e melhorar sua nova abordagem ou descartá-la se não estiver funcionando. A intenção por trás de procurar melhorar sempre deve estar lá.

Bottom Line

Por fim, o gerenciamento da lista de pendências é a escolha da OP. Como ele / ela deseja gerenciar a fila de trabalho é com eles. O único pensamento é que eles DEVEM manter o pipeline de trabalho para TODAS as equipes saudáveis ​​e em bom estado. Cabe, portanto, ao OP decidir.

O contrato

Nas sessões de planejamento de sprint, a equipe deve esperar uma lista de itens de lista de pendências de produtos limpos, inequívocos e ordenados. Com uma breve discussão com o OP, a equipe deve saber exatamente o que o OP quer; o que . A equipe então se concentra em como eles vão construir.

Se o pedido chegar à reunião de planejamento bem preparado, quem se importa com o gerenciamento do backlog. Se o OP não estiver preparado para a reunião de planejamento do sprint, isso deve ser tratado pela SM e tornado muito visível, pois isso é totalmente inaceitável e não é um problema da equipe.

Recentemente, absorvemos o backlog de outra equipe. A equipe tinha apenas um membro (não muito de uma equipe, eu sei), mas há um trabalho real em sua lista de pendências. Não estamos muito familiarizados com o trabalho deles e eles não estão muito familiarizados com o nosso.

Mesmo que seus backlogs sejam mesclados, isso não significa que todos tenham que trabalhar em tudo imediatamente. Não é razoável esperar isso, então não se preocupe muito com todo mundo ser capaz de fazer tudo nos dois registros em atraso imediatamente.

Em vez disso, comece com as duas equipes trabalhando exatamente no que estavam trabalhando antes; a única diferença é que tudo está na mesma lista de pendências.

Em seguida, toda iteração / sprint faz com que alguns membros de cada equipe trabalhem em histórias da outra lista de pendências. Por não ter todo mundo trabalhando em itens desconhecidos ao mesmo tempo, você distribui o custo de aprender os sistemas uns dos outros . Com o tempo, sua equipe absorverá gradualmente o conhecimento uns dos outros.

Se você fizer todo o aprendizado antecipadamente, haverá penalidades significativas de desempenho. Alguém da gerência sênior certamente notará, e você será forçado a absorver o atraso de outra equipe na esperança de que a nova equipe possa compensar o fraco desempenho ... :) Brincadeiras à parte, no entanto, essa seria minha recomendação.

Estou assumindo que o motivo pelo qual você (ou gerenciamento) deseja criar uma lista não processada mesclada para duas equipes é que você deseja selecionar apenas itens de lista não processada para um dos sistemas e que as duas equipes trabalhem neles.

Nesse caso, espere muito atrito da equipe que é forçada a trabalhar no sistema com o qual não está familiarizado. Espere que a equipe use todos os recursos (por exemplo, pequenos itens de lista de pendências relacionados ao sistema "doméstico") para continuar trabalhando no sistema em que estavam trabalhando antes. Quem deve culpá-los? Não é divertido trabalhar em algo em que você não é bom. E o fato de a outra equipe ser boa como algo em que você não é bom a torna pior - porque faz você parecer ainda mais idiota.

Portanto, a única maneira de obter sucesso é dividir as duas equipes e transformá-las em duas equipes mistas. Somente então, há uma chance de que você obtenha todos os desenvolvedores atualizados rapidamente no sistema (atualmente) "importante".

Isso não é muito bom para ser assim. Minha empresa anterior, entrou no modo de equipe única de produto único porque na grande empresa, tínhamos pessoas diferentes trabalhando em coisas diferentes.

Alternar entre projetos também custa esforço, e se houver uma nova pessoa para começar a desenvolver despesas gerais é realmente grande. É preciso obter direitos de acesso ao sistema desenvolvido, repositório diferente etc.

Eu prefiro a especialização, as pessoas sabem o que estão fazendo, têm todas as informações necessárias, conhecem as armadilhas do projeto e as pessoas não têm a sensação de que você precisa descartá-las de projeto em projeto para fazê-las funcionar, para sugar cada centavo eles.

Mesmo se estiverem ociosos em seu projeto, eles são muito mais produtivos no que estão familiarizados, do que saltar de um projeto para outro.