A foto é tirada deste recurso .Seu concorrente ou parceiro já implementou o Scrum e está apresentando bons resultados e, é claro, você deseja obter o mesmo. Tenho más notícias para você: se usado incorretamente, o Scrum pode ser prejudicial.
Aqui, por exemplo, há uma lista de situações empiricamente identificadas nas quais o Scrum pode interferir no seu trabalho.
1. Você planeja combinar funções do gerenciamento clássico de projetos e Scrum
A equipe Scrum deve incluir 3 funções: Dono do produto, Equipe de desenvolvimento e Scrum-Master. No âmbito da composição proposta, a equipe permanece “plana”, ou seja, não temos subordinação direta entre os participantes. Essa equipe tem o poder de tomar todas as decisões independentemente sobre o produto que está sendo desenvolvido. Os papéis no Scrum descrevem claramente quem é responsável por quais problemas.
Agora imagine que você está planejando implementar o Scrum em uma equipe com gerenciamento de projetos clássico. Em seguida, a equipe Scrum começa a trabalhar com a participação do gerente de projetos. O que acontece neste caso? De fato, a PM simplesmente não tem nada para se ocupar de um projeto como esse. Quaisquer áreas de responsabilidade que transferimos para ele criam um desequilíbrio na equipe Scrum. Dar um orçamento à PM? Excelente, isto é, o PM não regula o valor e o conteúdo do produto, mas em caso de problemas, será ele quem o receberá na cabeça. Também daremos a ele trabalho com o valor do produto? Então será possível abolir o Dono do Produto. Mas não será Scrum.
Como as funções e tarefas de uma equipe mudam com a chegada do Scrum2. Você trabalha com requisitos extremamente claros
O Scrum foi criado para desenvolver produtos com um alto nível de incerteza. Funciona bem nos casos em que precisamos de lançamentos frequentes para obter feedback do mercado. Em uma situação em que temos requisitos detalhados que não deixam espaço para a criatividade ou quando não precisamos de feedback do cliente / usuário, o Scrum gasta apenas tempo da equipe em reuniões que não são de grande valor para o desenvolvimento de produtos.
Quando tudo já está claro, por que complicar?
3. Você trabalha com projetos de curta duração
A base do Scrum é uma abordagem empírica. Seu significado é que nos voltemos para a experiência existente da equipe para poder prever seus sucessos futuros. Se estivermos trabalhando em um projeto com duração de 2 meses, simplesmente não teremos tempo para acumular experiência suficiente para aplicá-lo para melhorar os processos de trabalho.
4. A equipe não deseja mudar a abordagem do trabalho
Essa é uma das principais limitações na implementação do Scrum. Implementar o Scrum como uma diretriz é quase sempre uma péssima idéia, primeiro é importante transmitir valores para a equipe, "vender a idéia". Mas mesmo depois disso, você não terá garantias de que as idéias do Scrum estarão próximas de todos os seus participantes. Aqueles que não aceitaram internamente a idéia de Scrum e valores ágeis podem começar a destruir o sistema por dentro, "balançar o barco".
Existem vários cenários possíveis. Primeiro: Scrum não cria raízes. Isso pode acontecer se a maioria da equipe for contra a mudança. A equipe organizará uma revolta desde o início ou fará de tudo para tornar a nova abordagem ineficaz.
A segunda opção: um ou mais participantes não vão querer trabalhar no novo sistema. Normalmente, essas situações resultam em um participante "problemático" deixando a equipe por conta própria.
Alterar Estamos aguardando mudanças.
A foto é tirada deste recurso .5. Você não está pronto para usar todas as práticas necessárias do Scrum
Para essa abordagem, eles até cunharam o termo especial ScrumBut. É quando trabalhamos no Scrum, mas ... Não temos retrospectivas. Mas temos uma reunião diária 2 vezes por semana. Mas abandonamos o papel do mestre Scrum. E muitos outros "buts" semelhantes.
A estrutura Scrum fornece uma resposta simples e clara para todas essas situações. Sim, você pode adicionar práticas adicionais ao processo Scrum da sua equipe (por exemplo, práticas do XP). Mas não, você não pode recusar nenhum elemento do Scrum, pois esse não será o Scrum.
Todas as funções, eventos e artefatos do Scrum estão intimamente ligados e visam atingir um objetivo comum - fornecer aos clientes com eficiência um produto de valor máximo. A rejeição de qualquer parte do Scrum nos afasta desse objetivo.
6. Você não está pronto para recrutar funcionários para trabalhar em um produto em período integral
Você já viu um gráfico da dependência do tempo de trabalho produtivo com o número de projetos em que está trabalhando simultaneamente? Caso contrário, assista.
Esse diagrama em si é o melhor argumento a favor do envolvimento de funcionários no trabalho em um projeto de cada vez. Mas se ela não o convencer, subtraia o tempo restante em um projeto ao trabalhar com vários outros, o tempo que será gasto em reuniões obrigatórias (reuniões diárias, retro, planejamento, revisão de sprint). Um membro da equipe terá muito pouco tempo para trabalhar nas tarefas. Você precisa disso?
Há exceções a esta regra. Por exemplo, o Scrum-Master pode trabalhar com várias equipes ao mesmo tempo. Mas para outros participantes é necessário garantir o máximo envolvimento apenas neste projeto.
7. Você não tem suporte de gerenciamento
Assim como queremos que os funcionários adotem uma nova abordagem para o trabalho, também precisamos do apoio da gerência. É importante entender que a introdução do Scrum, especialmente em
estágios iniciais podem exigir algum investimento. Por exemplo, a contratação de um coach Agile ou um Scrum Master profissional, treinando o Product Owner, conduzindo o treinamento Scrum para funcionários e muito mais. O líder deve estar pronto para apoiar financeiramente o novo empreendimento.
Mas isso não é a coisa mais importante. É muito mais importante que a administração da empresa compartilhe os valores do Scrum e esteja pronta para mudar a cultura da empresa. Por exemplo, um líder precisa estar preparado para o fato de ter que dar novos poderes como parte de novos papéis na equipe. Nem todo mundo está pronto para isso, portanto, "vender uma idéia" nesse nível também pode ser necessário.
Esta lista de critérios não pretende ser exaustiva; você pode complementá-la ou compartilhar seus casos nos comentários.