Como usar o Método Kanban no Inferno com a ajuda do KMM

Talvez você, leitor, trabalhe em um ambiente infernal. No trabalho do submundo podemos observar os seguintes sintomas.

  • Tudo é prioridade;
  • Você sempre tem mais trabalho para fazer do que a sua capacidade;
  • As entregas são sempre para ontem;
  • Ninguem assume responsabilidade e a cultura da culpa é permanente;
  • Existem brigas diárias de vaidade entre os velhos demônios que criaram o inferno onde você trabalha;
  • Todo dia aparece um diabo novo para satisfazer.

Se você nao se identificou, que bom. Você não trabalha no inferno. Você pode sair da leitura e voltar a tocar harpa por toda a eternidade.

Mas se você se identificou, continue lendo para aprender como gerir o seu trabalho no inferno.

Princípios Gerais 

Antes de aprendermos a usar a ferramenta do modelo de maturidade Kanban, o KMM, precisamos estar cientes de alguns princípios.

  1. O inferno continuará sendo o inferno. Você não irá transformar o inferno em um paraíso, mas pode controlar o seu cercadinho intelectual. Os seus pensamentos são seus e você pode organizar como você irá responder a cada desafio trazido.
  2. O inferno continuará sendo habitado por capetas, ogros e trolls. Mas isso não quer dizer que você precise reagir de forma ruim aos eventos que ocorrem com você. A resposta a cada evento é sua responsabilidade, como reafirmei acima.
  3. Você é o principal responsável. Enquanto quiser trabalhar onde está, você é responsável por fazer o melhor trabalho possível mesmo em cenário de adversidade. Se estiver realmente infeliz e não quiser organizar o seu trabalho, seja honesto com você. Peça contas e deixe a empresa onde está viver na sua própria miséria.

Aplicando o KMM no Inferno

Já descrevi o KMM aqui em um post anterior. Caso não tenha lido, deixo o link aqui.

“O Kanban Maturity Model consolidada mais de 10 anos de experiência na implementação do Kanban em diversos setores, em empresas de pequeno a grande porte. Use-o para obter um melhor senso de realização, fornecer melhores produtos e serviços, encantar seus clientes e obter resultados de negócios superiores.”, David Anderson

Vamos explorar aqui as práticas do nível inicial do KMM, resumida na figura abaixo. No nível zero, que pode ser livremente traduzido como Desatento ou Absorto, temos o nosso trabalho muito desorganizado e precisamos fazer sentido do que fazemos dia após dia. Na dimensão cultural, estamos buscando propósito (Achievement).

Para isso, vamos trazer as práticas ao longo de cinco colunas que se aplicam nesse nivel.

  • Visualização do Trabalho
  • Limitação do Trabalho em Progresso
  • Gestão do Fluxo
  • Políticas Explícitas
  • Laços de Feedback

Visualização do Trabalho

Você deve explicitar o seu trabalho e para isso vai criar um quadro pessoal. Comece simples e tenha três colunas (A Fazer, Em Execução, Finalizado).

Cada pedido, seja de quem vier e pelo modo que vier, deve ser explicitado.

Chegou um telefonema do seu chefe demônio nível 2? Sem problemas. Coloque no seu Kanban.

Chegou uma solicitação do seu cliente mefistóteles nível 4. Sem problemas. Ouça com atenção e registre o pedido dele no seu Kanban.

Chegou agora um pedido no meio do cafézinho do satanás nível 6. Sem problemas. Escreva o pedido em um guardanapo. Ao voltar para a sua mesa, registre o seu pedido.

As regras são simples:

  • Cada pedido é registrado como um cartão.
  • Todo pedido é explicitado. Nada fica opaco e perdido em algum email.

Você pode operacionalizar o Kanban em uma ferramenta simples com o Trello. Mas se possível use uma folha A3 e a deixe na sua mesa. Ou afixe na parede se você tiver permissão para tanto. Afinal, em muitos infernos as paredes são imaculadas e não podem ser usadas. Mas, seja como for, o seu trabalho está agora visível e explicitado para todos.

Limitação do Trabalho em Progresso (WIP)

Você (e ninguém no planeta terra) não consegue fazer muitas coisas simultaneamente.  Não apenas isso é impossível devido como o nosso cérebro foi desenhado pela evolução. Mas isso é também danoso para a sua saúde intelectual e responsável por estresses crônicos e perdas massivas de produtividade.

O método Kanban nos ensina que limita o trabalho simultâneo é bom para sua produtividade. E então você deve limitar a quantidade de trabalho simultâneo que você aceita fazer. Comece com um número pequeno (exemplo. WIP LIMIT = 3) e busque descer para o celestial número 1.

Por exemplo, se você tem WIP LIMIT 1 e um diabo importante chega como uma urgência muito urgente, você cita que todo o trabalho em curso será impactado. Se isso for realmente urgente e confirmado pelo seu gestor, você cria um cartão para isso, coloca o cartão no topo da sua lista, interrompe o trabalho em curso e informa a todos que os outros trabalhos foram paralisados devido a urgência.

Ao ser cobrado pelo trabalho que estava em curso anteriormente, você irá ser metódico e reportar as interrupções que dragaram a sua atenção. E se você for muito interrompido durante um dia, a perda de produtividade será uma consequência natural e isso deve estar muito claro para o seu gestor. Que fique claro para ele como o sistema de interrupções no seu trabalho está afetando a sua produtividade.

Ao mesmo tempo, não devemos ser hipócritas em culpar nossa chefia pela interrupções e depois virar para o lado e abrir o Facebook e Whatsapp a cada 10 minutos. A autossabotagem não é legal e você não pode culpar a sua empresa se você mesmo está criando o seu inferno particular. Se precisar de ajuda, te recomendo esse livro aqui.

Gestão do Fluxo

Você pode ter 30 tarefas para fazer, mas deve ficar claro qual a mais importante nesse exato momento. E esse sistema de classificação deve ser acordado com todas as pessoas da sua organização.

Por exemplo, você pode começar um sistema simples onde você identifica o que é urgente. Ou você pode usar um sistema de priorização com classificação Alta, Média e Baixa. Uma outra técnica é a Matriz de Einsenhower, mostrada abaixo e popularizada no excelente livro Os Sete Hábitos, do Stephen Covey.

Seja qual for o seu sistema, deve haver uma priorização explícita em todo o seu trabalho e acordos claros com suas chefias.

Cuidado. Você terá a sua fé testada e será tentando.a quebrar o seu próprio sistema. Faça isso e você irá queimar em óleo quente por sua própria fraqueza moral. Defina e acorde o seu sistema de priorização e jogue pela regras que você mesmo definiu.

Políticas Explícitas

“O combinado não é caro”, Ditado Popular

Crie e publique as políticas do seu trabalho pessoal. Vou trazer exemplos reais de pessoas da minha rede que definiram:

  • Horários e tempo para horário de almoço.
  • Saída do horário de trabalho
  • Intervalos de descanso durante o trabalho
  • Formas de receber trabalho (e para muitos, whatsapp e conversa de corredor não é uma delas)
  • Tempo para responder a emails. (Email é mecanismo assíncrono de comunicação, afinal de contas)
  • Políticas de priorização de trabalho
  • Atendimento do trabalho (ou não) durante horários no final de semana.

Explicite as políticas e as deixe visíveis no seu Kanban pessoal.

Ou não e seja um profissional “passivo agressivo”. Eles não explicitam seus acordos de trabalho, fazem coisas que não querem, comprometem o seu trabalho e a sua vida pessoal e depois ficam reclamando na rádio peão igual a meninos birrentos de 5 anos. Conheço muitos deles,  que nunca dizem não para seus clientes internos e chefes e culpam as empresas porque nunca conseguem entregar nada.

Laços de Feedback

Se você faz sempre as mesmas coisas, não espere resultados diferentes, Albert Einstein

Todo profissional deve periodicamente observar o seu trabalho em nível pessoal e perguntar:

  • O que está bom?
  • O que está ruim?
  • O que posso melhorar?

Mas não faça isso em pensamento. Abra o seu caderno de anotações, Evernote, One Note, Notepad ou qualquer outro meio e registre isso.

Eu faço isso em base diária por 10 minutos antes de sair de casa. E recomendo que você faça o mesmo, mesmo que seja em base semanal. Ao sistematizar e anotar o que podemos melhorar, tornamos a melhoria contínua um hábito, geramos melhor consciência situacional no nosso cérebro (sistema reticular) e estamos menos sujeitos a cometer os mesmos erros em situações do dia a dia.

