Como muitos conflitos clássicos e sem fim, o debate sobre como as equipes de desenvolvimento devem se organizar e se autogovernar continua. Atualmente, quase parece que existem mais críticos do que fãs de Scrum. As três reclamações mais comuns são:

1. O processo pode ser o centro das atenções sobre o trabalho.
2. Pode ser facilmente confundido com microgerenciamento com outro nome.
3. O stand-up diário pode ser sentido como um encontro onde é necessário justificar a sua existência.

Em outros casos, as funções do Scrum não são representadas adequadamente. Às vezes, o product owner quer muitas coisas dentro de um sprint ou quer mudar as prioridades no meio do sprint - um Scrum Master que está obsessivamente focado em manter a velocidade e adotar cada nova cerimônia Scrum que aprenderem. Depois de algum tempo com o framework, uma pergunta comum parece surgir: “Somos nós ou a metodologia?”

As falsas esperanças do Scrum

Embora existam inúmeras disfunções como as descritas acima, uma causa raiz simples para a maioria delas é que o Scrum não foi projetado para resolver problemas subjacentes dentro de uma organização meramente seguindo o processo. Deixar de reconhecer isso pode colocar as novas equipes em risco assim que começam.

Falsa esperança # 1: Scrum faz as equipes trabalharem mais rápido

Scrum usa uma terminologia que parece para quem está de fora, como se fosse acelerar o processo sem adicionar recursos adicionais. É fácil se prender à terminologia como um nova equipe para Scrum (por exemplo, o que é um Scrum master? Qual é a diferença entre um product owner e um gerente de produto? O que são story points e como são atribuídos?)

Mais preocupante é que muitos veem termos como velocidade e sprints e pensam 'velocidade'. No entanto, o propósito de qualquer Ágil metodologia, Scrum incluído, é entregar um produto acabado. Eventualmente, conforme sua equipe se torna mais competente com Scrum, você será capaz de entregar novas funcionalidades mais rapidamente. No entanto, a velocidade não é necessariamente o objetivo principal. Essa distinção deve ser articulada dentro de sua equipe Scrum e também quando você está construindo uma consciência dentro de sua empresa para apoiar a metodologia Scrum.

Você não está vendendo velocidade; você está vendendo a conclusão.

Falsa esperança # 2: A adesão estrita ao Scrum resolverá os problemas culturais da empresa

Todo mundo tem estilos de trabalho diferentes. Algumas pessoas gostam de reuniões. Outros usam frases como 'trabalhe muito, divirta-se muito'. É essencial reconhecer que, qualquer que seja o estilo de trabalho que sua empresa valorize, você está aceitando suas vantagens e desvantagens. Uma empresa que valoriza as reuniões provavelmente terá dificuldades com a postura diária. Equipes agressivas e voltadas para a velocidade terão problemas com o aumento do escopo dentro de um sprint.

Às vezes, é fácil perder de vista o quadro geral, especialmente para equipes formadas recentemente. O que importa é entregar um produto acabado, em vez de seguir até a última parte do processo. Em vez de culpar a metodologia, sempre procure maneiras de refinar seu estilo de trabalho para atingir seus objetivos.

Falsa esperança # 3: contribuidores críticos podem enviar seus delegados para reuniões

Depois de iniciar a metodologia, é crucial que a equipe original participe, e não delegue. Se há uma reclamação quase universal que vejo dos desenvolvedores, é que os Scrum masters e proprietários do produto não estavam disponíveis quando necessário e seus delegados não tinham poderes. Ninguém gosta de vir a uma reunião esperando uma decisão apenas para ouvir que a pessoa que pode tomar a decisão não está disponível.

Delegar pode ser uma prática comum, mas no Scrum, você também deve capacitar os participantes.

Falsa esperança # 4: os levantamentos diários irão forçar todos a serem mais focados

A reunião diária em pé não deve se concentrar exclusivamente no que todos fizeram nas últimas 24 horas. É muito mais importante dar prioridade à superfície de bloqueios de estradas ou novas abordagens para resolver um problema.

Scrum requer que certas funções, particularmente o Scrum master, sejam assertivas, mas não opressoras. É importante para o Scrum master criar um ambiente positivo que leve a produtos concluídos.

Falsa esperança # 5: Teremos sucesso na primeira tentativa

Scrum envolve suposições, pensamento dedutivo e cometer erros. As pessoas raramente acertam na primeira tentativa. Scrum é iterativo em todos os aspectos: não apenas em como você chega a um produto acabado, mas também em como você governa e opera o processo. Scrum é projetado para ter uma barreira baixa de entrada para as equipes adotarem, mas também requer um compromisso de iterar e melhorar continuamente a participação no framework.

Como consertar um processo Scrum quebrado

Scrum é resistente à falácia do custo irrecuperável. A natureza iterativa do Scrum cria oportunidades para adaptar ou descartar processos ineficazes. Considere algumas das sugestões a seguir se o seu processo Scrum não for tão eficaz quanto você esperava que fosse.

Refine suas expectativas

Seja reduzindo o tempo de chegada ao mercado, criando produtos atraentes ou ajudando as equipes a colaborar, o sucesso exige comprometimento e tempo. Para novas equipes, um marco razoável a ser alcançado é se, após cada sprint, você poderia introduzir código funcional e testável em seu ambiente de produção.

Equipes avançadas podem medir o sucesso por sua capacidade de criar, testar e implantar sob demanda. Você é capaz de instrumentar e quantificar as reações do usuário aos novos recursos? A organização mais ampla está pronta para dar suporte às mudanças que a equipe está fazendo no produto?

Capacite seus participantes

