Maturidade 5 em Métodos Ágeis – Em busca da Anti-Fragilidade

Neste último artigo sobre um modelo de maturidade em métodos ágeis, iremos descrever como reduzir a fragilidade organizacional.

A figura abaixo mostra um esquema com níveis de maturidade organizacional em métodos ágeis, ao longo das perspectivas de times, ritos, entregas e qualidade. O nível 1 mostra uma organização mais frágil. Os níveis intermediários e avançados mostram organizações que não são mais frágeis.

 

ModeloMaturidadeMetodosAgeisv2
Melhoria contínua em métodos ágeis [Imagem maior]

A fragilidade organizacional é aqui definida aqui como aquele tipo de organização onde os eventos negativos provocam efeitos devastadores.

Um exemplo – A Anti-Fragilidade para Times

Um exemplo de fragilidade é uma organização que tenha um time baseado no modelo comando e controle. Neste modelo, existe a figura de um gerente forte e subordinados que cumprem comandos, com baixa interação entre si. Este modelo é frágil, pois pode ser abalado por várias questões tais como:

  • Uma provável baixa capacidade do gerente de lidar com todos os problemas do dia a dia;
  • Uma baixa capacidade de aprendizado dos comandados devido a sua baixa comunicação (não é tão comum encontrar pessoas que aprendam sozinhas);
  • Uma baixíssima resiliência a qualquer evento que afete o gerente (ausências no dia a dia ou faltas ao trabalho);
  • Um provável colapso do time quando esse gerente deixa a organização.

Ao reconhecer a fragilidade em um time, uma organização pode introduzir mecanismos de resiliência. Ao fazer isso, por exemplo, com mais autonomia para as pessoas, delegação administrativa  e maior comunicação interna, estaremos avançado para um time robusto.

Definimos robustez organizacional aqui como a capacidade de resistir a eventos negativos, que ocorrem em todas organização. No exemplo acima teríamos então a figura forte de um gerente, ao mesmo tempo com mais autonomia e comunicação entre os liderados. Nesse modelo robusto, o time consegue trabalhar sem o gerente e até suportar a sua perda, pois possuem autonomia e se comunicam com frequência.

A robustez parece o objetivo desejável, mas ela não é o contrário da fragilidade. Se a fragilidade fosse um número negativo, a robustez seria o número zero. Isto é, na robustez apenas lidamos com os eventos negativos, mas não geramos oportunidades de ganhos positivos nas incertezas. Times robustos, ao invés, apenas restauram o estado inicial após um incidente negativo.

E aqui entra o conceito da anti-fragilidade. Quando uma organização avança além da robustez, ela se torna anti-frágil. A anti-fragilidade é definida aqui como a resiliência para lidar com eventos negativos e ao mesmo tempo explorar oportunisticamente os eventos negativos e positivos. A anti-fragilidade é o contrário da fragilidade, i.e., é o tipo de organismo que se torna mais forte após as adversidades.

No exemplo de times, definimos então um time anti-frágil como um time auto-organizado.

  • Em times auto-organizados, não existem “gerentes” no sentido clássico. Existem líderes facilitadores que preparam o terreno para o time atuar e fazer o seu melhor coletivamente.
  • Aqui eles organizam as suas tarefas, resolvem os seus conflitos e periodicamente discutem o que funcionou e o que precisa ser aperfeiçoado. Aquilo que não funcionou irá gerar uma agenda de melhoria, que irá fortalecer esse time.
  • Em times auto-organizados, análises de causa raiz são realizadas para lidar com a fonte dos problemas, evitando erros similares futuros e portanto os tornando mais anti-frágeis.
  • Times auto-organizados são generalistas-especialistas e portanto redundantes a absenteísmos e rotatitivades (até um certo ponto). A redundância é uma das propridades desejadas em sistemas anti-frágeis.
  • Finalmente, time auto-organizados promovem e resolvem conflitos através de uma cultura permanente de feedbacks estruturados. Isso limpa arestas, problemas de relacionamento e cria extrema confiança entre os participantes.

Frameworks gerencias modernos como o Management 3.0  ou a Holocracia tem promovido a formação de times auto-organizados (e mais anti-frágeis que os tradicionais times de mercado). O  caso Zappos, que citamos em um post anterior dessa série, é um exemplo emblemático do uso da holocracia em uma empresa que fatura mais de 1 bilhão de dólares por ano.

