O Scrum se presta a ambientes de múltiplos projetos?

Mudarei o local de trabalho em um futuro próximo e acredito que eles estarão muito interessados ​​na minha experiência no Scrum e em como isso pode se relacionar com os negócios deles. Estou tentando entender se funcionará no ambiente deles.

Meu local de trabalho atual, temos 2 produtos / 2 pedidos em atraso / 2 equipes separadas. Esses backlogs são obviamente priorizados com base no que a empresa acha que mais precisa para uma plataforma que desenvolvemos. O local para onde vou me mudar, no entanto, tem muitos projetos em movimento, todos ao mesmo tempo com (2/3 indivíduos trabalhando em cada um), pequenos pedaços de trabalho entram e são fixados diariamente, e imagino todos os resultados do cliente são igualmente importantes.

Então, eu estou me perguntando se alguém tem experiência com Scrum em um ambiente semelhante, que exemplos reais você tem de coisas que funcionaram? O que não deu certo? Que considerações são necessárias para que o Scrum funcione nessa situação?

Existem alguns aspectos que não tenho certeza de como funcionariam bem:

1. Acredito que as pessoas nas equipes trabalharão em projetos e, portanto, potencialmente em equipes de scrum, se discriminadas.
2. Como você lida com a prioridade em tantas partes móveis que provavelmente estão mudando frequentemente e têm seus próprios prazos?
3. Se você possui uma equipe de scrum que trabalha em vários projetos (alguns exigem apenas 1 desenvolvedor), como você entende o contexto do stand-up?

Eu trabalho como gerente de desenvolvimento exatamente nesse ambiente e implementei o Scrum com muito sucesso com uma equipe de 4 pessoas no ano passado, do que foi uma bagunça horrível. Demorou um pouco de tempo para chegar onde estamos agora, mas funciona muito bem. Vou tentar resumir as ações mais importantes, mas sinta-se à vontade para fazer mais perguntas.

1. Atuei como Product Owner e Scrum Master. Trabalhei para criar uma lista de pendências para cada produto, com a parte interessada associada.

2. Em seguida, priorizei TODOS os backlogs, de modo que efetivamente tive meus próprios projetos abrangendo backlog. Isso estava usando o Fogbugz, para que eu pudesse filtrar cada um por projeto para que essa parte interessada trabalhasse comigo e embaralhasse os itens.

3. Planeje sprints a partir disso, encapsulando todos os projetos e todos os membros da equipe, para que alguns membros da equipe trabalhem em suas próprias tarefas específicas, mas incentivem o trabalho e o aprendizado multifuncionais. Todas as discussões em pé são úteis, porque se alguém está falando sobre algo que ninguém mais sabe, eles precisam elaborar o suficiente para que possamos entender. Isso ajudou o aprendizado.

   • Nesse ponto, a equipe estava sem coesão, mas estávamos pelo menos realizando as tarefas em todos os projetos, mantendo os negócios felizes e melhorando a qualidade adicionando controle de origem / testes automatizados. Foi uma enorme melhoria da bagunça que havia antes, mas também era difícil manter o foco, com nenhum objetivo além de concluir o sprint. Também não tínhamos demonstrações, pois elas não seriam particularmente relevantes para nenhuma parte interessada. Como eu era PO e SM, fui relativamente gentil ao comprometer demais a equipe. Vale a pena notar que ainda estávamos entregando MUITO mais do que antes da minha chegada.

4. Depois, tentei mudar lentamente o foco dos sprints mais para um único produto, para que tivéssemos um sprint de 60% em um produto, mas ainda com outras tarefas. Eventualmente, os sprints foram focados em 90% em uma tarefa, e as partes interessadas aprenderam a "esperar a sua vez" - afinal, ainda estávamos alcançando muito mais do que nunca. Isso tornou possível a demonstração para um produto de cada vez.

5. Depois que os sprints foram focados, comecei a treinar as partes interessadas no Scrum e a transformar algumas delas em Product Owners. Este é o estágio em que estou agora, trabalho com 3 proprietários de produtos e ainda tenho 2 produtos que efetivamente possuo. Os sprints podem ter 1 ou 2 tarefas para outros projetos, mas temos um foco suficiente para uma demonstração do sprint com os principais interessados ​​do sprint, demonstrando apenas os novos recursos de seus produtos.

