Agilidade em escala corporativa - Parte 2

No post passado sobre agilidade em escala corporativa mencionei o famoso modelo do Spotify, também chamado de “Scaling Agile @ Spotify” ou simplesmente “modelo em squads”. Falei sobre os squads, os chapters, as tribes e as guilds. Isso tudo é o que a teoria de 2012 do Spotify nos diz sobre agilidade em escala corporativa e um possível passo número um para grandes corporações inovarem nos seus métodos ágeis para que os mesmos se adequem à realidade de dezenas de times operando Scrum ao mesmo tempo.

Mas será que de 2012 pra cá nada mudou em termos de agilidade para grandes empresas? Será que o próprio Spotify ainda organiza-se da exata maneira em que é citado no famoso vídeo?

Melhoria Contínua

Os três pilares do Scrum são bem claros: transparência, inspeção e adaptação. Estes dois últimos tratam exclusivamente de melhoria contínua. Qualquer time ágil que se preze deve continuamente revisitar seus processos para aprimorá-los e por isso não há como acreditar que há 5 anos o Spotify descobriu o Santo Graal dos métodos ágeis e jamais teve de modificá-lo. E de fato, isso não aconteceu, embora poucas pessoas falem disso.

Segundo Andy Park, um ex-Agile Coach do Spotify, entre 2012 e 2014 o modelo sofreu algumas mudanças que fazem todo sentido para mim, considerando desafios como os que enfrento em aplicar agilidade em escala corporativa no Banco Agiplan.

A primeira mudança é sobre a liderança das tribos. As tribos, para quem não se lembra, são a junção de diversas squads que possuam uma área de negócios/projetos em comum, no caso de um banco, temos a tribo de crédito, a tribo de canais, a tribo de integrações, etc. No modelo original, toda tribo deveria possuir um tribe leader, que responde pelo alinhamento e suporte às squads sob sua responsabilidade. No entanto, este modelo original de um tribe leader nos leva a um impasse em diversos casos: o líder deve ser alguém da área de negócios ou da área de tecnologia?

Algumas tribos são mais de tecnologia e outras mais de negócios. No entanto, dificilmente eles não dependem fortemente de ambas as áreas. Não obstante, muitas vezes o número de squads dentro de uma tribo é proibitivo para apenas um líder consiga exercer seu papel de facilitador com qualidade. E embora sempre possamos argumentar que podemos dividir uma tribo em duas, na prática isso acaba gerando problemas de alinhamento e é algo que queremos evitar.

Mas e se tivéssemos ao invés de um, mais de um tribe leader? Que tal dois, como um líder de negócios e outro de TI, por tribo. Desta forma, garantiríamos que ambas skills garantissem que as squads tenham todo o suporte e alinhamento necessários para seus POs e devs. Claro, dois é uma sugestão, e nem sempre ter mais de um será algo necessário. O que ficou claro é que o Spotify agora não restringe a liderança da tribo a apenas uma pessoa. Isso vai depender da necessidade individual de cada tribo.

A segunda mudança é sobre o alinhamento entre tribos. Uma coisa é implantar o modelo de squads em uma empresa como a Umbler que possui dezenas de funcionários e nem mesmo possui tribos (a startup inteira é apenas uma tribo com diversos produtos, um por squad). Outra coisa é manter o alinhamento entre diversas tribos em uma empresa com dezenas de funcionários apenas no setor de TI, fora a área de negócios que não faço nem ideia do tamanho que é.

Quando se tem várias tribos, é muito comum que deva existir um alinhamento estratégico entre os líderes de tribos, para que os mesmos consigam alinhar as suas squads. Quando temos poucas tribos, isso é simples de fazer, mas conforme a coisa cresce, a preocupação com o alinhamento se torna maior pois ele se torna ainda mais crítico. Para piorar, algumas tribos dependem fortemente de outras, criando um ponto crítico para que o todo funcione.

Entre essas tribos que dependem fortemente umas das outras, recomenda-se atualmente a criação de Alliances (alianças), que são o modelo ágil das superintendências de grandes corporações. Da mesma forma, as Alliances possuem seus líderes, que são responsáveis por manter os líderes das tribos da aliança alinhados, ao mesmo tempo que lhes fornecem os recursos necessários para que suas tribos prosperem, como orçamento, estratégias, etc.

Algumas tribos não precisam participar de alianças, não é exatamente uma questão de hierarquia. Havendo a necessidade (temporária ou não) de duas ou mais tribos terem um altíssimo alinhamento entre elas, forma-se a aliança e designa-se um ou mais líderes para a mesma.

Voltando às Origens da Agilidade

Você leu bastante a palavra alinhamento neste artigo, certo? Isso porque um alto alinhamento é a chave para termos times autônomos. E times autônomos são a chave para termos agilidade. Mas como obter um alto alinhamento sem o demônio do microgerenciamento invadir nossas empresas?

Uma das possíveis respostas para esta pergunta vem das raízes de onde os primeiros agilistas se inspiraram: a manufatura industrial japonesa, mais especificamente do famoso chão de fábrica da Toyota Motor Company onde surgiu o processo Lean que inspirou tantas metodologias ágeis incluindo o Scrum, o Lean Canvas (do Ash Mauryia) e o Lean Startup. Dentre tantos aspectos e literaturas a respeito do Toyota Lean, gostaria de destacar um método muito interessante que só fui descobrir recentemente que é o Toyota Kata, mais especificamente o Improvement Kata ou Kata de Melhoria na tradução.

Não quero me estender aqui sobre o Improvement Kata, até porque ainda é um estudo em andamento que estou fazendo e pretendo escrever sobre ele no futuro, mas gostaria de ressaltar o seu funcionamento básico como um incrível método para garantir o alinhamento estratégico e a melhoria contínua dentro das organizações, em especial as grandes, onde problemas de alinhamento são mais comuns.

Basicamente um kata, assim como nas artes marciais japonesas, é a repetição de um método até que ele se torne instintivo. Todo mundo já deve ter visto Karatê Kid, certo? Tanto o antigo do sr. Myagi quanto o mais recente com o Jackie Chan, ambos mostram o que é um kata de maneira bem simplificada com os exercícios repetitivos e monótonos que os meninos realizam para só então, quando a hora chegar, aquilo tudo virar instinto. O Improvement Kata em questão, é um processo repetitivo que apesar de manter o foco e alinhamento no que foi definido como a estratégia da empresa, não restringe a liberdade de execução dos projetos.

Não quero me estender demais para não estragar o conteúdo que estou estudando e deixando para um post exclusivo sobre o assunto. Basta dizer que o Kata é a cola que faltava para sincronizar as tribos, alianças, etc dentro de uma grande organização.

* 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!