Um outro exemplo – A Anti-Fragilidade para a Qualidade de Produtos

Um exemplo de qualidade frágil é um time de desenvolvimento de software que entrega produtos em produção com muitos defeitos e por isso tem boa parte da sua agenda ocupada com incidentes críticos no ambiente de produção.

Ao mesmo tempo, se esse time reconhecer a fragilidade, criar uma consciência de testes e começar a trabalhar em pequenos instrumentos como refatoração, testes de unidade e TDD, essa mesma organização pode avançar do mundo da fragilidade para a robustez.

Uma organização robusta para testes e qualidade parece apropriada, mas ela simplesmente tolera até certo nível os riscos negativos que ocorrem no desenvolvimento e manutenção dos seus produtos. No exemplo de qualidade acima, ela é aquela que escreve testes e os automatiza para lidar com a imprevisibilidade ambiental, que sempre irá acontecer. (exemplo: hardwares ou banco de dados sempre falharão em algum momento). Ao mesmo tempo, a robustez não cria inovação e não usa as oportunidades positivas que também se apresentam (assim como as negativas).

Nesse mesmo exemplo de qualidade, um time pode perceber que as práticas de testes podem ser tão poderosas que podem ser usadas para:

  • provocar falhas rapidamente no ambiente com automação de testes (CI/CD) – gerar erros pequenos no começo do produto é benigno e anti-frágil;
  • trabalhar a especificação de requisitos em uma abordagem BDD (Behavior Driven Development). Com o BDD, analistas exploram narrativas de negócio na forma de teste desde o começo do desenvolvimento do produto, reduzindo assim o custo total do desenvolvimento de software e ao mesmo capturando problemas que somente seriam descobertos mais tarde no projeto;
  • realizar testes de situações anômalas, como provocar deliberamente a falha de componentes e observar o comportamento do sistema (um exemplo ótimo nesse sentido é o aplicativo CodeMonkey do NetFlix, que derruba aleatoriamente servidores em produção para descobrir e antecipar problemas. Sim, ambiente de produção!);
  • introduzir tolerância a falhas e elasticidade computacional nos seus ambientes de produção, para aproveitar as oportunidades de picos de usuários em eventos futuros incertos.

 

Da fragilidade para a robustez. E da robustez para a anti-fragilidade

A melhoria contínua é o processo contínuo que levou organizações sem maturidade a estágios mais avançados. Mesmo nas organizações mais avançadas quanto ao uso de métodos ágeis, a melhoria contínua é o instrumento que as levam a manter as suas conquistas e buscar ainda mais aprimoramentos.

A melhoria contínua é a mola mestra para sair da fragilidade e avançar para a robustez e anti-fragilidade. Ela envolve sistematizar:

  • a observação ambientel dos eventos (positivos e negativos);
  • o debate regular sobre os acontecimentos positivos e como eles podem ser mantidos no sistema;
  • o debate regular sobre os acontecimentos negativos e como eles podem ser eliminados ou mitigados através de ações de melhoria no sistema.

Se um time realiza este “ritual” periodicamente, ele avança de forma contínua e em breve começa a eliminar as suas fragilidades, uma a uma.

Se pudesse recomendar uma prática inicial para qualquer time que queira se tornar ágil, esta prática seria a retrospectiva Scrum ou o ritual Kaizen em métodos Lean.

A Toyota é um excelente exemplo de como a aplicação sistemática de pequenas melhorias, de forma contínua, pode trazer grandes resultados em longo prazo. De forma geral, a Toyota é reconhecida por produzir carros com maior qualidade, menos defeitos embutidos,  menos horas de pessoas, estoques e plantas menores no processo produtivo do que os seus concorrentes. O livro Toyota Way mostra como essa cultura gerencial fantástica foi trabalhada passo a passo.

Sobre Anti-Fragilidade

É um conceito cunhado por Nicholas Taleb e inicialmente sistematizado na história humana na filosofia estóica (Sêneca, Marcus Aurelius e Epícuro). Um artigo introdutório e interessante sobre o tema pode ser encontrado no artigo Beyond Sissy Resilience: On Becoming Antifragile, que apresenta uma bela figura metafórica sobre o conceito.

antifragile-3

 

Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better ― Nassim Nicholas TalebAntifragile: Things That Gain from Disorder

