Muitas organizações estão tentando implementar métodos ágeis e buscado aplicar práticas Scrum, Kanban, Squads e Lean no seu dia a dia de projetos e operações de TI. Entretanto, várias organizações tem falhado semana após semana nessas tentativas. Apesar das reuniões diárias, papéis estruturados como o PO e SM, pessoas trabalhando em contato físico permanente e ambientes modernos para atender as insatisfações das gerações Y e Z, vários gestores não tem observador melhoria efetiva nos resultados de negócio.

Se você está vivendo essa realidade, você pode estar contaminado por um terrível vírus que transformou o seu processo em uma coisa chamada Agile Zombie.

Agile Zombie

São sintomas comuns do Agile Zombie:

1. Não existe coração pulsante

Times Agile Zombie repetem ritos, mas não existe entrega frequente de software em produção. Em equipes ágeis saudáveis, entendemos que ter um fluxo contínuo de software entregue não é apenas uma boa ideia, mas um objetivo fundamental do método. O Agile Zombie aborda isso de forma diferente. Para eles, é sempre muito complicado fazer entregas intermediárias e sempre existem respostas prontas para dizer porque isso não é possível.

   2.  Sem resposta emocional a fracassos e sucessos

Como um corpo sem vida, as equipes do Agile Zombie não mostram resposta a um Sprint fracassado ou bem-sucedido. Onde outras equipes amaldiçoam ou se alegram, elas simplesmente mantêm seu olhar vazio. O moral da equipe é muito baixo. Itens do Sprint Backlog são transferidos para o próximo Sprint sem questionamentos. Porque não? Há sempre um próximo Sprint e as iterações são artificiais de qualquer maneira.

   3. Sem força de vontade para melhorar

No Agile Zombie não há alegria e certamente não há necessidade de melhorias. E ninguém parece se importar. O Product Owner não está normalmente presente durante a Revisão da Sprint ou o Planejamento da Sprint. As equipes são altamente instáveis, pois os membros são continuamente emprestados a outras equipes que precisam de suas habilidades (especializadas). Os desenvolvedores possuem desculpas prontas sobre o porque eles não tem tempo para fazer testes de unidade e os testadores também tem desculpas prontas sobre porque eles insistem em usar documentos Word para organizar casos de testes. Alguns dos gargalos podem ser reais, enquanto outros podem ser imaginados. E isso facilmente se traduz em retrospectivas chatas com  muitas reclamações. E certamente nenhum desejo de melhorar. Os sentimentos de sarcasmo, cinismo e desânimo são muito comuns.

Afinal, de quem é a culpa? Preciso trocar o meu time ou aquele mala que trabalha comigo?

Times ágeis são estruturas complexas, i.e., o seu poder vem das interações entre as pessoas que as formam e das interações entre essas pessoas com o ambiente, estruturas e crenças culturais. E isso implica que usemos instrumentos apropriados para compreender como eles realmente funcionam. O pensamento sistêmico nos ensina que na vasta maioria dos casos o problema não está nas pessoas, mas em elementos mais profundos e normalmente não óbvios.

E se você vive o Agile Zombie na sua organização, vamos conhecer um poderoso antivírus para esse sintoma, que é uma ferramenta do pensamento sistêmico chamado de Modelo Iceberg.

Modelo Iceberg

Eventos

Um software com incidentes críticos em produção ou uma pessoa que reclama muito são exemplo de eventos dentro do modelo Iceberg

Acima da linha de água estão os eventos. Os eventos são marcadores no tempo em que várias variáveis ​​são observadas. Elas são o “o que aconteceu” ou “o que vimos”.  Ao aplicarmos o Modelo Iceberg às questões globais, poderíamos dizer que na ponta, acima da água, há eventos ou coisas que vemos ou ouvimos acontecendo no mundo todos os dias. Os eventos que ouvimos dos nossos clientes, gerentes e colegas representam a ponta do iceberg. A maior parte dos gerentes gasta seu tempo no nível do eventos, tentando resolver problemas não triviais como produtividade e motivação de times. E isso quase nunca funciona.

Padrões de comportamento

Padrões são as mudanças nas variáveis ​​que ocorrem ao longo do tempo. São as tendências que percebemos ao longo do tempo. Por exemplo, podemos observar um fluxo cumulativo de valor ao longo de três meses e perceber que a taxa de entrega está reduzindo. Os padrões são importantes para identificar porque indicam que um evento não é um incidente isolado. Os padrões respondem às seguintes perguntas O que está acontecendo e o que está mudando?

