No Agile Brasil de 2017 apresentei a sessão Despencando do Olimpo: As difíceis lições que aprendi ao tentar fazer a Jornada Ágil na trilha É Caindo que se Aprende a Levantar. Escrevo este artigo resumindo alguns dos desafios que enfrentei ao tornar meu time ágil. Minha ideia é expor os erros que cometi para ajudar as pessoas que estão fazendo a Transformação Ágil a não cair nas mesmas roubadas.
Experimente ouvir este artigo! Dê o play!
O Olimpo
Antes de mergulhar nas lições propriamente ditas, gostaria de explicar a metáfora da Queda do Olimpo.
Segundo alguns textos sobre a Mitologia Grega [1] [2] [3], após Zeus resgatar seus irmãos de Cronos, eles passaram a habitar a terra (Gaia). Todavia, como eram seres extremamente poderosos, capazes de influenciar diretamente ou indiretamente cada aspecto da vida dos humanos, solicitaram a Hefesto (deus artesão) que construísse no topo do maior monte da Grécia o palácio dos deuses. Dali, os doze primordiais julgavam a terra.
Ao longo da história, esses deuses foram se achando cada vez mais e mais importantes e a cada dia menos acessíveis aos humanos. Só que os humanos eram a razão de existência deles e, com o passar do tempo e desdém dos deuses, a humanidade se esqueceu dos olímpicos e adotaram outras divindades.
O Monte Olimpo está vazio, pois sem necessidade de existência, os antigos deuses “despencaram”.
Experiências
Durante minha vida profissional utilizei diversos formatos de organização de trabalho para desenvolver software. Quando comecei, utilizávamos o tradicional Modelo Cascata descrito no artigo de Royce em 1970 [4]. Analistas, programadores e testadores ficavam em salas separadas e tudo era lento e burocrático.
Em duas ocasiões, participei de times de implantação de RUP (Rational Unified Process). Numa dessas ocasiões, ainda partimos para a certificação do modelo de maturidade CMMI (Capability Maturity Model Integration ou Modelo Integrado de Maturidade e de Capacidade) que foi posteriormente trocado pelo MPS-BR (Melhoria de Processo do Software Brasileiro) por causa dos custos de certificação.
Depois de muito tempo, troquei de emprego e fui para um time de desenvolvimento pequeno, com 12 desenvolvedores. Na época não tínhamos nenhum modelo específico. Cada um tinha a sua forma de trabalhar. Brincávamos que era o Modelo Nike: Just do it! (Apenas faça!).
Não funcionou. Começávamos muitas coisas, entregávamos pouco ou nenhum valor para a organização. Decidimos mudar para a abordagem PMBOK com todos os documentos e processos sugeridos e adaptados. Infelizmente, também não tivemos muito sucesso nessa empreitada, pois produzíamos diversos documentos e acordos, porém pouco software. Os projetos tinham duração longa, a lista de demandas ultrapassava 20 produtos. Interrupções eram constantes.
Ascensão
Em 2009, começamos a adotar o Scrum. Todavia, como apenas duas pessoas haviam sido capacitadas, o nosso Scrum era um tanto “Scrumlhambado”. No final daquele ano, todos os desenvolvedores e gestores do time fizeram o curso com o Rodrigo de Toledo (velha guarda, ainda não existia a K21 :-).
Com o passar do tempo, a coisa passou a funcionar. Passamos a entregar produto de 15 em 15 dias e nossos clientes ficavam muito satisfeitos com o resultado. Gostavam tanto que passaram a nos procurar não só para desenvolver novas ideias como também para apresentarmos e ajudarmos na adoção do Scrum como método de trabalho deles. Éramos chamados para todo o tipo de projeto, quer envolvesse software ou não.
Nos sentíamos tão fortes que resolvemos apresentar nossos cases em eventos, palestras e artigos no Brasil e até mesmo nos EUA. Ganhamos até alguns prêmios com isso. Havíamos chegado no topo do Olimpo.
Despencando
Nos sentíamos invencíveis e com isso deixamos de prestar atenção em alguns sinais importantes:
- Nossos clientes começaram a “importar” e comprar soluções que eram relacionadas ao negócio principal da organização enquanto nós desenvolvíamos produtos de apoio.
- As implantações de Métodos Ágeis que promovíamos em outras unidades não vingavam e morriam logo após nossa saída.
- Reuniões com tom de: “Não foi isso que eu pedi” e “a partir de agora, atas assinadas” passaram a ser constantes.
Com o tempo, vimos que não estávamos com aquela bola toda. Éramos vistos com desconfiança, o clima de nós contra eles imperava e sofríamos com as piadinhas dos clientes. Havíamos despencado do Olimpo, estávamos no Tártaro, Reino de Hades. Também conhecido como Submundo.
Causa raiz
Era hora de respirar fundo e encontrar culpados lá fora. Não faça isso! Embora seja fácil, não é uma boa ideia e não vai ajudar em nada. É o momento de encontrar a causa raiz dos problemas.
Utilizamos a dinâmica da Causa Raiz (Para entender seu funcionamento, veja o artigo disponível neste link). Chegamos à conclusão que a origem dos nossos problemas eram as seguintes:
Comunicação Fria
Quando trabalhamos com Desenvolvimento Ágil entregamos produto (software funcionando) o tempo todo. Tínhamos um produto que na primeira semana de entrega já tínhamos algumas dezenas de usuários. Esses eram os principais, pois forneceriam os requisitos e feedbacks importantes para evolução do produto.
Entretanto, na segunda semana, já tínhamos algumas centenas de usuários. Tentávamos escutar a todos e ficou impossível parar para ouvir e entender as dificuldades dos nossos principais clientes (aqueles da primeira semana). A solução foi fazer a comunicação através de E-mail e Bug Tracker.
Péssima escolha. A comunicação escrita não transmite algumas informações que são extremamente relevantes como expressões faciais, humor e ironia. Não permite a troca rápida de informações e dificulta muito o debate. Informações ficavam truncadas. Alguns de nossos clientes eram muito sucintos e não entendíamos o que eles queriam. Outros eram extremamente detalhistas. Dava vontade de responder os e-mails com o Tl; dr (Too long; didn’t read. Muito longo; não li).
Documentação Cover My Ass
Lembra da sua infância? Lembra quando você errava uma resposta na escola e recebia um zero do professor sem muitas explicações e uma bronca em casa? Na faculdade ou pós-graduação algo mudou? Normalmente não. Somos ensinados que erros são coisas ruins. Logo devemos tentar prever e evitar todos.
Se não funciona bem em ambientes simples, como uma avaliação individual, imagina na complexidade de projetos envolvendo grupos e grupos de pessoas. A melhor solução é: responsabilizar alguém pelo erro desde que não sejamos nós (claro que não).
Nós sabíamos que documentação excessiva e desnecessária tornava tudo improdutivo, mas decidimos fazer ata de reunião para tudo. A paranoia era tão grande que brincávamos de fazê-las até mesmo caso encontrássemos nossos clientes no cafezinho ou no elevador. A pergunta que ficou foi: Por que retornamos à documentação excessiva?
A Metáfora do Marcos Garrido parece ajudar. Segundo ele, o Ágil é como se fosse um cubinho de gelo que você está segurando na mão. Se você não o resfriar de tempo em tempo, ele voltará para o estado líquido (a forma de pensar que você foi ensinado durante toda a vida).
Excesso de Feedbacks Positivos
Ter feedback positivos é bom. Todavia eles não trazem reflexões sobre como você pode melhorar o seu trabalho (ver mais sobre esse tema no artigo O Bom Feedback). Em certa ocasião, enquanto desempenhava o papel de Product Owner, perguntei a um dos nossos clientes internos quais eram os problemas que ele via em um dos nossos produtos. Esse cliente era especial já que havia sido ele que fornecera a maior quantidade de informações e feedbacks durante a construção do mesmo. A resposta foi: “Nenhum! Esse é um dos melhores sistemas que já vi. Vamos inclusive exportá-lo…”.
Perguntei para ele se poderíamos colocar no site externo um questionário com uma única pergunta: Qual problema você teve para fazer XYZ (principal funcionalidade do sistema)?
Com base nas respostas, tivemos que refazer toda a interface do sistema, mudar fluxos e regras de negócio, remover pet features, trocar palavras, foram muitas mudanças. Os feedbacks devem ser capazes de levar você a uma situação melhor do que a atual.
Time de 1ª Guerra
Peter Senge no livro A 5ª Disciplina fala que na nova economia devemos investir e valorizar as pessoas pelo que elas têm do pescoço para cima e não do pescoço para baixo.
Em determinado momento nosso time de desenvolvimento passou a ser um time tarefeiro (implementar o que os clientes queriam sem questionar o propósito daquilo). Entregávamos tudo o que pediam, mas o pedido nem sempre estava certo. Como disse um dos membros durante a dinâmica da Causa Raiz: “Nosso produto foi um fiasco. Fomos para o fundo do mar, mas com muita elegância” (referência ao Titanic).
O time de 1ª Guerra não tem estratégia, apenas executa. Pega uma missão e sai correndo e gritando no meio do campo de batalha com o objetivo de conquistar a próxima trincheira. Com sorte, alguém sobrevive à saraivada de balas.
Product Owner Dividido
O trabalho do Product Owner é imenso. Conversar com stakeholders, obter feedbacks, acompanhar métricas, propor novas funcionalidades, avaliar o contexto do produto, corrigir cursos de solução, etc.
Tentamos ter um Product Owner (P.O.) para 2 ou 3 produtos e tivemos dois resultados. Na primeira, o P.O. adotou um dos produtos e o outro morreu de fome (não havia histórias de usuário para o time de desenvolvimento implementar). Na segunda, o P.O. tentou trabalhar em todos os produtos e todos morreram de fome.
Também tentamos ter pessoas com múltiplos papéis: Product Owner e Gerente; Product Owner e Desenvolvedor. Em ambos os casos, as pessoas escolheram seus papéis favoritos (ou aquele que elas eram de fato cobrados) e deixaram o produto para o segundo plano.
Soluções
Para encontrarmos a solução voltamos ao início de tudo. O manifesto Ágil [5].
Comunicação Fria
“O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.”
“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.”
Para os clientes principais, telefone passou a ser o meio de comunicação mínimo. Melhor se puder conversar face a face com ele.
Documentação Cover My Ass
“Colaboração com o cliente mais que negociação de contratos”
Questione se você tem realmente poder de fogo para usar a temida ata de reunião assinada ou o documento de escopo do projeto, ou seja, lá qual for a bengala assinada que você está se apoiando. Se for contra um diretor ou alguém mais próximo dele (profissionalmente ou pessoalmente) seu poder pode ser nulo e até mesmo negativo.
A solução foi remover toda documentação desnecessária. Manter apenas aquelas que ajudassem em alguma questão ou que fossem obrigatórias pelas regras da empresa.
Excesso de Feedbacks positivos
“Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.”
Buscar novos stakeholders e mudar a forma como perguntávamos. Descobrir qual valor deveríamos agregar e para quem.
Time de 1ª Guerra
“Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto”.
“Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho”.
Deixar muito claro o propósito do produto e incluir o time na tomada de decisões.
PO dividido
“Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.”
O PO tem muito trabalho para fazer: Conversar com clientes, participar de reuniões, avaliar métricas do negócio, fazer benchmarking, conversar com o time de desenvolvimento, alinhar expectativas entre os stakeholders, fatiar, priorizar e descartar itens do backlog. É bastante trabalho para uma pessoa. Por isso, é importante que o PO faça apenas o papel de PO e reduzir a quantidade de produtos que ele toma conta. Se possível para um único produto.
Conclusão
Com essas ações, conseguimos sair do Reino de Hades e retornamos à superfície da terra. Não foi fácil, mas aprendemos com nossos erros e demos mais alguns passos para nos tornarmos um time verdadeiramente ágil.
Ações tomadas pelo time de desenvolvimento para retomar o desenvolvimento ágil de produtos.
Gostou desse artigo. Aprenda muito mais sobre os temas abordados nos nossos treinamentos de Product Owner, Scrum Master e Desenvolvedor Ágil.
Também há outros artigos relacionados a esse tema no nosso blog:
- Retrospectiva da Causa Raiz
- O Bom Feedback
- Documentação Abrangente X Comunicação Eficaz
- O trabalho de FDP do Product Owner
