Muitos projetos concorrentes, poucos profissionais que se dividem entre os projetos

oi Paulo

Esse é um problema que infelizmente aparece com frequencia. A conta simplesmente não fecha. O importante é que, com algumas práticas ágeis, esse grande problema pode ficar explícito para a direção, que vai ser obrigada a fazer uma escolha

• As retrospectivas com um PO participando e que possa levar essa informação de impeditivos para a diretoria
• Um quadro de historias/kanban/trello que mostre que as estimativas estão piorando e numero de historias cada vez menor por semana.
• Talvez um quadro para ficar transparente toda vez que um dev tem de migrar de um projeto para outro durante a semana. vai tambem ajudar a ficar claro o quanto isto está atrapalhando.

Quando ficar transparente de que há N projetos para apenas P profissionais, e que os 2-3 principais projetos estão lentos por causa disso, a priorização entre esses projetos deve acontecer logo.

abraços

Oi Paulo (Kolbe, não Silveira, rs...),

esse é um cenário bem comum em diversas empresas, inclusive por aqui, e a resposta mais comum para esse problema é dividirmos os profissionais em times e cada time cuidar de um número de projetos.

O backlog do time vai conter itens de todos os projetos que esse time cuidar e eles serão priorizados pelo PO normalmente, afinal, todos eles vão consumir esforço do time.

Eu, particularmente, gosto de marcar cada projeto com uma cor diferente para identificar facilmente as histórias que pertencem a um ou a outro. E, muito importante, times que cuidam de vários projetos têm que ter uma preocupação especial com compartilhamento de conhecimento entre membros, para que todos se sintam à vontade para puxar qualquer que seja a história mais prioritária.

Quanto mais compartilhado esse conhecimento for, mais simples vai ser a troca de contexto e o equilíbrio do trabalho dentro do time.

Agora... se, de fato, isso virar um problema, como o Paulo (Silveira) comentou acima, concordo apenas com a ideia de deixar o tempo de mudança de contexto claro para o time e os stakeholders.

O PO deve estar em toda retrospectiva do time, afinal é parte dele, mas não é função dele levar isso à diretoria -- se esse for o caso. O time é que decide se deve ou quem vai escalar problemas: idealmente é qualquer pessoa do time, mas em situações mais burocráticas e seguindo a teoria do Scrum, quem resolve esse tipo de impedimento é o Scrum Master.

Muito obrigado, Paulo e Cecilia! Ficaram claras as opções.