Photo by Patrick Perkins on Unsplash

O “Scrum, só que não”

Como fazer o Scrum falhar

Artigo traduzido e adaptado de Sjoerd Nijland. Veja o original neste link.

Ao longo da minha carreira como Scrum Master, deparei-me com diversas situações em que, por alguma limitação do ambiente, por falta de conhecimento do time ou devido à cultura da empresa ou do cliente, um time não pôde, de fato, praticar o framework Scrum e chegou a modificá-lo, a fim de adequar à realidade do cenário.

Por conta disso, alguns times acabam deturpando o Scrum, fazendo um “go-horse gourmetizado” ou um “waterfall em pele de Ágil”, e não se dão conta de que muitas empresas estão perdendo a credibilidade no framework, afirmando que ele não funciona. Não é que ele não funcione: o problema é tentar fazer o Scrum caber em um contexto no qual, por qualquer motivo, ele não é bem-vindo.

Como tenho percebido o impacto que esse pensamento de “Scrum não funciona” tem tomado uma grande proporção, principalmente, em setores acostumados à uma gestão de projetos mais tradicional e como sei que a causa disso é o fato deles não estarem, realmente, utilizando o Scrum, resolvi traduzir, com algumas adaptações, o artigo do Agilista holandês Sjoerd Nijland, que representa bem essa questão. Segue o resultado, abaixo:

Em primeiro lugar, gostaria de dedicar este post a todos os corajosos Scrum Masters, que lutam contra as disfunções organizacionais todos os dias. É preciso muita coragem para correr o risco de chatear alguém, rompendo o status quo, sendo a bola de demolição, tendo que abrir mentalidades rígidas, sendo radicalmente transparentes e expondo políticas tóxicas e jogos de poder. Estamos em uma jornada para criar ambientes melhores e mais saudáveis não apenas para nós mesmos, mas também para nosso legado.

Alguns de vocês podem estar operando em uma organização que quer apenas o “Ágil de Batom”, ou em empresas que contrataram o Scrum Master apenas para se certificar de que eles realmente não querem o Scrum. Ainda há toneladas de anti-padrões a serem observados.

Muitas vezes você vai se sentir incompreendido. Pior ainda: seus esforços vão ser mal interpretados ou distorcidos. Você encontrará aqueles que estão determinados a provar que você está errado, eles criarão versões “Frankenstein” de suas iniciativas bem-intencionadas. Mas, ao contrário de outros, você não se acomoda. Você não vai se comprometer com o que discorda. Certo?

No entanto, compromissos são uma segunda natureza obscura para o Scrum. Cada jornada do Scrum envolve arrastar a organização para sua própria lama.

“Os papéis, eventos, artefatos e regras do Scrum são imutáveis ​​e, embora implementar apenas partes do Scrum seja possível, o resultado não é o Scrum. O Scrum existe apenas na sua totalidade e funciona bem como um recipiente para outras técnicas, metodologias e práticas. ”- Scrum Guide.

A maioria das organizações vai chamar a jornada em direção ao Scrum de “Scrum” e isso, acidentalmente, fará com que o Scrum seja associado a toda essa lama. “Nós fazemos Scrum, MAS…”

Então comecei a colecionar alguns desses grandes “mas”. Prepare-se para um discurso retórico e definitivo. Um breve aviso: alguns deles podem ser propensos a debates acalorados; por favor, não leve isso muito a sério. Há muitas interpretações diferentes e depende muito do contexto. Vamos a eles!

Sua organização faz Scrum, mas…

Scrum em geral

• “Scrum não é um objetivo em si.”
• “O Scrum é apenas para desenvolvedores, não para os membros da equipe de gestão.”
• “O Ágil nos diz ‘indivíduos e interações sobre processos e ferramentas’ e Scrum é um processo, certo?”

Práticas de Waterfall

Então você faz Scrum, mas não entrega um incremento de trabalho a cada Sprint?