E não se preocupe com o tamanho da melhoria. Melhorias, mesmo que incrementais, se aplicadas sistematicamente geram grandes retornos. É o famoso efeito de juros compostos, já demonstrado na teoria de sistemas econômicos.

Resumo – Como controlar o trabalho infernal no nível pessoal

O KMM no nível zero traz bons aprendizados para você domar o seu trabalho e lidar com os capetas que trabalham com você.

Resumo as lições abaixo

  • Visualização do Trabalho. Crie um quadro Kanban para o seu trabalho. Deixe ele visível. Registre tudo que chegar lá.
  • Limitação do Trabalho em Progresso. Controle o paralelismo e interrupções pessoais. Crie foco no seu trabalho. Comunique a todos o impacto das interrupções nos seus acordos. Não entube a desorganização alheia ou você irá fritar.
  • Gestão do Fluxo. Crie priorização para tudo. Acorde o seu sistema de prioridade. Siga suas regras.
  • Políticas Explícitas. Explicite como você trabalha, como você recebe o seu trabalho e quando você não está disponível. Combinado não é caro, certo?
  • Laços de Feedback. Periodicamente pare e reflita sobre como você pode melhorar. Registre seus aprendizados e crie um hábito de Journaling.

“Entre o estímulo e a resposta, existe um espaço. Nesse espaço existe o poder de escolher a nossa resposta. Na nossa resposta está o nosso crescimento e nossa liberdade”, Victor Frankl, o Sentido da Vida.

Criando Antifragilidade com sistemas Kanban e o KMM

Coisas frágeis, resilientes e antifrágeis

No seu livro chamado Antifrágil – Coisas que se beneficiam do Caos, Nicholas Taleb oferece algumas heurísticas simples para ajudar as empresas e os indivíduos a prosperar em uma vida agitada com volatilidade. Antes de fazer isso, Taleb argumenta que pessoas / sistemas / organizações / coisas / ideias podem ser descritas de uma das três maneiras: frágil, resiliente ou antifrágil.

Coisas que são frágeis quebram ou sofrem com o caos e aleatoriedade. Sistemas, pessoas e coisas frágeis procuram tranquilidade porque têm mais a perder do que ganhar durante tempos incertos. Mas no mundo VUCA em que vivemos, não existem águas calmas por muito tempo.

O resiliente, ou robusto, não se importa se as circunstâncias se tornaram voláteis ou perturbadoras (até certo ponto). Eles permanecem estáveis em tempos de adversidade e tranquilidade. A resiliência, ou robustez, é certamente mais desejável que a fragilidade. Devemos fazer tudo o que pudermos para tornarmos a nós mesmos, nossos negócios e nossa sociedade mais resilientes diante da volatilidade. Mas Taleb argumenta que apontar apenas para a resiliência é frouxo. Isso porque você está essencialmente se conformando com o status quo. Claro, quando as coisas são resilientes, você se recupera da adversidade, mas acaba se recuperando do estado em que estava antes da queda.

Para ser verdadeiramente eficaz em um mundo em turbilhão com complexidade, aleatoriedade e risco, você não pode parar no estado de resiliência. Sempre que puder, você deve sempre encontrar oportunidades para realmente crescer a partir de desordem, volatilidade e adversidade. O objetivo deve ser ir além da resiliência simples e se tornar antifrágil.

As coisas que são antifrágeis crescem e se fortalecem com a volatilidade e o estresse (até certo ponto). Quando pessoas ou sistemas são antifrágeis, há mais vantagens do que desvantagens quando ocorrem eventos aleatórios e caóticos.

Como Taleb aponta várias vezes ao longo do seu livro, a natureza fez um trabalho fantástico implantando a antifragilidade em organismos e sistemas. Nossos corpos possuem antifragilidade incorporada de várias maneiras (músculos e ossos, por exemplo).  Outro exemplo é como nosso corpo responde ao jejum. Quando ficamos sem comida por longos períodos de tempo, nosso corpo libera hormônios que realmente nos tornam mais fortes e mentalmente mais aguçados. Essa resposta antifrágil faz sentido. Nossos ancestrais de homem das cavernas evoluíram numa época em que a aquisição de alimentos era escassa e aleatória, de modo que nossos corpos evoluíram para se adaptar a esse ambiente.

Taleb também argumenta que as tradições humanas têm antifragilidade dentro delas. Mas eles se desenvolveram por uma razão e sobreviveram por muito tempo porque serviram a algum propósito. De acordo com Taleb, as tradições são muitas vezes apenas heurísticas testadas pelo tempo que tornam a vida em um mundo aleatório e volátil gerenciável. Por exemplo, os ritos de passagem têm sido empregados em culturas de todo o mundo para permitir que os rapazes tenham uma noção clara de quando se tornaram homens e assumem responsabilidades adultas, em vez de deixá-los confusamente chegarem à idade adulta. Através dessas cerimônias de amadurecimento desafiadoras e muitas vezes dolorosas, um jovem emerge mais forte do que antes.

Esse poderoso conceito é resumido na figura abaixo. O mito da espada de Democles representa algo frágil, que pode morrer a qualquer momento. A mítico pássaro Fênix representa algo resiliente. E o mito da Hidra represente o antifrágil.WhatsApp Image 2019-05-22 at 14.03.49

 

Diretrizes para reduzir a fragilidade do meu time e empresa 

Algumas diretrizes gerais para atacar a fragilidade incluem:

  1. Injetar intencionalmente o estresse nos seus sistemas, pessoas e times. Sistemas periódicos de feedbacks e aumento da inteligência emocional das pessoas são exemplos desse princípio.
  2. Adicionar redundâncias no seu time e nos seus sistemas. Falhas irão ocorrer. Pessoas podem deixar a sua empresa a qualquer momento. Sistemas podem falhar. Eventos ruins podem acontecer a qualquer momento. E você deve estar preparado para isso.
  3. Empregar a “estratégia dos halteres”. Taleb descreve a “estratégia dos halteres” como “uma atitude dupla de proteção em algumas áreas e assumir pequenos riscos em outras, obtendo assim a antifragilidade”. Jogar com segurança reduz a potencial desvantagem da volatilidade e assumir pequenos riscos expõe você aos ganhos potencialmente massivos do mesmo caos. Um exemplo seria uma empresa de produtos criar MVPs com baixo investimento (lado direito do halter) enquanto ela ainda ganha dinheiro com o seu produto vaca leitera (lado esquerdo do halter).
  4. Nunca aceitar conselhos por alguém que não tenha “skin in the game/a pele no jogo”. Vivemos em um mundo em que as ações, as opiniões e os conselhos das pessoas são separadas das consequências. Aceitar conselhos, opiniões e até mesmo contratos assimétricos com clientes e fornecedores irá apenas aumentar a sua fragilidade.
  5. Praticar a Via Negativa. Os romanos estóicos e teólogos como Tomaz de Aquino sugeriam imaginar situações ruins para eventos do seu dia (Premeditato Malorum). Aquela demonstração de produto para a diretoria. A recepção ao novo MVP pelo diretor da área comercial. A situação econômica do Brasil no próximo ano. E ao imaginar desfechos ruins, você já imaginaria como seria lidar com isso.Não devemos confundir isso com negatividade ou pessimismo. Ao invés, a Via Negativa é uma técnica de antecipação de riscos e criação de planos de contigenciamentos mesmo nas piores das situações.
  6. Manter as opções em aberto. Manter as opções em aberto reduz a sua fragilidade. Possui pessoas com mais habilidades e possuir sistemas redundantes em produção são exemplos poderosos de manter opções em aberto.

Uso do Kanban e KMM para atacar a fragilidade

O método Kanban, criado por David Anderson e popularizado pela comunidade Lean Kanban, é um método leve e orgânico de promover melhoria contínua em organizações de qualquer tipo. Ele pode ser trabalhado de forma isolada ou em conjunto com outros métodos ágeis, como por exemplo o Scrum ou M3.0. E pode ser usado para organizar portifólios complexos de projetos, projetos, desenvolvimento de produtos ou até mesmo tarefas rotineiras. Isso o torna muito versátil.

Mas como podemos usar o Kanban para atacar ambientes e sistemas frágeis?