É importante orientar os membros da equipe offline em termos de como eles podem aumentar seu valor para a equipe. Se eles estão sendo solicitados a tomar decisões, aumente sua confiança coaching sobre quando e como incluir outros membros da equipe. Os gerentes precisam estar prontos para eliminar obstáculos e apoiar a equipe quando necessário.

Resolver problemas proativamente

Scrum não foi projetado para dar uma transformação em sua empresa. Se você deixou os problemas sem solução, é mais do que provável que esses problemas surjam em seu processo de desenvolvimento de produto. Scrum masters podem introduzir frameworks projetados para criar uma maneira positiva para os membros da equipe estruturarem seu feedback para reduzir a sensação de conflito.

Um exemplo é a estrutura “Eu desejo, me pergunto, e se”. Durante as discussões da equipe ou retrospectivas , um membro da equipe pode dar feedback abrindo sua declaração com uma destas três frases. Por exemplo, eles podem dizer: “Eu gostaria que as reuniões stand-up pudessem dar mais foco aos bloqueios de estradas de que preciso estar ciente naquele dia”. Você também pode usar o seu próprio abridor, como “Eu gosto ...”.

Outra solução de feedback estruturado que pode ser útil durante as reuniões é o método Triage from Holocracy, criado por Brian Robertson e usado por empresas como a Zappos. Por exemplo, os participantes constroem uma agenda de “tensões” para discutir. Cada participante descreve seu problema dizendo “Estou com uma tensão” e, em seguida, relaciona as pessoas e os recursos de que precisam para resolvê-lo. Ao encorajar os participantes a abordar diretamente as questões como “tensões”, a Holocracia permite que os participantes se comuniquem livremente sem criar uma atmosfera de conflito.

Use retrospectivas para resolver problemas e iterar no processo

Em muitas empresas, a retrospectiva não recebe a devida atenção. Isso se deve principalmente ao medo que muitos têm de que a retrospectiva seja um local para velhas discussões, conflitos e queixas. É vital para a equipe desenvolver regras básicas que reflitam os valores da equipe e a cultura da empresa.

Tão importante é a necessidade de evitar investimentos em processos estáticos. O que funcionou uma vez pode não funcionar para sempre. Muitas equipes lutam com a rotatividade de participantes. Isso é comum em muitas empresas, pois os participantes são transferidos para outras equipes, são promovidos ou deixam a empresa completamente. Conforme a composição da equipe evolui, é importante não permanecer comprometido com o fato de que tudo é iterativo no Scrum. Erros ocorrerão, mas, felizmente, eles durarão pouco enquanto você itera.

Scrum funciona melhor quando os diretores estão presentes

Para fazer parte da equipe, você tem que se comprometer a estar presente e disponível. O desenvolvimento de produtos é provavelmente o processo mais crucial que sua empresa pode empreender para melhorar seu crescimento a longo prazo. Portanto, é importante que o processo Scrum, como caminho principal para o desenvolvimento de novos produtos, receba a atenção que merece. Em muitos ambientes, a equipe de desenvolvedores geralmente trabalha desligada das decisões e discussões que direcionam os objetivos da empresa. Scrum é diferente. Scrum é onde as decisões, direção e desenvolvimento vêm juntos como um único processo. É muito importante enviar delegados ou deixar de fora membros da equipe das reuniões que acontecem dentro da metodologia Scrum.

Resumo: Você pode consertar um processo Scrum quebrado

Devido à sua natureza iterativa, o Scrum ajuda a proteger o negócio de ir muito longe no caminho e se comprometer com o que pode acabar sendo uma má ideia ou um processo mal implementado. Aderir a este princípio pode ajudar a livrar-se dos erros do passado e melhorar iterativamente o processo Scrum.

É importante focar nos indivíduos e na equipe que você tem. Os membros da equipe mudam. Todos os projetos são diferentes. A adesão estrita a um processo nem sempre produz os melhores resultados. O que você investe nos membros de sua equipe fora do processo é tão importante quanto a forma como você se comporta dentro do processo.

Scrum pode ser flexível. Se algo não estiver funcionando, considere incorporar elementos de outras estruturas dentro e fora do Agile. Identifique e adote estilos estruturados de comunicação para discussões de confronto.

Scrum é benéfico para o ROI de longo prazo, permitindo que as equipes construam produtos completos em resposta às mudanças nas necessidades do cliente. Scrum é provavelmente a melhor metodologia para evitar que você se comprometa demais com ideias ruins, enquanto dá às grandes ideias algum espaço para se desenvolverem mais.

Compreender o básico

O que é Scrum em termos simples?

Scrum é uma estrutura de desenvolvimento de produto. As equipes lançam incrementos de produtos a cada duas semanas e buscam feedback do cliente. Essa abordagem minimiza o desperdício e cria oportunidades para os clientes fornecerem feedback desde o início.

Como funciona a metodologia Scrum?

Uma equipe Scrum entrega incrementos de produtos de trabalho em sprints de duas semanas. Cada sprint tem uma sessão de planejamento, durante a qual a equipe decide quanto trabalho será capaz de realizar em duas semanas. O proprietário do produto prioriza o trabalho com base na pesquisa do usuário e do mercado.

Por que usamos Scrum?

Scrum é usado como uma alternativa ao desenvolvimento em Cachoeira, onde um cliente somente faz interface com um produto ao final do ciclo de desenvolvimento. No Scrum, o cliente está constantemente testando incrementos de novos produtos e fornecendo feedback para a equipe de desenvolvimento. Essa abordagem minimiza o desperdício e maximiza o valor do cliente.

Qual é a diferença entre Agile e Scrum?

Scrum é um framework dentro da metodologia Agile. Agile descreve os princípios básicos de como o software deve ser desenvolvido. Scrum oferece um sistema concreto de como implementar princípios Agile.