Transformação Ágil: Passo a Passo – Parte 3

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.”

Stanley McChrystal Photographer: Patrick T. Fallon/Bloomberg

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.

MAPA
MAPA

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!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

Transformação Ágil: Passo a Passo – Parte 2

Transformação Ágil
Transformação Ágil

Recentemente iniciei uma série de novos artigos aqui no blog com o post Transformação Ágil: Passo a Passo que, se você ainda não leu, sugiro que o faça antes de começar a leitura deste, uma vez que é a continuação do mesmo.

Na data que escrevo este artigo estou passando pela segunda experiência com transformação ágil em corporações, mais especificamente em bancos, empresas tidas como das mais tradicionais dentre todas que se poderia escolher para fazer uma transformação. Mais ainda, ambos bancos são privados e presididos pelo dono ou membro da família do dono. Antes disso, havia participado da construção e crescimento de diversas startups, então imagine a mudança de paradigma que foi pra eu sair de ambientes que transpiravam inovação e cultura e ir parar em escritórios cheios de regras…

Mas enfim, faz parte do jogo, e onde temos os maiores desafios é também onde estão as maiores oportunidades. Neste segundo capítulo da série, sigo dissecando o passo a passo para transformações ágeis, baseados não apenas em minhas experiências pessoais como Agile Coach, mas também em cases de mercado e literaturas famosas. Não se surpreenda se algo que ler lhe pareça familiar, afinal não inventei tudo da minha cabeça.

Formando o time que irá liderar a transformação

Uma vez que a alta gestão decida avançar, ela precisará de um time para liderar a jornada. Idealmente a transformação ágil será liderada pelo C-Level com o apoio do board da empresa. Isto porque uma transformação ágil é uma jornada sem fim que eventualmente afetará tudo dentro da organização e a própria relação da empresa com o mercado.

No banco gaúcho que fiz a maior transformação da minha carreira até o momento, montamos um time composto pelo Diretor de Tecnologia (CIO), pelo Gerente de Planejamento e Governança de TI (que até então era responsável pelo PMO da empresa), pelo Superintendente de Desenvolvimento de Sistemas (Head of Development), pelo Arquiteto Líder (que desempenhava um papel semelhante ao de um CTO) e por mim, o Agile Coach recém nomeado.

Note que seguimos a premissa do próprio Scrum ao montar um time multifuncional para liderar a transformação:

  • CIO: era o nosso Product Owner, pois representava os stakeholders, a empresa, etc; definiu a visão da transformação, as prioridades, etc; o cara da estratégia;
  • Governança: era o nosso analista (que no Scrum seriam membro do Dev Team) e gerente de projetos (era uma empresa tradicional, lembra?), cuidava das finanças, das burocracias, de estruturar as fases do projeto e ajudava com o alinhamento;
  • Head: ele representava todos os devs da empresa, uma vez que os gerentes de TI estavam abaixo da sua gestão e abaixo deles os devs propriamente ditos. Ele inclusive era o maior afetado na primeira etapa da transformação, que era focada nos times de desenvolvimento;
  • Arquiteto: era sua responsabilidade toda a parte de DevOps e Qualidade de Software, definindo as diretrizes de arquitetura, stacks de tecnologia, etc que os times de desenvolvimento usariam para trabalhar;
  • Agile Coach: era o facilitador  multiplicador, atuava como Scrum Master neste time de transformação, mas ao mesmo tempo era quem ajudava a construir os times, treinar os Product Owners e Scrum Masters e fazer coaching com TODAS as lideranças da TI;

Mais tarde, em outras fases de transformação, esse núcleo mudou.

No início da transformação, enquanto a organização ainda está achando o seu caminho, o time de liderança ágil pode ser um misto de C-Level com agilistas de todos os tipos (Agile Coaches, DevOps, etc). Como dito antes, o ideal é que seja um time multifuncional e que consiga representar todas as facetas da transformação que está se desenhando. Se a liderança for composta apenas de C-Level, a tendência é que a empresa entenda como comando-controle. E se não tiver participação do C-Level, o time pode não ter autoridade para crescer as mudanças organicamente.

Independente dos integrantes, o time precisa agir como um grupo de Agile Coaches, que realmente acreditem e multipliquem a transformação que desejam na empresa, que lutem pelas ideias, não importa os desafios que aparecerem. Isso incluir ter coragem para dizer as verdades que precisam ser ditas, mas ao mesmo tempo a inteligência para saber a hora certa, o local certo e o jeito certo de fazê-lo.