Aqui entra um recente modelo que foi desenvolvido sobre o Kanban, que é o KMM. O Kanban Maturity Model consolidada mais de 10 anos de experiência na implementação do Kanban em diversos setores, em empresas de pequeno a grande porte.  Use-o para obter um melhor senso de realização, fornecer melhores produtos e serviços, encantar seus clientes e obter resultados de negócios superiores.

O portal do KMM com recursos iniciais para praticas Kanban está nesse site: https://www.kanbanmaturitymodel.com

Um primeiro livro também já foi publicado também.

41lkdwvq3ml._sx404_bo1204203200_

O Kanban Maturity Model mapeia as práticas Kanban típicas, bem como os valores culturais em relação aos 7 níveis de maturidade organizacional. Isso o torna uma ferramenta poderosa para implementar iniciativas Kanban e ajudar as empresas a melhorar sua agilidade.
Vamos resumir os níveis abaixo.

Nível 0 — Desatento (Frágil)
A organização é alheia à necessidade de processo. Indivíduos concluem tarefas com pouca colaboração de equipe.

Nível 1 — Focado em Times
A definição do processo está surgindo, mas pode ser aplicada de forma inconsistente. Existe um conceito de equipes e colaboração, mas o alinhamento ainda é ruim. O heroismo de indivíduos é ainda comum para resolver crises.

Nível 2 — Focado no Cliente
Processos básicos, fluxo de trabalho e políticas são estabelecidos e seguidos de forma consistente, mas os resultados desejados ainda são inconsistentes. Qualidade e prestação de serviços são desiguais. Aprimoramentos como os limites de WIP por pessoa são focados internamente. O comportamento é reativo, não proativo.

Nível 3 — Moldado para o Propósito (Fit for Purpose)
Processos, fluxos de trabalho e políticas são compreendidos e consistentes. Definições de serviço e acordos são claros e definidos. Um sistema de tração kanban está em pleno funcionamento. Os resultados desejados são alcançados de forma consistente. A prestação de serviços é adequada para o propósito da organização. Os clientes estão satisfeitos

Nível 4 — Com cobertura de riscos (Resiliente)
Aqui temos o uso de métricas e loops de feedback sofisticados. Classes de serviços gerenciados ativamente e recursos compartilhados. A capacidade é deliberadamente alocada e ajustada intencionalmente. Os resultados econômicos são consistentes. Os gerentes estão satisfeitos.

Nível 5 — Líder de Mercado
Otimizado para eficiência e melhores resultados econômicos. Uma cultura de melhoria contínua surge. Uso de análise quantitativa, loops de feedback, experimentos e melhorias conduzidas pelo modelo.

Nível 6 — Desenhado para durar (Antifrágil)
Permite alinhar continuamente a estratégia às capacidades operacionais. Ele é “Construído para durar!” e pode suportar grandes mudanças do mercado.

O KMM compila, ao longo desses sete níveis, 150 práticas para você usar no seu dia a dia para melhorar times, empresas e sistemas de trabalho. Essas práticas são organizadas ao longo ds seguintes dimensões de conhecimento:

  • Gestão Visual
  • Limitação do Trabalho em Progresso
  • Gestão do fluxo de trabalho
  • Criação e explicitação de políticas
  • Laços de feedback
  • Melhoria colaborativa

Irei publicar aqui, ao longo das próximas semanas, um série de artigos sobre o KMM descrevendo as dimensões de conhecimento e níveis para lhe trazer um resumo desse livro e das suas principais práticas.

Pare de Começar e Comece a Terminar, Motto Kanban

 

O filme “O Primeiro Homem” e os aprendizados para criação de uma cultura DevOps

Assisti o filme “O Primeiro Homem” nesse final de semana. É um filme que relata a história da chegada do homem da lua na perspectiva da vida profissional e pessoal de Neil Armstrong.

Caso não tenha visto, coloquei aqui o trailer do filme.

Não sou crítico de cinema e não vou falar das qualidades e defeitos que vi no filme. Mas como agilista quero me debruçar no que a história da corrida espacial americana traz de ensinamentos para você que está buscado implementar DevOps na sua organização.

1. Objetivos Claros

No começo dos anos 60, a governo americano colocou um objetivo claro para a NASA e seus engenheiros, que era ter alguém pisando no solo da lua até o final desta década. Isso deu a todos um senso de propósito mensurável, por mais desafiante ou impossível que pudesse parecer.

No mundo DevOps, não deve ser diferente. A ausência de objetivos de negócio claros traz opacidade para as ações do time e muitas vezes torna uma iniciativa DevOps centrada em apenas rodar um pipeline com o Jenkins ou criar conteineres com o Docker, que são erros primários.

Aprendizado da NASA: Se a sua iniciativa DevOps não tiver um propósito de negócio, você pode estar trabalhando pesado mas a sua bússola pode estar errada. DevOps não é sobre tecnologia. DevOps é para você melhorar resultados de negócio. Simples assim.

Ferramenta para suportar objetivos em iniciativas DevOps:  O OKR (Objective and Key Results) é uma ferramenta leve, de natureza organizacional fractal e que se bem usada, pode apoiar no atingimento de objetivos para uma empresa, áreas, squads e até mesmo indivíduos em implantações DevOps.

Uma boa introdução a essa técnica pode ser encontrada aqui.

2. Cultura de Experimentos

Durante o filme, vemos o time conduzir vários experimentos. Eles estão trabalhando em ambientes complexos e tentando criar coisas que não existiam: foguetes maiores, módulos de alunisagem e outras tecnologias que não existiam.

Nas nossas TIs, não estamos colocando foguetes com humanos na lua, mas estamos criando coisas novas em ambientes complexos. E isso exige que você crie uma cultura de experimentos.

Aprendizado da Nasa: Cultive um sistema de trabalho para permitir que o seu time rode experimentos continuamente.

Ferramenta para suportar experimentos em iniciativas DevOps: Gosto do modelo mental do Lean Change, que traz instrumentos leves e simples para você propor e avaliar opções e criar experimentos simples em ciclo de vida leve com as etapas — preparação, introdução e revisão

Uma boa introdução ao modelo de Lean Change pode ser encontrado aqui nesse sítio.

Se você é gerente, lembre-se que experimentos não surgem se você não fornecer ao seu time as três coisas abaixo:

  • Tempo
  • Recursos
  • Autonomia

A gestão 3.0 pode te ensinar bastante sobre isso e a respeito recomendo o excelente livro Como Mudar o Mundo: Gestão de Mudanças 3.0, escrito por Jurgen Appelo.

A mensagem e intenção do livro é brutalmente simples e tomo a liberdade de reproduzi-la abaixo.

Como lidar com minha organização medíocre? Eu gosto do meu trabalho, mas eu não gosto do que a gestão está fazendo. Como lidar com isso?

Bem, é fácil. Você tem três opções:

1. Ignore. Mudar organizações é um trabalho duro. Se você não tem o vigor necessário para aprender como tornar-se um bom agente de mudança, então, pare de reclamar do que está ruim. Aceite que a organização é o que é, e aproveite as partes boas do seu trabalho. Nesse caso, você pode parar de ler, daqui.

2. Peça demissão. A única razão pela qual organizações ruins existem é porque as pessoas não pedem demissão. Faça um favor para o mundo e encontre um lugar melhor para trabalhar. Ajude organizações ruins a saírem de suas misérias não trabalhando para elas.

3. Aprenda sobre gestão de mudanças. Muitas pessoas são péssimas em influenciar outras pessoas a mudarem organizações. Mas, se você levar a sério, você pode aprender a ser um agente de mudança mais eficiente.

É pegar, largar, ou mudar.

Este livro é para aqueles que escolheram a opção 3.

3. Esteja preparado para falhar

Durante o filme, vemos várias falhas. Vemos também acidentes que terminam em mortes. E vemos também que as pessoas vivem em contextos sociais complexos, que podem gerar falhas no trabalho delas.

Em uma passagem do filme, Neil Armstrong, depois de destruir um módulo de alunisagem, diz algo aproximadamente assim: “Precisamos falhar aqui embaixo para não falharmos lá em cima”.

Se você é curioso o suficiente, deixo aqui uma lista de acidentes que ocorreram durante o programa espacial americano dos anos 60. A lista é enorme.

