Os 12 princípios do manifesto ágil e dinâmicas

Agilidade, no contexto de desenvolvimento de software, é algo difícil de definir e de mensurar. No entanto, é unânime que sua formalização e, provavelmente suas principais características, estão documentadas no Manifesto Ágil, o documento criado e assinado em 2001 por 17 das maiores autoridades em desenvolvimento de software mundial à época.

Embora existam correntes modernas tentando redefinir o que é agilidade ou até desacreditá-lo enquanto ideal a ser buscado, ainda acredito humildemente que tem muita sabedoria em suas palavras e que ainda é um caminho muito válido a ser perseguido por times de desenvolvimento.

No artigo de hoje, gostaria de dar uma breve visão sobre cada um dos 12 princípios do software ágil, parte fundamental do Manifesto, e dar algumas ideias de dinâmicas envolvendo os mesmos, para ajudar a educar e melhorar times em torno do mesmo. No final do artigo você pode baixar um baralho com os mesmos, para ajudar nas dinâmicas.

#1 – Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

Gerar valor para o cliente é o primeiro princípio e não é à toa. Substitua a palavra software pelo produto do seu trabalho (independente do setor) e você tem o clássico posicionamento de “cliente no centro da empresa”. Todo time deveria se focar em entregar valor continuamente (e não apenas uma vez no final do projeto) e de maneira adiantada (o que gera mais valor, primeiro).

#2 – Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

Se tem uma expressão que pode ser usada como sinônimo para agilidade é “reagir a mudanças”. O calcanhar de Aquiles do waterfall sempre foi justamente sua inflexibilidade: uma vez fechado escopo, prazo e custo (os três pilares clássicos da gestão de projeto), é só ladeira abaixo. Times ágeis tentam manter um lead time baixo e ciclos curtos de entregas (sprints, por exemplo) justamente para poder aceitar mudanças de requisitos de maneira mais fácil, com menos atrito.

#3 – Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

Em uma era de DevOps e Entrega Contínua (CD) esse princípio pode soar ultrapassado se levado ao pé da letra. No entanto, mude o trecho “software funcionando” por “valor ao cliente” e novamente nota-se que não “chegamos lá”. Apesar da engenharia de software moderna lhe permitir entregar software todos os dias e até várias vezes no mesmo dia, entregar valor pro cliente em ciclos curtos não é assim tão simples e é algo que os times devem estar sempre atentos.

#4 – Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

Esse princípio originou uma série de papéis novos em times ágeis como o Product Owner no Scrum, o Service Request Manager no Kanban e o Cliente no Extreme Programming. Desde muito tempo notou-se que um dos maiores gaps na entrega dos projetos era o popular “telefone sem fio” e que uma maneira de atacar este problema diretamente era alocando um profissional de negócio dentro do time ágil, para trabalhar requisitos e dúvidas diariamente com os desenvolvedores.

#5 – Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

Esse é um dos mantras do Management 3.0, popular framework de gestão ágil. O criador do método alega que não se deve fazer gestão de pessoas, mas gestão do entorno destas pessoas, garantindo um bom ambiente, suporte e motivação, para que as pessoas consigam se auto-organizar e realizar o trabalho necessário. Um apelo contra o microgerenciamento, uma prática que sempre destruiu mais valor do que gerou.

#6 – O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

Tido como um princípio polêmico em uma era de home office, times distribuídos e trabalho remoto, parece insanidade forçar todo mundo a conversar cara a cara, certo? Errado. Pelo menos no meu entendimento. Lembra do primeiro valor do Manifesto? Indivíduos e interações entre eles mais que processos e ferramentas! Incentivar e perseguir conversas diretas e o mais próximas possível de “conversa cara a cara” sempre será algo eficiente e sadio. E sim, você pode usar Skype pra isso se a outra pessoa está há kilômetros de distância…

#7 – Software funcional é a medida primária de progresso.

Novamente, troque “software funcional” por “entrega de valor” e você tem um princípio à prova de métricas de vaidade. A principal métrica de sucesso de qualquer time deve ser o quanto de valor ele entrega para a empresa. Afinal, de nada adianta um lead time baixo se o time entrega rapidamente software inútil pro cliente, não é mesmo? Um mau condutor em um carro veloz ainda será um mau condutor. Seja criativo, existem muitas maneiras de mensurar valor.

#8 – Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Esse princípio vem lá do pensamento Lean, onde é chamado de Muri (sobrecarga). Para garantir a entrega contínua de valor, o time deve ser capaz de trabalhar constantemente em um ritmo saudável. Eventuais picos de trabalho acontecem nas melhores empresas, mas salas de guerra todos os dias são uma exclusividade das piores.

#9 – Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

Esse princípio é contra-intuitivo para alguns gerentes mas é uma máxima do desenvolvimento de software e até mesmo do pensamento Lean: faça uma coisa bem feita na primeira vez, e não será necessário trabalhar de novo nesse mesmo item tão cedo. Débito técnico, ferramental ruim, ausência de pipeline automatizado e os famigerados bugs acabam com a capacidade, velocidade e moral de times técnicos. Não deixe isso acontecer.

#10 – Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

Você já ouviu falar no Princípio de Pareto? O famoso 80/20 é aplicado a muitas coisas e em software não poderia ser diferente. 20% das features de um software geram 80% do seu valor para o usuário e/ou são usados em 80% das vezes. Então porque perder tempo fazendo 100% do software? Ou melhor, porque você primeiro não faz os 20% que importam?

