A foto acima foi tirada durante uma das minhas viagens de escalada pra a Patagônia argentina, no Cerro Frey. Um local mágico em que escaladores vão provar suas capacidades, ou iniciar a longa jornada para metas ainda maiores. Medo e Coragem sempre fizeram parte do esporte que pratico, ainda que o primeiro seja o mais presente no meu caso – já que ainda sofro um pouco com ataques de Acrofobia. Aprendi a lidar com isso, e a usar o pensamento racional e sistêmico para sobrepor-se ao desespero. E assim consigo até escalar de verdade. Por incrível que pareça.
Em comparação a colocar a sua vida em risco, baseado em sua própria capacidade, entregar software parece fácil. Seguindo a série de posts que o Giovanni iniciou a respeito da última atualização do Scrum Guide, vamos falar sobre Coragem.
Já trabalhei em vários tipos de projetos, e uma experiência marcante que tive, foi atuar numa empresa que fazia sistemas para indústria, operando grandes máquinas. Toda vez que nossa equipe fazia um release para produção, enfrentávamos a mesma discussão: será que dessa vez a máquina vai operar com erro e gerar prejuízo pro cliente? Aqui, um bug de sistema poderia causar centenas de milhares de reais de prejuízo: alterando as peças produzidas, desperdiçando material ou até mesmo machucando um operário: o risco era real.
Obviamente, esse era um ambiente de muito medo. Ainda mais pelo fato de não existir nenhuma camada de segurança para esse código: build era feito manualmente, testes eram manuais e não extensivos, código era antigo, legado e cheio de problemas. Como esperar uma postura ativa do desenvolvimento em melhorar o código se não existia nenhuma confiança? Escalar uma montanha sem cordas até é possível, mas a queda pode ser fatal…
Quando eXtreme Programming foi criado, Kent Beck listou 4 valores mais importantes para a condução dos projetos de software: comunicação, simplicidade, feedback, coragem – respeito, o quinto valor, foi adicionado mais adiante no tempo. Minha visão sobre agilidade é totalmente influenciada por essa época, e coragem talvez seja o meu valor favorito.
Direto do site ExtremeProgramming.org, temos a definição:
Nós diremos a verdade sobre progresso e estimativas. Não documentamos desculpas para as falhas porque planejamos para o sucesso. Não tememos nada porque ninguém trabalha sozinho. Nos adaptaremos às mudanças a qualquer momento que elas acontecerem.
No Scrum Guide, coragem vem da capacidade do time de dizer não e trabalhar naquilo que realmente importa dentro do projeto. Para isso, a equipe se vale das diversas práticas e cerimônias do scrum, permitindo grande confiança para agir.
Como time, coragem significa estar pronto para todos os desafios que surgem, além de ter a confiança de que suas decisões terão resultados esperados.
Mudar o mundo de gestão de projetos e entrega de software exige coragem: de apresentar novas idéias, de defender seus valores e de seguir com o que acredita ser certo.
Tecnicamente, práticas como pair programming, código coletivo, TDD, Integração contínua, etc podem dar ao time a coragem para colocar a mão em qualquer do código, ainda que nunca tenham trabalhado numa parte específica de um problema. Atacar de frente código ruim e mal escrito, sem arrumar desculpas para não melhorar o próprio trabalho. A coragem que vem da confiança e segurança das práticas e ferramentais permitirá ao time inclusive questionar e remover features não utilizadas ou mesmo código inútil.
Quantas vezes você disse não para uma requisição do cliente? Essa talvez seja a principal lição que tenho ensinado há anos às pessoas com quem trabalho: dizer não é um ato de coragem! Você precisa fazer isso algumas vezes para seus clientes. Ambientes ágeis, devido a todo o contexto de participação e confiança, permitem que as pessoas falem o que pensam, independentemente dos cargos e papéis que as pessoas executam.
Neste ambiente de transformação organizacional que o mercado ágil se tornou nos últimos anos, essa retomada do foco em valores que a Scrum.org está promovendo é um movimento interessante. Independentemente das inúmeras práticas de escala que a comunidade tem falado hoje, foram os valores ágeis que nos trouxeram até aqui. No meu entendimento, serão ainda Valores bem definidos que nos levarão para a próxima etapa da gestão em desenvolvimento de software.