• “O cliente quer um grande projeto inicial (BDUF — Big Design Up Front).”
• “Estamos dando um primeiro passo que envolve apenas design.”
• “As estórias devem conter projetos funcionais e técnicos.”
• “Já planejamos as próximas seis Sprints.”
• “Nosso Backlog é um documento de requisitos.”
• “Nosso Backlog é priorizado e/ou organizado usando os tamanhos MoSCoW e T-Shirt.”
• “Pontos de estória? Sprints? Backlog? Nossos clientes não vão entender isso. Vamos apenas fazer contratos fixos de escopo, tempo e hora.”
• “Sou um [Product Owner/Project manager/Coach Ágil/Scrum Master/Desenvolvedor de Negócios/Gerente de Contas/Gerente de Programas/Gerente de Portfólio/Gerente de Equipe] (escolha todos os que se aplicam).”
• “Vamos fazer uma [Design Sprint, Sprint 0, Esteira de Arquitetura, Pré-Sprint, Sprint de Descoberta, Sprint de Planejamento].”

Não multidisciplinar

• “A equipe de desenvolvimento consiste apenas de desenvolvedores de software.”
• “Nossa equipe de [QA/Design/UX/Arquitetura/TI] (ou insira qualquer outra função ou área aqui) […]”
• “Eu sou um [designer/desenvolvedor], então só vou [projetar / desenvolver].”
• “[Johnny] vai trabalhar na estória [X] sozinho, porque ele pode.”
• “Dois desenvolvedores em uma [tarefa/estória]? É muito ineficiente.”

Nossa gerência não concorda com a auto-organização

• “Não podemos confiar que a equipe tem autoridade para se auto-organizar ainda.”
• “Não envolvemos a equipe em fazer ofertas iniciais aos clientes.”
• “Já dissemos/prometemos ao cliente que…”
• “O Product Manager é o Product Owner… mas o cliente também… e todos os seus stakeholders. Na verdade, quem entrar em contato com nossa gerência terá prioridade. ”
• “Quando o Product Owner recusou [X], o cliente/stakeholder pediu à gerência para informar ao Product Owner que […]”
• “[Jenny] é a Product Owner, mas ela precisa obter uma aprovação da gerência antes de poder […]”
• “Nós [gestão/PO] vamos colocar [pedido urgente x] no Sprint Backlog”.
• “Os desenvolvedores não devem interagir com [cliente/usuário/stakeholder], somente o [Scrum Master/Product Owner]”.
• “Vamos simplesmente dizer à equipe para […]”
• “A gerência diz ao Time B para fazer o que funciona para o Time A.”
• “Priorizaremos nosso trabalho de acordo com quais partes interessadas estão mais irritadas/chateadas/frustradas/com a probabilidade de entrar em contato com a gerência.”
• “Estimar com a equipe é ineficiente.”

A Rotina

• “Nós só nos falamos nas reuniões diárias de Scrum”.
• “Eventos Scrum demoram muito…”
• “A Sprint não pode começar porque [X] não está claro.”
• “A Sprint vai demorar mais porque [Y] não foi feito.”
• “Nossa Sprint é de seis semanas de duração.”
• “A Sprint não pode ser iniciada porque nem todos os itens da Sprint anterior foram concluídos.”
• “A equipe não cumpriu seu compromisso, por isso precisa fazer horas extras.”
• “A Review não pode começar porque a equipe ainda não terminou o trabalho.”
• “Coaching/treinamento deve ser feito durante os eventos Scrum… ou que tal as sessões de pizza tarde da noite?”
• “Use o tempo da Retrospectiva da Sprint para corrigir problema/tarefa.”
• “A estimativa é muito alta porque: é só copiar e colar, certo? Você já fez algo parecido antes, né?”
• “Eu preciso de mais informações antes de começar.”
• “A pessoa [x] não está aqui, então não é necessário ter [inserir evento do Scrum aqui]”
• “Devemos ter uma reunião sobre […]”

As Métricas

