Complexidade e Agile (Parte 2): Cadência Básica

“Tudo é sobre o fluxo e não sobre uma avaliação estática.” Dave Snowden

Na parte 1 dessa série contei uma história onde agilistas “casca-grossa” num ambiente de alta experimentação tiveram um desentendimento irreconciliável. Como disse, essa história será explorada nessa série. Neste post vamos falar sobre transições e cadências dentro do Cynefin, um assunto que não vejo os agilistas do Brasil sequer mencionando, e isso gera diversas disfunções, especialmente em ambientes Scrum.

 

O Cynefin em 5 minutos

O framework Cynefin está na figura acima. Algumas dicas importantes: ele não é uma matriz 2×2; não o desenhe como 4 retângulos com um losango no meio (como já vi até em livros) e Cynefin é uma palavra em galês cuja pronuncia mais próxima em português é “Quinevin”. Esses três alertas são importantes porque se o Dave Snowden ver você cometer esses erros ele vai te xingar no Twitter.

No Cynefin temos 5 domínios: Óbvio, Complicado, Complexo, Caótico e Desordem (o espaço vermelho no meio). O lado direito do framework que inclui os domínios Óbvio e Complicado são os sistemas ordenados. Faça um esforço para deixar de lado neste momento o que você aprendeu sobre o complexo no background do Scrum. Não existe “meu ambiente é complexo” – esse é o maior ponto cego dos agilistas – as coisas no nosso mundo ocorrem num fluxo que quase não nos permite qualquer tipo de análise estática. O Cynefin é sobre a transição de um domínio para outro, como e porque transicionar e como se comportar no domínio que você está. Repito: não é uma matriz de classificação 2×2 adorada por consultores de gravata.

A melhor forma que tenho para explicar as transições entre domínios do Cynefin é uma metáfora que criei: você está em uma cidade pela primeira vez e entra no seu carro para chegar a um determinado destino. Você vira a chave e o motor do carro começa a funcionar. Como você não sabe como chegar ao destino você usa o Waze e vai contente pelo caminho indicado pelo aplicativo. Até que você dá de cara com um acidente que o Waze não detectou ainda. O Waze insiste para que você continue no trânsito parado, porém você decide desligar o Waze para experimentar novos caminhos e sair daquela situação. Sem o aplicativo o negócio é ficar de olhos abertos e explorar as oportunidades para chegar no destino mais rápido, através da experimentação. Até que o Godzilla aparece! Sim, o lagartão de 40 metros. Pra fugir dele você dispara a 120 Km/h numa rua residencial, entra numa avenida movimentada na contramão, trafega pela calçada… Nesse exemplo simples você navegou pelos domínios do Cynefin: ligar o carro é algo Óbvio, seguir o Waze é Complicado, experimentar novos caminhos sem o Waze é Complexo. Logicamente fugir do Godzilla é o Caótico.

Minha metáfora (como todas) tem limitações. Eu gosto dessa metáfora e uso ela principalmente para conversar com agilistas porque ela demonstra as transições, porém, creio que o próprio Dave me daria um tapa ao dizer que dirigir um carro experimentando caminhos é necessariamente Complexo. O Dave tem outra metáfora que pode te ajudar a entender o Cynefin no seu ambiente: imagina que você está organizando uma festa para adolescentes de 14 anos. A festa é na sua casa. Eles estão se divertindo até que aumentam o volume do som, colocam um funk pancadão, acham as suas garrafas de whisky, pulam na piscina e desinibidos começam uma exploração de suas intimidades. Quem não encontrou um par achou legal tentar colocar fogo no sofá e sua casa vem abaixo em chamas. Esse é um exemplo de um sistema Caótico. É uma característica do Caótico é ter um alto tempo de recuperação (a casa destruída). Ainda na metáfora do Dave, uma outra abordagem para a gestão de festas é definir um plano e objetivos detalhados para os adolescentes e fazer um quick-off de 45 minutos antes do início da festa onde estarão presentes os responsáveis pelo som, divertimento, aprendizado e conduta. No início da festa serão traçadas as metas de aprendizado dos convidados e o anfitrião apresentará um PowerPoint com frases motivacionais, regras de conduta e penalidades. O cronograma da festa é divulgado e reuniões de status são agendadas para cada 30 minutos para garantir o cumprimento dos milestones do projeto… err… quer dizer… festa. O plano de execução ocorre dentro dos parâmetros especificados mas a pesquisa de satisfação mostra que 97.6% dos convidados não gostaram da experiência. Aí os coaches entram em cena e mudam a mentalidade dos jovens para que suas narrativas se encaixem nos objetivos do processo. A festa é considerada um sucesso e as lições aprendidas geram melhoria contínua para o próximo “projeto”. Entretanto, “por de baixo dos panos”, alguns jovens burlaram as regras: tomaram bebidas alcóolicas escondidos, quebraram alguns pratos e teve rala e rola no porão. Os responsáveis por cada área da festa não ficaram sabendo de nada disso. Essa seria a abordagem de transformar a festa num sistema ordenado. A característica que temos aqui é de um sistema com altas restrições que podem proporcionar comportamentos indesejados, ou agentes burlando as regras para buscar seus objetivos.