Será necessário perseverança, urgência, direcionamento, energia, habilidade de inspirar outras pessoas, bem como o realismo para reconhecer a escala da tarefa e o tempo que é necessário para realizá-la. Em uma grande organização, pode ser necessário até uma década a exemplo da Microsoft, que começou sua jornada em 2008 e continua até os dias de hoje.

O time irá precisar compartilhar sua paixão, inspiração e guiar a implementação das práticas e mudanças. Ajuda externa sempre é bem vinda mas não deve ser uma dependência, esse time precisa de autonomia e proatividade. A experiência de outras pessoas é válida, mas não deve jamais ser seguida à risca pois é muito perigoso que este time se deixe levar pelo status quo, pelo pessimismo e pela prudência covarde. Todo e qualquer conselho externo deve ser ouvido, refletido, e confrontado com a nova situação que está se desenhando para a empresa. Não faça nada considerando apenas o cenário atual, mas sempre mirando o cenário futuro.

Provando o Conceito do Ágil

Transformação não é algo que ocorre do dia para a noite, é algo lento e orgânico. Ainda assim, existem alguns empurrões iniciais que geram o impulso necessário para a transformação deslanchar. Uma dessas atividades iniciais é provar que agilidade funciona.

O processo geralmente começa através de um ou mais times que funcionam como “piloto” de agilidade na empresa. Afinal, falar que só funciona para os outros é fácil, mas e quando um time ao seu lado está trabalhando usando práticas ágeis, que desculpa você vai assumir para não aderir?

Os sucessos desses times iniciais geralmente espalha uma energia positiva e gera entusiasmo para com a transformação. Em ambos os casos de transformações que participei, eu iniciei com o time de Canais Digitais (mobile banking, internet banking, etc), por algumas razões:

  • não impactavam diretamente o faturamento da empresa à época da transformação, ou seja, eram menos críticos caso algo desse errado;
  • não tinham um grande legado para dar manutenção, eram times jovens e com grande propensão a aceitar métodos novos de se trabalhar;
  • me contrataram especificamente para estes times e com carta branca para trabalhar conforme eu achasse melhor com eles;

Além de espalhar a ideia de que o ágil funcionou na empresa, esse movimento inicial gera a primeira turma de Agile Champions ou multiplicadores do ágil na empresa. A Microsoft fez exatamente isso quando começou sua transformação em 2008, começando com apenas um time na divisão do Visual Studio. Em 2009 já tinha alguns times, em 2010 já tinham 25 e em 2011 a divisão de desenvolvimento inteira já tinha mais de uma centena deles, enquanto que a empresa inteira só foi aderir em 2014 e a jornada continua em andamento.

No banco privado gaúcho que trabalhei entre 2017 e 2019, de 1 pulamos para 4 em menos de 3 meses. Quando a transformação de fato foi anunciada, em 3 meses “viramos” mais de 20 times (todos de desenvolvimento à época) e até o final do primeiro ano de transformação eram mais de 40 times incluindo áreas fora de desenvolvimento de software. Ou seja, foi um movimento bem mais agressivo uma vez que temíamos que a cultura tradicional engolisse nosso movimento, então decidimos agir mais rápido para não dar-lhes esta chance.

E se você pensa que fomos os únicos a pensar assim, saiba que a Salesforce não quis cometer o erro de perder o impulso inicial e decidiu uma transformação completa na organização em apenas 3 meses. Ainda assim, eles adotaram essa estratégia de ir tombando time a time, só que rapidamente. Claro que não foi algo percebido como “orgânico” ou suave e que eles encontraram resistência (assim como eu) mas seguiram em frente.

Outras histórias, como a da SRI International, o CEO menciona que perderam muitas pessoas que não se adequaram ou não concordavam com o novo jeito de se trabalhar. Isso também aconteceu comigo e confesso que foi bem sofrido quando os primeiros gestores não abraçaram a ideia a tal ponto de se demitirem e irem para outros lugares. Embora eu acredite que se tornará cada vez mais difícil encontrar lugares para se trabalhar com gestão e métodos 100% tradicionais.

