Além do copiar e colar: navegando pela complexidade

Ágil e a complexidade: a ameaça fantasma

Por que a agilidade é uma boa ideia? O livro de Jeff Sutherland diz: "Scrum, a arte de fazer o dobro do trabalho em metade do tempo". À primeira vista, parece simplesmente uma questão de eficiência. Mas se perguntarmos para agilistas experientes, a razão deles adotarem essa metodologia, normalmente surge uma lista de desafios em que a aplicação do ágil funciona melhor que outras abordagens, ou seja, os usuários entendem seus próprios requisitos pela metade.

Os requisitos mudam porque o contexto muda. É preciso construir a substituição tecnológica no seu design. Sua solução está conectada a muitas outras coisas e todas interagem e mudam. Mas mesmo dentro do projeto, sabe-se que haverão surpresas e problemas imprevistos. Se olharmos por trás do óbvio: qual a força comum que fazem esses desafios se comportarem da forma como se comportam? A resposta é: complexidade. Explorar a complexidade tem uma enorme vantagem. Quando entendemos mais sobre a complexidade por trás do problema que estamos tentando resolver com ágil, na verdade estamos trazendo clareza para o propósito da aplicação do ágil. Esse é o ponto de partida para construir tanto foco quanto uma priorização comuns dentro da cultura agilista.

Métodos ágeis: a tentação do sistema

Do meu ponto de vista como um coach de líderes trabalhando com empresas ágeis do setor de TI, acredito que a parte estrutural das metodologias ágeis promove muitas capacidades que ajudam a lidar com a complexidade: o progresso iterativo significa a adaptabilidade a cada iteração. E significa que podemos experimentar: optar pela tentativa e erro em vez da análise e conclusão lógica. Além disso, também ganhamos força ao preservar a iteração individual; por exemplo, preservamos o sprint de ser muito perturbado. A oportunidade de envolver o cliente no processo com o mínimo de filtro possível é outra competência relacionada à complexidade (e podemos questionar se a típica forma de capturar os requisitos dá conteúdo não-filtrado suficiente, e a possibilidade de diálogo). Outra opção seria fazer uso da diversidade de perspectivas em equipes multifuncionais, ou testes A-B.

Mas métodos e processos funcionam um pouco como livros de receita: ajudam a quem adota as práticas a se tornarem bons e rápidos, mas sem necessariamente entender porque se tornaram bons. Para quem desenvolve em organizações, a tentação é guiar toda a transformação a partir deste ponto de vista: fazemos com que as pessoas aprendam processos e métodos ágeis e então desenvolvemos mais a organização ao simplesmente adotar métodos e processos cada vez mais sofisticados.

O lado ruim desta tentação se mostra nos pontos em que é possível usar essas ferramentas muito bem ou muito mal. Qual tópico precisamente vamos abordar na retrospectiva? Como aplicamos o julgamento quando priorizamos o backlog? Como mantemos uma conexão aberta com o cliente e seus novos requisitos? É aí que o entendimento sobre a origem da complexidade ajuda a tomar decisões.

Por exemplo, ao mudar da rigidez do sprint para a abertura de uma mudança no sprint, na verdade estamos jogando com o equilíbrio entre estabilidade e adaptabilidade. Se executarmos isso mal, vamos acabar no que a teoria da complexidade chama de conversão prematura (tornar as coisas rígidas muito cedo) ou na eterna ebulição (manter as coisas em aberto tempo demais). Contudo, nenhuma regra estrutural consegue dizer com precisão qual o equilíbrio ideal, depende do contexto.

O mesmo se aplica à coordenação entre o que acontece nas equipes de desenvolvimento e no nível da estratégia de produto. Sob a perspectiva da complexidade, uma boa estratégia se comporta como um vetor: mesmo que seja impossível acertar o resultado final, temos uma direção, um "norte", e deixa ao critério das equipes a definição dos próximos passos. Mas ao mesmo tempo deve incluir uma ideia clara sobre o "sul", neste caso, o que deve ser evitado.