Segundo Dave, gerenciar a festa de adolescentes usando a complexidade é bem mais fácil: desenhe uma linha bem clara que os jovens não vão poder ultrapassar e diga: “Se vocês ultrapassarem essa linha vou esfolar vocês vivos.” – essa é a visão do Dave, eu avisei no artigo anterior que o humor dele é inusitado.

Uma característica de sistemas que quero destacar é QUE TODOS OS DOMÍNIOS TEM VALOR. Não ache que o Complexo é excelente e excitante e o Complicado é ruim e banal. Cada domínio tem os seus objetivos e uma forma otimizada de se gerenciar. A maneira que desenvolvemos software atualmente é uma constante transição entre o Complexo e o Complicado, algumas vezes no Óbvio, raramente no Caos. Mesmo dizendo que todos os domínios tem valor, posso comprar uma briga aqui com os desenvolvedores com o que vou afirmar agora: a atividade de escrever código está no domínio complicado na maioria das vezes. Escrever código é um ambiente onde aplicamos boas práticas, o resultado esperado é conhecido e conseguimos escala. A maior evidência que tenho para defender que codificar software está no domínio complicado é o TDD (Test-Driven Development). Se eu consigo escrever um teste definindo a intenção, estabelecendo asserções dos resultados e fazer esse teste passar rapidamente muitas vezes conseguindo logo na primeira tentativa, bem, isso é característica do domínio Complicado, onde as relações entre causa e efeito são mais claras. Por incrível que pareça a análise de negócios e a disciplina de requisitos está na maioria das vezes no Complexo.

 

O Domínio Complexo

Antes de falar sobre o ambiente Complexo uma notícia para você: o Scrum não é um framework completamente adequado para a Complexidade. Sim, você ouviu certo, o Scrum não “roda no Complexo”, apesar de gurus e usuários do método afirmarem que sim. Ele navega entre o Complicado e o Complexo no melhor dos cenários, mas pode ocorrer também Sprints por meses rodando só no Complicado e até no Óbvio. Se seu Scrum tem uma grande liberdade de criação, foram derrubadas algumas restrições do próprio processo, está em adaptação constante, previsibilidade não é seu foco e a inovação está correndo solta, eu diria que seu Scrum roda quase o tempo todo no Complexo e está na cadência básica (explicarei adiante). Se o objetivo do seu Scrum é a estabilidade e para tal, além das regras do Scrum, vocês criaram regras adicionais para garantir a continuidade, previsibilidade e padronização do que ocorre dentro da Sprint, possivelmente seu ambiente não depende tanto de inovação. Seu Scrum roda quase o tempo todo entre o Complicado e o Óbvio.

Nos nossos ambientes de tecnologia é muito comum ocorrer uma cadência básica retratada pela seta verde na figura acima. Nessa cadência vemos um sistema que faz incursões no Complexo para obter informações, experimentar caminhos, testar hipóteses e avaliar opções.

