desvantagens do scrum

Oi Carlos vou te falar da minha experiência gerenciando alguns times.

A equipe que você gerencia deve conhecer o framework, ou seja tem um processo de educação aí que envolve tempo, principalmente para pessoas que nunca trabalharam com frameworks agéis, demora pra intronizar a filosofia do scrum dentro delas principalmente (entregar valor mais rápido) muitas pessoas estão acostumadas a entregar login e landing page antes de tudo. Ter uma parte do time que domina o framework e outra que não gera desconforto entre os membros.

Na minha experiência não consegui trabalhar mais do que com 5 pessoas.

É muito fácil estimar errado, backlogs iniciais via de regra são muito imprecisos.Mais aí não sei se seria desvantagem do framework maisfoi comum chegar em final de sprint sem um entregável e com erros de mesuração de toda a equipe.

Os papéis do P.O e do Scrum Master bem como as atividades de cada membro precisam ser muito bem definidas senão cada um fala uma coisa, sofri problemas de comunicação demais em alguns projetos por essa situação de "quem é que manda em quem".Senão você vai ver programador que faz o que dar na cabeça porque é mais fácil

Você precisa acompanhar sempre a documentação do que tá sendo feito, pra não chegar no meio-fim de um projeto sem saber como ele foi construido e sem ter como testar ele de uma forma eficaz com BDDS por exemplo.

Reunião diária nem sempre é possível mas é extremamente necessária se você não acompanha diariamente desanda semanalmente.

Retrospectiva pra lavar a roupa suja evite, geralmente tem sprint que o desgaste o stress dos membros tá la em cima e começa uma guerra do a culpa não foi minha, no scrum todos somos responsáveis pelo sucesso e pelo fracasso.

Se você tiver como Scrum Master vai ter que ter liderança senão vão te engolir, se tiver como P.O seja antecipado ao backlog e é bom que entenda um pouco de código ou de infra, senão se anteciparão a você bem é isso não tá na literatura mais acontece.

Os projetos que rodam Scrum estão focados no feedback do usuário. Por isso dizemos que o Scrum trata de problemas complexos. Se o seu problema é bem definido, se você sabe exatamente o que quer e como chegar lá o Scrum (ou qualquer método Agile) não é o mais indicado. Assim como um projeto tradicional os custos são controlados, a diferença fica que um sistema inicialmente proposto pode não ser o sistema entregue e tudo bem. Afinal, baseado nos feedbacks os rumos do sistema são guiados e com isso o usuário recebe mais valor. O desempenho da equipe e suas métricas é transparente para todos, inclusive um dos 3 pilares do Scrum é a transparência (Transparência, Inspeção e adaptação) e todos se beneficiam disso. Nesses anos trabalhando com projetos vi mais prejuízo nos feitos de forma tradicional do que com Agile de forma geral.