Transformando Organizações com Definition of Done

É isso mesmo meu caro leitor, você não leu errado, estou me referindo aquela prática dos métodos ágeis frequentemente utilizada como um simples checklist técnico.

Aquele checklist que muitos times fazem questão de deixar visível em uma lousa, de enfatizar em um PPT de kickoff ou ainda de registrar em ferramentas como Jira e GitHub, mas que na primeira turbulência do projeto é esquecido, despriorizado e simplesmente ignorado, pois a nova prioridade é entregar o MVP (minimum viable product) a qualquer custo e, o que não ficar bem feito, vira dívida técnica para ser paga algum dia.

É, eu sei, você já viveu esse cenário inúmeras vezes. O que você, talvez, não tenha visto é como essa prática pode ser capaz de transformar toda uma organização. Mas calma que a gente já chega lá.

Antes, precisamos entender o que é esse tal de DoD, Definition of Done ou Definição de Pronto. Na verdade, não há muito segredo. Basicamente, ele é uma ferramenta de comunicação e o seu propósito é garantir que todos na equipe tenham o mesmo entendimento sobre o significado do termo pronto.

Parece simples, não? Tão simples que discuti-lo chega a parecer perda de tempo de tão óbvio que é, afinal, pronto é pronto! No entanto, sugiro que você faça um experimento: pergunte para pessoas de diferentes posições da sua equipe quando eles consideram que o seu trabalho está pronto. Provavelmente, você receberá respostas como:

  • Quando o software está desenvolvido e com testes de unidade passando;
  • Quando o software está homologado em ambiente de QA;
  • Quando o software está validado pelo cliente em ambiente de UAT;
  • Quando o software está em produção;
  • E por aí vai…

Agora imagine toda essa galera reunida com o cliente e ele solta a pergunta mágica: “Pessoal, o software está pronto?”. Será que vai dar confusão? Aliás, vamos além, vamos tentar entender o que a ausência do DoD pode causar.

Já vimos que consenso não existe, podemos deduzir também que haverá uma grande quebra de expectativa, pois a equipe não tem uma visão compartilhada. Se o time não sabe exatamente o que está construindo, o objetivo não está claro e é muito difícil conseguir comprometimento e engajamento quando não se tem metas claras. Agora me diz: qual a chance desse pessoal que está trabalhando com uma visão míope pensar em integração e colaboração?

Ficou claro a dimensão do impacto dessa prática? Mas talvez você ainda esteja se questionando: “Poxa André, eu não faço uso do DoD, mas o meu time está alinhado”. Sinto em lhe dizer: não é a mesma coisa. O DoD vai ser discutido na reunião de planejamento, durante o desenvolvimento de cada funcionalidade, durante a apresentação para o cliente, na retrospectiva. A equipe vai respirar DoD. Assuntos como integração, alinhamento de expectativa, comprometimento e colaboração serão parte do dia a dia da equipe e não mais um assunto tratado em reuniões trimestrais.

Quer dizer que se você adotar o DoD no próximo ciclo de entrega da sua equipe, você terá automaticamente consenso, gestão de expectativa, visão compartilhada, objetivos claros, comprometimento, engajamento, integração, colaboração e uma comunicação muito melhor? Claro que não, mas se você souber trabalhar a disciplina na equipe para que o DoD não seja abandonado, mesmo nos momentos críticos, coragem para resolver os problemas que o DoD vai jogar na sua cara e habilidade em negociação para conseguir aliados para as mudanças necessárias, você tem grandes chances.

Pois é, eu disse que o DoD é capaz de transformar uma organização, não disse em nenhum momento que era fácil e já que chegamos até aqui, vamos entender, de fato, o nível que essa prática pode ser alavancada para impactar muito mais que um simples projeto.

Sabe aquela história de que nós entregamos o que somos medidos? Sabe aquela outra história, na verdade, um dos 12 princípios do manifesto ágil que diz que software funcionando é a medida primária do progresso? Então! É por ela que vamos começar.

Nossa definição de pronto será: Software Funcionando!

Software funcionando não são screenshots colados em um PPT e exibidos na review com o cliente, muito menos uma API chamada pelo Postman com dado “mockado”. Software funcionando também não é software em ambiente de DEV, QA, ou UAT, caso contrário, o descreveríamos como: software em desenvolvimento, software em homologação ou software em validação pelo cliente, mas jamais como software funcionando. Software funcionando significa ambiente produtivo! Se ele vai estar disponível para o usuário final ou não, uma técnica como feature toogle pode resolver.