Aumento de Maturidade em Métodos Ágeis

Muitos times no Brasil tem experimentado o uso de princípios e práticas ágeis no seu trabalho de desenvolvimento de projetos e operação continuada. Entretanto, nem sempre os efeitos originalmente buscados em termos de eficiência de tempo e qualidade são alcançados. Para os mais céticos, isso cria uma “prova” que não funcionam na realidade única e particular de suas empresas. Se o ceticismo alcança a camada gerencial, isso pode significar a morte de iniciativas ágeis, que se tornam para sempre amaldiçoadas como apenas mais um modismo de consultores.

Pessoas que se debruçaram seriamente sobre a dinâmicas de times e projetos em empresas já perceberam que a dinâmica tradicional baseada em hierarquias rígidas, comando e controle, comunicação através de papel e aceitação de defeitos e desperdícios é ineficiente. Taiichi Ohno foi uma dessas pessoas e o resultado do seu sistema alternativo de pensamento pode ser observado no desempenho superior da Toyota através do sua filosofia Toyota Way, conhecido no ocidente como pensamento Lean há quase 50 anos. Kent Beck, Jeff Sutherland, Allistair Cockburn, Craig Larman, Mary Poppendick, entre outros, tem evidenciado há mais de 20 anos que métodos ágeis funcionam em organizações dos mais diversos tamanhos, setores e propósitos.

Para evitar que a desilução se instale e acabe com os movimentos ágeis nascentes na sua organização, é fundamental reconhecer que adotar métodos ágeis não é apenas tomar uma decisão ou comprar um livro. Adotar métodos ágeis é um processo, que demanda tempo e disciplina. Ao mesmo tempo, podemos observar a nossa maturidade ao longo do caminho, comparar com um modelo de referência, reconhecer as fragilidades e então decidir como avançar.

Modelo de Maturidade para Implantações Ágeis

Boa parte da comunidade ágil não usa modelos de maturidade, que tendem a ser prescritivos e ordernar artificialmente as ações futuras de uma TI. O CMMI é um exemplo deste tipo de modelo prescritivo. Ao mesmo tempo, nem todo modelo de maturidade precisa ser prescritivo. Ele pode ser um modelo de reconhecimento crescente da dinâmica da sua organização e uma capacidade crescente de sentir e responder aos fenômenos e incidentes que lá acontecem.

Neste contexto, apresentamos aqui um modelo de maturidade para aumentar a agilidade no seu trabalho, do seu time e até mesmo da sua empresa. O modelo apresenta os seguintes níveis.

0. Desconhecimento (Ignorância)
1. Reconhecimento da Realidade (Princípios)
2. Práticas Ágeis Nascentes em Indivíduos e Projetos
3. Práticas Ágeis Consistentes em Projetos
4. Agilidade em Escala Organizacional
5. Melhoria Contínua em Escala Organizacional

O nível 0 (Desconhecimento) é ainda dominante na maior parte das empresas. Muitas pessoas trabalham mal, geram resultados ruins, não reconhecem o seu desempenho ruim e reclamam que o problema está sempre lá fora. Frases comuns incluem:

  •  “A realidade aqui na minha empresa é diferente. Esta teoria não irá funcionar aqui.”
  •  “Eu trabalho com isso há quase 30 anos. Eu já sei muito bem o que preciso fazer”.
  •  ” Se você conhecesse o meu chefe, saberia que não posso fazer nada.”
  • ”O nosso contrato com o fornecedor nos impede de fazer isso.”
  • ”Eu já sou muito eficiente.”
  • ”O meu time somente funciona na base da pressão.”

O nível 1 (Reconhecimento) acontece quando pessoas começam a reconhecer que existe algo errado. É como alguém com sobrepeso extremo começar a ter ciência que o seu estilo de vida irá matá-lo em poucos anos. Em métodos ágeis, o reconhecimento se dá através da descontrução das crenças limitantes e percepção que:

  • pessoas e interações entre pessoas é o fator crítico de sucesso em projetos;
  • responder a mudanças é vital para lidar com o ambiente dinâmico de projetos e organizações;
  • buscar colaboração com os clientes e resultados ganha-ganha é mais eficiente que regulações e contratos rígidos;
  • entregar produtos em funcionamento em ciclos curtos é um aspecto vital no estabelecimento de confiança com seus clientes internos e externos;