#11 – As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

Dê uma missão clara e com propósito a um time de especialistas e deixe-os trabalhar. Bons times técnicos buscam a excelência por natureza e você não precisa dizê-los como fazer o seu trabalho.  Obviamente, quanto mais distante de um time maduro você tiver, mais próximo você vai ter de gerenciá-los e isso vale pra tudo, não apenas arquitetura, requisito e design.

#12 – Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Melhoria contínua é um processo, um método e se você quer ter resultados reais, precisa se dedicar a ela. Como dito no Toyota Kata, todo processo tende a se tornar ineficiente com o passar do tempo e temos de buscar a melhoria contínua se quisermos nos manter competitivos no mercado.

Dinâmicas com os princípios ágeis

Existem vários dinâmicas possíveis de serem realizadas usando estes princípios, seja no formato de baralho que estou disponibilizando logo abaixo, seja apenas escrito em post its mesmo. Em momentos como Retrospectivas, treinamentos e team buildings, você pode trazer esse assunto à tona para estimular a autocrítica, a reflexão e o amadurecimento enquanto time ágil.

Abaixo, três dinâmicas envolvendo o baralho com os 12 princípios.

Agile Clock

Cole os 12 princípios na parede, formando um relógio do princípio #1 ao #12.

Se for apenas um time que estiver participando da dinâmica, divida-o em duplas ou se for muito pequeno, deixe os indivíduos separados. Se for mais de um time, forme times menores mesclando os indivíduos.

Para cada princípio, o facilitador lê em voz alta e instiga as pessoas (em time, ou individualmente, dependendo da configuração) a tentarem resumir o princípio a uma palavra, no máximo duas. Para que consigam chegar nessa síntese, o time terá um tempo para discutir o princípio e definir sua palavra.

Faz-se isso para cada princípio. Ao término, o próximo passo é, dentre as palavras dos diferentes times para o mesmo princípio, deve ser escolhida apenas uma para ser colocada no relógio, em cima ou ao lado do respectivo princípio. Par se chegar na palavra final de cada princípio, os times terão de debater com uma timebox fixa controlada pelo facilitador.

Note que não existe uma resposta certa pois o entendimento dos princípios pode variar conforme o contexto dos times. No entanto, cabe ao facilitador presente instigar e provocar, sem nunca expor suas opiniões de maneira afirmativa, mas sempre interrogativa, para não se sobressair aos demais.

Dinâmica vista durante o PACC do Andy Barbosa.

Prós e Contras

Esta é uma outra dinâmica bem interessante, por ser contra intuitiva ter uma utilidade interessante especialmente com gestores. Divida o grupo da dinâmica em dois (grupo PRÓ e grupo CONTRA), ou faça divisões por princípios, dependendo do volume de pessoas.

Crie um painel em 2 linhas e 12 colunas (ou o contrário) colocando nas linhas a legenda PRÓS e CONTRAS e nas colunas pode colar cada carta dos princípios (baralho para download abaixo).

O grupo PRÓ deve elaborar em post its bons motivos para seguirmos os princípios ágeis. Coisas boas que eles trazem, o lado positivo das coisas.

O grupo CONTRA deve elaborar em post its razões para não seguirmos os princípios ágeis. Coisas que eles podem atrapalhar, riscos que eles podem trazer, o lado negativo das coisas.

Durante as apresentações, intercale um princípio de cada vez, pedindo que as pessoas apresentem os prós e contras e discutam brevemente sobre cada um para espalhar as percepções. Não é um trabalho de convencimento, mas de compreensão e empatia.

Os objetivos dessa dinâmica são dois: primeiro, entender que sim, existem riscos e que os princípios não são bala de prata e segundo, que para cada item identificado pelo grupo CONTRAS, podemos definir ações para mitigá-los.

Um terceiro e oculto objetivo é o agilista identificar o mindset das pessoas do grupo (em especial os gestores) para identificar principalmente os seus medos e temores quanto ao ágil em seus times. O resultado do grupo CONTRAS é muito mais importante neste caso e é ali que você vai ter insumos de como vender e aplicar o ágil corretamente nessa empresa.

Dinâmica vista durante o PACC do Andy Barbosa.

Quadrante Mágico

Essa dinâmica eu aprendi no blog do mestre Jorge Audy. Ele teve a ideia de usar o conceito de quadrante mágico do Gartner para refletir com o time sobre sua adoção e entendimento dos princípios ágeis.

Divida um painel em quatro quadrantes, traçando uma cruz no centro dele. Da esquerda para direita, de cima para baixo, nomeie cada quadrante com: Não Acredito mas Faço, Acredito e Faço, Não Acredito e Não Faço, Acredito e Não Faço.

Peça que um membro do grupo pegue uma carta de princípio aleatória e leia em voz alta, dando o seu entendimento sobre o princípio. Na sequência, incite uma discussão para decidir se esse princípio é acreditado pelo grupo e se o grupo o faz na prática, para posicionar a carta nos quadrantes. Obviamente o quadrante mágico é o topo direito (Acredito e Faço), mas não deixe nada ser colocado lá se não for consenso de que aquele princípio de fato é acreditado e aplicado.

No final, o time pode definir ações para alguns itens que não ficaram no quadrante mágico (Acredito e Faço), sendo a escolha baseada nas prioridades que o agilista tem para o time (por exemplo, vamos nos focar em fazê-los acreditar antes de fazer? Ou fazer para depois acreditar?)

Curtiu o artigo? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!