A Agilidade precisa ser salva? Ou simplesmente pessoas precisam acordar para o que realmente importa?

Este artigo foi escrito em 2019, depois que uma pessoa conhecida “pediu pra sair”. Foi pra outra empresa. Ela desistiu do sonho. Ela não queria mais correr aquela corrida.
Aí me vi falando sobre salvar o sonho e depois bati em algum assunto sobre agilidade e me veio a mesma pergunta. Agilidade precisa ser salva?

TL;DR; Veja este vídeo da conferência Velocity 2009:

Eu fico pensando como minimizar o impacto de cursos vazios e certificações que não vão ajudar em nada as pessoas na primeira nhaca do dia a dia. Você não vai ter tempo de puxar um Canvas e escrever em notas adesivas com baixa quantidade de cola. Você precisa de argumentos e de princípios para atuar nas restrições do dia a dia. Precisa de espaço, de abertura, de pessoas com tempo para escutar.

Como desenvolver um ambiente seguro, para que não sejam necessários “quebra gelos” ou dinâmicas que ajudem a manipular pessoas para extrair informações delas? Como garantir que a gente pode funcionar “pra frente” e do jeito que a gente é e do jeito que estivermos nos sentindo? E que se eu não estiver bem no dia, podemos falar sobre isso? Ou que seja possível eu não participar da retrospectiva neste dia, se existir uma?

Eu escolhi em 2009 não seguir movimentos ligados em certificações de metodologias ágeis, porque teria que me afastar da operação de empresas, e isso me torna vazio. Preciso contar histórias que eu vivo. Preciso documentar o que eu faço. E preciso estar do lado de quem vive o problema. Também gosto do papel de mentor e pratico ele em diversos contextos, mas me interessa estar em operação, no Gemba!

Um caminho alternativo para agilidade, é… volte pra 2009: infraestrutura ágil, ou devops também aparece nesta fala. É uma resposta, se a transformação é digital e ágil, e precisamos de resultados mais rápidos, e mais frequentes? Precisamos criar fluxo, minimizar variabilidade e remover qualquer desperdício em trabalho repetitivo e passivo de falha por essa repetição. Também precisamos remover trabalhos de espera, melhorando a passagem de trabalho entre as pessoas que fazem parte do fluxo.

Diferente de atividades mais ligadas ao gerenciamento de processos, projetos e produtos, uma pessoa que diz atuar em um contexto DevOps, seja de desenvolvimento, qualidade, negócios ou operação, não consegue enganar no dia a dia. Ela não consegue se esconder, ela não consegue fugir da necessidade de colaborar, melhorar e buscar a entrega de resultado de negócio que estamos atrás.

Se a missão de uma equipe é entregar valor de negócio mais frequente, não adianta melhorar refinamento, planning, retrospectiva, se a equipe não for capaz de priorizar o que é essencial e garantir foco para automatizar o que é necessário. Remover dependências de pessoas é algo necessário, pela qualidade de vida destas pessoas.

Isso me deixa muito feliz, porque é meu princípio número 1 em ação: seja inútil.

Fico chateado por vezes com a banalização que o termo Agile vem tomando… mas sei lá, desde 2003 quando comecei, pessoas precisam detonar algo. Então nem sinto mais este incômodo. O primeiro artigo sobre agilidade que li era uma pessoa falando mal do eXtreme Programming.

Lendo um livro sobre métricas, logo no prefácio tem um soco no eXtreme Programming, de graça, sem refletir que se as equipes realmente aplicassem 1 disciplina do XP chamada de Continuous Integration, diversos problemas iriam aparecer. E elas poderiam realmente melhorar. Se elas evoluíssem para fazer entregas menores, poderiam também aprender a usar estruturas de configuração mais leves, como Feature Toggles, que habilitaria trabalhar na diferenciação entre deploy e release de produtos de software. E a visão de entrega de valor de negócio e entrega contínua iriam aparecer. Aprenderiam a priorizar o que realmente importa, minimizando o trabalho em andamento e criando políticas para proteger o que é importante.

Ao trabalhar dentro do contexto de DevOps, queremos conhecer mais do negócio para poder conectar nossas entregas técnicas com os objetivos de negócio da empresa.

Então se eu pudesse dar algumas dicas para você sobre como encarar agilidade na sua empresa, cheguei em 5:

  • Nenhum consultor deveria atuar “full time” na sua empresa. Não faz sentido. Se você e sua equipe não tem tempo nem disponibilidade para dar atenção em melhorar o fluxo de trabalho e indicadores de negócio, tem algo errado. O que está sendo mais importante que os resultados de negócio a serem atingidos?
  • Quando você contratar alguém para consultoria, não importando o assunto, lembre de uma coisa: se a pessoa está preocupada em melhoria contínua, os seus fluxos de trabalho precisam ser mais leves e não mais complexos. Elimine artefatos, reuniões, silos e crie políticas e princípios com os aprendizados. Notas adesivas nas paredes não significam progresso de nada.
  • Quando for contratar alguém para atuar na sua equipe, busque a prática daquela pessoa na missão que ela vai ter na sua empresa. E se ela “falar” sobre certificações, faça 5x mais perguntas sobre as certificações e relação com a prática da pessoa. Já ouvi em um processo de seleção o candidato querendo saber se o valor sendo oferecido na vaga poderia ser maior pois ele faria uma certificação na semana seguinte. :-/
  • Elimine desperdícios de espera. Foque muito nestes. Toda vez que alguém fica esperando por alguém, cuide. No time de desenvolvimento e operações, use “Trunk Based Development” para forçar a quebra de esperas e código parado esperando revisão. Pelo menos o código espera por revisão no trunk/main.
  • Crie espaços de escuta. Para isso ser possível, as pessoas precisam ter tempo disponível. Não faça suas pessoas ocupadas. Faça elas terem missões. Elas precisam ter tempo de pensar, experimentar, trabalhar em conjunto, para poderem operar. Ensine as pessoas a atuarem com escuta ativa, desenvolva redes de apoio e estruturas de conversa, como por exemplo um Lean Coffee.

Isso não é um guia para o sucesso… mas é um pouco do que vejo que venho aprendendo, tirando os rótulos de XP e Lean Thinking da frente. E me parece seguir fazendo sentido.

— Daniel Wildt

Eu tenho encontros mensais para falar sobre consciência de tempo, sobre projetos paralelos e para apoiar você no seu caminho de aprendizagem, nas Jam Sessions. Faço isso através do projeto A Filosofia da Tranquilidade! Conteúdos em texto, vídeos e encontros para trilharmos nossos caminhos, com tranquilidade! E olha também minha newsletter, e projetos que tenho dado atenção agora.

Respostas de 2 a “A Agilidade precisa ser salva? Ou simplesmente pessoas precisam acordar para o que realmente importa?”

  1. Avatar de Destrua o seu posicionamento e a sua prática. Não sua comunidade. – danielwildt
    Destrua o seu posicionamento e a sua prática. Não sua comunidade. – danielwildt

    […] com as metodologias ágeis desde 2003, iniciando pelo eXtreme Programming, é constante um caminho de ver […]

  2. Avatar de Transformação ágil ou sistêmica? – danielwildt
    Transformação ágil ou sistêmica? – danielwildt

    […] muitas pessoas “matando agilidade” e qualquer outra palavra da vez, é que agilidade não precisa ser salva. As empresas é precisam acordar para o que realmente importa. Exemplo de “assuntos” […]

Deixe um comentário