O nível 2 (Práticas Nascentes) acontece quando alguém começa a realizar um experiento em base pessoal ou no seu time. Por exemplo, um desenvolvedor de software começa a fazer “Código Limpo”, que é uma abordagem estruturada para codificar com manutenibilidade, estensibilidade, segurança e reduzidos defeitos. Um outro exemplo é um arquiteto que implanta a prática de “Arquiteturas Evolutivas” no seu trabalho de infraestrutura. Um terceiro exemplo são times que introduzem o conceito de sprints, que são intervalos de tempo fixos usados para construir e demonstrar incrementos de produtos para os seus clientes internos e donos de produto. No nosso exemplo da pessoa com sobrepeso extremo, ela começa a agir e deixa de comer o seu terceiro ou quarto pedaço de pizza antes de dormir. Para avançar para o nível 2, é importante investir em leituras contínuas e um processo enxuto de experimentação (hipótese plausível, experimento curto, análise de resultados e relato das lições aprendidas).

Quando uma organização avança para o nível 3 (Práticas Consistentes), a cultura instalada na organização já reconheceu e aceitou que as novas práticas são melhores e que devem ser mantidas em novos projetos. É como um indivíduo que fumou durante 30 anos, reaprendeu a viver sem nicotina no seu organismo e que agora consegue subir 3 lances de escada sem ficar ofegante. Ele não aceita retornar para o nível de mediocridade que vivia e almeja agora subir 4 ou 5 lances de escada para alcançar o seu escritório e tornar irrelevante o elevador. Em organizações, observamos que este fenômenos em times com alta produtividade, que estabeleceram o seu conjunto de práticas vencedoras e são muito mais produtivos que times similares na mesma organização.

O nível 4 (Agilidade em Escala Organizacional) acontece quando a alta direção incorpora os modelos ágeis como cultura dominante na organização. Este novo organimo agora opera de forma com modelos gerenciais descentralizados com o uso de práticas como por exemplo a Holocracia. A Zappos, que faturou 2 bilhões de dólares em 2014, é um exemplo deste tipo de organização e foi citada em um Revista Forbes – Caso Zappos de 2015 pela revista Forbes. Frederic Laloux, no seu livro – Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness – descreve este tipo de maturidade organizacional como Green Companies, em oposição a empresas Red Companies, que representam o clássico modelo “Comando e Controle”.

O nível 5 (Melhoria Contínua) acontece quando uma organização opera em melhoria contínua, com uma cultura contínua de aprendizado. A prática de cada trabalhador se torna o lema Kaizen do Toyota Way“O meu trabalho é fazer o meu trabalho e melhorar continuamente o meu trabalho”. Aqui as pessoas operam com excelência, que foi trazida por anos da prática da observação, orientação, decisão e análises consistentes.

Observe que este modelo de maturidade não diz quais são as práticas que devem ser adotadas, nem a sua ordem implantação. Mas ele indica que o nível de consciência organizacional e o grau de espalhamento das práticas é que determina maturidade. Iremos abordar estes níveis em detalhes nos próximos artigos e lhe explicar como iniciar essa jornada em nível pessoal e promover esta melhoria para o seu trabalho, os seus times e a sua empresa.

Nível 1 – Reconhecimento (publicado em 08/12/15).

Nível 2 – Práticas Nascentes (publicado em 18/12/15).

Nível 3 – Práticas Consistentes (publicado em 04/01/16).

Nível 4 – Agilidade em Escala Organizacional. (publicado em 14/01/16)

Nível 5 – Em busca da Anti-Fragilidade (publicado em 07/03/16)

Os Sete Pecados Capitais do Desenvolvimento de Software

O quadro o Jardim das Delícias Terrenos é um dos mais impactantes quadros a avisar aos transgressores da fé católica o destino deles ao final de uma vida impura. Obra-prima de quase 2 metros de altura e largura, o quadro retrata o inferno dos luxuriosos, gulosos, avarentos, invejosos, preguiçosos, iracundos e vaidosos.

O Jardim das Delícias Terrenas
Obra prima de Hieronymus Bosch, pintor holandês contemporâneo de Leonardo da Vinci

 

