No post em que diferenciei complicado, complexo e caótico eu explico alguns conceitos que deixam claro em quais tipos de projeto faz sentido uma abordagem ágil, e em quais faz sentido uma abordagem tradicional, baseada em cascata. Explico também o que significa ser simples, complicado, complexo, e caótico, além de explicar as características de um contexto complexo. Você vai aproveitar melhor este post se ler aquele primeiro.

Estou estudando o framework Cynefin e percebo que alguns conceitos complementam bem o que eu já havia iniciado, já que ele levanta os modelos de gestão apropriados a cada contexto.

A categorização é parecida com a que eu havia proposto antes, e que é parte do curso de Professional ScrumMaster:

Nesse gráfico, temos expostos os contextos em que uma situação, um projeto de software, por exemplo, acontece. Estes contextos são classificados em ordenados e desordenados:

1. Nos contextos ordenados as decisões são baseadas em fatos, existe uma clara relação de causa e efeito (causalidade), e o sistema restringe os agentes, ou seja, é possível limitar as ações e criatividade das pessoas e ainda assim obter resultados. Um estilo comando e controle pode funcionar, ainda que eu prefira uma liderança democrática, e não autocrática. Os contextos simples e complicados são contextos ordenados.
2. Nos contextos desordenados há necessidade de avaliação empírica, e a análise de padrões é que determina a resposta. Há pouca ou nenhuma relação evidente entre causa e efeito (ainda que ela exista, é difícil de medir). Nesse cenário, somente o autogerenciamento e a autoorganização libertam os agentes para criar soluções que realmente endereçam os problemas que aparecem. Hierarquia estrutural e autocracia são o melhor caminho para o fracasso. Os contextos complexo e caótico são contextos desordenados.

O problema maior é tomar um pelo outro. A maioria dos líderes/gerentes imagina trabalhar em ambientes ordenados. Isso é um problema porque as respostas esperadas em cada contexto são diferentes. Ao tomar um pelo outro, as decisões ficam aquém do esperado e produzem desperdício, no mínimo.

No contexto simples e também no complicado, o ambiente é planejado e previsível.

No simples, sabe-se tudo ou quase tudo o que pode acontecer ao processo. Nesse contexto, os líderes sentem, categorizam e respondem, ou seja, eles avaliam a situação, as categorizam e decidem com base nos fatos categorizados. Nesse cenário, os líderes podem não perceber a mudança de contexto, de simples para complicado, complexo ou caótico, e caminham para a falha, já que o contexto mudou e eles continuam aplicando técnicas baseadas em sentir, categorizar e responder, na expectativa de uma previsibilidade que pode ser falsa, e achando que sabem mais do que sabem.

No ambiente complicado, muito pouco é desconhecido sobre o processo e o produto. Sabe-se mais do que não se sabe. Nesse contexto, os líderes sentem, analizam, e respondem, ou seja, é preciso analizar as situações que aparecem, e não só categorizá-las. Essa análise fica a cargo de experts, que precisam informar como responder. Nesse cenário, não os líderes (como no contexto simples), mas os experts é que correm o risco de não perceber a mudança de contexto, e, junto aos líderes, podem aplicar abordagens erradas para endereçar cada situação.

No contexto complexo, o desconhecido predomina sobre o conhecido, sabe-se pouco, e não se sabe o que não se sabe. É preciso levantar os fatos antes de tomar as decisões, e por isso, o processo não começa pelo sentir, como nos contextos ordenados, mas começa com sondar, e então sentir, e só então responder. É o processo empírico tateando a cada passo, porque sabe que não é possível crer no planejamento, já que não sabemos quase nada. Nesse cenário, tentar impor ordem e buscar previsibilidade é caminhar para o abísmo, já que o contexto é naturalmente desordenado; mais vale entender e abraçar a complexidade, adaptando-se sempre que necessário. Aqui o sistema restringe os agentes, devido à sua imprevisibilidade, e os agentes restringem o sistema, impedindo que ele caminhe para o total desconhecido, inspecionando frequentemente e adaptando sempre que necessário.

No contexto caótico, não só não sabemos nada, mas não conseguimos saber. Não adianta sondar, os resultados serão nulos ou inúteis. Causa e efeito não tem relação aparente alguma. Resta agir, e esse é o primeiro passo, seguido do sentir, e então responder. Os líderes agem, e então sondam os resultados, e respondem aos efeitos dessa sondagem, tentando trazer o contexto para algo no mínimo gerenciável, onde também não se sabe, mas pelo menos temos como tatear, ou seja, buscam o complexo. O ideal é atuar de forma rápida, a fim de reestabilizar; imagine um avião em queda, e girando – a primeira coisa que se faz é agir e fazer o avião parar de girar, só depois é que faz sentido buscar nivelar o avião. Buscar ler os instrumentos ou planejar seria absurdo. Neste contexto, o sistema e os agentes estão sem restrições, não há controle ou previsibilidade alguma, e não há como medir. Mas o caótico não é só ruim, ao mesmo tempo que busca agir, o líder tem em mãos uma grande oportunidade de mudança radical, proporcionada pela desordem absoluta e pela total falta de posição. Se o momento caótico passar e a mudança não acontecer, dificilmente ela acontecerá tão facilmente como poderia antes.

Reforçando: o grande erro está em liderar imaginando um contexto, quando na verdade estamos em outro. O mais comum é responder utilizando técnicas para contextos simples ou complicados, quando na verdade estamos no caótico ou complexo, por acaso os mais comuns no mundo de software.

Por exemplo, uma empresa que desenvolve software sob medida, sempre atuando em novos clientes, ambientes, tecnologias, e com pessoas diferentes, vive um ambiente no mínimo complexo e portanto pouco previsível. Aplicar técnicas baseadas em análise e resposta, como as baseadas no modelo cascata, ou atuar como um líder que comanda e controla, é ignorar o contexto em que o projeto vive, além de ignorar o que não se sabe. Pior, assumir que sabe, ou até basear-se em informações erradas, desatualizadas ou ambos.

O mesmo vale para o oposto. Uma empresa que trabalha com um software vanilla, que customiza para clientes sempre de forma semelhante, está sempre atuando no mesmo produto, ou seja, atua num ambiente provavelmente no máximo complicado. Nesse cenário, sondar é desnecessário, e trará um custo extra ao projeto. Basta analizar os resultados das medições e corrigir de acordo com o plano. Um modelo em cascata, baseado em alta previsibilidade, seria o ideal e o mais barato.

E você? Trabalha em qual contexto? As decisões dos líderes batem com o contexto?