Aprendizadazem da NASA: Se você rejeita a falha, irá continuar a ser medíocre. Mas se abraçar a falha e usá-la como instrumento de feedback irá crescer e se tornar melhor. E isso vale para organizações complexas e para a sua empresa também. A Toyota e a Amazon, que abraçaram a cultura de expor falhas com segurança psicológica e promover melhoria contínua, se destacaram de outras organizações.

Ferramenta para suportar falhas em iniciativas DevOps: O Celebration Grid, ferramenta do Management 3.0, é um instrumento barato e simples para você coletar aprendizados.

Fonte: Site do Management30.com

Um artigo introdutório a esse instrumento pode ser encontrado aqui.

Um outro instrumento que gosto é o Safe to Fail Probes, derivado do modelo mental do Cynefin, de Dave Snowden. E aqui nessa página você encontra um roteiro detalhado de como aplicá-lo no seu dia a dia.

4. Sistematize a melhoria contínua

Quando você combina o segundo e o terceiro princípio acima, pode criar uma cultura Kaizen.

Aprendizados da Nasa: Teste práticas e faça provas de conceito e busque organizar o que esta funcionando e o que não está funcionando através de reuniões periódicas e análises post-mortem dos eventos.

Ferramenta para suportar falhas em iniciativas DevOps: O Loop OODA,, criado por um militar americano chamado Joyn Boyd, é um poderoso modelo mental de como você pode  lidar com problemas diversos que organizações vivenciam na entrega de produtos, redução de retrabalho e criação de aprendizado e melhorias.

Uma outra técnica derivada da retrospectiva e apresentada no excelente livro DevOps Handbook são as Análises Post-Mortem Sem Culpados. Descrevo ela brevemente abaixo.

Para fazer isso, nós agendamos o post-mortem o mais cedo possível após o acidente e antes de perdemos as memórias vívidas do ocorrido.

Você deve chamar. As pessoas envolvidas em decisões que podem ter contribuído para o problema. As pessoas que identificaram o problema. As pessoas que responderam ao problema. As pessoas que diagnosticaram o problema. As pessoas que foram afetadas pelo problema. E qualquer outra pessoa que esteja interessada em participar da reunião.

Nessa reunião post-mortem, faremos o seguinte:

  • Construir uma linha do tempo e reunir detalhes a partir de múltiplas perspectivas sobre falhas, garantindo que não iremos punir as pessoas por cometer erros;
  • Capacitar todos os engenheiros e analistas para melhorar a segurança, permitindo-lhes prestar contas detalhadas de suas contribuições para falhas;
  • Capacitar e incentivar as pessoas que cometem erros a serem especialistas que educam o resto da organização sobre como não repeti-los no futuro;

Finalmente, as contramedidas são registradas com uma data prevista e um proprietário para acompanhamento

“Um especialista é alguém que conhece alguns dos piores erros que podem ser cometidos em seu assunto e como evitá-los.”
– Werner Heisenberg

 

O Ornitorrinco Ágil e o Desenvolvimento de TIs Antifrágeis

Muitas empresas já aderiram aos métodos ágeis. Cursos foram comprados. Papéis como o SM, PO ou Service Delivery Manager foram criados. Ritos foram estabelecidos. Ambiente foram modernizados com comida a vontade e jogos eletrônicos. Squads foram formados.

E ainda assim vários gestores não tem percebido geração de valor. A taxa de defeitos continua similar ao de métodos cascata. O moral do times não tem melhorado muito.  E a produtividade dos times também não mostrou avanços enormes.

Se você está passando por isso, você não está sozinho. Muitas empresas tem experimentado isso no Brasil e no mundo. Chamo isso do Ornitorrinco Ágil em ação.

O Ornitorrinco Ágil é um processo que lembra um método ágil na aparência e forma, mas não incorporou na sua essência princípios ágeis essenciais. Ele lembra um bicho que tem bico, nada, bota ovos, mas não é uma ave.

Ornithorhynchus.jpg

Sim, ornitorrincos são bichos muito estranhos. Além de serem mamíferos, eles ainda possuem esporões venenosos nas patas traseiras. E caudas que lembram um castor.

Abrace a complexidade (ou continue fracassando)

Discuti em outro post a importância de usarmos o pensamento sistêmico no desenvolvimento e testes de software e na sua TI. Uma ferramenta potencialmente valiosa é o Modelo Iceberg. Essa ferramenta  nos ensina a correlacionar os eventos e padrões com as estruturas e modelos mentais. E ela também nos ensina que mudanças permanentes devem acontecer através de novos modelos mentais que irão gerar novas estruturas.

Captura de Tela 2018-09-01 às 15.12.20

Gestores, Devs e Testers que ignoram isso estarão  sempre amaldiçoados a culpar outras pessoas e continuar fracassando

Uma outra ferramenta poderosa é o pensamento da antifragilidade, popularizada por Nichiolas Taleb, que discuto abaixo no contexto de criação de TIs antifrágeis.

Coisas Frágeis, Robustas e AntiFrágeis

Se você perguntar  à maioria das pessoas qual o contrário de frágil, é provável que a resposta seja “robusta” ou “resiliente”. Mas o filósofo Nassim Nicholas Taleb diria que essa não é a resposta correta.

Ele argumenta que se itens frágeis quebram quando expostos ao estresse, algo que é o oposto de frágil não simplesmente não se rompe (permanecendo assim o mesmo) quando colocado sob pressão. Em vez disso, ele deve ficar mais forte!

Não existia uma palavra no Aurélio para descrever tal pessoa, time ou organização. E então Taleb criou uma: antifrágil.

Em seu livro Antifragile: Things That Gain from Disorder, Taleb argumenta que essa poderosa qualidade é essencial para empresas, governos e até mesmo indivíduos que desejam prosperar em um mundo cada vez mais complexo e volátil.

Se você quiser ter sucesso também no seu desenvolvimento ágil, não será mais suficiente se recuperar da adversidade e da volatilidade e ser resiliente apenas. Você tem que se recuperar mais forte e melhor. Você tem que se tornar antifrágil.

Como posso reconhecer coisas frágeis na minha TI e no meu time

  1. Coisas frágeis são tipicamente grandes. Times grandes. Sistemas grandes com milhões de linhas de código. Hierarquias gerenciais pesadas. O tamanho geralmente oferece uma falsa sensação de segurança, mas normalmente não são ágeis o suficiente para sobreviver, e muito menos prosperar em momentos de crises. Há muitas complicações técnicas ou camadas de burocracia para permitir uma ação rápida.
  2. Respostas à variabilidade e estresse vêm do exterior. Se algo é frágil e está exposto ao estresse, não há nada embutido para ajudar a evitar esse estressor. A resposta deve vir de algo externo a ela. E isso significa processos, políticas, procedimentos operacionais e camadas de burocracias chamadas de gerências.O mesmo se aplica a pessoas. Uma pessoa frágil provavelmente precisará de ajuda externa quando a realidade difícil se manifestar. Isso porque lhes falta capital – seja financeiro, social ou emocional – para ajudá-los a enfrentar a diversidade.
  3. Coisas frágeis são excessivamente otimizadas. Empresas, pessoas e organizações frágeis costumam ser espertas demais para seu próprio bem. Nosso mundo moderno é obcecado com eficiência e otimização. As empresas buscam o maior número possível de entregas em prazos curtos e com o menor custo possível. Da mesma forma, os indivíduos são instruídos a serem tão eficientes quanto podem com seu tempo.

    O problema principal de ser excessivamente otimizado e eficiente é que não podemos prever quando problemas e erros aparecerão. E como Taleb observa, quando esses erros aleatórios ou flutuações ocorrem em sistemas excessivamente otimizados, “erros compõem, multiplicam e incham com um efeito que só vai em uma direção – a direção errada”.

    Por exemplo, se você é um gestor e planeja o cronograma do seu time com alocação de 8 horas diárias, sem nenhum espaço para folgas, você está fazendo otimização excessiva e criando fragilidade no seu ambiente. E, sim, você será punido por isso pois o mundo é regido pela aleatoriedade. Aleatoriedade é a regra, não a exceção.Um outro exemplo é corpo de diretores que buscam antecipar todas as estratégias e projetos a serem feitos para um ano completo em um planejamento estratégico de larga escala.

  4. Pessoas, times e TIs frágeis buscam eliminar a variabilidade e a tensão. Como as pessoas e os sistemas frágeis não têm respostas integradas ao estresse e à variabilidade, eles tentam ingenuamente eliminá-lo completamente da equação.Mas tentar eliminar a aleatoriedade e a variabilidade é um jogo de perdedores. Isso simplesmente não é possível. Lembre-se, aleatoriedade e variabilidade são a regra da sua vida, não a exceção.

    A tentativa de eliminar o estresse e a variabilidade não é apenas uma causa perdida, mas acaba fazendo com que uma pessoa ou sistema já frágil seja ainda mais frágil

    Para ser eficaz em um mundo que roda com complexidade, aleatoriedade e risco, não basta tentar ser resiliente, apenas. Sempre que puder, você deve sempre encontrar oportunidades para realmente crescer a partir de desordem, volatilidade e adversidade. O objetivo deve ser ir além da resiliência para se tornar antifrágil.

