Muitas organizações estão batendo cabeça durante sua transformação Ágil em busca de Business Agility: O plano estava claro, bem desenhado e comprado pela gestão, os times agora são chamados de Squads e o framework ou método Ágil já foi escolhido e implementado com razoável sucesso na TI. No entanto, meses se passaram e os resultados ainda não apareceram como esperado, gerando pressão e desconforto sobre times e gestão. 

Esse cenário, muito comum em organizações mundo afora, revela uma série de problemas e equívocos que muitas vezes não são compreendidos pelas organizações, que acabam por culpar o método. O trauma pode inclusive fazê-las voltarem ao estado anterior, desistindo do processo de transformação. Em outros casos os problemas são simplesmente ignorados e o estado final do processo de transformação é “temos times ágeis”, enquanto o resultado para os negócios da organização é marginal.

Uma das causas desse tipo de problema é frequentemente o foco na otimização local, ou seja, enxergar um time como se fosse uma ilha ou fomentar, muitas vezes sem intenção, a melhoria do time de forma isolada do resto da organização. Times então promovem suas otimizações locais, sem olhar para o sistema organizacional como um todo. Neste caso, define-se como “sistema organizacional” a relação e dependência entre as partes desta organização. Em um cenário em que, por exemplo, um time constrói, outro valida, outro documenta e outro entrega, mesmo que todos esses times sejam ágeis, a melhoria do sistema não necessariamente ocorrerá, uma vez que os times olham apenas para seus próprios processos internos, ignorando o fluxo da cadeia de valor como um todo e as dependências e relações entre eles.

É aí que entram os Flight Levels: um modelo para pensar a comunicação e alinhamento da organização para fazer com que o time certo desenvolva o produto certo no momento certo, promovendo melhorias em diferentes níveis da organização e gerando a otimização real no fluxo de valor.

O modelo de Flight Levels conta com 3 níveis de voo, descritos a seguir:

– Flight Level 1: o nível de voo mais baixo, olhando a operação, com foco no time de desenvolvimento de produtos e/ou serviços. Times no nível 1 realizam 4 atividades fundamentais: visualizam seu trabalho, limitam WIP, buscam e integram feedbacks rotineiramente e promovem melhorias locais identificadas.

– Flight Level 2: um nível de voo um pouco mais alto, olhando a coordenação entre partes da organização, com foco na colaboração, comunicação e coordenação entre times que atuam em diferentes etapas da cadeia de valor de ponta a ponta. No nível 2, são realizadas as mesmas 4 atividades do nível 1, mantendo a comunicação entre os dois níveis. É neste nível que emerge a gestão de portfólio, e é aqui que dependências entre times são identificadas e tratadas, gerando visibilidade, chamando a atenção para os gargalos e a sincronia entre os times.

– Flight Level 3: o nível de voo mais alto, com foco no alinhamento entre a priorização das iniciativas (projetos e produtos) e o direcionamento estratégico da organização. Aqui a gestão estratégica é conectada à operação. Neste nível de voo o C-Level também se torna Agile e o progresso dos objetivos estratégicos são monitorados.

O modelo de Flight Levels foca na contínua otimização da cadeia de valor, ao invés das otimizações locais de cada time, onde para isso é fundamental compreender o contexto da organização, desenhar uma arquitetura de flight levels para permitir a visualização e gestão do fluxo ponta a ponta e entender as melhores métricas e cadências de reuniões de acompanhamento para cada nível de voo.

Embora o modelo seja simples, há muitos elementos a serem considerados. Apesar do envolvimento e comprometimento da gestão seja um desafio, o uso deste modelo de pensamento leva a uma mudança cultural importante e profunda, com resultados de médio e longo prazo incríveis levando a empresa a aplicar verdadeiramente a tão desejada Business Agility.

Confira no link abaixo o conteúdo que fala um pouco sobre o tema Flight Levels e Governança:

Governança Puxada e a MVB – Minimum Viable Bureaucracy

Este artigo foi escrito pelos Agile experts Marcos Garrido, José Jr e Luiz Rodrigues