LuizTools

Este é o terceiro artigo da minha série sobre transformação ágil. Meu intuito é compartilhar experiências próprias, de terceiros, estudos que estou realizando e o que mais vier à cabeça e eu achar que pode auxiliar outros profissionais passando por este tipo de jornada.

Afinal, não é nada fácil e precisamos nos ajudar.

Uma coisa é criar times ágeis, tarefa que um bom Scrum Master resolve muito bem. Outra é tornar uma organização inteira ágil. Por exemplo, o General Stanley McChrystal na Força-Tarefa do Iraque em 2003 tinha excelentes times individuais, mas, como ele explica em seu livro,  Team of Teams, os times não colaboravam entre si, como um só. O problema não era colaboração dentro dos times em si, mas colaboração entre os diferentes times, como ele explica nessa tradução livre de um trecho do livro:

“Os laços dentro das squads são fundamentalmente diferentes daqueles entre squads ou outras unidades. Nas palavras de um de nossos SEALs, só a sua própria squad prestava. Os times tinham definições muito limitadas de propósito: completar uma missão ou finalizar uma análise de inteligência, ao invés de derrotar o inimigo. Para cada unidade, o único pedaço da guerra que importava era o pedaço dentro do seu quadrado no organograma; eles estavam lutando suas próprias lutas em seus próprios silos. A especialização que permitiu a eficiência máxima se tornou um passivo diante da imprevisibilidade do mundo real.”

Resolver o problema significava dar vários passos em muitas áreas diferentes, incluindo trazer todos os atores-chave juntos em um mesmo espaço físico para permitir fluxos de informação horizontal; não apenas fazê-los se comunicar melhor, mas levar os tomadores de decisão mais pra perto dos níveis mais baixos da hierarquia, fazer com que trocassem membros entre os times, e mais importante, McChrystal tinha de mudar seu próprio comportamento. Ele tinha de desaprender o que significava ser um comandante do jeito que ele aprendeu, tudo aquilo que ele sabia de como o mundo funcionava.

“Eu comecei a ver liderança efetiva neste novo ambiente organizacional e descobri que liderar era mais parecido com jardinagem do que com xadrez.”

Ao longo de uma transformação ágil, a ideia e o entendimento do que é ser ágil vai evoluir várias vezes. Fazer uma transformação não é apenas uma questão de desenhar uma visão ou definição e espalhá-la pela empresa. Também não é um processo mecânico de oito etapas. É sobre continuamente adaptar a ideia e os métodos para a realidade evolutiva da organização. Conforme a organização e todos nela se adaptam à mudança no seu próprio contexto, cada indivíduo passa a ser dono da transformação.

E isso é o que mais assusta os executivos despreparados para o ágil. Eles querem saber quando acaba a implantação? Quando a virada ágil termina?

A resposta não é muito animadora: ela não termina. A não ser que fracasse!

A pergunta que gosto de fazer em resposta à primeira não é menos desconcertante: quando que a empresa vai parar de evoluir?

Enquanto a empresa crescer, ela vai continuar evoluindo e consequentemente mudando. Como esperar que estruturas, métodos e práticas desenhados para 100 pessoas se comporte igualmente bem para 1000? Ainda que ela parasse no mesmo tamanho, o mercado segue mudando e o tempo não perdoa.

O Murilo Gun diz que o mundo é como uma esteira ligada. Você até pode parar, mas ele vai te levar para trás até te derrubar…

Enfrentando o Agile Fake

Por muitos anos depois do Manifesto Ágil em 2001, o problema foi vender o ágil para os gerentes. Agora a página virou. Com mais de 90% dos executivos dando alta prioridade para “agilidade e colaboração”, existe um risco alto de transformarmos a agilidade em um apenas outro conjunto de ferramentas ineficientes destinadas a reduzir o número de funcionários. De certa forma, a recompensa pelo sucesso da agilidade é a proliferação de Agile Fakes.

Jez Smith tem um site chamado Why Agile Transformations Fail, onde ele entrevista executivos de várias empresas que passaram ou estão passando por transformações ágeis, para aprender com eles. Uma de suas conclusão sobre Agile Fake após mais de 30 entrevistas é que:

“Por exemplo, Agile pode se tornar meramente um dispositivo de redução de custos, ou um adendo para um fluxo de trabalho pré-existente. Em alguns casos, as empresas aplicam métodos ágeis para os seus melhores times, mas em outras partes da empresa, eles continuam trabalham de maneira ineficiente o que chega a ser anti-ético do ponto de vista de gestão ágil. Em alguns casos, um framework de agilidade em escala é implantado em toda organização, mas sem mudanças significantes nas práticas de trabalho onde o trabalho realmente é feito.”