Como posso introduzir antifragilidade na minha TI e no meu time

  1. Menos é geralmente mais com antifragilidade. Para se tornar antifrágil, vale a pena ser pequeno. Com o tamanho pequeno, aumenta a agilidade e flexibilidade durante os tempos voláteis e caóticos.

    Dois exemplos na TI:
    . Arquiteturas de microsserviços permitem maior adaptabilidade, evolução tecnológica facilitada e respostas mais rápidas a desafios de negócio. Empresas grandes e outrora muito frágeis por todo o Brasil tem abraçado esse modelo arquitetural.

    . Projetos pequenos tem chance de sucesso muito maior. Não à toa, muitas empresas tem trabalhado com paradigma de projetos com tempo máximo de três meses. Um outro exemplo é o modelo Two Pizza Team, popularizado pelo CEO da Amazon, Jeff Bezos.

  2. As respostas à variabilidade e ao estresse são incorporadas ao antifrágil. Ao contrário das coisas frágeis que exigem uma resposta externa para protegê-las da variabilidade e do estresse, as coisas antifrágeis têm força e proteção incorporadas.
    Mais alguns exemplos:
    . Introduzir pulmões nos seus sprints ajuda a lidar com incidentes em produção e ausências por doenças e problemas familiares que ocorrem com as pessoas no dia a dia.
    . Trocar a produção empurrada de métodos como o Scrum pela produção puxada do Scrumban ou do método Kanban permite maior adaptabilidade a variabilidade do escopo.
    . Incentivar o desenvolvimento de habilidades nas carreira conforme modelo T ou modelo E prepara pessoas e times para trabalhar em áreas que anteriormente eram impossíveis.
    . Evitar contratos otimizados que buscam escopo fechado também contribui para lidar com a variabilidade de escopo.
  3. Coisas antifrágeis têm redundâncias embutidas. Ao contrário das empresas e pessoas frágeis, as coisas antifrágeis não fazem da eficiência o objetivo principal.
    Para o antifrágil, prosperar na aleatoriedade é a meta, que geralmente requer ser “ineficiente” por meio de redundâncias de camadas.
    Exemplos na TI incluem:
    . Introduzir tolerância a falhas e clusters nos seus sistemas em produção;
    . Possuir múltiplas camadas de testes, manuais e automatizados, funcionais e não-funcionais, com diferentes escalas de tempo.
    . Criar ambientes redundantes para recuperação de desastres.

    As redundâncias não precisam criar coisas grandes que podem tornar os sistemas novamente frágeis. Ao contrário de camadas de burocracia, uma pessoa ou organização antifrágil tem acesso direto ao seus recursos e controle total sobre a decisão de quando e onde usá-la. O empoderamento de times e o uso de modelos mentais como a Gestão 3.0 permitem que redundâncias possam ser usadas.

 

Os princípios para você desenvolver a sua TI Antifrágil

  1. Injetar intencionalmente o estresse nos seus sistemas, pessoas e times. Práticas como a Engenharia do Caos para sistemas e infraestruturas, sistemas periódicos de feedbacks e aumento da inteligência emocional das pessoas são exemplos desse princípio.
  2. Adicionar redundâncias no seu time e nos seus sistemas. Falhas irão ocorrer. Pessoas podem deixar a sua empresa a qualquer momento. E você deve estar preparado para isso.
  3. Empregar a “estratégia do halter/barra de pesos”. Taleb descreve a “estratégia dos halter” como “uma atitude dupla de proteção em algumas áreas e assumir pequenos riscos em outras, obtendo assim a antifragilidade”. Jogar com segurança reduz a potencial desvantagem da volatilidade e assumir pequenos riscos expõe você aos ganhos potencialmente massivos do mesmo caos.Um exemplo seria uma empresa de produtos criar MVPs com baixo investimento (lado direito do halter) enquanto ela ainda ganha dinheiro com o seu produto vaca leitura (lado esquerdo do halter).
  4. Nunca aceitar conselhos por alguém que não tenha “skin in the game/a pele no jogo”. Vivemos em um mundo em que as ações, as opiniões e os conselhos das pessoas são separadas das consequências.
    Aceitar conselhos, opiniões e até mesmo contratos assimétricos com clientes e fornecedores irá apenas aumentar a sua fragilidade.
  5. Praticar a Via Negativa. Os romanos estóicos e teólogos como Tomaz de Aquino sugeriam imaginar situações ruins para eventos do seu dia (Premeditato Malorum). Aquela demonstração de produto para a diretoria. A recepção ao novo MVP pelo diretor da área comercial. A situação econômica do Brasil no próximo ano. E ao imaginar desfechos ruins, você já imaginaria como seria lidar com isso.Não devemos confundir isso com negatividade ou pessimismo. Ao invés, a Via Negativa é uma técnica de antecipação de riscos e criação de planos de contigenciamentos mesmo nas piores das situações.
  6. Manter as opções em aberto. Sistemas Kanban, por exemplo, adiam a tomada de decisões até o último momento (Defer Commitment). Manter as opções em aberto reduz a sua fragilidade. Possui pessoas com mais habilidades e possuir sistemas redundantes em produção são exemplos poderosos de manter opções em aberto.

“Further, my characterization of a loser is someone who, after making a mistake, doesn’t introspect, doesn’t exploit it, feels embarrassed and defensive rather than enriched with a new piece of information, and tries to explain why he made the mistake rather than moving on. These types often consider themselves the “victims” of some large plot, a bad boss, or bad weather.”
Nassim Nicholas Taleb, Antifragile: Things That Gain From Disorder

Trilhando a sua jornada DevOps

Tivemos o privilégio de acompanhar nessa semana o primeiro DevOps Days Belo Horizonte. Lotação esgotada, excelentes palestras e muitas trocas de experiência. Definitivamente, o tema DevOps está nos corações e mentes de muitos profissionais de TI pelo Brasil afora.

E como boa coincidência, tivemos nesse mês a publicação do relatório State of DevOps Report 2018 do instituto de pesquisa e avaliação DevOps – o DORA. Ele trouxe nessa edição um modelo evolucionário para o aumento da sua maturidade DevOps. E esse modelo foi compilado através da análise do que milhares de empresas tem feito por todo o planeta. Faço um resumo do relatório abaixo para ajudá-lo a desenhar a sua jornada DevOps.

vladislav-babienko-703701-unsplash.jpg
A sua jornada para o mundo DevOps

Estágio 0 – Construir a Base

A análise dos dados da pesquisa do estado de DevOps de 2018 revelou as práticas fundamentais empregadas pelas equipes bem-sucedidas. Essas práticas se correlacionam tão fortemente com o sucesso do DevOps que o instituo DORA recomenda que elas são essenciais em todos os estágios do desenvolvimento do DevOps. Em outras palavras, as práticas que devem ser adotadas em qualquer estágio para progredir para o próximo estágio permanecem importantes até mesmo para aquelas organizações que evoluíram mais longe em sua jornada DevOps e que já mostraram o maior sucesso.

As práticas fundamentais estão listadas abaixo:

  • O monitoramento e alertas são configuráveis ​​pelas equipes que operam o serviços em produção. 
  • Os padrões de implantação para a criação de aplicativos ou serviços são reutilizados.
  • Os padrões de teste para a criação de aplicativos ou serviços são reutilizados.
  • As equipes contribuem com melhorias nas ferramentas fornecidas por outras equipes.
  • As configurações são gerenciadas por uma ferramenta de gerenciamento de configuração.

Estágio 1: Normalize a pilha de tecnologia

A maioria das organizações que usam grandes quantidades de tecnologia está lidando com muita complexidade, diminuindo seus esforços para avançar nos negócios. Portanto, não é surpreendente que os primeiros esforços em uma transformação DevOps
(ou qualquer tipo de transformação de negócios) se concentraria na redução da complexidade.