O que exatamente é o Complexo? É um ambiente onde você fornece liberdade (menos restrições) pois busca deixar os agentes evoluirem ideias buscando inovação. É o ambiente onde você “não sabe o que não sabe”. De natureza disposicional, as relações entre causa e efeito são praticamente inexistentes, ou melhor,  é um ambiente onde as relações entre causa e efeito só são conhecidas após os fatos: primeiro você roda o experimento e só então saberá porque teve tais resultados. Quem já participou de um Brainstorming teve uma experiência com um sistema no domínio Complexo. Uma das regras mais interessantes do Brainstorming é que é proibido dizer NÃO – pois queremos explorar todas as ideias e possibilidades sem inibição dos participantes. Quando queremos buscar soluções e levantar alternativas através do Brainstorming as regras são bem flexíveis e todos tem a autoridade e liberdade para expressar sua opinião. No Complexo você não busca assertividade, previsibilidade, ajuda de consultores ou uma receita de bolo. É um domínio onde você consegue observar a direção que as coisas estão indo (vetor) e a velocidade, mas não consegue traçar a rota em detalhe antecipadamente e ajustar o acelerador. Gestão por observação nesse ambiente faz muito sentido. Sem dúvidas estar no Complexo envolve riscos.

Uma característica importante da Complexidade é a emergência. Poucas restrições e desconforto unidas a agentes ativos dentro de um sistema farão com que esses agentes se relacionem, formem padrões, e assim, apareçam comportamentos emergentes. No Complexo (como o Brainstorming citado acima) ideias normalmente começam a ganhar tração e convergir ao passo que outras ideias minguam e são descartadas – isso é a emergência de comportamentos. O emergir de padrões na complexidade ocorre porque pessoas (agentes ativos) se relacionando de forma auto-organizada (eu até prefiro o nome auto-regulada) entram num estado onde os comportamentos e as restrições co-evoluem, ou seja, o próprio sistema define comportamentos e ajusta suas restrições. Um erro é achar que coisas emergindo do processo no Complexo é tudo necessariamente “bom” ou desejável. Não, prezado(a) leitor(a), o Nazismo foi algo que emergiu na Alemanha, fruto de comportamentos e restrições co-evoluindo.

É no Complexo que estão as novas descobertas, a solução de problemas nunca antes enfrentados, as ideias matadoras, a definição de estratégias e a inovação. É no Complexo que todo mundo quer estar o tempo todo. Felizes são os golfinhos, gorilas, pássaros e lobos que vivem somente no Complexo. Infelizmente ou felizmente, os seres humanos tem uma capacidade que nenhuma outra coisa nesse planeta tem, e isso muda o jogo.

 

O Domínio Complicado

A vida não é somente inovar, você precisa também implementar aquele CRUD esperto ou trabalhar em coisas mais banais mas que colocam dinheiro no seu bolso. Como citei anteriormente o mantra “Scrum é para ambientes complexos e meu ambiente É COMPLEXO” é o maior ponto cego que vejo nos agilistas atualmente. Não é um “fatalismo” estar no domínio X ou Y. Você decide e gerencia sair do X e entrar no Y se você quiser. Me parece que o Scrum quer fazer essa escolha por você. Nós podemos trafegar entre o Complexo e o Complicado e a falta de entendimento que o Complicado também tem valor é o que impede maiores evoluções nas implementações ágeis que vejo por aí.

Talvez alguns de vocês saibam que no meu tempo livre uma das coisas que mais gosto de fazer é velejar. Pegar meu Hobie Cat 16 e voar o vento sul do inverno na Represa Guarapiranga ou o vento leste no verão na raia da Ponta das Canas na Ilhabela é uma das sensações mais impares e prazerosas que existem na minha vida! Velejar me levou a estudar um pouco a história das navegações no mundo e encontrei algumas informações que reforçam minha visão aqui.

 

 

Se você estudar História você verá que para assuntos abstratos e pessoais – como a religião, a arte e a linguagem – dentro de diversas civilizações, durante várias épocas, temos uma grande variedade de rituais, deuses, estilos de pinturas, esculturas e estilos literários e etc… Entretanto, se você analisar qualquer outro assunto que seja mais concreto ou de engenharia – como a arquitetura, a matemática, a cartografia, a guerra e a navegação – diferentes povos como europeus, vikings, árabes, asiáticos, africanos e outros, nas diversas eras, mesmo separados por oceanos de distância e sem qualquer comunicação entre eles, nesses assuntos técnicos, todos os povos chegaram nas mesmas conclusões e a variação é bem menor.

Os sistemas ordenados (Complicado e Óbvio) só existem para nós os seres humanos. Somente seres conscientes capazes de se comunicar, prever, projetar, analisar e repetir experiências é que se importam com o domínio Complicado. O domínio Complicado é o domínio da análise.