Quando fazemos uma declaração como “parece que estamos reduzindo o tempo gasto para implantar software em produção”, esses são padrões que estamos observando, uma série de relações entre eventos observados na linha do tempo. Quando chegamos ao nível do padrão, podemos antecipar, planejar e prever. Ele nos permite adaptar aos problemas para que possamos reagir de forma mais eficaz a eles.

Estrutura do sistema

A estrutura suporta, cria e influencia os padrões que vemos nos eventos. Estruturas podem ser entendidas como as “regras do jogo”. Elas podem ser escritas ou não escritas; eles podem ser físicas e visíveis ou invisíveis. São regras, normas, políticas, diretrizes, estruturas de poder, distribuição de recursos ou formas informais de trabalho institucionalizadas tacitamente ou explicitamente. Eles respondem a pergunta: o que pode explicar esses padrões?

Pode não ser fácil ver a estrutura, mas os padrões que podemos ver nos dizem que a estrutura deve estar lá. Estruturas são compostas de relações de causa e efeito. Estas são conexões entre padrões. Por exemplo, um desenvolvedor pode dizer: “Se eu aumentar o número de testes de unidade automatizados, terei menos problemas em produção”. Ela está dizendo que há uma conexão entre um número crescente de casos de testes – um padrão – e uma quantidade decrescente de defeitos – outro padrão.

Se você observar a causa raiz de alguns padrões, poderá começar a entender e abordar soluções sustentáveis ​​de longo prazo, como por exemplo políticas robustas de testes de regressão ou mecanismos que apoiem que pessoas se motivem.

Modelos mentais

O modelo mental usado para perceber o mundo e é o que gera as estruturas, padrões e eventos

Abaixo das estruturas estão os modelos mentais. Estes definem o pensamento que cria as estruturas que então se manifestam nos padrões dos eventos. Os modelos mentais são suposições e crenças profundamente arraigadas que, em última análise, impulsionam o comportamento de todo o time. E não existem apenas um padrão, estrutura ou modelo mental em jogo; podem haver muitos.

Os modelos mentais são as atitudes, crenças, moralidades, expectativas, valores ou cultura que permitem que as estruturas continuem funcionando como estão. Essas são as crenças que muitas vezes aprendemos subconscientemente em nossa sociedade ou família e também nas empresas e times de desenvolvimento e sustentação de software. Os modelos mentais são, em última análise, o que mantém a estrutura fazendo o que faz. São os pensamentos e processos de raciocínio que precisam existir para fazer com que a estrutura seja como é. Essas ideias existem nas mentes das partes interessadas da estrutura, das pessoas que montam a estrutura ou daquelas que desempenham um papel na maneira como ela opera. Modelos mentais são tipicamente difíceis de identificar, pois geram muitas suposições que nunca são explicitadas.

Ao mesmo tempo, se você trabalhar e for bem sucedido em trabalhar os modelos mentais dos gerentes e dirigentes de uma organização, você irá permitir que todo um novo conjunto de estruturas, padrões e eventos possam ocorrer.

Exemplos de Uso do Modelo Iceberg

Cliente “Mal Educado”

Ao invés de reclamar que o seu cliente é mal educado, pare e pense por um momento no sistema onde ele trabalha e na pressão que ele recebe em base diária dos chefes e clientes deles. Observe também os sistemas pessoas dessa pessoa, como condições de vida, família e outros fatores.  Ao fazer isso você poderá ter uma compreensão mais profunda sobre os comportamentos observados, que são apenas os efeitos (e não as causas).

Aquele seu colega lambão que entrega muito defeito

Ao invés de reclamar que o seu colega entrega muitos defeitos, busque compreender o sistema de incentivos onde ele trabalha. Por exemplo, se ele é incentivado para entregar no prazo para receber bonificações financeiras, é perfeitamente esperados que ele entregue código com muita rapidez .. e com defeitos de brinde. Ou você pode se questionar se ele foi treinado em práticas de código limpo ou até mesmo se ele aprendeu na prática como fazer código limpo com um mentor em algum projeto.

Um Caso Real 

Vamos omitir o nome da empresa, para sermos educados. E nessa empresa existe uma tribo com várias Squads que estão lutando com todas as suas forças para implementar práticas de Squads e acelerar a implantação do Scrum e Kanban.