Não apenas isso, mas vemos todos os dias notícias de transformações ágeis bem sucedidas em empresas que, se você for visitar ou ao menos conversar com quem trabalha nelas, verá que a realidade é outra. Quadros kanban e post its coloridos por todo lado não tornam a sua empresa ágil, nem mesmo se você estiver usando jargões de startup (erroneamente) e rodando waterfall em ciclos quinzenais.

Claro que investir no ambiente, para torná-lo mais leve, é sempre uma boa ideia. No entanto, isso é a cereja do bolo. Não faça de sua transformação ágil uma maquiagem para uma empresa que apenas renomeia processos tradicionais com nomes “modernosos”. Isso é o que chamamos aqui no sul de “passar batom no porco”.

Como eu combato o Agile Fake por onde passo? Com informação e aculturamento.

Quando todos estão confundindo MVP com MMP ou pior ainda: POC com MVP, eu chamo para um workshop sobre o assunto. Quando tem post its colados na parede mas sem método algum, eu ensino Kanban. Quando tem PO autoritários demais com os devs, eu auxilio com uma retrospectiva. E assim por diante.

É simplesmente impossível evitar que o Agile Fake floreça de vez em quando, como uma erva daninha, mas podemos impedir que ele tome conta do jardim inteiro nos mantendo sempre atentos e atuando para reduzir seus impactos.

Expandindo a agilidade

Em uma transformação ágil, uma vez que os times ágeis estejam firmemente estabelecidos como a nova forma de se trabalhar na organização, é hora de trazer para o jogo as demais funções de apoio da organização, como o RH e o financeiro, para evitar que eles se tornem “cotovelos” dentro dos processos organizacionais.

Neste trabalho, a alta gestão deve apoiar a mudança e serem apoiados pelos líderes da transformação. Embora implementações dessa magnitude não funcionem simplesmente baixando normas top-down, o suporte da alta gestão é chave para criar o guarda-chuva da mudança, para definir a direção e mediarem os conflitos que ocorrerão inevitavelmente. Este apoio não é vital para começar, mas será necessário conforme a mudança se espalhar.

Conforme a transformação ágil continua, a natureza da jornada em si continuará evoluindo. As regras rígidas dos frameworks como Scrum que uma vez apoiaram a transformação nos estágios iniciais passam a se tornar riscos de gargalo. O mindset ágil deve imperar ao invés dos métodos e o foco deve ser tornar a cadeia de valor mais fluida e os processos mais maleáveis.

Um jeito popular de descrever esta evolução é através da referência ao conceito ShuHaRi das artes marciais japonesas, que descreve os estágios de aprendizado até a maestria. Este conceito tem sido aplicado à agilidade por referências como Martin Fowler e Jeff Sutherland (que explica no seu famoso livro Scrum: A arte de fazer o dobro do trabalho na metade do tempo), dois dos idealizadores do Manifesto Ágil.

• Shu: é o estágio inicial, onde o estudante segue precisamente as instruções do mestre.
• Ha: com as práticas básicas funcionando, agora o estudante começa a aprender os princípios e teorias por trás da técnica e explora alternativas.
• Ri: por fim, o estudante está aprendendo a partir da sua própria prática e adaptando o que ele aprendeu ao seu contexto e circunstâncias particulares.

Nos estágios mais avançados da jornada ágil, os princípios e práticas se tornam algo natural para todos na organização. Enquanto ainda existem cursos e treinamentos para os recém chegados, o mindset ágil já foi completamente internalizado, pensando de maneira ágil sem se esforçar para isso. Esse é o estágio final, o Ri.

Eu gostei tanto desta analogia marcial que, quando estruturei a transformação ágil de um banco que trabalhei, eu construí um modelo de maturidade gamificado que emulava estas etapas de domínio do ágil. Inicialmente nós ditávamos quais processos e práticas seriam usadas e metrificávamos a adequação e aderência dos times àquelas práticas. Depois, expunhamos alternativas e ensinávamos o modo de pensar ágil, ao invés de apenas repeti-lo. Por fim, aos times mais avançados, dávamos a liberdade de construírem seu próprio horizonte com base em tudo que aprenderam ao longo da jornada.

Cerimônias trimestrais contavam com a troca de faixa dos times que avançaram no modelo de maturidade e celebrávamos essa evolução com todos da empresa. Essa celebração era muito aguardada e esse modelo ficou conhecido como MAPA, sigla para Maturidade em Arquitetura, Processos e Ambiente, pois não era composto apenas por práticas ágeis, mas por elementos mais técnicos também como cobertura de testes adequada e pipelines de entrega contínua.

Esse tipo de ação não apenas reforça o sentimento de transformação como aumenta o engajamento e retroalimenta todo o processo de melhoria contínua.

Super recomendo.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso sobre o mesmo assunto!