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