E, apesar das tentativas repetidas de uma pessoa bastante competente, os resultados são ruins. A taxa de defeitos é muito alta e o moral do time é muito baixo.

Conduzi nessa organização uma análise com o modelo Iceberg e chegamos a alguns resultados interessantes, resumidos abaixo.

Eventos

• Pessoas reclamam e demonstram atitudes cínicas.
• Sprints falham.
• Produtos lançados em produção tem um índice alto de defeitos.
• Clientes reclamam e alguns deles o fazem com muita agressividade.
• O gerente interrompe os analistas que ousam gerar reclamações, no meio de suas falas.
• A gerência discute com o time de arquitetura como o produto deve ser desenhado e implementado.

Padrões

• O moral do time está reduzido, devido a contaminação do ambiente pelas críticas ao longo do tempo.
• O produto está atrasado e a taxa de chegada de novos requisitos é maior que a taxa de saída.

Estruturas

• As áreas de negócio não se envolvem e não tem “tempo” para interagir com os times
• A gerência sênior delega todo o problema para o gerente de projeto, que atua colocando ainda mais pressão no time.
• A gerência sênior bonifica o time pelo cumprimento de datas, a qualquer custo.
• A gerência apartou o time de testes do time de desenvolvimento. Eles se comunicam primordialmente com emails e documentos Word.

Modelos Mentais

• A gerência acredita no micro-gerenciamento, especificando o que fazer e impedindo que os times introduzam práticas técnicas “estranhas” ao conhecimento dele.
• A gerência acredita em hierarquias rígidas e no modelo do Management 1.0
• A área usuária acredita que projetos devem atender simultaneamente o custo, escopo e o prazo, ainda que esse compromisso tenha sido feito com informações precárias em um documento de 1 página.
• Vários desenvolvedores e testadores acreditam que eles devem receber comandos claros e o que trabalho deles termina no comit do código (time de desenvolvedores) e na geração de defeitos (time de testes)

Ao analisar esse caso, vemos que o modelo de incentivo da diretoria induz comportamentos de micro-controles em alguns gerentes médios, que por sua vez propagam e criam força a uma cultura comando e controle aumenta o nível de passividade de várias técnicos do time.

Aplicando Mudanças com o Modelo Iceberg

O modelo Iceberg não apenas ilustra as diferentes dimensões de um problema, mas também oferece uma visão sobre como implementar mudanças de maneira mais eficaz dentro do sistema, através dos chamados pontos de alavancagem.

Um ponto de alavancagem é um lugar dentro de um sistema – uma organização, uma economia, um corpo vivo, uma cidade, um time -, onde uma pequena mudança em uma coisa pode produzir grandes mudanças em tudo. Quanto mais baixo nós vamos no iceberg, mais alavancagem teremos para transformar o sistema. Mudar estruturas e influenciar modelos mentais tem um efeito mais amplo e mais abrangente do que reagir no momento e eventos discretos de combate a incêndios.

1. Mudança no nível dos Eventos – Efeito: Reação

   Se apenas olharmos para os eventos, o melhor que podemos fazer é reagir. Algo acontece e nós consertamos. Essa é tipicamente nossa resposta na primeira vez que um evento ocorre. Nós não mudamos nosso pensamento de forma alguma; Nós apenas agimos rapidamente para corrigir o problema imediato usando soluções pré-existentes que funcionaram no passado. Para alguns eventos superficiais, esta abordagem pode funcionar bem, mas falhará claramente se uma questão é mais sistêmica, pois estamos apenas lidando com os sintomas do problema, não com as causas subjacentes.

   A metáfora do iceberg ajuda a ilustrar que, se de alguma forma alteramos o evento no topo sem encontrar uma solução para a causa, a flutuabilidade do gelo por baixo simplesmente empurra para recriar a ponta novamente. Como tal, apenas os problemas mais superficiais podem ser resolvidos neste nível.

2. Mudança no nível de Padrões de Comportamento – Efeito: Antecipação

   Quando começamos a notar um padrão em uma série de eventos, temos mais opções. Podemos antecipar o que vai acontecer e podemos planejar isso. Quando começamos a perceber padrões, podemos começar a considerar o que está fazendo com que os mesmos eventos aconteçam repetidamente.

   Por exemplo, você observar que liberações sem testes de regressão irão trazer um alto volume de incidentes no mês seguinte. E isso lhe permite estabelecer no futuro estratégias de testes e práticas de qualidade contínua para se antecipar a esses problemas.

