Dentre alguns dos princípios temos:
“Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de software de valor.”
Este único princípio já levou a várias discussões há anos. Em particular leia o artigo Our Highest Priority e Why Satisfy de Customer?.
Em particular eu gosto de pensar como Eliyahu Goldratt onde ele diz – claro que simplificadamente – que a prioridade de qualquer empresa é ganhar dinheiro. Agora calma aos anti-capitalistas e populistas de plantão :-) Não estamos falando em “ganhar dinheiro em prejuízo das pessoas, dos clientes e da sociedade” ou coisa parecida.
A prioridade não é criar inovação, não é criar produtos, não é gerar empregos, é ganhar dinheiro. E os meios para isso podem ser, criar inovação, criar produtos, gerar empregos, por exemplo. O que quero dizer é que confundimos os meios com os objetivos.
“Entregar rápido e continuamente” é muito importante de se ter na cabeça. Muitas vezes isso não é possível, por exemplo, se você depende de fornecedores ou outros fatores externos. Mas deixe-me pegar outros princípios relacionados a este primeiro:
“Entregue frequentemente software que funciona, de algumas semanas a alguns meses, com preferência para um período curto.”
O tempo nunca é fixo, porque todo profissional sabe que não dá para prever o futuro. Entregar valor rápido é um princípio, não uma regra. Significa que faremos tudo que for possível para tentar entregar algo que funciona, com qualidade, o mais breve possível. Para isso tentaremos retirar impedimentos, melhorar processos, otimizar procedimentos, melhorar a comunicação e tudo mais que for necessário para entregar alguma coisa. É um lembrete para todo agilista em todos os momentos que as entregas começarem a demorar mais que o normal.
“Software que funciona é a medida primária de progresso.”
A mesma coisa dita com outras palavras: software que não está entregue é software que não serve para nada. Um agilista deve se sentir mal de estar trabalhando meses num software que ninguém está usando. Softwares são diferentes, às vezes leva 1 dia inteiro para descobrir uma solução que dá para resolver em 1 linha de código. Às vezes dá para escrever 100 linhas em 1 hora. É o velho dilema de produtividade que a indústria já tentou resolver com várias técnicas falidas como LOC (linhas de código), Pontos de Função e outras bobagens.
Não consigo deixar de imaginar que foi o Martin Fowler um dos que devem ter sugerido esse princípio, especialmente por causa do seu artigo Cannot Measure Productivity. Software não se mede em função de produtividade, ele se mede em função de valor. E quem define o valor a ser atingido via desenvolvimento de software é o cliente/empresa. Se o software desenvolvido não trás valor, isso não é culpa do software, mas culpa da definição de valor do software. Uma ferramenta, por si só, não tem valor nenhum.
Por isso que eu disse que LOC e pontos de função não servem para nada. Posso ter uma equipe que entrega 10 mil pontos de função por Sprint. Não significa nada se o que foi pedido para se desenvolvido não trás nenhum valor para o cliente. Essa é uma das funções de um Product Owner: garantir que o que está sendo priorizado para desenvolvimento é algo que efetivamente trará valor, seja no curto prazo, seja no longo prazo, dependendo da visão de futuro que ele tenha. Se o PO não tem visão, não tem estratégia e não tem direção clara, ele terá exatamente isso como resultado: muito software e pouco valor, e a culpa disso nunca é da equipe técnica, é da falta de visão e, consequentemente, problema do PO e/ou da empresa.
E falando em POs, não podemos deixar de falar de stakeholders em geral, os interessados no valor a ser gerado pelo projeto:
“Pessoas de negócio e os desenvolvedores devem trabalhar juntos diariamente durante o projeto.”
Pessoalmente eu detestaria burocratas todos os dias num ambiente de desenvolvimento :-) Mas cinismos à parte este é outro lembrete de que quem está interessado no valor gerado por um projeto é quem deve procurar a equipe e ver se não precisam de nada. Um stakeholder que não se dirige à equipe técnica demonstra que não está interessado no resultado a ser gerado. E não estamos falando em fazer reuniões diárias com a equipe, mas de trocar idéias rapidamente, coisa de 5 ou 10 minutos por dia seriam suficientes. E não é necessário nenhum ritual como um Daily Scrum para isso. Um stakeholder interessado sai de sua cadeira e se dirige às equipes. Um stakeholder desinteressado fica na sua cadeira e espera as coisas acontecerem sozinhas. Adivinhe qual dos dois é mais eficiente? E se o stakeholder, que deveria ser o mais interessado, demonstra desinteresse no que se está produzindo, porque alguém das equipes deveria se mostrar interessado?
Equipes são um reflexo da organização da empresa. Se as camadas mais altas são desorganizadas, indecisas, incomunicáveis e irresponsáveis, as equipes serão da mesma forma. O que são equipes se não sub-sistemas, cópias do sistema complexo adaptativo mais chamado “empresa”?
Uma empresa pode contratar 100 Linus Torvalds, 100 Guido Von Rossum, 100 Jonh Resig, mas não espere que eles sozinhos saiam com iPods, com iPhones e outros grandes produtos que venderão milhões. A Apple funciona porque – eu especulo – um Steve Jobs sai da sua cadeira e se envolve no dia a dia das equipes de pesquisa e desenvolvimento pessoalmente, mesmo sendo o CEO.
Falando dessa forma parece que um lado se isenta da responsabilidade do outro. É claro que não, a melhor forma de trabalho é colaborativa, porém a responsabilidade de chegar com as melhores soluções tecnológicas, de qualidade técnica e eficiência, a equipe técnica é quem tem que se virar. Por outro lado os stakeholders são os responsáveis em fazer estudos mercadológicos, pesquisas de marketing, visão de produtos. Um lado pode e deve colaborar com o outro, mas infelizmente todo mundo não pode igualmente fazer tudo. Dado que os stakeholders tragam a visão, a equipe técnica vai fazer o possível para cumprir essa visão. Mas a visão não é autoritária, da mesma forma como algumas decisões tecnológicas não devem ser. A crítica fica porque normalmente as ordens vêm de uma direção só, sem discussão, e a equipe técnica, mesmo performando seu trabalho corretamente, pode estar seguindo uma direção errada e no final a crítica se volta a ela mesma pelo fracasso de uma visão que sequer foi discutida.
“A maneira mais eficiente e efetiva de transmitir informação para uma equipe de desenvolvimento é via conversas cara-a-cara.”
Para mim esse é um corolário do princípio anterior. Esqueçam sistemas automatizados de comunicação, sistemas de fluxo de informações, ou qualquer dessas baboseiras. Todo mundo já viu filmes dos anos 80 e 90 ridicularizando os “memorandos”, que era uma técnica de espalhar informações. Até hoje as pessoas ainda tentam algo parecido com memorandos, só que agora são planilhas eletrônicas, e-mails, wikis, etc. O mais importante é: sente-se lado a lado com a pessoa que vai lhe entregar valor e diga claramente quais são as expectativas, o que mudou, o que se manteve e sai do caminho. Se um stakeholder não tem capacidade de conversar ao vivo com as equipes, novamente demonstra desinteresse com o resultado sendo gerado e, portanto, a mensagem é clara: o que está sendo desenvolvido não tem valor, por se tivesse o stakeholder demonstraria interesse por isso.
Enquanto um stakeholder tiver a mentalidade antiquada de “esse pessoal que trabalha para mim tem obrigação de adivinhar o que estou pensando e entregar o que quero, quando eu quero”, jamais terá valor algum, e vai ficar se perguntando “será que minhas equipes são todas tão incompetentes assim que não conseguem me entregar nada?” A conclusão óbvia que ele deveria ter é “hm, talvez se eu simplesmente ‘disser’ o que estou pensando talvez eles consigam me entregar o que quero.”
Finalmente, não existe nada pior que um stakeholder ausente que só dá as caras quando alguma coisa dá errado, para bronquear, ameaçar, aterrorizar. Onde ele estava durante todo o processo que, por acaso, levou a esse acidente, em primeiro lugar?
“Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, então refina e ajusta seu comportamento de acordo.”
Toda metodologia ágil possui uma fase de “Retrospectiva”, um dos rituais para equipes que não estavam acostumadas a conversar. Nenhum processo é uma bala de prata e ela precisa ser refinada constantemente. Aliás, o ideal é que toda retrospectiva ao final de todo sprint tenha algo a ser mudado. Não existem cenário perfeito, existe sim melhoria contínua e ininterrupta. Se nada muda depois de cada retrospectiva, se ninguem sugere mudanças ao final de cada sprint, alguma coisa está errada.
Os outros princípios acho que falam por si só:
“Receba mudanças de requerimento, mesmo tarde no desenvolvimento. Processos Ágeis esperam mudança que tragam mais vantagem competitiva ao cliente.”
Mudanças são bem vindas, mas somente mudanças que tragam vantagens competitivas ao cliente, e não mudanças aleatórias baseadas no humor dos envolvidos.
“Construa projetos ao redor de pessoas motivadas. Lhes dê o ambiente e suporte que precisam, e confie neles para realizar o trabalho.”
Novamente óbvio: ou você confia nas suas equipes e funcionários, ou não confia. Se não confia, demita. Se confia, não fique micro-gerenciando e cobrando relatórios o tempo todo. Simples assim. Se você não confia e acha que pode controlar via micro-gerenciamento, você é um péssimo gerente e deveria você mesmo se demitir primeiro.
Sobre ambiente, lembre-se da Pirâmide das Necessidades de Maslow. Se seu ambiente é apertado, quente, sujo, desorganizado, não espere que suas equipes sejam motivadas, pró-ativas, organizadas. Ninguém motiva ninguém, mas é muito fácil desmotivar. Não exija o topo da pirâmide quando nem a base está satisfeita ainda.
“Processos Ágeis promovem desenvolvimento sustentado. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.”
Significa que todos os princípios acima estão sendo considerados, ou seja, existe um bom ambiente, os stakeholders estão envolvidos, a comunicação ao vivo e frequente acontece, as prioridades estão bem entendidas e, com isso, podemos ter entregas frequentes e em ritmo constante e, mais ainda, acelerando.
“Atenção constante à excelência técnica e bom design aumenta a agilidade.”
O primeiro princípio, isoladamente, às vezes transmite a falsa impressão que valor deve ser entregue a qualquer custo, inclusive sacrificando qualidade, mantenabilidade, bom design, etc. E isso é falso e é por isso que eu disse que não adianta não considerar todos os princípios de uma vez.
Sim, software de valor deve ser entregue o mais depressa possível mas, não, nunca ao custo de sacrificar demais a mantenabilidade futura desse software, justamente quando estiver acontecendo o Retorno do Investimento. Cada caso é um caso e é por isso que os stakeholders e as equipes devem se comunicar com frequência e tomar decisões baseadas, por exemplo, em custo-benefício.
“Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial.”
Em conjunto com o princípio anterior também significa não se preocupar demasiadamente com “talvez precisem disso no futuro” e criar software “bloat”, gordo, arquiteturalmente pesado e complexo para tentar torná-lo “à prova de futuro.” Isso também é impossível e leva a software que demora demais para ser entregue e com valor dúbio no final.
Novamente, é uma questão de comunicação, de negociação e de custo-benefício baseada no valor que o stakeholder comunicou que precisa.
“As melhores arquiteturas, requerimentos e designs emergem de equipes auto-organizadas.”
Esse tópico em particular eu já expliquei dezenas de vezes de diversas maneiras, mas recomendo ler este meu artigo anterior sobre Agilidade, Caos, Auto-Organização.
Se você não entende Emergência e Auto-Organização, você não entende de Agilidade. E isso, por acaso, também me remete ao meu artigo Você não Entende nada de Scrum que também recomendo ler agora.
Como podem ver, o mundo de Agilidade é fundado em cima de princípios muito importantes. Nenhum deles deve ser considerado em isolado, ou você os considera todos em conjunto ou nunca terá nenhum deles.
Mas cuidado, muitos confundem Agilidade, e os conceitos de Auto-Organização e Gestão Participativa com Busca pelo Consenso. Nada poderia estar mais longe do que isso. Estou demorando mais do que gostaria para terminar de ler o livro Systems Thinking. Mas aqui vai um trecho que eu gosto:
“Finalmente, medo de rejeição e uma forte tendência em direção à conformidade entre membros de um sistema social e outros obstáculos a mudanças sociais. Um exemplo é o experimento em uma cidade com lei-seca (que não permite venda de álcool) cujos constituintes deveriam votar sobre a banição contra o álcool. Uma pesquisa pré-votação indicou que 75% dos eleitores eram a favor de abolir o banimento. Entretanto, cada um dos eleitores achavam que a maioria preferia a lei-seca. Quando os resultados foram tabulados, 60% dos eleitores votaram para manter a lei-seca. Não surpreendentemente, depois que a pesquisa foi publicada, a próxima eleição sobre o assunto produziu 65% de maioria em favor da abolição do banimento.”
Democracia baseada em Tirania da Maioria não é útil. Esse assunto é bem mais complicado do que simplesmente fazer as pessoas votarem as opções e não deve ser tratada de forma leviana. Cientistas Políticos, Filósofos e diversos pesquisadores vem estudando esse assunto e garanto que existem ampla literatura a respeito.
Aliás, esse assunto todo é mais complexo do que meramente ler os 12 princípios. Um Engenheiro, um Médico, um Advogado, estudam anos e estão sempre longe de serem mestres nas suas áreas. Um Gerente, por outro lado, estuda muito pouco sobre o assunto, e por isso decidem baseados mais em folclore do que qualquer outra coisa. Isso é péssimo e, principalmente nesses casos, quando acertam é por sorte e quando erram é nada mais do que o esperado.