Principais desafios utilizando Scrum como framework

A maioria das empresas já aceitou o fato de que o modelo em cascata não funciona bem para desenvolvimento de software e na verdade já fizeram bastante esforço para ser mais agile, a maioria delas utiliza o Scrum como principal framework de trabalho.

O Scrum se popularizou resolvendo os desafios do modelo em cascata, mas agora já estamos trabalhando com Scrum tempo suficiente para saber que ele também possui muitos problemas.

Este artigo tem objetivo de compartilhar alguns desafios que encontrei aplicando o Scrum, isso não significa que o Scrum não funciona e nem que não devemos utilizá-lo ou nos basear em sua metodologia.

A ideia é compartilhar desafios e situações que o Scrum não ajuda e às vezes realmente nem tem a intenção de ajudar.

Balanço entre Production Quality e Sprint Timebox

Normalmente uma equipe Scrum trabalha com sprints pequenas, de 1 a 2 semanas, a justificativa é que quanto maior a sprint mais esforço de coordenação e planejamento é exigido, com uma sprint de 3 semanas começa a ficar difícil planejar e manter as coisas sem mudanças dentro da sprint.

Também sabemos que cada user story deve ter um business value, ou seja, um valor para o usuario final, criar um serviço backend normalmente não pode ser considerado uma user story já que essa atividade sozinha não traz valor para o negocio.

A maioria das user stories são compostas por mudanças no backend, frontend, base de dados, mudanças no código de infraestrutura, as vezes precisa de testes E2E, load tests, as vezes depende de um serviço externo (um parceiro ou um serviço de outra equipe interna), às vezes o desenvolvimento é em um serviço que a equipe não é owner. Podemos dizer que grande parte das user stories tem alguma complexidade técnica.

Quando falamos de production-quality queremos garantir que a funcionalidade tenha: validação de código estatica, provas unitarias, provas integradas e que seja escalável, tolerante a falhas, de confiança (execute o que ela foi desenhada para executar), de alta performance, segura, deploy com CI/CD e monitoração.

Além disso, não queremos entregar somente uma user story por sprint, queremos entregar algumas e queremos que as user stories sejam entregues em produção, aceitas e com métricas coletadas dentro da sprint. Queremos ver nosso burndown chart baixando a cada dia com user stories sendo terminadas a cada 3~4 dias.

É possível entregar software realmente de qualidade e com real valor de negócio em uma semana?

Quantas iterações de micro valores de negócio realmente precisamos para ter um produto de valor? Como ter uma visão de longo prazo com essa dinâmica?

Lidar com as mudanças dentro da sprint

Tenho certeza que muitos engenheiros e managers já trabalharam em uma empresa ou time onde a prioridade muda toda semana, todo dia e às vezes mais de uma vez por dia.

O pior é que às vezes realmente são mudanças simples que deveriam demorar pouco, por exemplo, uma cor de um botão ou um texto. Porém, quando essa mudança vem no meio da sprint ela exige um esforço extra de várias pessoas envolvidas:

• O product manager precisa garantir com os engenheiros que podemos realizar essa alteração fácil dentro da sprint.
• Os engenheiros que estão trabalhando na user story precisam se organizar.
• O product designer UX precisa atualizar a versão de mockups e validar com outros stakeholders.
• O QA precisa saber para quando for validar não se confundir.
• O product manager precisa comunicar áreas de negocio envolvidas: marketing, sales ou finanças etc.

O trabalho de coordenação tira o foco do time na sprint e tira o foco do product manager e product designer que provavelmente estão refinando user stories do próximo sprint.

A recomendação nesse caso é não permitir mudanças dentro da sprint, mas isso realmente ajuda?

Saber que estamos construindo algo que já não deveria ser assim desmotiva temporariamente o time, por isso muitos product managers e engenheiros têm a tendência de aceitar essas “pequenas mudanças” e subestimá-las.

Quando subestimamos é muito provável que vão existir outras atividades que não vão ser terminadas dentro da sprint, os famosos carry-over. Mas como justificar um carry-over com “apenas uma mudança de texto?” E o que acontece com o “welcome changes” no Scrum?

Estimar atividades com Story Points