Possivelmente, você esteja pensando: “André, se eu começar o meu projeto com essa definição de pronto tão agressiva, eu vou ter que pensar em infraestrutura, segurança, pipelines de automação, testes e integração já na Sprint 1”. Exatamente, vai dizer que você nunca trabalhou em um projeto que deixou algum destes itens para depois e nunca mais “teve tempo” para corrigir? E outra, é muito mais simples implementar todas essas disciplinas no início do projeto, com as features iniciais ainda em desenvolvimento, do que deixar o legado crescer. Se você já teve que automatizar testes em sistemas legados, sabe muito bem do que estou falando.

A próxima coisa que você provavelmente pensará é: “Isso nunca vai funcionar na minha empresa”. Excelente reflexão! Meus parabéns por chegar até aqui. Finalmente, vamos falar sobre o título do artigo.

Vamos ver abaixo os problemas que esse DoD vai apresentar e eventuais soluções:

Problemas Soluções
Não consigo entregar software em produção em uma sprint, pois ao final do ciclo preciso enviar o pacote para o time de infraestrutura implantar. Vamos rever o processo da empresa, quebrar os silos e começar a implementar a cultura DevOps?
Não tenho profissionais capacitados para atender todos os projetos com a mesma qualidade e alguns projetos acabam sendo penalizados. Que tal implementar uma política de formação de talentos interna e investir na sua equipe?
Não consigo formar profissionais na velocidade que preciso para atender os projetos. Que tal buscar talentos no mercado?
Tenho dificuldade para contratar talentos. Vamos conversar com o RH e o Marketing para criar iniciativas para aumentar a atratividade da empresa?
Nós até encontramos bons profissionais, mas eles estão pedindo muito alto. Eles estão pedindo alto ou estão pedindo o justo devido a sua capacitação acima de média? Vamos contratá-los?
Mas eu não consigo pagar o que eles estão pedindo, a margem operacional não permite. Simples, vamos melhorar a margem. É possível aumentar o preço?
Não dá para aumentar o preço. Se eu fizer isso, meu cliente vai para o concorrente. O cliente vê valor na sua entrega? Será que você não está brigando em um oceano vermelho? Que tal oferecer um serviço diferenciado?
Nós estamos vendendo Squads padrão Spotify, mas ainda assim o cliente me trocaria se eu aumentasse o preço. Mas Squads não são uma alocação disfarçada? Que tal rever sua proposta de valor para algo que o cliente realmente valorize e você não tenha que brigar tanto por preço?
Nós até temos algumas ideias inovadoras, mas o meu time de vendas não está preparado para oferecer aos nossos clientes. Vamos rever a estratégia comercial, criar aceleradores de venda, material de apoio, formar os vendedores, eventualmente substituí-los?
Seu eu trocar os vendedores, eles vão levar a minha carteira de clientes Vamos discutir estratégias para os seus clientes serem fiéis a sua marca e a sua proposta de valor ao invés de serem fiéis aos vendedores?
E assim vai …

Entenderam aonde um DoD consegue chegar por efeito cascata? O DoD questiona o seu Processo, RH, o Marketing, o seu Preço, sua abordagem Comercial, a sua Proposta de Valor, a Estratégia e até a Politicagem que, infelizmente, sabemos que existe em toda empresa.

Eu trabalhei muitos anos com consultoria de ALM, implantando e revisando processos, contratando e formando equipes, criando e refinando ofertas de serviços, implantando ferramentas de automação e integração e frequentemente era contratado para resolver problemas de delivery, pois “os devs não estavam entregando”. Após algum tempo, ficava claro que o problema não era só em delivery, era algo que já começava errado em vendas, era agravado pela pressão no RH, impactado por processos burocráticos e o time de entrega era só o final da cadeia onde tudo estourava. E para explicar isso para os executivos? Mas o básico da agilidade com experimentos, inspeção e adaptação normalmente trazia bons resultados e as mudanças aconteciam.

Como eu citei acima, o DoD vai jogar os problemas na sua cara. Serão problemas de engenharia, de processos, de gestão, ou mesmo problemas organizacionais. E aí? Preparado para resolvê-los? Pronto para transformar a sua organização com o Definition of Done?

Abraços e até a próxima!
André Dias