Oi Ferreria,

claro que não existe uma única solução, e um profissional capacitado pode avaliar o caso da empresa, indicando bons caminhos. O Scrum permite adaptações, mas quanto maiores, mas risco se corre e o auxílio de alguém com experiência e o devido conhecimento ajuda. De qualquer forma, sem interferir muito, há um caminho normal, que é inserir a demanda urgente como uma história extra na Sprint. Se isso for conversado e acertado com o time, não quebrará a Sprint e permitirá o atendimento de todas as necessidades. Isso, conjugado com o uso de Sprints curtas, deve resolver a maior parte das necessidades de manutenção.
Um abraço.

Uma vez que os projetos são de grande complexidade o que faz com que as equipes especialistas acabem sendo criadas, como mitigar o problema de estimativa para as Sprints? uma vez que sem um conhecimento mínimo do projeto, fica difícil para o desenvolvedor estimar e garantir a qualidade do que está fazendo.

Considerando ainda a complexidade do projeto, o que vocês sugerem para resolver o problema da análise?
Lembrando que, uma vez que o projeto é complexo e específico, fica difícil para o desenvolvedor abstrair e compreender todo o necessário para planejar uma sprint. Isso fica mais evidente na criação de um novo projeto de regra de negócio mais complexa.

No texto foi colocado que “casos imprescindíveis inevitáveis … resta-nos a alternativa do cancelamento das Sprints dos projetos de desenvolvimento, em benefício dos projeto de manutenção”. Vocês propõe alguma forma de decisão para isso? ou seria somente um comum acordo entre as partes?

Na questão dos projetos em Manutenção, foi citado que é comum entrar demandas e correções “todas para ontem”. Como estipular prazo de entrega para essas correções considerando uma sprint? Como negociar um incidente junto ao cliente, de forma que ele aceite esperar a conclusão de uma sprint, para que somente então seu item entre na próxima sprint? (no artigo é citado o prazo de 1 semana de sprint, ou seja, em alguns casos uma sprint pode começar e logo em seguida um novo incidente muito importante ser registrado).

A cerimônia diária deve ser somente para dizer oque fez, vai fazer e se está com alguma dificuldade, a qual inclusive não deve ser sanada no momento da reunião. Alguém com conhecimento para a solução se compromete a após a reunião ajudar quem está com dificuldade.
Quanto ao tamanho da equipe, a sugestão seria quebrar em duas. Existe recomendação para cada time ter de 3 a 9 integrantes, contando inclusive PO, SM e Tester.

Oi Janaína,
de certa forma, você já elencou as soluções na sua pergunta: reduzir o time e se ater ao previsto para cada reunião/cerimônia. Vocês tem Scrum Master? Como ele se posiciona com relação a esses problemas? E o PO? Ele não percebe que a produtividade do time poderia ser melhor? Ninguém enxerga riscos par ao time com essas práticas?