Podem haver muitas razões para a falta de claridade no propósito. Por exemplo, às vezes a visão corporativa é simplesmente vaga demais: já trabalhei em uma empresa da indústria química cuja visão era "Moldar o Futuro", e isso pode significar qualquer coisa, e consequentemente, nada.

Um exemplo melhor é o "Leitbild" que a BMW colocou em seu site nos primórdios de 2007: "Entregamos produtos e serviços de primeira na área de mobilidade individual". Isso significa: até um Mini Cooper será sempre premium no seu setor, nunca tentaremos competir com a Hyundai. Não faremos ônibus ou caminhões. Enxergamos serviços, como o leasing ou o aluguel de última hora (a Drive Now como uma joint venture entre BMW e Sixt), como sendo tão importantes quanto a produção de carros. E não estamos pensando somente em motores a combustão. Isso é válido até hoje.

Por outro lado, as questões não resolvidas da orientação estratégica podem ter um impacto devastador na eficiência e no espírito ágil da equipe. Uma empresa de software está desenvolvendo um produto de última geração do zero. A composição dos investidores da empresa mudava com frequência e os clientes atuais queriam usar a perspectiva da nova geração de produtos como alavancagem para renegociar os contratos existentes, que eram enormes.

Como consequência disso, a direção oscilou entre "substituir o produto existente por um que priorize as grandes corporações" ou "ir para o mercado de massa antes e migramos as grandes corporações depois". Essas inseguranças e mudanças de prioridades eram tão fundamentais que o uso do "ágil" no desenvolvimento de software se tornou pouco eficiente e sem foco. A estratégia não fez o seu trabalho de ser um direcionador.

O retorno da mentalidade

Dessa forma, para evitar essa armadilha de adaptações cegas de processos e métodos, para preencher conscientemente as lacunas que isso deixa nos julgamentos individuais, é importante desenvolver a mentalidade apropriada. O manifesto ágil é um texto que fala sobre a mentalidade e, muito conscientemente, evita ser um livro de receitas. Já vi equipes se beneficiarem por voltarem aos 12 princípios do manifesto e descobrirem o que esses princípios significam para eles. Ao mesmo tempo, é um modelo normativo: há uma quantidade de declarações que dizem "isso é melhor" ou "faça isso". Se quisermos aplicar isso ao próprio contexto, temos que descobrir, para cada declaração, por que isso é uma boa ideia.

É aqui que o sentido do propósito e a criação de um foco comum entram na jogada novamente, e onde o entendimento sobre a origem da complexidade vem a calhar. Um participante de um dos meus treinamentos disse depois de seis meses: "Olho as situações de uma forma diferente agora". Não é uma ferramenta ou método de precisão, mas uma competência que leva a um impacto específico em um contexto específico. Deixe-me ilustrar como a mentalidade correta pode preencher a lacuna entre o framework estrutural e o contexto individual.

Agilidade corporativa: a necessidade de uma linguagem comum

A relação entre estrutura e mentalidade ganha importância quando pensamos em escalar a agilidade por toda a corporação. A essência do ágil está no desenvolvimento de software. Se quisermos expandir isso para obtermos uma corporação ágil, seria insuficiente ensinar a toda a equipe os métodos e processos. Soube de um departamento de pesquisas em uma empresa farmacêutica que introduziu o modelo do Spotify em um workshop de três horas e achou que o trabalho estava feito. Para mim, isso é a garantia do ágil zumbi. Precisamos abordar a mentalidade e, mais especificamente, o "para quê" do ágil, de forma que as pessoas possam vincular o propósito da transformação às suas necessidades. As pessoas querem entender o suficiente para poderem decidir quais métodos podem aplicar em outros contextos, como precisam construir seus próprios frameworks ágeis e, até mesmo, como o ágil não é uma boa ideia.