3. Mudanças no nível da Estrutura – Efeito: Redesenho

   Quando começamos a prestar atenção às estruturas subjacentes, começamos a ver onde podemos mudar o que está acontecendo. Nós não estamos mais à mercê do sistema. Podemos começar a identificar o pensamento e os modelos mentais que estão causando essas estruturas a serem do jeito que são.

   Por exemplo, podemos ter uma estrutura de desenvolvimento onde os usuários chave estão em contato diário com o time de desenvolvimento e possuem tempo semanal dedicado para gerar feedback dos produtos. E isso permite que novos padrões de construção floresçam, que irão reduzir muito retrabalho de requisitos e reduzir defeitos.

4. Mudanças no Nível dos Modelos Mentais – Efeito: Transformar

   Mudar o modelo que uma organização usa é o ponto de alavancagem mais alto, pode levar a uma transformação real, com a possibilidade de reestruturar totalmente o sistema e superar até mesmo desafios complexos.

   Por exemplo, quando você tem um time cujo gerente “comando e controle” foi removido e agora você tem um líder que promova discussões aberta e transparência radical para tratar e resolver problemas, você consegue criar um ambiente de aprendizado verdadeiro e mais resiliente para lidar com as pressões.

Em resumo, o pensamento sistêmico nos convida a parar de reclamar das pessoas pelo ato de reclamar e estudar os motivadores diretos e indiretos que levam as pessoas a fazer o que elas fazem. Os atos que você observa são apenas eventos. Julgar os eventos sem entender os padrões,  estruturas e modelos mentais é raso e normalmente não vai resolver nada que seja realmente complexo.

Efeitos da Aplicação do Modelo Iceberg

As regras do jogo mudam quando você começa a jogar

Quando você incorpora o espírito de times ágeis, você compreende que o seu trabalho é não linear, i.e., que regras que anteriormente valiam podem ser invalidadas no meio do jogo. Por exemplo, você pode perder aquele excelente desenvolvedor de backend que foi trabalhar em uma outra empresa. Ou você pode ter parte do seu escopo invalidado por uma regulamentação que acabou de chegar do governo. Aceitar a imprevisibilidade e desenvolver mecanismos de adaptação a mudança são fundamentais para fazer com que as Squads prosperem.

Você pode estar errado

Outra regra importante do pensamento sistêmico diz que mesmo que você seja muito experiente, você pode fracassar. Você pode ter executado uma prática com sucesso em vários locais, mas pode falhar miseravelmente na próxima iniciativa. Ou seja, ter a mente aberta para tratar seus movimentos ágeis como hipóteses e buscar validar essas hipóteses o mais rapidamente possível é crítico para prosperar.

Você pode ter efeitos colaterais

Quando você está experimentado com uma Squad, você deve ter ciência que seus movimentos podem gerar efeitos colaterais, também chamados de consequências não-intencionais. Esteja aberto para avaliar os efeitos de segunda e terceira ordem das suas mudanças e crie um ambiente de banda larga

Você deve envolver muitas pessoas, continuamente.

Não é fácil mudar o modelo mental e estruturas e você deve envolver muitas pessoas para discutir as mudanças e debater o que deve ser realizado. Crie instrumentos de meritocracia para avaliar quais são as pessoas que estão realmente aptas para contribuir com mudanças e lhe ajudar a estabelecer pontos de alavancagem firmes.

Dicas para Operar Mudança no Nível dos Modelos Mentais

1. Descubra o que é REALMENTE importante para as pessoas, ignorando o que dizem que é importante.

2. Incentive as pessoas nas dimensões que são valiosas para elas, mas quem podem ser facilmente proporcionadas por você.

3. Preste atenção à maneira como reagem. Se você ficar frustrado ou surpreso com suas reações, trate de aprender com elas e experimentar algo diferente

4. Crie incentivos que mudem as estruturas de antagônica para cooperativa.

5. Nunca acredite que as pessoas farão algo simplesmente porque é a coisa certa.
   
6. Saiba que certas pessoas farão tudo que estiver ao seu alcance para manipular o sistema, encontrando maneiras de vencer que você jamais havia imaginado. Esteja preparado para isso e se adapte.