Espero que isso ajude, essa é a jornada em que estive com meu atual empregador e até agora a equipe de desenvolvimento, as unidades de negócios e (o mais importante) meu chefe estão muito felizes.

Atualmente, estou trabalhando como parte de uma equipe de scrum para 4 pessoas, responsável, em um grau ou outro, por todos os produtos de nossa empresa. Totalizando cerca de 16 produtos, além de uma bagunça de pontos únicos semi-conectados, posso dizer por experiência que o scrum não se parece com um ambiente de múltiplos projetos. Como mencionado acima, é difícil criar sinergia de equipe quando você está constantemente trabalhando individualmente em coisas diferentes. Além disso, é difícil se relacionar com os detalhes de trabalho das tarefas de seus colegas de equipe, já que seu foco está em uma tarefa completamente diferente, em um projeto completamente diferente.

Além disso, a análise de "apaixonar-se" ou mesmo a não atribuída a um produto específico é quase impossível devido à taxa de rotatividade de tarefas, que pode levar à podridão do código, entre outras coisas.

Se você se encontra em uma posição em que não pode escapar de vários projetos atribuídos à sua equipe, eu não recomendaria o SCRUM.

A resposta aceita aborda bastante a questão, mas permita-me compartilhar minhas experiências. Estive em duas situações diferentes em que membros de uma equipe do SCRUM tiveram que lidar com vários projetos. Uma equipe do SCRUM pode lidar com vários projetos, mas apenas sob certas condições.

No primeiro caso, os múltiplos projetos apresentaram um desafio significativo. Meu empregador ainda tinha que adotar metodologias ágeis como um todo. Eu fazia parte de um piloto onde usamos o SCRUM para um único projeto.

O problema é que a equipe de gerenciamento de projetos preferia ter muitos projetos simultâneos e de longa duração em vez de projetos curtos e focados. Como resultado, minha equipe recebeu constantemente mais projetos do que os desenvolvedores; era típico para a equipe de quatro pessoas manipular de seis a dez projetos! Isso foi exacerbado pelo fato de termos também que lidar com uma quantidade considerável de responsabilidades operacionais e de suporte.

O que descobrimos foi que a equipe tinha apenas uma pequena fração do tempo dedicada à equipe do SCRUM, não conseguimos estabelecer uma velocidade confiável e estávamos limitando a quantidade de trabalho para cada Sprint por medo de não assumir nossos compromissos com a Sprint. Incorporar todo o trabalho de outros projetos em nosso planejamento pode ter ajudado, mas esses projetos tinham datas e escopos fixos, tornando improvável que pudéssemos ter feito o SCRUM corretamente.

No segundo caso, toda a empresa havia adotado o Agile há muito tempo e havia desenvolvido um meio pelo qual vários projetos podiam ser enfrentados por uma equipe do SCRUM. Foi tão eficaz que, como engenheiro, eu nem sabia o que eram metade dos projetos! Os proprietários do produto trabalhariam com os gerentes de projeto para identificar o trabalho necessário; usando as estimativas fornecidas por nossos engenheiros e a velocidade estabelecida pela equipe, os Proprietários do produto poderiam fazer previsões razoáveis ​​sobre quando um item específico seria concluído. Contanto que a equipe cumpra seus compromissos de forma consistente, não precisamos nos preocupar com as datas de vencimento para obter as melhores entregas.

No entanto, ajudou que todos trabalhávamos no mesmo pequeno conjunto de aplicativos. As equipes estavam alinhadas com os produtos, facilitando o entendimento do que seus colegas estavam trabalhando e facilitando a mudança do foco de um projeto para o próximo, conforme necessário.

Em resumo, o SCRUM pode ser facilmente adaptado para lidar com vários processos simultâneos, se o planejamento e a organização adequados forem realizados.

Não sei se entendi, se você tem "2/3 indivíduos trabalhando em cada um", então não é o mesmo que ter várias equipes, cada uma trabalhando em um projeto.

Eles podem mudar de projeto regularmente, em vez de ter um 'produto' no qual trabalham continuamente, mas isso não faz muita diferença. Alguns lugares até esperam que as equipes trabalhem em diferentes partes de um produto e mudem para trabalhar em outra coisa após a conclusão de cada projeto - principalmente para garantir uma boa disseminação de conhecimento.