Em um dos meus clientes no mercado de telecomunicações, isso foi aplicado num nível mais macro do desenvolvimento da corporação. Foram permitidos (e não obrigados) alguns experimentos locais com várias estruturas organizacionais diferentes. As restrições organizacionais foram mantidas muito amplas, de forma a apontar onde a ausência de rigidez, e algumas vezes compatibilidade entre várias partes da organização, se tornou um problema. Decidiram viver com esse problema pelo tempo necessário para muitos dos experimentos perderem o sabor de novidade e alcançarem um nível suficiente de maturidade que os permitissem tirar conclusões válidas do tipo "se pudéssemos recomeçar, faríamos ...". Por essa base, agora estão encorajando o surgimento de formas organizacionais mais padronizadas e reguladas. Na próxima fase, o esperado é que as organizações que estão insatisfeitas com seus experimentos migrem para o novo padrão. Ao longo de todo o tempo dos experimentos isso demanda uma grande dose de paciência e tolerância à variedade de muitos participantes-chave. Ao mesmo tempo, a burocracia cega e a resistência à mudança são mantidas em um mínimo.

Se quisermos que esse tipo de transformação contextual e aberta aconteça, precisamos de uma linguagem comum e abstrata o suficiente para que muitos diferentes contextos da corporação consigam ser mapeados dentro disso, mas ao mesmo tempo clara o suficiente de forma que as pessoas consigam, com um mínimo de esforço, voltar dos conceitos comuns e traduzi-los para algo específico que possam realizar amanhã, em seus próprios ambientes.

É aí que o Amber Compass entra em cena: um conjunto de princípios, atividades e ferramentas que ajuda as pessoas em todos os níveis de uma corporação a dominar a complexidade.

Um corrimão para a competência: o Amber Compass

O Amber Compass é como um corrimão que o guia na direção certa, sem ser muito prescritivo, veja como um convite para se pensar de outra forma. Ele se baseia muito no trabalho de Dave Snowden, na verdade, algumas pessoas da Cognitive Edge estão envolvidas no seu desenvolvimento desde o começo. Em seu núcleo, está o entendimento de complexidade, representado pelo framework de Cynefin. Esse é um bom ponto para se começar, pois trata-se de um modelo de contingência: Ao invés de dizer "Tudo é complexo, portanto faça isso", o modelo diz "Dependendo da situação, escolha o curso de ação apropriado". Se usarmos isso como um ponto de partida para entendermos mais sobre o que é fundamentalmente diferente entre ordem e complexidade, então estamos em um caminho útil para desenvolvermos modelos mentais mais inteligentes sobre complexidade.

O próximo círculo inclui os princípios que ajudarão a focar as ações. Os exemplos de agilidade anteriores se conectam a muitos desses princípios, como remover filtros e ajustar a granularidade, mas também uma autonomia alinhada: como podemos delegar as decisões de forma que a corporação possa reagir a eventos imprevisíveis e excepcionais, enquanto, ao mesmo tempo, mantém um curso de ação comum à corporação? Atualmente, trabalho com uma empresa no ramo de semicondutores em que estamos lentamente delegando a autoridade da tomada de decisões para as equipes. Ao mesmo tempo, temos que trabalhar duro para aumentar a consciência comum sobre como funciona o negócio, e, portanto, qual o foco comum que todos devem ter. Isso não é feito por meio de diretivas gerais, mas sim por meio da discussão comum de exemplos do dia a dia das equipes.

Finalmente, o círculo mais externo representa as atividades nas quais podemos engajar. Algumas delas também já mencionamos: experimentação, ou gerenciamento de limitações. É claro que, a imagem da bússola, é somente um lembrete visual. Mas mesmo que cada palavra chave seja explicada, o processo funciona de uma forma que permite vários tipos de abordagens, métodos e ferramentas, enquanto que, ao mesmo tempo, dá uma ideia de qual direção seguir. Então, fundamentalmente, a bússola é um vetor e é adaptável a muitos contextos. Aqui vão alguns exemplos:

Em uma empresa que, por qualquer razão, se recusou a ter uma estratégia clara em papel, e o gerente de desenvolvimento de pessoal se deu conta de que tinha que "gerenciar limitações" de forma mais rígida em seus sistemas, como o modelo de competência, programas de desenvolvimento de liderança, etc, porque esses eram lentos e caros para serem mudados. Então criou uma estratégia de desenvolvimento de pessoal que se tornou uma âncora informal para muitas outras unidades e processos que estavam desesperados para se conectarem a algo estável, falando em termos de complexidade, esse gerente criou um atrator.