• “A velocidade da equipe não está aumentando, então eles não estão melhorando.”
• “Vamos adicionar mais capacidade para aumentar a velocidade e atender à demanda do cliente.”
• “Não podemos esperar pelas estimativas da equipe: o cliente quer valores hoje.”
• “Estimativas são prazos.”
• “As estimativas são feitas apenas pelo [Arquiteto de Soluções/Analista de Negócios/Desenvolvedor Sênior].”
• “Não temos tempo para fazer estimativas.”
• “Nosso mapa de burn-down parece mais um gráfico de burn-up.”
• “Nosso burn-down só queima na sexta-feira.”
• “Nós usamos compromissos em vez de previsões.”
• “Story points são horas, certo?”
• “Quantas horas é um story point?”

Resistindo à Mudança

• “Sempre fizemos [X] dessa maneira…”
• “Não devemos tentar mudar [a maneira atual de trabalhar] agora.”
• “Eu só vou fazer as tarefas que foram definidas na ferramenta [X] de acordo com o formato [Y].”
• “Eu sou [sênior], então eu não tenho que fazer [tarefas superficiais].”
• “Não podemos começar (trabalhar na estória/Sprint) porque não temos todos os detalhes.”

Ferramental

• “Não precisamos de quadros físicos/de Scrum porque usamos Jira.”
• “Nós usamos Jira, portanto, somos ágeis.”
• “As equipes devem usar Jira.”
• “Jira.” (sim, este merece o seu próprio “mas”)
• “Podemos usar o Skype para que não precisemos realmente ficar juntos”.
• “O cliente relata um ticket na ferramenta de descoberta [A], com links para a ferramenta [B], que inclui o anexo da ferramenta [C], que nós vamos [copiar/sincronizar] para a ferramenta [D] na qual refinamos antes de passar para a ferramenta das equipes de Scrum [E] e os desenvolvedores, então, criam tarefas na ferramenta [F], mas também rastreiam na parede de post-it.”

Práticas

• “Todos nós falamos sobre testes automatizados, mas nunca aplicamos. Também não fazemos testes manuais porque deveriam ser automatizados.”
• “Qual destes catorze objetivos da Sprint deveríamos fazer primeiro?”
• “Isso é apenas 15 minutos de trabalho, então não precisa passar pelo DoD todo, certo?”
• “Aprendizagem/treinamento?! Faça isso no seu tempo livre.”
• “Não fazemos nenhuma documentação porque o Manifesto Ágil diz isso.”
• “Não temos tempo para trabalhar com débitos técnicos.”

Spikes, Estórias, Definições de Feito

• “Uma estória é a mesma coisa que o item do Backlog do Produto, certo?”
• [Johnny] acrescentou critérios: “a conversão aumenta em [insira a porcentagem aleatoriamente composta aqui].”
• [Jimmy] adicionou: “etc”.
• [Jenny] adicionou: “Veja o Powerpoint anexo”.
• [Johan] acrescentou critérios: “Tem que estar em produção esta noite!”
• [Jacob] adicionou: DoD: “O [Product Owner/usuário] gosta disso”.
• [Jessica] adicionou: DoD: “Não há bugs/defeitos”.
• [Joanna] adicionou a estória do usuário: “Como Product Owner, quero um botão verde de compra para que a conversão aumente”.
• [Jill] adicionou a estória do usuário: “Como departamento de Marketing, nós queremos SEO para termos mais exposição”.
• [Jaimie] adicionou a estória do usuário: “Como departamento de Marketing, precisamos disparar o e-mail-marketing esta tarde”.
• [Jason] adicionou bug: “No sistema está faltando [uma feature nunca antes mencionada], é óbvio que isso deveria ter sido parte de [X], por favor, quero isso pronto até [amanhã]!”
• [Jessie] adicionou a estória do usuário: “Oh, só mais uma coisa […]”

Ufa! Assim como o autor (Sjoerd Nijland), você que está lendo também deve ter outros exemplos de frases de “Scrum, só que não”, certo? Que tal postá-los aqui nos comentários? Até a próxima!