Se a engenharia de software tivesse um inferno, poderíamos nos arriscar, como Dante Aligheri, a descrever os sete pecados capitais do desenvolvimento de software que os porquinhos de software cometem em base diária. Mary Poppendieck, uma das autoras doLean Software Development, descreva 7 formas de desperdício no desenvolvimento de software. Apresento e contextualizo estes pecados capitais abaixo no dia a dia do trabalho de software.

1. Funcionalidades extras. Pesquisas de institutos como o Standish Group (XP Conference, 2002) mostram que metade das funcionalidades de um software são raramente ou nunca usadas. Ainda assim, é muito comum que desenvolvedores “criativos” introduzam funcionalidades não desejadas em seus software que não trazem valor agregado algum para os seus clientes. A redução do desperdício tem forte relação com escrever menos linhas de código.

2. Transferência de responsabilidades, conhecimentos, ações e feedbacks. O uso de papéis muito especializados é um sintoma deste problema. “Arquitetos” e “projetistas” que não sabem codificar, “desenvolvedores” que não sabem testar ou implantar software e “gerentes de projeto” que se orgulham de não entrar em temas técnicos são exemplos de handovers (repassese fontes comuns de desperdício.

3. Defeitos. Se orgulhar de ter um time de testes que encontra muitos defeitos é no mínimo contra-produtivo. Devemos nos lembrar que defeitos são desperdícios, ou dinheiro jogado fora. As ações de projetos devem impedir que defeitos sejam introduzidos em primeiro lugar, e não focar em pegar defeitos ao final.  Um exemplo simples é no ciclo tradicional de especificação, codificação e testes. Ao invés, o teste deve validar e corrigir a especificação antes que a primeira linha de código seja escrita, visto que a maior parte dos defeitos nasce ainda na especificação do software. Da mesma forma, é papel do desenvolvedor usar técnicas diversas (refatoração, teste de unidade e integração contínua) para reduzir a quantidade de defeitos introduzidas no software.

4. Débito Técnico. Fazer código de má qualidade tende a gerar débito técnico no código, módulo e arquitetura de um produto. O débito técnico gera um efeito muito ruim a médio e longo prazo e gera efeitos colaterais no produto em pontos não imaginados. Livros como “Clean Code”, do Robert Martin, exploraram a criação de código de qualidade

5. Trabalho em progresso. Manter uma longa lista de tarefas com o status em  ”execução” esconde problemas e eventualmente gera desperdício. Cada pessoa de um time deve manter o mínimo número de tarefas abertas. Cada tarefa aberta deve ser rapidamente terminada para reduzir o seu tempo de ciclo, evitar retrabalhos e trabalho multitarefa. Um exemplo vem da metodologia japonesa chamada Kanban, que introduz o conceito chamado (WIP). O WIP (Work In Progress) tem um valor limite pequeno (tipicamente 3) e impede que uma pessoa tenha mais de 3 tarefas em execução. Um outro exemplo de combate a este desperdício é a prática de entregar software com frequência para os usuários chave, que limita o tamanho do backlog de tarefas em aberto para todo o time de desenvolvimento.

6. Trabalho multitarefa. Há algum tempo este mito assola os times de software, atolados no trabalho de novas demandas e na resolução de defeitos e adaptações de diversos softwares em paralelo. Estudos diversos mostram que o fator multitarefa reduz a produtividade, gera desmotivação e trabalho de pior qualidade, o que introduz mais defeitos e gera mais trabalho em progresso.

7. Esperas e atrasos. Provocar esperas e atrasos gera um efeito nocivo na produtividade do time e é também uma forma de desperdício. Por exemplo, enviar um email para uma equipe de desenvolvimento validar um documento de casos de uso gera espera, atraso e descontinuidade do trabalho. Apresentar este documento ao vivo melhora o entendimento para todos e também reduz ciclo de validação do documento gerado. Allistar Cockburn descreve a prática chamada de “Radiadores de Informação” em seu método ágil chamado Crystal Clear, que consiste em manter pessoas próximas e privilegiar a comunicação ao vivo com o uso de quadros brancos. Outros métodos ágeis como o Scrum ou o XP também advogam práticas similares.

Eliminar desperdícios é chave para gera software mais eficaz e em menos tempo para clientes. Um bom livro sobre este tema é o livro: Implementing Lean Software Development: From Concept to Cash, de Mary e Tom Poppendieck.

Lean Software Development