Um gerente de testes de hardware, de forma a reduzir as reclamações a volta de faturas internas, substituiu uma regra rígida, e portanto inaplicável, que dizia "se nossa oferta interna não for confirmada por escrito antes do teste, o teste será cancelado", por uma outra regra mais flexível e com mais bom senso, ou seja, um vetor, que dizia "sempre se assegure de que o consumidor interno tenha expectativas realistas."

Da minha parte, inclusive, tive uma discussão sob o ponto de vista de um professor de primário, sobre a atividade "explore a exploração"; era sobre o equilíbrio entre as rotinas, as quais ajudavam a classe a se preparar para um tipo de trabalho mais rapidamente, e formatos de aula novos, individuais e às vezes espontâneos, que eram mais bem adaptados a situações específicas.

É aí que vejo a conexão para expandir o ágil para toda a corporação. Precisamos nos desvencilhar dos métodos e estruturas, entender como funciona o ambiente de trabalho e em que focar, e então podemos voltar e decidir quais métodos copiar e quais fazer de forma diferente, porém compatível.

Continuando a partir daqui: desenvolvendo sua própria esperteza sobre complexidade

O Amber Compass, e o treinamento Navegando a Complexidade sobre ele, são tentativas de cobrir um pouco de espaço em branco no mapa. Muitas coisas que se acham sobre complexidade ainda são muito acadêmicas e teóricas. Ainda resta muito a se fazer para preencher as lacunas até a prática, sem cair nas armadilhas dos livros de receita. Uma forma que estamos usando para tentar aumentar essa prática é com o uso de jogos de cartas, que nos deixam discutir eventos práticos do dia a dia, como tráfego ou vizinhanças, e os conectar a complexidade, de forma que no final, quando deparamos com um framework teórico, teremos termos genéricos para conclusões que já havíamos obtido. Por exemplo, temos um vídeo no Youtube que deixa explorar o Framework Cynefin com a ajuda de diferentes formas de fazer compras (Cynefin Framework with the help of different ways of shopping).

Se preferir livros, alguns de leitura mais fácil são o "Harnessing complexity" por Robert Axelrod e Michael Cohen e o "Embracing Complexity" por Jean Boulton, Peter Allen e Cliff Bowman. Ou os muitos vídeos no YouTube de Dave Snowden. Também gosto de livros sobre exemplos práticos, como o "Team of teams" de Stanley McChrystal, o "Six simple rules" de Yves Morieux ou até mesmo o "Complexitools" de Niels Pflaeging.

Uma desvantagem que vejo nisso é que tornamos meio que um buquê de flores, no que falta é a ordem. Sejamos claros: sua pergunta mais urgente é "Ok, mas o que posso fazer agora, aqui?", e em um contexto de complexidade, não existe uma resposta genérica para sua pergunta. Mas podemos tentar simplificar. Espero que o Amber Compass preencha esta lacuna, ao funcionar como um caso de tipo, pois dá um lugar para ordenarmos os exemplos e ideias. Assim, podemos operar o próprio ciclo de aprendizagem: tentamos uma abordagem específica que leva a uma experiência específica dentro de um contexto. Conectamos isso a uma categoria ou conceito genérico, de forma que possamos achar isso de novo quando conversarmos com outras pessoas, ou quando conectarmos outro contexto a esta categoria. Não iremos simplesmente copiar e colar uma abordagem, ao invés disso, pensaremos sobre como o novo contexto poderia justificar certos usos e adaptações dessa experiência. É por isso que, por exemplo, em esportes como o surf, snowboard e skate, o aperfeiçoamento em um deles rapidamente leva a novos, porém diferentes, avanços nos outros. Chame de curiosidade consciente se quiser. E com o tempo se tornará melhor e melhor.

Sobre o autor

Bernhard Sterchi da Palladio Trusted Advisers, é treinador de líderes, coach e desenvolvedor de organizações. É o autor do www.teleadersfairytales.com.