Os primeiros meses foram os mais sofridos pois embora nosso discurso fosse brilhante e pintasse um futuro utópico de colaboração, agilidade, entregas de valor, etc; o presente não era nada favorável com projetos atrasados, times desmotivados, turnover alto e alta competitividade. Investi muitas horas semanais em sessões individuais de coaching com todas as lideranças da onda inicial: Product Owners, Team Leaders (os gerentes renomeados) e Scrum Masters. Tivemos alguns problemas, todos envolvendo pessoas (o que prova que o mais difícil não é adotar uma nova prática, mas ter a adesão das pessoas ao movimento):

  • algumas pessoas não quiseram aderir e decidiram sair da empresa;
  • pouquíssimas pessoas foram julgadas incapazes de se adequarem por seus gestores e foram demitidas (já possuíam um vasto histórico de resistências a outros movimentos e conduta inapropriada para a nova realidade da empresa);
  • algumas pessoas aderiram em um primeiro momento, mas depois voltaram atrás e quiseram voltar às suas funções antigas;

De minha parte posso afirmar que não desisti de ninguém. Busquei todo o ferramental e formações que poderiam ser úteis para este momento, como relato em Como se tornar um Agile Coach, e investi pesado em ajudar essas pessoas a atravessarem essa turbulência inicial da transformação. A prova disso são as belas histórias de transformação pessoal de alguns líderes que carrego comigo destes atendimentos que duraram quase um ano.

Na experiência do SD Learning Consortium, todas organizações encontraram reveses nas suas jornadas. A Microsoft, por exemplo, levou um ano até que seus times Scrum conseguissem realmente entregar valor a cada sprint, end to end. As sprints deles eram de três semanas e segundo Aaron Bjork, um dos líderes da transformação deles, era muito doído para os times ver que mesmo após três semanas de trabalho onde eles faziam tudo que podiam para finalizar um item de backlog, ele não estava realmente disponível para os usuários dentro deste período. Sempre faltava o setup, o upgrade, o deploy, etc.

Apesar de todos os percalços, é muito importante seguir em frente para não perder o ritmo.

No próximo artigo da série, continuo o passo a passo.

* 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, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis

 

Transformação Ágil: Passo a Passo

Transformação Ágil
Transformação Ágil

Conforme a agilidade vai devorando o mundo, muitas corporações estão se deparando com a necessidade de uma transformação ágil. Para a maioria, este é um grande desafio, envolvendo muitas mudanças ao longo de vários anos. Se a organização tem sido gerenciada de maneira tradicional, a jornada irá incluir mudanças radicais em atitudes, valores, mindsets, jeitos de pensar e jeitos de interagir com o mundo, ou seja, uma mudança na cultura organizacional.

Transformação Ágil: Passo a Passo é uma série de artigos que será publicada ao longo das próximas semanas que tem como intuito auxiliar quem está pensando ou iniciando este processo. Não tenho como pretensão esgotar este assunto, mas sim dar uma luz ao tema com as minhas experiências e com diversos cases que conheço.

Também não se surpreenda se você ler ideias e argumentos que já viu em outros lugares, eu não inventei tudo isso aqui, mas bebi de diversas fontes de pessoas com muito mais experiência que eu, mas sem abrir mão das minhas próprias opiniões e experiências sobre o tema, é claro. Sempre que possível (conforme minha memória e organização ajudar) incluirei links para referências onde você pode se aprofundar no que está sendo citado.

Comentários, dúvidas e sugestões são bem vindas na seção de comentários ao final do artigo.

O mundo corporativo atual

A maioria das corporações atuais não são ágeis. Uma pesquisa recente da Deloitte com mais de 10.000 executivos revelou que menos de 10% deles vêem sua organização como realmente ágil.

Por outro lado, mais de 90% deles diz que “agilidade e colaboração” são fatores críticos para o sucesso da sua empresa. Isto reflete as descobertas da McKinsey & Company de que unidades que usam métodos ágeis dão melhores resultados financeiros do que as tradicionais.

O resultado esperado de uma gestão ágil é claro: a habilidade da empresa de se renovar, adaptar, mudar rapidamente de curso e ser bem sucedida no mundo VUCA em que vivemos, para aproveitar melhor as oportunidades.

No entanto, implementar agilidade é um meio, não o fim. O objetivo é permitir que a organização gere valor em escala com a menor fricção possível, de maneira customizada e incremental, livre de riscos e que as recompensas financeiras sejam equivalentes às obtidas pelas empresas de maior e mais rápido crescimento do planeta: Amazon, Apple, Facebook, Google, Microsoft, etc.