As duas práticas que definem o estágio 1 funcionam para reduzir a complexidade:
• As equipes de desenvolvimento de aplicativos usam controle de versão.
• Equipes fazem a implantação de aplicações em um conjunto padrão de sistemas operacionais.

Estágio 2: Padronize e reduza a variabilidade

No estágio 1, vemos organizações normalizando suas tecnologias
e processos. Quando chegam ao estágio 2, as organizações já começaram o processo de padronização de um conjunto de tecnologias; configurações de aplicativos separados dos dados, uso consistente de controle de versão e também um processo consistente para testes de infraestrutura e um padrão de compartilhamento de código-fonte.

No estágio 2, as organizações estão trabalhando para padronizar e reduzir a variabilidade, um tema que prevalece em todos os estágios da evolução do DevOps.

Toda organização tem variação, que pode derivar de várias causas diferentes, incluindo:
• Adoção de novas tecnologias para substituir muitas funções de tecnologias antigas. E ao mesmo tempo, as tecnologias mais antigas nunca são removidas.
• Produtos caseiros que não seguem padrões comuns do setor e não possuem interfaces comuns.
• Uma proliferação de ferramentas que se sobrepõem e não foram racionalizadas.
• Fusões e aquisições, que trazem ainda mais tecnologias legadas para casa.

No estágio 2, a reutilização de tecnologias e padrões se torna importante. Isso leva os times de Dev e  Ops a colaborar e tomar decisões de arquitetura que afetam a capacidade de implementação e testabilidade dos aplicativos. Por causa do direcionamento para esses padrões comuns, as equipes começam a inventar maneiras de aumentar a velocidade na adoção de padrões e reduzir ainda mais a variação. Isso impulsiona a inovação no nível de equipe para otimizar processos e fluxos de trabalho em torno das pilhas de tecnologia abençoadas.

Um antipadrão primário a ser observado neste estágio é que cada equipe se normalize em seus próprios padrões. Isso levará a um maior grau de variação global e é exatamente a direção errada.

Em essência, as práticas de definição para o estágio 2 são:
• Construa em um conjunto padrão de tecnologias.
• Implante em um sistema operacional padrão único. (ou em um conjunto mínimo, se um apenas não for possível)

Os principais benefícios da organização dos padrões e tecnologias de uma equipe de TI são:
• Velocidade de entrega mais rápida.
• Mais flexibilidade para a equipe de desenvolvimento trabalhar em novos aplicativos, serviços ou componentes.
• Área de superfície reduzida para vulnerabilidades de segurança.
• Menos partes móveis para manter, atualizar e aprender. E isso reduz a complexidade essencial e acidental.

Etapa 3: Expandir as práticas do DevOps por toda a TI e além

Os estágios 1 e 2 reduzem a complexidade geral da pilha de tecnologia para que as equipes possam obter resultados mais repetitivos com variação limitada. O estágio 3 é sobre a expansão das práticas de DevOps para o grupo mais amplo de equipes de TI e prestação de serviços.

No estágio 3, as práticas de DevOps se espalham para além das equipes de desenvolvimento e operações, onde primeiro criaram suas raízes. À medida que a colaboração aumenta e a organização se concentra em melhorias em torno do gerenciamento de serviços, implantação, redução de tempos de espera e minimização de aprovações, esses esforços afetam as áreas além dos departamentos de tecnologia. O compartilhamento de ferramentas, aplicativos e serviços aprimorados – assim como o conhecimento – com outras áreas funcionais da empresa agora se torna fundamental para expandir o sucesso anterior do DevOps e dimensionar o DevOps em toda a organização.

As pesquisa do instituto DORA mostraram que o estágio 3 é onde as iniciativas de DevOps mudam de pequenos grupos de sucesso em algumas equipes para uma onda que se espalha e eventualmente transforma toda a organização.

Foi também observado em achados do grupo que o Estágio 2 (reduzindo a variação
na pilha de tecnologia) e a Etapa 3 pode ocorrer em ordem direta, em ordem inversa ou ao mesmo tempo. Mas ambos precisam acontecer antes de progredir para o estágio 4 (automatizar a entrega da infraestrutura).

Ou seja, faz mais sentido concentrar-se na redução da variabilidade nos estágios iniciais, de modo que haja menos ocorrências para gerenciar, economizando tempo e distração de sua equipe. Mas se isso não for possível porque algumas dessas coisas estão fora do seu controle, trabalhe primeiro nas coisas que você pode controlar. O mais importante é que a equipe de gerenciamento de serviços de TI e quaisquer outras equipes que dependem de serviços trabalhem juntas durante esse estágio.

As práticas definidoras no estágio 3 são:
• Os indivíduos tem autonomia para poder trabalhar sem aprovação manual de fora da equipe (ex. gerentes e áreas de negócio). E isso foi alcançado através da confiabilidade obtida na busca das práticas do estágio 2.
• Padrões de implantação para criar aplicativos e serviços são reutilizados.

Outras práticas importantes para estágio são:

• Os indivíduos conseguem fazer alterações com tempos de espera reduzidos (lead times).
• Mudanças de serviço podem ser feitas durante o horário comercial.
• Revisões pós-incidente ocorrem e os resultados são compartilhados.
• Equipes constroem código em um conjunto padrão de tecnologias.
• Equipes usam integração contínua.
• As equipes de infraestrutura usam também controle de versão.

Etapa 4: Automatizar a entrega da infraestrutura

O estágio 4 é onde as equipes de infraestrutura estão no centro da atenção. As práticas definidoras neste estágio são sobre automatizar a entrega de infraestrutura – o que muitos pensam como o início de uma iniciativa de DevOps.

Essas práticas de automação de infra-estrutura aparecem mais tarde na jornada evolucionária do que podemos esperar. Isso porque são ativadas por coisas que caracterizam estágios anteriores: normalização, redução de variáveis ​​e expansão da evolução do DevOps para além das equipes de tecnologia nos negócios. Sucesso em estabelecer esses fatores em estágios iniciais torna muito mais fácil alcançar o sucesso no Estágio 4.

E  isso não quer dizer que a automação de infraestrutura não está acontecendo em estágios anteriores. Já no Estágio 0: Construir a base, a prática de gerenciar configurações de infraestrutura com uma ferramenta de gerenciamento de configuração rapidamente se instala desde o início, quando as equipes de operações estão buscando padronizar para resolver suas próprias necessidades.

A principal diferença no estágio 4 é que o objetivo de conduzir a automação de infraestrutura nesse estágio é proporcionar maior agilidade a todo o negócio, não apenas para uma única equipe.

Embora esse estágio seja gratificante – parece que você está realmente fazendo o DevOps agora – é importante reconhecer que os estágios anteriores possibilitam a automação da infraestrutura. O instituto DORA viu organizações tentando saltar imediatamente para este
estágio sem passar pelos estágios anteriores. E o resultado é a frustração. É preciso que essas organizações demorem mais do que o esperado para fazer qualquer progresso real com a automação da infraestrutura.

As equipes de infra-estrutura nesse estágio da jornada de DevOps começam a adotar práticas de desenvolvimento ágil, como o uso de controle de versão para configuração do sistema e configurações de aplicativos, e adotam ferramentas usadas pelas equipes de desenvolvimento de aplicativos. As equipes, nesse estágio, também automatizam as configurações de políticas de segurança dentro de sua esfera de influência.

As práticas centrais para o estágio 4 são:
• As configurações do sistema são automatizadas.
• O provisionamento é automatizado. 

E algumas práticas associadas são:
• Configurações de aplicativo estão no controle de versão.
• As equipes de infraestrutura usam o controle de versão.

Estágio 5: Fornecer recursos de autoatendimento

Para passar para o Estágio 5, uma organização deve ter os seus vários departamentos comprometidos em fornecer recursos de TI como um serviço para a empresa, em vez de tratar a TI como um centro de custo que executa ordens de serviço. Esses departamentos incluem desenvolvimento, qualidade, operações, segurança, ITSM e outras áreas funcionais.

Neste último estágio da evolução do DevOps, os benefícios para a organização multiplicarem-se enormemente à medida que a colaboração bem-sucedida entre os limites funcionais se acelera.

