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

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.

E se não faz a mínima ideia do que seja uma Transformação Ágil, comece por aqui.

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 (abaixo) sobre o mesmo assunto, onde ensino algumas dinâmicas que você pode fazer com seu time!