Alguns agilistas não esperam pela alta gestão e começam suas jornadas sem uma autoridade central ou recursos. No entanto, esse não é o melhor jeito de começar, sendo o jeito mais difícil de conseguir todo o conhecimento organizacional e capital social para causar um grande impacto. Quem trabalha ou já trabalhou em corporações sabe do que estou falando: a boa e velha política tem um papel fundamental nesse tipo de iniciativa. Implementações ágeis limitadas a pequenas partes da empresa (como alguns times de desenvolvimento) rapidamente entram em conflito com outras partes da organização que estão se movendo mais devagar e algumas vezes são esmagadas antes que possam tomar maiores proporções.

Não é de se admirar que o progresso de agilidade nos negócios está diretamente relacionado com o nível de liderança dos engajados na transformação ágil. Glória Abreu, Master Coach que foi minha orientadora durante uma de minhas formações, fala que “a melhor estratégia é a do chuveiro, nunca a do bidê”. Quem não sabe ou não lembra, os bidês eram aqueles antigos lavatórios de “baixo pra cima”, para limpeza íntima. Sim, é uma analogia sofrível, a Glória adora fazer o pessoal rir, mas é a mais pura verdade.

Transformações ágeis não são feitas por lobos solitários, você irá precisar de uma matilha, e com machos-alfa…digo, executivos junto. Isso se você não quiser que seja apenas fogo em palha.

Quando iniciei uma de minhas transformações mais bem sucedidas eu tinha o patrocínio do diretor de TI e, mais tarde, do CEO da empresa. Jamais teria tido tanto sucesso sozinho.

Pensando na transformação

Por onde começar? A alta gestão precisa começar considerando como a própria gestão da empresa se relaciona com o mundo da agilidade e quais desafios despontam à frente em uma jornada ágil. Isso irá envolver a absorção de alguns exemplares da vasta literatura sobre este assunto e entender a essência da agilidade.

Isso incluirá descobrir quais princípios ágeis já começaram a enraizar em partes da organização, mesmo sob outros nomes. Embora o movimento Agile seja extremamente abrangente em escopo, a maioria das organizações de todos os tamanhos possuem ao menos alguns focos de agilidade, como um ou outro time. Em 2017, eu liderava um destes times ímpares em um dos bancos gaúchos que trabalhei, responsável pelos Canais Digitais da empresa, por isso que fui “encontrado” e recebi o “chamado” para fazer algo maior.

A alta gestão precisa encontrar esses focos e aprender sobre o progresso que eles fizeram até agora e quais problemas estão enfrentando. A alta gestão precisa celebrar quaisquer sucessos que aconteceram para estabelecer as fundações para o futuro. Os líderes desses esforços iniciais são potenciais aliados e campeões para a jornada ágil que se avizinha.

Citando outro exemplo, quando a alta gestão do Barclays começou a olhar para agilidade em 2014, els descobriram que já existia um movimento alternativo de praticantes ágeis dentro da empresa. Em março de 2015, quando os times de operações e tecnologia anunciaram que se tornar ágeis era uma iniciativa estratégica importante, as muitas ilhas de agilidade dentro da Barclays foram convidadas a saírem das sombras e se tornarem campeões da transformação ágil do banco.

Fazer este estudo também ajuda que a alta gestão aprenda com quaisquer falhas em esforços anteriores antes de lançar uma jornada do tipo na companhia. Por que estes esforços falharam? Quais passos necessitarão ser tomados para prevenir esse tipo de falha recorrente? Quais novos riscos devem ser endereçados?

A organização está preparada?

Os patrocinadores também precisarão entender os riscos e benefícios de iniciar uma transformação ágil exatamente agora.

A escala dessa missão pode ser assustadora. Mas a alternativa – morte corporativa através de falha em adaptar-se continuamente ao mercado – pode ser ainda mais arrepiante. Existe um consenso quase geral de que a única opção real é QUANDO mudar, e não SE devemos mudar.