Story Points é a metodologia utilizada para estimar atividades dentro da Sprint, seu principal objetivo é ajudar o time a conhecer sua capacidade e servir como base para futuras sprints. Essa metodologia não faz parte oficial do Scrum mas é frequentemente utilizado.

Apesar de ter um objetivo super claro muitas equipes ainda imaginam que os story points vão ser utilizado como um critério de avaliação de equipes, comparação de equipes ou avaliação de performance (a verdade também é que alguns managers fazem isso).

É muito difícil como manager remover essa ideia, ainda mais quando algumas perguntas são feitas, por exemplo:

• Porque não conseguimos entregar todos os story points que prometemos no começo da sprint?
• Essa sprint vamos fazer apenas 2 stories de 8 pontos?

Existem também algumas perguntas que começam a surgir por parte dos desenvolvedores:

• Vamos estimar bugs e tasks também?
• Se existe um carry over dentro da sprint vou estimar de novo para o próximo sprint? O que acontece com os pontos que a nós já desenvolvemos?
• Como backend eu preciso estimar as user stories do frontend?
• O QA e UX precisam estimar também?

Existe muitas dúvidas e receios com o story points e essas dúvidas acabam ganhando mais atenção do que o objetivo principal que é ajudar o time a conhecer sua capacidade.

Vejo muitos times abandonando o story points ou simplesmente estimando por estimar e no final eles já sabem informalmente quantas atividades podem executar durante 2 semanas.

Dar visibilidade do trabalho completo

Existe um enorme trabalho antes do desenvolvimento, teste e deploy:

Cagan, Marty. INSPIRED (Silicon Valley Product Group)

Esse trabalho envolve muitas vezes iterações com os engenheiros ou com alguns deles (as vezes chamados de tech leads) e esse trabalho deveria ser o mais importante, pois é ele que define o que vai ser construído.

Em um modelo scrum normalmente terminamos uma sprint e logo começamos outra de acordo com o backlog mantido pelo product manager, mas não existe muitos momentos dedicados pelo scrum onde o time participa desse backlog.

Muitos times fazem uma sessão de uma hora chamada refinamento onde discutem as tarefas que estão no backlog, mas normalmente essas tarefas já estão lá definidas. Não existe muita visibilidade do trabalho realizado para deixar as user stories ready to start e como os engenheiros podem ajudar nisso.

Onde podemos acompanhar o progresso das pendências para as atividades estarem definidas? Onde podemos discutir outras soluções? Como conciliar isso com a sprint que está sendo executada?

Definir o escopo da sprint

O escopo da sprint é definido no sprint planning de acordo com a prioridade do product manager e a capacidade do time, porém as vezes as atividades priorizadas são apenas de backend ou são apenas de frontend, nesse caso o que fazemos?

Precisamos atacar essas atividades porque são as mais prioritárias porém o time não tem o skill necessário para atacar esse conjunto de uma vez.

Isso também acontece quando algum engenheiro termina uma atividade e deseja começar a próxima priorizada, o engenheiro percebe que não tem skill suficiente para atacar essa atividade e o resto dos companheiros estão ocupados. Esse engenheiro também não é aconselhado a pegar atividade fora da sprint com risco de carry-over.

O Scrum pede para evitar adicionar atividades durante a sprint e atacar as mais prioritárias. O que podemos fazer nesse caso?

Podemos pensar que o time não tem o skill suficiente e devemos contratar novas pessoas ou formar novos skills, porém isso é muito comum hoje em dia com arquiteturas de microserviços, as vezes utilizando até 4 linguagens diferentes e inumeras tecnologias e ferramentas. Além disso o produto tem exigências diferente todo o tempo, hoje precisamos entregar mais features que exigem frontend porém amanhã precisamos atacar features que precisam de mais backend.

E isso também entra no problema de como contratar engenheiros mais juniors em time multidisciplinares com todas essas exigencias.

Conclusão

O Scrum é um framework que tem muitas vantagens comparado ao modelo de cascata porém também existem alguns problemas que geram tempo de discussão e as vezes não se chega a nenhuma conclusão satisfatória.

A ideia é refletir sobre esses desafios e pensar como podemos diminuir eles ou simplesmente lidar melhor com eles.

Será que nessa fase devemos abandonar a ideia do Scrum, testar outro framework, ou simplesmente adaptar algumas das “regras” impostas pelo framework?