Esses ganhos são vistos em várias áreas distintas:
• A arquitetura de aplicativos vai além da padronização de tecnologias e começa a evoluir no sentido de trabalhar e suportar a migração na nuvem, a adoção de contêineres e a proliferação de microsserviços.
• A automação da política de segurança passa de atender as necessidades de uma equipe para se tornar a linha de base de como a segurança e a conformidade são medidas em todo o departamento, ou mesmo em toda a organização. Além disso, o provisionamento automatizado avança para o provisionamento de ambientes completos para desenvolvedores, testadores e outras equipes técnicas.

Uma vez que você comece a ter sucesso em múltiplos limites funcionais, os pilares do DevOps – (CAMS) Cultura, Automação, Mensuração e Compartilhamento – tornam-se mais difundidos em toda a organização.

As duas práticas de definição para o estágio 5 são:
• Respostas a incidentes são automatizadas.
• Recursos de TI (ex. máquinas ou conteineres) estão disponíveis via autoatendimento.

As duas práticas associadas neste estágio são:
• Aplicativos de arquitetura com base nas necessidades de negócios.
• As equipes de segurança estão envolvidas no design e na implantação de tecnologia.

Resumo do relatório

Em resumo, os dados coletados pelo instituto DORA mostraram que embora existam muitos caminhos individuais por meio de uma transformação DevOps, há maneiras de atingir e dimensionar o sucesso mais rapidamente. As organizações têm uma escolha: elas podem escolher ser sistemáticas sobre como elas evoluem ou podem adotar uma abordagem mais dispersa. É claro que é possível que até mesmo uma abordagem ad-hoc funcione, mas o que foi observado nas organizações que atingiram os níveis mais altos da evolução do DevOps é que elas não chegaram lá por acaso.

O Todo Poderoso Gráfico do Fluxo Cumulativo de Valor

Figuras brilhantes da administração moderna, como Peter Drucker, já diziam que é inútil tentar gerenciar um sistema de trabalho sem um sistema consistente de medições e métricas. Se você já trabalha com métodos ágeis isso é ainda mais importante pois métodos ágeis são baseados nos princípios de transparência radical, feedbacks e replanejamentos contínuos. Sem números apropriados, não conseguimos avançar na maturidade do uso de métodos ágeis.

Felizmente, existe um gráfico simples e superpoderoso que pode ser facilmente usado por times ágeis. Esse gráfico lhe dará muitas informações valiosas, tais como:

  1. A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.
  2. O tempo médio que o seu sistema de trabalho demora para processar um novo pedido ou requisito. (lead time ou tempo de atravessamento).
  3. O tempo médio que cada papel ou área do seu sistema de trabalho demanda para processar novos itens. (cycle time ou tempo de ciclo).
  4. A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).
  5. Observar mudanças de escopo ao longo do tempo
  6. Observar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)
  7. Observar gargalos
  8. Estimar quando o seu projeto irá terminar

Ferramentas normalmente usadas por times ágeis, como por exemplo o Microsoft VSTS/TFS, JIRA Agile, Redmine ou o Trello com plugins, já constroem automaticamente esse gráfico e liberam o nosso tempo para a análise intelectual das informações. Ao mesmo tempo, você pode criá-los em ferramentas de planilhas simples como o Google Sheets ou o Excel. Irei fazer isso ao longo desse post para que você possa entender como construir e interpretar esse gráfico.

Construindo o Gráfico do Fluxo Cumulativo de Valor

O nome do nosso super-gráfico é fluxo cumulativo de valor e é também chamado de CFD ou Burn-Up.

Os passos essenciais para a construção desse gráfico são:

  1. Decidir que tipo de informação será medida.
  2. Decidir a frequência da análise.
  3. Decidir que etapas do fluxo de valor serão medidas.

Vamos trabalhar com um primeiro exemplo onde queremos analisar os incidentes que são atendidos por uma área de suporte de um produto. A nossa análise nesse exemplo será semanal e iremos analisar as seguintes etapas:  novos incidentes, incidentes em tratamento e incidentes fechados.

Primeiro monte uma tabela com as informações dos incidentes em cada estado ao longo de cada semana.

Captura de Tela 2018-09-09 às 11.02.39.png

Depois você deve somar os dados em cada semana, i.e, em cada semana iremos ver todos os incidentes naquele estado. Na semana 2, portanto, teremos 17 incidentes no estado aberto, 10 em execução e 7 fechados. Isso irá gerar uma planilha simples conforme mostrado abaixo.

Captura de Tela 2018-09-09 às 11.02.46

Agora iremos representar isso visualmente em um gráfico de área 2D (Area Chart Non Stackable no Google Sheets ou Área 2D no Excel). O resultado abaixo será mostrado.

chart

 

Extraindo Informações do Gráfico Cumulativo de Valor

Vamos agora interpretar as informações trazidas por esse gráfico.

A representação das entregas realizadas no fluxo de valor do seu sistema de trabalho.

O primeiro fato a ser extraído do gráfico é como o seu sistema de trabalho está se comportando conforme o seu fluxo de valor, que é a coleção de etapas ou estados através dos quais podemos observar o sistema de trabalho.

Podemos observar que nas 4 primeiras semanas tivemos 52 incidentes abertos, 33 itens em execução e 19 fechados. Já na semana 6 observamos 78 itens abertos, 51 em execução e 40 itens fechados. E isso indica que o sistema na semana 6 está menos saudável que na semana 4 pois existe um acúmulo maior de itens nos estados aberto ou em execução. Colocado de outra forma, podemos ver que na semana 4 existe um acúmulo de 33 itens (52 itens abertos – 19 itens fechados). Já na semana 6 temos 38 itens acumulados (78 itens abertos – 40 itens fechados).

Se observamos a figura, podemos observar como a barriga da área azul. Visualmente podemos ver que a barriga na semana 6 se tornou maior que a barriga da semana 4. E isso indica que a saúde do sistema piorou.

Sistemas de trabalho saudáveis devem manter conseguir processar itens em taxas similares às suas chegadas. Isso evita filas, troca de contexto e defeitos no processamento de pedidos, requisitos, demandas ou encomendas.

O tempo médio de processamento de pedidos (lead time ou tempo de atravessamento)

Um dos motivos que leva a que métodos ágeis tenham esse nome é que eles buscam garantir que um pedido aberto não fique muito tempo dentro do seu sistema de trabalho, i.e., um novo pedido ou requisito deveria ser rapidamente construído, verificado e liberado para os seus clientes. Chamamos essa métrica global de tempo de atravessamento ou lead time.

Vamos examinar como o lead time pode ser examinado pelo gráfico do fluxo cumulativo de valor. Ele pode ser lido através da diferença horizontal entre os itens fechados e os itens abertos.

Captura de Tela 2018-09-09 às 11.38.25.png

Por exemplo, na semana 5 estamos vendo que os itens fechados correspondem aos itens que foram abertos na semana 2. O lead time da semana 5 está perto de 4 semanas, que indica que um incidente fica perto de um mês no seu sistema antes de ser finalizado.

Se observarmos a semana 10, vemos um o sistema ficou ainda menos saudável.  Os itens fechados na semana 10 foram abertos entre a semana 5 e a semana 6, que indica que o lead time médio agora está em cerca de 4 semanas e meia.

Nos métodos ágeis, buscamos minimizar o lead time. Quanto menor o lead time, mais rápida é a capacidade do seu time de processar pedidos. E portanto a medição do lead time é em minha opinião a mais importante métrica a ser observada em sistemas baseados em métodos Scrum, Kanban e afins.

O tempo médio de processamento de pedidos por papel ou área (cycle time)

Se o lead time mostra o tempo total de atravessamento no nosso sistema de trabalho, podemos usar o mesmo racional para examinar como uma etapa do trabalho (papel ou área) está se comportando. Considere o gráfico abaixo como exemplo.

Captura de Tela 2018-09-09 às 11.54.21.png

Aqui estamos observar o tempo de ciclo da etapa de execução, i.e, o tempo médio que um incidente demorou para ser efetivamente resolvido uma vez que ele começou a ser tratado pela equipe. Podemos ver que o tempo de ciclo na semana 5 era de um pouco mais de 1 semana. Já na semana 10 o tempo de ciclo já era de 3 semanas, indicando que o time de execução claramente não está conseguindo liberar incidentes na mesma taxa que eles estão chegando.

Veja ainda que o tempo de ciclo pode ser analisado em outras etapas. Por exemplo, no gráfico abaixo podemos observar o tempo de ciclo da etapa de Novos Incidentes.