Por que um barco Viking do século IX é muito parecido com um barco Chinês do século XI mesmo sem ter tido qualquer contato entre essas duas civilizações? Na teoria da Complexidade a explicação que temos é que ambos mergulharam no Complexo, na novidade, na inovação e emergiram desses experimentos as mesmas conclusões ou conclusões muito parecidas.

Trazendo isso para nosso mundo de tecnologia a cegueira “a complexidade nos trás uma imprevisibilidade inerente, nenhum ambiente é igual ao outro, temos que achar uma solução específica para nossa realidade, contexto é muito importante e etc…” faz equipes perderem tempo tentando achar uma solução que já existe (emergiu) em outro ambiente e está documentado em livros ou na Internet. Ao invés de você caminhar por uma trilha já aberta você quer abrir a sua própria trilha. Com isso você perde tempo, dinheiro e energia que poderia ser investido em coisas mais importantes. É reinventar a roda.

Tenho lido Nassim Nicholas Taleb e no seu livro “Black Swan” ele me apresentou a filosofia dos empiristas-céticos. Um empirista-cético é aquele que entende que num ambiente complexo múltiplas soluções podem ser aplicadas para resolver um problema e os resultados obtidos dos experimentos podem formar uma fenomenologia que permite o progresso. Ser empirista significa acreditar que é possível ter conhecimento e tomar decisões mesmo sem ter teorias comprovadas pelo método científico. Ser cético é assegurar que qualquer teoria deve ser levada ao escrutínio e a desconfiança antes de ser experimentada para a solução de problemas no seu ambiente. Agilistas podem até ser empiristas, mas raramente são céticos. A aceitação quase unanime deles da furada teoria dos Story Points por anos a fio e com baixo questionamento é evidência do que defendo aqui.

Meu recado para os agilistas é que existem teorias consistentes ou fenomenologias muito fortes que eles podem experimentar em seus ambientes sem mergulhar no complexo para buscar respostas – pensadores(as) como Taichii Ohno, Edward Deming, Eliahu Goldratt, Donella Meadows, Don Reinertsen entre muitos outros já fizeram esses mergulhos no passado e deixaram dados, fórmulas e teorias que vão te poupar um bocado de trabalho e reduzir bastante sua frustração. Isso é se beneficiar do domínio Complicado.

Se seu problema é tempo de resposta, comunicação e falta de entendimento, talvez reduzir o tamanho dos lotes possa resolver (Ohno). Se sua equipe está afogada em defeitos entender seu ambiente como um sistema possa ajudar (Deming). Se seu problema é falta de fluidez, talvez compreender sobre gargalos possa aumentar sua produtividade (Goldratt). Se você está vendo padrões no Complicado e vendo emergir comportamentos viciados ou oscilações em “estoques”, dá uma olhadinha na Donella Meadows. Se você quer entender a dinâmica do seu processo como um framework econômico, pergunte ao Don Reinertsen.

Uma equipe que desconhece totalmente TDD, mergulhada no Complexo, pode perfeitamente  – através dos experimentos e vivenciando problemas  –  chegar as mesmas conclusões que as equipes Smalltalk dos anos 80 chegaram.

A cadência básica dos sistemas que vivemos em TI pode ser resumida em mergulhar no Complexo, soltar amarras, procurar o novo, dar liberdade para criar e voltar ao Complicado para formular teorias ou fenomenologias que aumentem o conhecimento e se tornem ferramentas que possam ser replicadas e escaladas. Ambos os domínios são importantes e o artifício que temos para transacionar de um domínio para o outro são remover, alterar ou adicionar restrições, o assunto para o próximo artigo da série.

Nesse momento podemos revisitar a história dos agilistas em 2011 na Taiba (mostrado na parte 1) e se questionar: Era um ambiente Caótico? Eles estavam no Complexo? Passaram ou passariam também pelo Complicado?

Para concluir mais esse artigo da série “Complexidade e o Agile” deixo meu pensamento a respeito da importância do Complicado: se você é ignorante a respeito de teorias que explicam os problemas no seu ambiente, por favor, não culpe a Complexidade ou a use como desculpa.

Continuar para a Parte 3: Caos e Restrições >>