Aviso ao leitor: esse artigo (e sobretudo sua conclusão) foram escritos num período profissional em que eu estava 100% comprado na cultura corporativa da Stone, não atoa foi publicado inicialmente no tech blog da empresa. Ainda que eu não me arrependa do meu posicionamento nessa época, hoje certamente eu escreveria um relato muito menos emocionado.
Trabalhei em agência a vida inteira e se tem uma coisa que quem trabalhou em agência digital sabe é que, salvo raras exceções, tudo é pra ontem.
Nesse mercado é difícil projetos durarem mais de três meses e é três vezes mais difícil medir algum resultado depois que o projeto foi para a rua. Você tem que matar um trabalho rápido e pegar outro mais rápido, senão a conta não fecha. Linha de produção total.
Durante esses anos o waterfall perdurou na minha vida profissional e o sonho era trabalhar com produto. Minha experiência com Scrum e agilidade se resumia a ter lido o livro do Jeff Sutherland e ter esbarrado com o manifesto uma vez ou outra.
Quando surgiu a oportunidade de trabalhar como líder técnico de um produto ágil, o cenário era de muito interesse, pouca teoria, zero prática.
“Agora [o time] está começando a estruturar, está melhorando muito”.
O amigo que me indicou para a vaga que ocupo hoje me mandou essa frase — ou algo similar — quando contei que tinham confirmado minha contratação.
Entrei na mesma época que a Scrum Master e a Product Owner.
O prognóstico desse novo desafio era realmente bem motivador, uma nova versão do produto se consolidando, posições chave para agilidade sendo recrutadas, treinamentos, desafios motivadores no horizonte e tudo mais.
Photo by Jake Ingle on Unsplash
Chegou o momento e minhas primeiras reuniões soavam muito parecidas com conceitos que eu já tinha na cabeça. Você tem alguns projetos, esses projetos quebrados em tarefas, cada um do time pega um pedaço e no final da sprint a gente junta tudo e manda pra rua. Trabalhar com agilidade é fácil!
Rapaz, eu estava errado.
Agilidade, do jeito certo, é bem difícil.
Cá entre nós, agilidade só me parecia fácil porque estávamos fazendo muita coisa errada. O que acontece com frequência quando você tem foco (quer muito fazer), mas ainda não tem direção (não sabe ao certo o que fazer).
Olhando para trás, vejo que essa falta de direção pode ser atribuída a quatro questões fundamentais nesse primeiro momento:
- O time não havia sido convencido das razões da companhia em prol da virada ágil e, mais importante, o que isso trazia de bom para a equipe no final do dia.
- O produto que desenvolvemos, por natureza, tem peculiaridades que não foram tratadas diretamente em treinamento sobre processos e papéis na agilidade.
- Não estava claro para o time o caráter definitivo da virada para agilidade, sobretudo em relação a adoção do Scrum, o que deixava o time em uma situação de incerteza sobre o modelo.
- O Scrum exige uma sincronia organizacional, principalmente em relação a impedimentos e projetos envolvendo mais de um time, que não existia.
A consequência disso foi, naturalmente, a resistência do time em “comprar” a agilidade.
A sensação era de todo ônus e nenhum bônus, dezenas de regras novas para aprender e seguir, e ainda assim, menor produtividade comparado ao período anterior, pré-agilidade.
No entanto, olhando com mais calma e bom senso, essa sensação era exatamente isso, uma sensação. Um sentimento, uma emoção rápida (e muito justa) de se sentir em reação a uma mudança radical na maneira de fazer as coisas.
É claro que a produtividade iria ser menor! Qualquer um que fez obra em casa entende a regra “primeiro piora, para depois melhorar”. Agilidade, como qualquer outra habilidade, tem uma curva de aprendizado até você ficar fera.
E se no primeiro mês da virada para agilidade suas métricas são muito boas, é sinal de que você provavelmente mediu errado.
Voltando ao time, com o tempo (e com esforço) assimilamos esse fato e a medida que o time foi avançando nos conceitos de agilidade, os resultados foram aparecendo discretamente.
Maior controle sobre demandas, menos tarefas com dono, melhor rastreabilidade e acompanhamento, entre outras…
Mas ainda não era o suficiente. Estávamos melhores nesse jogo, mais dispostos a jogar (e vencer), mas ainda não estávamos lá.
Coisas que fazíamos errado:
- Não criávamos user stories, tudo era tarefa e bola pra frente
- Misturávamos assuntos nas cerimônias, perdendo horas em discussão técnica na hora errada
- Negligenciávamos o board, ignorando a importância das métricas na agilidade e a disciplina necessária para cultivar dados fiéis
- Não deixávamos constantemente claros os papéis de cada um no time
Isso entre outras.
Agora, uma coisa muito importante em começar a fazer o certo é perceber o que você está fazendo de errado.
Inevitavelmente o time iria chegar por si só na solução desses problemas, mas isso tomaria muito mais tempo e energia, e causaria mais desperdício. Sem falar que esbarraríamos constantemente no “Dark Scrum” até chegarmos nesse lugar ideal…
Entra a figura do Agile Coach #
E a diferença que um olhar de fora do time pode fazer
Photo by Kevin Maillefer on Unsplash
Vamos lá, até a chegada do nosso amigo Agile Coach nós estávamos operando o Scrum com as seguintes ferramentas:
- Treinamentos realizados junto com outros times
- Um conjunto de regras para seguir à risca
- Uma boa dose de força de vontade e dedicação, ainda que as vezes a contragosto
Nós conhecíamos os nossos erros, mas faltava uma figura de consulta rápida, dentro do nosso contexto, para resolver esses problemas imediatamente assim que eles surgiam.
O “o que” fazer para melhorar era claro, o “como” que era o problema.
Já no primeiro mês com Agile Coach presente, participando ativamente das cerimônias e tirando dúvidas nos corredores, nós começamos a pegar a aceleração necessária. Agilidade parecia cada vez mais como uma habilidade útil a ser desenvolvida, ao invés de só mais um novo conjunto de regras a serem seguidas “porque sim”.
E, para além disso, o diferencial hoje mais claro da presença de um Agile Coach foi não somente ter alguém que conhece muito de agilidade, mas alguém que conhece de como implementar agilidade.
Essa aproximação e didatismo foram e continuam sendo fundamentais.
Onde estamos hoje #
Melhores que ontem, ainda melhores amanhã
Photo by Max Winkler on Unsplash
O cenário de operação da agilidade hoje é mais confiável e estável. Seguimos na luta constante de medir a velocidade do time de maneira confiável e, ainda que não estejamos operando perfeitamente, já resolvemos questões fundamentais relacionadas ao produto e a agilidade.
O time segue as cerimônias pontualmente e o aperfeiçoamento do foco na temática da cerimônia é outra luta constante — me incluo em todos os cenários de melhoria, e nesse de modo ainda mais particular — mas seguimos fazendo progresso.
Nosso maturity level, ferramenta que acompanha a adoção de práticas ágeis do time, segue sendo aperfeiçoado e funciona muito bem como uma meta a ser alcançada pelo time.
No último mês operamos sem um Product Owner e, ainda que tenhamos sobrevivido e aprendido muito sobre agilidade, nossas entregas foram afetadas sem essa posição chave no time.
Plannings sem PO exigem uma flexão grande dos músculos de business do time e estamos aliviados de que essa situação já foi resolvida.
Minha visão da agilidade até agora #
Princípios, pessoas, produto, processo. Nessa ordem.
Photo by Alan Gibworth on Unsplash
Falo com propriedade que meus últimos meses foram um verdadeiro “crash course” de agilidade que, no bom português, significa “aprender na porrada”. Não tem curso no mercado que me ensinaria o tanto que aprendi em tão pouco tempo.
A virada ágil foi e vem sendo incrivelmente desafiadora. Como eu disse lá em cima, agilidade, do jeito certo, é difícil.
A questão é entender essa dificuldade. Agilidade, na minha visão, só é difícil por conta de toda minha experiência profissional ter sido baseada em modelos lineares até então. Eu não estava habituado a forma de pensar ágil.
Minha cabeça ainda seguia o modelo waterfall, que na minha visão era mais fácil e intuitivo. É só pegar um monte de requisitos, dividir o projeto em etapas lineares e fazer uma entrega monolítica no final.
Mais ou menos como comprar todos os tijolos, argamassa e cimento para construir uma casa.
O problema é que enquanto você trabalha nessa entrega monolítica o seu concorrente já colocou quatro releases na rua e testou diversas hipóteses de negócio.
E provavelmente os requisitos mudaram algumas vezes nesse meio tempo…
O objetivo de trabalhar com agilidade é justamente mitigar esses problemas através de processo, estrutura, disciplina e comprometimento do time. Isso tudo para avançar a medida primária de progresso: software funcionando.
E eu não sei você, mas se tem uma coisa que me motiva demais é a satisfação de ver o trabalho do meu time resolvendo problemas reais de pessoas reais.
E se trabalhar com agilidade faz isso acontecer de maneira mais rápida, com menos desperdício, controlada e mais segura…
Pode mandar ver!
Agilidade pode até ser difícil, mas meu time é o impossível.