Também é necessário que seja avaliado o risco do formato de implantação. Se for decidido implementar agilidade como uma “receita de bolo”, forçando as pessoas a adotarem processos ágeis porque os executivos ouviram que funciona na empresa X ou porque eles ouviram isso de alguma consultoria, o risco de resistência institucional aumentará consideravelmente. Em mudanças profundas como agilidade, copiar e colar não funciona. Ao invés disso, a empresa precisa fazer a mudança organicamente de dentro pra fora, para que faça mais sentido. A oposição é inevitável em qualquer mudança organizacional, mas ela será ainda maior se vista como uma iniciativa imposta do topo.

Ou seja, além de considerar quando é o melhor momento para começar a transformação, tem de ser verificado o tamanho e intensidade das batalhas que serão travadas internamente.

Não obstante, tem de ser entendidos os conflitos que possam haver entre os objetivos da agilidade – obsessão em entregar valor ao cliente, por exemplo – e a forma como a empresa funciona hoje. Por exemplo, muitas empresas listadas em bolsa trabalham única e exclusivamente para aumentar o valor das ações e/ou o retorno para acionistas.

A alta gestão também tem de decidir como lidarão com a burocracia tradicional de áreas como orçamento, controladoria, compliance, etc. Embora não seja necessário lutar todas estas batalhas no “dia um” da transformação, a alta gestão precisa saber o que enfrentará à frente, incluindo uma ideia de quando estas batalhas serão travadas.

Algumas empresas decidem, depois de considerar todos os riscos, que não é o momento de iniciar uma transformação agora. Esta decisão não é exatamente ruim, afinal é melhor não ir adiante do que começar uma transformação sem estar 100% comprometido, o que geralmente traz implantações falsas de agilidade, que são ágeis apenas no nome e que geralmente bloqueiam iniciativas futuras de uma real transformação.

Buscando ajuda

Ao ponderar se deve prosseguir, os líderes da transformação podem aprender a partir de outras empresas que estão envolvidas em transformações ágeis. Eles podem visitar empresas que já são bem sucedidas em suas jornadas e aprender sobre práticas-chave que valem a pena ser emuladas e quais que evitar. Eventos podem ser úteis para fazer contatos, embora as apresentações costumem apresentar somente o lado bom destas iniciativas, então foque no networking.

Na prática, o que se vê no mercado é que as jornadas ágeis bem sucedidas estão diretamente ligadas à adoção de um mindset ágil, ao invés de um processo ou metodologia específicos. As visitas realizadas pelo SD Learning Consortium mostraram que algumas empresas estavam implementando todas práticas ágeis “by the book”, mas não estavam obtendo muitos benefícios delas. Por outro lado, algumas empresas estavam demonstrando agilidade nos negócios e obtendo benefícios, mesmo que não estivessem rodando as práticas famosas à risca. O fator de diferenciação entre essas empresas não está nas práticas escolhidas mas no fato das pessoas estarem realmente comprometidas a uma ideia diferente de como o trabalho deveria ser feito. É um jeito diferente de pensar, entender e agir no ambiente de trabalho.

Os executivos tem de aprender que uma transformação ágil não é um projeto ou uma iniciativa, ou um novo processo ou nova estrutura organizacional, mas sim uma jornada sem fim, é empreender com um jeito de pensar que é fundamentalmente diferente da hierarquia top-down de comando e controle típica das empresas do século 20.

Além de tudo isso é importante levar em consideração qual terminologia ágil será encorajada. É comum as empresas descobrirem que existem muitos termos diferentes e confusos no mundo ágil. A empresa precisa decidir quais termos não são interessantes para serem utilizados no seu ambiente, incluindo o próprio termo agilidade, além de todo o vocabulário comum como Scrum, Scrum Master, Lean Startup, Kanban, etc. Pode parecer bobo, mas realmente faz a diferença definir os termos que serão utilizados.

No banco que mencionei antes quisemos descolar de uma série de terminologias e principalmente de um método específico, para evitar ranços e discussões no estilo “sexo dos anjos”. Sendo assim, criamos um framework de agilidade em escala feito sob medida e que era composto por um guarda chuva de práticas definidos por uma comunidade interna de agilistas. Isso nos permitiu por quase dois anos avançar na adoção e transformação, sem os reveses de estar preso a uma única terminologia ou processo, como o proposto pelo SAFe.

O segundo artigo desta série pode ser conferido neste link.

* 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, onde ensino algumas dinâmicas que você pode fazer com seu time!

Curso de Scrum e Métodos Ágeis
Curso de Scrum e Métodos Ágeis