Captura de Tela 2018-09-09 às 12.02.14.png

Aqui podemos ver que na semana 3 um incidente demorava, em média, uma semana e meia até começar a ser tratado pelo time. Já na semana 10 um item ficava aberto quase 4 semanas até começar a ser tratado pelo time.

Longos tempos de ciclo para uma etapa indicam que a área associada aquele trabalho está com dificuldades. E isso indica que a gestão deve buscar formas de apoiar aquele time para reduzir nos gargalos. Ao invés de permitir a chegada de novos itens de foram desenfreada (ilusão de controle) ou fazer ameaças (management 1.0) a gestão ágil deve promover enxames de ajudantes de outras áreas e funções para desafogar o time com dificuldades e com isso reestabilizar o sistema.

A quantidade de itens que estão sendo processados em um determinado momento do tempo (WIP ou trabalho em progresso).

Esse gráfico é tão legal que podemos observar também como os itens estão se acumulando no sistema de trabalho. A isso chamamos de trabalho em progresso ou WIP (Work In Progress). Valores altos do WIP indicam que o seu sistema não está saudável pois indica que as pessoas estão tentando fazendo muita coisa ao longo de uma semana. Isso leva a interrupções no trabalho, trocas de contexto e esgotamento mental pelo seu time.

No gráfico abaixo, podemos observar que o WIP da semana 10 é claramente pior que o WIP da semana 02, mostrando como o sistema está se degradando ao longo do tempo.

Captura de Tela 2018-09-09 às 12.09.16.png

De fato, se você observar os dados da planilha fornecida no exemplo você irá observar que o WIP da semana 02 era de 19 itens (26 – 7). Já o WIP na semana era de 37 itens (119 – 72).

Observar mudanças de escopo ao longo do tempo

Vamos considerar o contexto de um time que precise construir um produto e fez um levantamento inicial dos requisitos do produto. Esse time trabalha em um fluxo de valor com os estados: Backlog, Em Análise, Em desenvolvimento, Em testes, Em homologação e Fechado.

O gráfico mostrado abaixo mostra que houve um intenso esforço na descoberta de requisitos nas semanas 2 e 3. E o gráfico também mostra que houve mudanças de escopo ao longo da semana 8 (12 novos itens surgiram). E se o projeto foi baseado em premissa de escopo fechado, isso indica um sinal gerencial amarelo que sinaliza que novos sprints talvez sejam necessários para completar o escopo recem-descoberto.

Captura de Tela 2018-09-09 às 13.34.42.pngObservar a vazão do seu sistema de trabalho, de um papel ou de uma área. (throughput)

Podemos observar ainda um aspecto bem importante na saúde de um sistema que é a sua vazão, ou taxa de produção de itens no tempo. Por exemplo, considere o seguinte gráfico.

Captura de Tela 2018-09-09 às 13.41.45.png

Explicitei nesse gráfico a vazão dos responsáveis pelo desenvolvimento nas semanas 4, 5, 6 e 7. Observe que quanto maior a inclinação da seta, maior é a vazão. E então podemos observar que o time de desenvolvimento teve um problema mais sério entre a semana 5 e 6. A inclinação da seta aqui está muito baixa nesse região do gráfico. Talvez algum dos desenvolvedores tenha sido alocado em outro projeto ou algum aspecto técnico da arquitetura ainda não explorado do produto tenha surgido e atrasado o trabalho de todos eles.

A análise da vazão ao longo de cada etapa é um instrumento importante para o Scrum Master, Agile Coach e time analisar a saúde e estabilidade do sistema de trabalho.

Observar gargalos

Um outro superpoder desse gráfico é permitir que você analise gargalos. E para isso vamos habilitar as linhas de tendência das etapas inicial e final desse sistema de trabalho (novos requisitos no backlog e requisitos fechados). As linhas de tendência são criadas pela opção Trend Lines no Google Sheets e Excel e são observadas pelas linhas vermelha e preta nesse exemplo.

Captura de Tela 2018-09-09 às 13.56.38.pngSe a inclinação das linhas é igual isso indicaria que o sistema está saudável. No caso aqui, estamos vendo que a inclinação da linha vermelha é maior que a inclinação da linha preta. E isso indica que mais itens estão chegando do que itens saem do sistema de trabalho.

Podemos fazer essa análise comparando quaisquer duas etapas (ex. desenvolvimento versus testes ou análise versus testes), para todo o intervalo de tempo ou para um período de análise. As inclinações das retas nos permitem analisar se gargalos estão sendo formados.

E se você observar um gargalo, é o momento de ligar um sinal amarelo e analisar como podemos pensar coletivamente e apoiar área que está apresentando dificuldades.

Estimar quando o seu projeto irá terminar

Por último, mas não menos importante, esse gráfico lhe dá também uma oportunidade de estimar quando o projeto provavelmente irá terminar.  Vamos considerar o gráfico mostrado abaixo, onde explicito a quantidade de itens fechados ao longo do tempo e também a quantidade de itens que devem ser realizados ao longo do projeto.

Captura de Tela 2018-09-09 às 14.07.07.png

Uma heurística simples que podemos usar aqui é a regra de três sobre os itens fechados até o momento. No nosso exemplo temos 28 itens que foram fechados em 10 semanas. E como temos 117 itens a serem realizados, o tempo total para finalizarmos todos os itens no escopo seria calculado como: 117/28 *10 = 41 semanas.

Essa abordagem, pois mais simplista que pareça, trabalha com o princípio básico que a velocidade passada é um excelente preditor da velocidade futura em um sistema. E isso se torna cada vez mais verdade quando você tem um bom número de observações ao longo do tempo.

Erros Comuns no uso do Fluxo Cumulativo de Valor

Embora esse gráfico seja extremamente poderoso, devemos ter atenção a alguns pontos para não usarmos a ferramenta de forma errada. Alguns erros incluem:

  1. Começar com um fluxo de valor complexo. Recomendo começar com um fluxo simples (A Fazer, Em execução, Finalizado) e incluir mais estados a medida que você e o seu time se acostumarem com o instrumento.
  2. Possui uma definição fraca de Finalizado. Finalizado é algo que está pronto para os seus usuários finais. Se você trabalha com entrega de livros, Finalizado significa que o seu livro está na casa do seu cliente. Se você trabalha com uma cozinha, Finalizado significa que o seu cliente está almoçando o prato que ele pediu há 30 minutos atrás. E se você trabalha com desenvolvimento de software, Finalizado implica que o aquela funcionalidade está nas mãos dos seus usuários no ambiente de produção.
  3. Não possuir Critérios de Aceite para mover um item ao longo do fluxo de valor.  É fundamental que o time defina critérios objetivos que permitam avaliar se um item pode transitar de um estado para outro no fluxo de valor. Isso evita falsos positivos e a maquiagem de dados.
  4. Não comunicar o gráfico. Esse gráfico deve ser afixado em base periódica nas paredes do local de trabalho do seu time ou exibido na TV da sua sala. Esconder esse gráfico em alguma planilha obscura na rede não irá ajudar ao seu time, nem você.
  5. Ter uma frequência baixa de atualização. O poder do gráfico cumulativo de valor vem das interpretações que conseguimos obter das medidas ao longo do tempo. (WIP, Lead Time, Taxas e Gargalos). E isso depende de um ciclo de amostragem regular. Recomendo um ciclo mínimo de uma semana. mas se você coletar os números em base ainda menor você terá insumos ainda melhores.
  6. Adotar esse gráfico apenas para  um único tipo de informação. Todo sistema complexo deve ser examinado em diferentes níveis. E cada nível  lhe dar perspectivas diferentes de análise. Por exemplo, na construção de produtos podemos analisar Épicos, Features ou Histórias. E podemos ter gráficos CFD para cada um desse itens, que permite que você observe a saúde do sistema em níveis distintos e possa extrair interpretações mais robustas.

“Don’t look with your eyes, look with your feet. Don’t think with you head, think with your hands.“ – Taiichi Ohno


A planilha mostrada nesse exemplo está compartilhada aqui para seus estudos sobre o CFD.

Acelerando a Implantação de Squads com o Modelo Iceberg

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

Captura de Tela 2018-09-01 às 15.12.20.png

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.

Alavanca
“Dê-me uma alavanca e um ponto de apoio e eu moverei o mundo”, Arquimedes.

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.