Flight Levels em Ação de Klaus Leopold

A quarta palestra da primeira Agile100 convidou a voar. Klaus Leopold mostrou com "Flight Levels in Action" como uma organização pode ser melhorada em diferentes níveis.

O modelo dos Flight Levels abrange três níveis, que cuidam dos seguintes temas:

• Flight Level 1: Nível operacional
• Fight Level 2: Coordenação
• Flight Level 3: Gestão estratégica de portfólio

Klaus explica isso com mais detalhes nos seus slides, que estão disponíveis no Recap de Maio da Agile100. Além disso, a palestra incorporada abaixo mostra de forma clara como os Flight Levels funcionam na prática.

Flight Levels in Action de Klaus Leopold

Mais sobre Klaus Leopold

Dr. Klaus Leopold é cientista da computação, pioneiro em Kanban e criador do Flight Levels Model. Ele possui vasta experiência como consultor de alta gestão, com cerca de 1000 participantes em workshops por ano. Klaus assessora empresas em todo o mundo sobre como atuar de forma ágil no mercado. É autor do bestseller Rethinking Agile, Practical Kanban e coautor da obra de referência Kanban Change Leadership.
Ele é cofundador da Flight Levels Academy e compartilha seus pensamentos e experiências atuais no mundo dos Flight Levels e do desenvolvimento organizacional em seu blog www.LEANability.com e em sua conta no Twitter: https://twitter.com/klausleopold.

„Teoria sem prática é inútil. Prática sem teoria é cara."

Flight Levels em Ação (Transcrição)

Caso você não queira assistir ao vídeo completo, preparamos aqui uma transcrição de toda a palestra de Klaus Leopold. Boa leitura!

Sohrab:

Bem-vindos de volta. É ótimo ter Klaus Leopold conosco hoje. Klaus e eu na verdade nunca nos conhecemos pessoalmente, mas temos muitas pessoas que participaram dos cursos dele e dos meus cursos. E nos meus cursos, sempre falavam do Kanban-Klaus, e talvez nos cursos dele falassem do Scrum-Sohrab, não sei, talvez Klaus possa nos contar. Mas estou muito, muito feliz por termos Klaus conosco.

Ele é um dos autores que acompanho há algum tempo. Gostei especialmente do seu último livro "Rethinking Agile", onde fala sobre Flight Levels. Tenho certeza de que ele vai compartilhar algo sobre isso conosco hoje. E se você estiver interessado em saber mais, depois da palestra dele, não durante, vá ao stand da empresa dele e converse com alguns dos colegas dele, acho que Catherine e Cliff estarão lá. Klaus, o palco é seu.

Klaus:

Perfeito. Legal. Muito obrigado, Sohrab, por essa introdução tão gentil. Sim, bem, "Rethinking Agile", esse é o título do meu livro, e também é o título da minha apresentação de hoje. E acho que o subtítulo é praticamente a mensagem que tenho tentado transmitir: por que times ágeis não têm nada a ver com Business Agility. Então, do que se trata? Bem, gostaria de contar uma história. Quero contar uma história sobre uma organização. E essa organização tinha alguns problemas. O problema principal era que queriam melhorar o tempo de lançamento no mercado. Disseram: "Ok, nossos projetos demoram tempo demais para ficarem prontos. Precisamos realmente reduzir nosso lead time até o mercado."

E, bem, esse tipo de desejo eu ouço com bastante frequência: "Queremos melhorar nosso time-to-market." Mas do ponto de vista de negócios, há muito mais por trás dessa redução do tempo de lançamento no mercado. Nessa empresa específica, era muito sobre ser proativo no mercado. Antes eram líderes de mercado, mas agora estão apenas tentando acompanhar a concorrência. Não é uma sensação boa. E disseram: "Ok, queremos ser proativos novamente, queremos aproveitar as oportunidades." Quer dizer, eles sabem o que está acontecendo nos mercados. E disseram: "Ok, o problema é que quando tentamos montar um dos nossos projetos, a oportunidade já passou." Então, nada bom.

E claro, queriam estar preparados para a mudança descontínua que está acontecendo, certo? Todos conhecemos esses novos modelos de negócio que estão surgindo, não fazemos mais projetos, fazemos produtos, não fazemos mais produtos, fazemos soluções, fazemos serviços, fazemos sei lá o quê. Tem blockchain, inteligência artificial e por aí vai. E disseram: "Bem, o futuro provavelmente vai chegar. Mas se continuarmos como hoje, provavelmente sem nós." E disseram: "Ok, precisamos mudar fundamentalmente o que fazemos aqui." E bem, quando você ouve algo assim, o que faz? A resposta é simples, né? Vamos ser ágeis, certo? Com agilidade podemos abordar facilmente todos esses temas. Pois é, e foi basicamente isso que tentaram fazer. Então começaram uma transformação ágil.

O que fazia parte da transformação ágil? Bem, como em qualquer livro de Agile, sabemos que precisamos combater os silos funcionais. Silos são ruins e malvados, então precisamos formar equipes multifuncionais. Eles disseram: "Reorganizem em equipes multifuncionais." O que mais? Eles foram ainda mais longe e disseram: "Ok, precisamos ter equipes de produto. Queremos ter equipes de produto multifuncionais." Isso significa que uma equipe trabalha sempre em apenas um produto. Uma coisa boa, se você pensar bem. O que fazemos então é reduzir dependências de alguma forma, para que possamos entregar diretamente ao mercado, e isso naturalmente encurta nosso time-to-market. Então, pessoalmente, eu gosto disso.

Eles disseram: "Não sejamos dogmáticos demais sobre qual método ágil as equipes usam. Elas podem escolher seu método ágil, o método ágil preferido, há apenas alguns requisitos que devem observar. Assim, cada equipe precisa ter uma visualização, e em um quadro. Queremos ver o que está acontecendo nas equipes." A ideia era: se eu vejo o que todas as equipes estão fazendo, posso basicamente ir até uma equipe, iniciar uma conversa sobre o trabalho deles e discutir seus problemas. Então cada equipe precisa ter o quadro, queremos ver o que está acontecendo nas equipes. Outro requisito eram reuniões padronizadas. Cada equipe precisa de uma ferramenta de feedback rápido, com a qual possam se adaptar a coisas que surgem rapidamente, ou seja, reuniões de stand-up, cada equipe.

Cada equipe precisa realizar retrospectivas, que é basicamente uma máquina de melhoria, o que faz bastante sentido, certo? Queremos melhorar. Então, tornar-se ágil não é apenas uma melhoria, queremos melhorar continuamente. E por último, e isso também me agrada, disseram: "Queremos ver algumas métricas." Sabe, uma coisa é se sentir bem, outra coisa é qual é o resultado real do que estamos fazendo aqui? O lead time da equipe deve diminuir, e o throughput deve aumentar, certo? Essas eram as duas métricas. E bem, se você olha para algo assim, e acabou de ler um livro de Agile, provavelmente está pensando agora: "Ótimo. Quero dizer, eles realmente entendem o que precisa ser feito, certo? Quero dizer, é isso que se deve fazer. Nada pode dar errado."

Bem, foi isso que eles tentaram. E como abordaram essa transformação? Bem, primeiro de tudo, lançaram um projeto de transformação de um ano e meio. Você consegue sentir? Esse é meio que o meu tipo de humor, certo? Queremos nos tornar ágeis, e a primeira coisa que nos vem à mente é definir a representação em cascata de como nos tornaremos ágeis. Não tenho certeza se esse é o melhor caminho para fazer isso. Mas, bem, ok, foi assim que fizeram. Então um plano de projeto de um ano e meio sobre como se tornar ágil. E uma das primeiras coisas nesse plano de projeto foi, estamos falando de 600 pessoas, então não é tão grande, mas ainda assim 600 pessoas, bastante gente. Eles disseram: "Todos esses, bem, precisam receber algum tipo de treinamento ágil básico."

Acho que todos aqui já ouviram falar que agilidade não é tanto sobre as práticas. Agilidade é muito mais sobre a mentalidade. Vocês pensam nisso? É sobre a mentalidade. Se as pessoas tiverem o mindset certo, tudo fica ótimo. Então não é sobre as práticas. É sobre a mentalidade. E foi isso que eles fizeram. Lançaram esse programa de um dia sobre mindset ágil, pelo qual todas as 600 pessoas basicamente passaram, e então puderam marcar a caixinha no plano do projeto: mindset ágil estabelecido. Bem, podemos pensar se funciona assim, mas talvez seja necessário um treinamento de dois dias, certo? Então, ok, isso é uma coisa sobre mindset. O que mais? A reorganização foi feita. E o que isso significa? As pessoas foram basicamente jogadas para o alto, aterrissaram em algum outro lugar da organização nesses times de produto multifuncionais, e então começou-se basicamente a implementar times ágeis por equipe.

Então os times Scrum receberam seu treinamento de Scrum, seu Treinamento de Product Owner, e os times Kanban construíram alguns sistemas e assim por diante. E bem, no início todo esse processo foi apoiado por 16 coaches externos, o que é legal se você tem uma consultoria. Quero dizer, dá para vender bastantes dias assim. Mas quando você olha o que está acontecendo aqui, estamos falando de 600 pessoas. Então isso é realmente... quando você pensa em quanto treinamento e tudo mais é necessário aqui, provavelmente você realmente precisa dos 16 treinadores externos.

O que mais? De alguma forma eu gosto disso aqui. Eles disseram: "Precisamos construir capacidade interna." Então formaram 11 coaches internos, e a ideia era: "Ok, precisamos manter o conhecimento na nossa organização", porque, quero dizer, já vi isso tantas vezes, enquanto os consultores externos estão lá, tudo fica mais ou menos bem. E quando os coaches e consultores externos vão embora, muitas pessoas pensam: "Finalmente podemos voltar ao normal." Então, bem, você provavelmente não quer voltar ao normal quando investiu tanto dinheiro como eles fizeram aqui. Então, esse era o plano, mais ou menos. Qual foi o relatório de status? O relatório de status após cerca de um ano dizia que 80% dos times estavam completamente transformados. Gosto dessa formulação, certo? Eles estavam completamente transformados. Então o que significa que 80% dos times estavam completamente transformados?

Bem, você poderia fazer várias dessas verificações na retrospectiva do seu plano de projeto. Nós as vimos, seu suporte, claro, reuniões padrão, check, check, check. Havia uma caixinha chamada métricas. E eles disseram: "Sim, os times fazem métricas, mas... ok, marcamos a caixinha, mas vamos olhar as métricas. Quero dizer, é para isso que as temos." Então, agora fica um pouco interessante. Este é um chamado gráfico de Velocity de Sprint Scrum. Vou mostrar esses gráficos de Velocity e gráficos de Lead Time um pouco mais tarde, e o que você vê aqui são tendências de times. Então este é um gráfico de tendência não de um time, mas de vários times. E a ideia é que queremos ver de forma geral se estamos melhorando ou não. É uma medida de throughput da filosofia. Basicamente significa quanto um time entrega.

Então, vemos o eixo do tempo no eixo X, e no eixo Y vemos os pontos de história fictícios, acho que é assim que chamam no Scrum. Isso é a velocidade. E a tendência, é isso que esperavam ver. Queriam ver a velocidade subir naturalmente. No início, talvez não haja tanta velocidade, porque tudo é novo, sabe, as equipes precisam aprender como tudo funciona, mas depois definitivamente deveria subir. Legal. Esse é o resultado esperado. O resultado real foi assim. Então, sim, melhorou um pouco, mas depois caiu de novo. Eles se perguntaram: "O que está acontecendo aqui? Não tenho certeza. Quer dizer, não é isso que esperávamos." E bem, as primeiras vozes, você podia ouvir as primeiras vozes nessa organização, e elas diziam: "Bem, sabe, sempre dissemos que Scrum não funciona. Essa é a prova, certo? Kanban é muito melhor que Scrum, certo?"

Então, tudo bem, se Kanban é melhor que Scrum, vamos dar uma olhada nos gráficos do Kanban. Este é o gráfico de lead time do Kanban. Bem, lead time é basicamente velocidade, quão rápido entregamos? É novamente um gráfico de tendência de várias equipes. Vemos a tendência no eixo X, e no eixo Y a velocidade, quão rápidos são. E claro, queriam ver o lead time diminuir, certo? E, bem, o resultado esperado, o resultado real foi assim. Eles disseram: "Bem, isso é meio fantasioso. Podemos dizer que não está piorando. Mas, bem, é bem difícil dizer que isso é muito melhor." Então estavam meio agitados. Disseram para si mesmos: "Ok, não sabemos o que está acontecendo aqui." Esse é o problema com esses gráficos.

O problema é que é bem difícil criar um gráfico quando está escrito, sem melhoria, porque estamos falando de gráficos de equipes e estamos falando de gráficos após uma reorganização. Ou seja, essas equipes não existiam antes. Então, tudo bem, houve essa reorganização, agora tudo é diferente, basicamente. E não posso comparar, porque as equipes não existiam antes. Mas havia um gráfico que basicamente existia antes de se tornarem ágeis e depois de se tornarem ágeis. E esse é o time-to-market das iniciativas deles. Lembra, é por isso que fizeram tudo isso, porque o tempo até o lançamento no mercado tinha aumentado. E eles realizavam iniciativas antes de se tornarem ágeis. E fizeram ou ainda fazem iniciativas depois de se tornarem ágeis.

Dependências e interações ágeis

O tempo até o lançamento no mercado foi ficando cada vez mais longo, e eles disseram: "Ok, precisamos mudar isso. Então precisamos trazer essa linha para baixo." Esse era o resultado esperado. Mas o resultado real foi assim. E isso realmente dói, porque o que vemos aqui não é que não há melhoria. É mais que está piorando. Então eles não se tornaram ágeis, e demorou ainda mais para chegarem ao mercado. E então eles se perguntaram: "Que fenômeno é esse que está acontecendo aqui?" Quero dizer, isso não faz sentido para eles, certo? E bem, eles me ouviram falar na conferência, quando eu falava sobre otimização local versus otimização global e coisas assim. E disseram: "Bem, talvez tenha algo a ver com o que você está falando."

Então basicamente me ligaram e disseram: "Ok, você pode vir dar uma olhada? Não estamos vendo melhorias aqui. Talvez tenha algo a ver com o que você falou na sua apresentação da conferência." Eu disse: "Claro. Posso dar uma olhada." Então o que fiz basicamente foi ir até lá e passei, acho, um dia e meio, quase dois dias com eles. E sim, eu estava meio que procurando as causas. E foi bem legal, porque, sabe, todas as equipes eram ágeis. E isso significa... ou estavam usando um desses métodos adicionais. E isso significa que havia muita visibilidade. Então fui basicamente até as equipes, porque era lá que a agilidade estava acontecendo nessa organização. Fui até as equipes e simplesmente comecei a conversa com elas.

E no início eu falei sobre as dependências e as interações ágeis. Então quando conversei com as equipes, essa é a visualização simplificada que sempre vi aqui, algo como coisas que precisamos fazer, tipo o backlog. Próxima coluna, o que já comprometemos. Desenvolvendo é, estamos trabalhando nisso agora. E depois tem a coluna done, uma visão simplificada de um dos quadros da equipe. Havia apenas uma coisa, cada equipe tinha algo assim no seu quadro, espera externa. Isso significa que essa equipe não pode mais trabalhar nesse item de trabalho aqui, porque outra equipe nessa organização precisa trabalhar nisso. Então está bloqueado dessa perspectiva, e outra equipe precisa desbloqueá-lo. Então, uma dependência, certo? O interessante é que cada equipe nessa organização, realmente 100%, cada equipe tinha esse problema de espera externa. E eu pensei: "Ok, o que isso significa?"

Vamos realmente supor que cada equipe nessa organização tem uma visualização assim, isso significaria que há um segundo quadro em algum lugar nessa organização. E se a equipe número um encontra essa dependência aqui, como espera externa, isso significa que de alguma forma dispara uma demanda na equipe número dois. Eles fazem algum tipo de, sei lá, planejamento mágico, qualquer coisa, e chegam à conclusão: "Ok, vamos começar a trabalhar nesse item, e quando terminarem, isso significa que terminamos e a equipe lá em cima pode liberar esse item." Então isso é basicamente o que está acontecendo quando vemos esse problema de espera externa. Então perguntei às equipes com que frequência isso acontece. E por quem vocês esperam? Não apenas uma vez na vida, mas mais numa base frequente.

E o que eu fiz foi desenhar algo como um diagrama de dependências, e ficou assim. Então realmente existe uma quantidade enorme de dependências. E eu pensei: "Isso é interessante." E você vê, são apenas oito times aqui. Então na vida real, 600 pessoas, você pode imaginar que isso é gigantesco quando olha para esse diagrama de dependências. A pergunta é: por que existem tantas dependências? Quer dizer, eles fizeram muita coisa para reduzir essas dependências. Lembre-se, eles formam times multifuncionais. Eles constroem times multifuncionais porque queremos eliminar dependências. A outra coisa é até ter times de produto. Isso significa que um time trabalha em apenas um produto. Então eles fizeram muita coisa para eliminar as dependências, mas mesmo assim acabam numa situação como essa. A pergunta é: por quê?

Bem, existem várias razões, três razões. Acho que essas são as três razões mais importantes que eu descobri. Razão número um é, sim, está certo. Um time trabalha em apenas um produto. Isso está ok. No entanto, vários times trabalham no mesmo produto. Isso significa, por exemplo, que esse time aqui em cima trabalha apenas no Produto A, mas o outro time e o outro time também trabalham no Produto A. E, que surpresa, existem dependências, certo? O que mais? Outro problema é que os produtos não são completamente independentes uns dos outros. Isso significa que se você muda algo no Produto A, também precisa mudar algo no Produto B e no Produto C. Então temos uma quantidade enorme de dependências dentro dos produtos ou entre os produtos.

E bem, no final estamos falando de 600 pessoas. Pessoalmente, eu nunca vi uma organização com mais de 30 pessoas sem dependências no trabalho do conhecimento, certo? Então é completamente claro que vemos dependências aqui. E, bem, sempre que penso em dependências, uma imagem aparece na minha cabeça, uma imagem de um teclado. Vamos supor que nossa organização é um teclado, e somos bons no negócio de digitação. O que fazemos é escrever cartas para nossos clientes. Então vamos organizar nossa organização, time um, dois, três, quatro, certo? Time um pressiona apenas as teclas numéricas, time dois, Q, W, E, R, time três A, S, D, F e assim por diante. E agora vamos supor que o cliente quer que a gente escreva uma carta de amor. Bem, precisamos descobrir como entregar essa carta de amor. Mas se você é uma organização com 600 pessoas, você não tem apenas quatro times. Sua organização provavelmente se parece com isso.

Para cada maldita tecla do seu teclado existe um time em algum lugar que pressiona essa tecla. Temos um time R, temos um time T, temos um time G, temos um time A, toda organização precisa de um time A, claro. Senão você está basicamente ferrado. E agora vamos supor que otimizamos todos esses times. E vamos supor que funciona. Temos o melhor time R deste planeta. Temos o melhor time V e o melhor time S. E quando o time D começa a pressionar a tecla D, sai fumaça do teclado. Eles são simplesmente fantásticos. Somos o benchmark internacional quando se trata de bater no teclado, pressionar teclas no teclado. A pergunta é: quanto mais rápido conseguimos entregar nossa carta de amor? Bem, talvez não muito mais rápido, certo?

A equipe certa precisa trabalhar nas coisas certas no momento certo

O ponto é: quando se trata de usar o teclado, não é tão importante que você pressione cada tecla super rápido. É muito mais importante que eu garanta que você pressione a tecla certa no momento certo. Se eu pressiono a tecla certa no momento certo, posso terminar minha carta muito, muito mais rápido. E o mesmo vale para organizações. O mesmo vale para organizações. Não é tão importante que cada equipe individual trabalhe muito, muito rápido. É muito mais importante que garantamos que a equipe certa trabalhe nas coisas certas no momento certo. A equipe certa precisa trabalhar nas coisas certas no momento certo. É disso que se trata o desempenho organizacional.

Agora, existe um cara chamado Russell Ackoff. Russell Ackoff já dizia que o desempenho de um sistema não é a soma de suas partes. É o produto de suas interações, o produto de suas interconexões. O que isso significa? Bem, se transportarmos isso de alguma forma para o nosso mundo atual, poderíamos dizer que a agilidade de uma organização não se trata de ter, sei lá, muitas equipes ágeis. Uma organização ágil se trata mais de haver interações reais entre as equipes. Precisamos tornar as interações ágeis, não tanto as equipes - é aí que está a agilidade organizacional. Precisamos garantir que a equipe certa trabalhe nas coisas certas no momento certo. E isso era algo que não estava no radar dessa organização. Eles diziam: "O santo graal é a multifuncionalidade. Precisamos derrubar esses silos funcionais, e tudo vai ficar ótimo."

Não me entenda mal. Sou um grande fã de equipes multifuncionais. Mas o problema é que não basta derrubar os silos funcionais. Então, o que essa organização basicamente fez foi: sim, eles derrubaram os silos funcionais, mas construíram silos multifuncionais. O ponto é: não é tão importante qual pessoa está em qual equipe. É muito mais importante que de alguma forma furemos buracos de interação nas paredes das equipes. Precisamos tornar possível que essas equipes interajam de forma ágil. E isso não foi feito nessa organização. Então essa foi a descoberta número um: não havia interações reais. Tenho mais dois problemas para você. E depois dos problemas, vamos passar para a solução. Problema número um: nenhuma interação ágil. Vamos para, digamos, o segundo problema, a segunda descoberta.

Como mencionei antes, conversei com as equipes, e também falei com elas sobre o fluxo. O que isso significa? Bem, vamos dar outra olhada no quadro. É assim que esses quadros se parecem. E eu pensei: "Ok, isso é interessante. Então você desenvolve, e depois do desenvolvimento você terminou. Isso significa que o cliente está totalmente satisfeito, tudo está ótimo." Eles disseram: "Bem, não é tão simples assim. Depois do desenvolvimento, claro que precisamos integrar o que fizemos." E eu: "Ok, legal. Por que não?" Então construímos outra coluna. Quero dizer, queremos tornar isso visível. É para isso que serve uma visualização, certo? Então criamos uma coluna esperando integração. Tudo bem. Mas então eu pensei: "Ok, e quando a integração está pronta, então você terminou. Isso significa que o cliente está completamente satisfeito."

Eles disseram: "Não, não exatamente. Claro que ainda precisamos fazer alguns testes de aceitação." Eu disse: "Ok, interessante. Então vamos introduzir outra coluna. Esperando testes de aceitação. Mas agora o cliente aceitou. Então o cliente está totalmente satisfeito agora, certo?" Eles disseram: "Não, há, sabe, essas janelas de lançamento, e precisa caber numa janela de lançamento, e assim por diante. Mas então estamos de alguma forma prontos." Eu disse: "Ok, essa é uma boa informação, certo? Agora temos um quadro com algumas colunas a mais." Então não se trata tanto da visualização. Trata-se mais do que podemos aprender com essa visualização. E quando vejo uma visualização assim, começo a fazer perguntas como: "Ok, esperando integração? Quanto tempo isso leva? Quanto tempo isso leva? Quanto tempo isso leva?"

E, bem, nesse caso específico a resposta foi que a integração era feita mensalmente e quatro vezes por ano havia testes de aceitação que passavam pelo release. Queremos melhorar o time-to-market dos nossos projetos. Acho que tenho algumas ideias, certo? Mas claro que eu não estava totalmente feliz aqui, especialmente em desenvolvimento de software sabemos muito bem o que precisamos fazer aqui. Então, existe Integração Contínua, Entrega Contínua, Deploy Contínuo, Tudo Contínuo. Também olhei para a frente do quadro. Pensei: "Ok, aqui está o backlog. Isso significa que aqui você tem sua visão, sua ideia de produto, sua ideia de feature incrível, e você começa a desenvolver."

E eles disseram: "Não, não, não, não é tão simples assim. Sabe, quando falamos do backlog aqui, estamos falando do backlog de desenvolvimento. Antes de começar o desenvolvimento, claro que precisamos fazer algumas análises." Eu pensei: "Ok, por que não? Quero dizer, é para isso que construímos esse quadro, certo? Então vamos criar outra coluna, tipo pacotes de produto aqui em cima, análise e então estamos no backlog de desenvolvimento, e então podemos começar. Isso significa que aqui no Product Backlog realmente temos nossa ideia incrível." E eles disseram: "Não, na verdade nosso processo se parece bastante com isso. Temos algo como um pool de novas ideias, e fazemos uma espécie de triagem dessas ideias, então escrevemos um conceito inicial. Esse conceito inicial espera pelo comitê diretor, então escrevemos um business case detalhado, que por sua vez espera aprovação. E agora finalmente estamos no Product Backlog. E podemos começar a analisar."

Eu pensei: "Ok, interessante, claro. E o legal é que, se dermos um zoom out, o processo se parece com isso." E eu pensei: "Ok, legal." E novamente, como antes, quando vejo algo assim, o ponto é que podemos começar a fazer perguntas de novo. E a pergunta era a mesma de antes: com que frequência isso acontece? E quanto tempo temos que esperar? E a resposta foi assim: a triagem era feita mensalmente, o que é de alguma forma bem rápido. Quatro vezes por ano havia o comitê diretor, que de alguma forma aprovava os business cases iniciais. E uma vez por ano os business cases detalhados eram aprovados, uma vez por ano. Queremos melhorar o time-to-market dos nossos projetos. Acho que identifiquei algumas alavancas que poderíamos puxar. Bem, eles também tiveram uma ideia. Disseram: "Desenvolvimento, problema descoberto. Colocamos um pouco de pó de fada ágil aqui e somos tão incrivelmente ágeis, é simplesmente fantástico."

Bem, não, desculpe dizer isso. Não acredito nisso. Quero dizer, claro que podemos de alguma forma acelerar isso, mas no final das contas não alcançamos muito quando se trata de entregar mais rápido ao mercado. Quero dizer, isso talvez seja desenvolvimento de software ágil. Tudo bem. Não tenho problema com isso. Mas com Business Agility, isso não tem nada a ver com Business Agility. Essa empresa X está no mercado como antes, então não há mudança nenhuma. E esse foi exatamente o segundo problema que descobri. Não havia captura nem gestão do fluxo de valor.

Vamos ao terceiro problema, antes de passarmos às soluções!

Então, o problema, e eu tenho mais um problema antes de passarmos para as soluções: Podemos falar um pouco sobre o portfólio estratégico ágil. Antes de fazermos isso, vamos voltar às equipes, certo? Então esse era um daqueles quadros de equipe. E o que eu podia ver nesses quadros era algo como números neles, números como limites de WIP, eu acho. Vocês todos já ouviram falar de limites de WIP, como limites de trabalho em processo. Isso significa que eles só podem começar dois itens aqui e precisam terminar um desses itens antes de começar um novo item. Então isso é para as equipes Kanban, mas também havia equipes Scrum, talvez as equipes Scrum não tivessem essa limitação explícita. Mas as equipes Scrum, elas limitaram seu trabalho porque trabalham com Sprints ou fazem Sprints. Então Sprint é basicamente semelhante a limitar o trabalho em processo, porque o que você faz é simplesmente dizer: "Ok, eu me comprometo a entregar esses itens nas próximas duas semanas. Não vou começar mais itens até entregar esses itens, e então podemos começar mais itens." Então também é "pare de começar, comece a terminar".

Então estou falando sobre criar foco, porque criar foco é simplesmente ótimo. Há tanta teoria por trás disso. E há até uma prova matemática, como a Lei de Little, de que mais ou menos tudo o que você pode ler aqui é verdade. Então, o overhead de troca diminui, o tempo de ciclo diminui, o custo do atraso diminui, seu sistema é estável, o que significa que você é previsível. Então há tantas coisas ótimas quando você cria foco na sua organização. E, bem, há até uma coisa, o tempo de ciclo diminui e o tempo até o mercado diminui. Então o ponto é, se você cria foco, você fica mais rápido, o tempo até o mercado diminui. Mas o que vimos agora nesta organização é que o tempo até o mercado na verdade aumentou. Como isso é possível? Quero dizer, há algumas provas matemáticas de que isso está correto.

Então eles simplesmente falsificaram a Lei de Little? Bem, não. Deixe-me colocar assim. Quando se trata de criar foco, há, digamos, letras miúdas. E eu acho que 99% das organizações nunca leram essas letras miúdas. Então aqui estão as letras miúdas, um pouco maiores. O ponto é, não se trata de focar em qualquer item ou qualquer unidade aleatória na sua organização. O que você precisa fazer é focar, você precisa criar foco, você precisa limitar esses itens de trabalho onde você quer ver o benefício. Você precisa limitar esses itens de trabalho onde você quer ver o benefício. O que isso significa? Bem, esta organização estava trabalhando em iniciativas, certo? O que eles fizeram foi dividir as iniciativas em Epics. Depois dividiram os Epics em histórias e histórias não amadas em tarefas. Foi assim que fizeram. Bem, precisamos melhorar.

Então o que queremos ver é que queremos melhorar o tempo até o mercado das nossas iniciativas. O que precisamos limitar? No que precisamos focar na nossa organização? Bem, como eu disse, iniciativas, claro, então precisamos garantir que a quantidade, o número de iniciativas na nossa organização seja de alguma forma limitado. É isso que precisamos fazer. O que eles fizeram? Bem, agilidade era uma coisa de equipe. Então agilidade era apenas uma equipe e nada mais. Eu como equipe, nesta cadeia, o que posso influenciar? O que posso realmente limitar? Muito provavelmente não as iniciativas. Muito provavelmente não os Epics. Então minha esfera de influência está em algum lugar aqui, provavelmente posso limitar as histórias, posso limitar as tarefas. E eu acho que é exatamente esse o problema. E é exatamente esse o problema que vimos nesta organização.

Não atribua à estratégia as coisas que você faz, mas faça apenas o que a estratégia lhe diz!

O ponto é: não se surpreenda se você não vir a melhoria que quer ver. Você precisa se concentrar nos itens de trabalho onde quer ver a melhoria. E claramente não são histórias. São iniciativas. E nessa organização, eles replicaram os times, tinham suas metas de Sprint e tudo defendido, mas ainda estavam trabalhando em 1000 iniciativas em paralelo. Então, surpresa, surpresa, nenhuma das iniciativas foi concluída mais rápido. Isso não é bom. Onde podemos limitar essas iniciativas? Onde podemos criar um foco nessas iniciativas? Eu diria, em algum lugar num portfólio estratégico, em algum lugar lá em cima, seja lá o que isso signifique, mas é além do nível de time, certo? Quando falamos sobre estratégia e portfólio estratégico, havia outra coisa que era interessante nessa organização, que era o processo de desenvolvimento de estratégia.

Nessa organização, a estratégia era abordada de forma um pouco interessante. Deixe-me colocar assim. Vamos inserir uma linha do tempo, ok? Nessa organização, as pessoas estavam trabalhando em algo. Isso é bom. Quero dizer, é por isso que são pagas. E então houve esse anúncio de estratégia. A estratégia foi meio que proclamada numa... sei lá, reunião geral, comida ótima, bebidas, tudo. E, sim, isso é toda a estratégia. E a consequência do anúncio de estratégia foi que as pessoas trabalhavam nas coisas. Então, nenhuma grande diferença, certo? E então, mais tarde no ano, eles meio que viram o sinal sobre o final do ano. E então pensaram: "Ok, tinha algo sobre estratégia, em algum lugar no início do ano." E o que você podia observar nessa organização era que mais e mais pessoas começavam a criar novos documentos PowerPoint como cumprimentodaestrategia.pptx.

E o que basicamente faziam era tentar mapear retroativamente todas as coisas em que estavam trabalhando para a estratégia. Então diziam: "Ok, trabalhei neste projeto. Isso se encaixa neste balde estratégico. Trabalhei nisso, isso se encaixa nesta área estratégica." Então meio que tentavam planejar de trás para frente e justificar com base no trabalho estratégico que fizeram. Mas esse não é o propósito da estratégia. A ideia da estratégia é que a estratégia determina no que trabalhamos. Não é um método de justificação, certo? Então essa é outra coisa que realmente chamou atenção nessa organização. E vou falar um pouco mais tarde na solução sobre o que fizemos a respeito. Ok, então esse foi o problema número três, basicamente nenhum gerenciamento real de portfólio estratégico nessa organização.

Então basicamente falamos sobre esses três problemas: nenhuma interação real, a estratégia era boa, o gerenciamento de estratégia não estava disponível, e nenhum gerenciamento ponta a ponta do fluxo de valor. Então basicamente esses foram os três problemas que descobri. Vamos falar sobre soluções. Bem, no final, as soluções não eram ciência de foguetes. Essa é a boa notícia. Mesmo assim, levou algum tempo até chegarmos ao ponto onde podíamos começar a trabalhar nas soluções. Mas quais eram as soluções? Bem, primeiro, as interações reais entre os times. Lembra, havia aquele diagrama onde tínhamos todas essas dependências. E, sim, o que fizemos? Bem, o que fizemos foi, lembra, as dependências estavam lá porque os times trabalhavam num produto, mas vários times trabalhavam no mesmo produto.

Então ainda tínhamos um monte de dependências. O que basicamente fizemos foi partir do nível de time e criar quadros de produto. O que isso significa? Basicamente identificamos qual time trabalha em qual produto. Então digamos que esses três times trabalham num produto. O que basicamente fizemos foi meio que trancar os três times numa sala, e criar uma visualização de como eles gerenciam seu fluxo de trabalho juntos. E no final fizemos isso para todos os produtos. Então construímos quadros de produto. O ponto é: paramos de otimizar estruturas organizacionais. Um time é uma estrutura organizacional, eu como cliente, não me importo se você tem alocações de time ou seja lá o que for, não me importo, certo? Então paramos de focar nisso e otimizar as estruturas organizacionais. O que fizemos foi otimizar a entrega de valor.

O valor para o cliente surge no produto

O produto é algo em que o cliente tem um certo benefício quando está pronto. E foi isso que fizemos. Então construímos quadros de produto. E diante dos quadros de produto, e isso é o mais importante, as equipes se coordenavam. Tínhamos reuniões de stand-up e retrospectivas entre as equipes diante desse quadro. E acho que isso também é algo muito importante. O ponto é que não se trata tanto do quadro. Trata-se muito mais de que as pessoas, as pessoas certas tenham a conversa certa diante do quadro. A interação real é o mais importante. E, sim, o que fizemos foram reuniões de stand-up de produto e retrospectivas de produto. Isso significa que as equipes enviavam representantes para a reunião de stand-up, para a retrospectiva, eles tinham uma reunião de stand-up para todas as equipes, depois voltavam para sua equipe e tinham uma reunião de stand-up na equipe. Sim, essa é uma coisa.

Quando você faz algo assim, o número de dependências diminui, certo? Mas ainda restavam algumas dependências. Então essas dependências agora são gerenciadas dentro do produto. Mas lembre-se, ainda havia a questão de que se você muda algo no produto dois, você precisa mudar algo no produto um. Então temos dependências entre os produtos. O que fizemos para superar isso? Bem, construímos algo que hoje eu chamaria de portfólio operacional. Portfólio operacional significa basicamente que de alguma forma identificamos os produtos e serviços onde há muitas dependências. E juntamos esses quadros e criamos outro quadro onde podemos gerenciar essas dependências entre os produtos.

Isso é apenas uma ilustração, por exemplo. Isso é produto um, produto dois, produto três, todos esses produtos estão no mesmo quadro, e agora representantes dos diferentes produtos participam da nossa reunião de stand-up, participam da nossa retrospectiva, e podemos coordenar o trabalho entre os produtos. Então, novamente, não se trata tanto do quadro. Trata-se mais da interação que acontece diante do quadro. Sim, e isso é basicamente o que fizemos para superar o problema dessas dependências. Então nos afastamos da estrutura organizacional e nos concentramos no que é interessante para o cliente, ou seja, a criação de valor, neste caso eram produtos e quadros onde podíamos gerenciar as dependências e tudo entre os produtos, entre as equipes, ponto número um.

O que fizemos? Qual foi a solução para o ponto número dois? Você se lembra, era aquele quadro enorme, aquele processo gigantesco que ficava cada vez maior e maior e maior. Bem, a solução é simples. Quando eu apresento para você assim. Mas no final, estávamos falando de um processo de mudança de um ano e meio, quase dois anos, para chegar a esse ponto. Então, a solução no final ficou assim. Simplificamos de alguma forma o upstream. Lembre-se que não temos tantos passos aqui antes que as pessoas realmente comecem o trabalho propriamente dito. Então agora trabalhamos apenas com um conceito básico que aguarda aprovação. E, sim, já podemos começar a trabalhar. E trouxemos o negócio para bordo. O que significa quando digo que trouxemos o negócio para bordo? Bem, era uma organização bastante tradicional, e eles realmente funcionavam como silos, tipo, existe o negócio e existe a TI. E do ponto de vista do negócio, a TI é apenas custo.

Então é melhor não falar com essas pessoas. O verdadeiro desafio foi juntá-los de alguma forma para que pudéssemos gerenciar todo o fluxo de valor. E o que também fizemos, lembre-se, aquele processo de aprovação era acionado apenas uma vez por ano, reduzimos isso para quinzenalmente, a cada duas semanas podíamos começar novo trabalho. Normalmente, começar novo trabalho não é um grande problema nas organizações. Mas o ponto é que limitamos o trabalho em processo aqui. Então só podíamos começar novo trabalho quando o trabalho em andamento estivesse concluído. E aqui também estabelecemos interações reais, ou seja, realizamos reuniões diárias e retrospectivas e convidamos o negócio. Não inventamos novas reuniões, as reuniões já existiam, mas o negócio passou a fazer parte delas.

Certo, tenho mais uma solução e depois termino. Então, o que fizemos com a estratégia? Bem, lembre-se, era aquele processo de mapeamento estranho, de trás para frente. Então, o primeiro passo que tentamos estabelecer foi um processo de mapeamento para frente. Ou seja, havia uma estratégia. E com base na estratégia, o que fizemos foi derivar resultados e ações da estratégia. Isso significa que a estratégia basicamente disparava uma conversa: O que queremos alcançar? E o que precisamos fazer para chegar lá, certo? Isso foi derivado da estratégia. Então medimos os resultados, se alcançamos o que queríamos alcançar. E isso naturalmente disparou o processo de aprendizado que refinou a estratégia. Essa era a mentalidade. E basicamente mapeamos tudo isso de alguma forma em um quadro. E esse era nosso quadro de estratégia. Temos esses pontos estratégicos, certo? Tipo, você sabe, três a cinco anos, como digitalização e algumas questões culturais, e assim por diante.

E o que fizemos foi basicamente definir resultados, o que queremos alcançar dentro do ano. Então estreitamos o funil. Depois, quando temos esses resultados para um ano, fomos um passo além, tipo, e o que isso significa para os próximos 90 dias? Então temos resultados mensuráveis para os próximos 90 dias. Criamos um foco ao longo da linha do tempo, 3 a 5 anos, 1 ano, 90 dias. Você realmente precisa se concentrar nisso. É bem difícil priorizar projetos de cinco anos. Esse projeto de cinco anos é mais importante que o outro? Bem, não sei. Temos que concluir todos eles em cinco anos. Mas se você de alguma forma estreitar isso, pode criar foco. E se tivéssemos algo assim, derivaríamos ações disso. E quando vejo algo assim, já vejo o quadro de estratégia. No final, é bem simples. Só precisamos adicionar algumas linhas e remover algumas outras. E esse foi mais ou menos o quadro de estratégia com o qual começamos a trabalhar.

Então temos nossos resultados aqui, os resultados anuais, e temos uma escala de 0% a 100% onde podemos ver se estamos fazendo progresso. E aqui temos apenas uma versão muito simplificada do quadro, de um quadro, das ações e é isso que fazemos. E o ponto é que criamos o foco aqui. Isso significa que criamos o foco em termos de estreitar o funil de tempo, e então todos precisamos das ações certas, das ações certas que realmente alcançam alguns resultados dentro dos próximos 90 dias. Esse foi o quadro de estratégia. E claro, com um quadro de estratégia assim, também realizamos reuniões diárias. E também fizemos retrospectivas nesse quadro. Então esses foram basicamente os três problemas e as soluções que criamos. E vamos de alguma forma refletir sobre o que fizemos. Uma coisa foi... uma coisa... estou ouvindo vozes, não sei se é um bom momento.

Uma coisa é, quando faço a conclusão, que, bem, Business Agility definitivamente não é um esporte de equipe. Quando se trata de Business Agility, é um esporte empresarial, você realmente precisa pensar na empresa inteira. E Sohrab já falou sobre Flight Levels. E vou te dar mais um minuto, porque acho que quando falamos de esporte empresarial, o que isso significa? Então, onde em uma organização podemos fazer melhorias? Onde precisamos nos tornar ágeis? E é exatamente disso que se trata Flight Levels. Para mim, Flight Levels é um modelo de pensamento que me ajuda a entender onde em uma organização preciso fazer o quê para alcançar o que quero alcançar. Flight Levels é um termo da aviação, você pode voar baixo ou pode voar muito alto. Dependendo do nível em que você voa, você vê coisas diferentes. Podemos voar muito baixo em uma organização.

Ajuste sempre a altitude de voo!

Quando voamos baixo em uma organização, estamos no Flight Level One, e o Flight Level One é o nível operacional. As equipes, as equipes que realmente fazem o trabalho, podemos tornar nossas equipes ágeis. Normalmente, uma organização tem mais de uma equipe, então vemos vários sistemas de Flight Level One em uma organização. O que também vemos com muita frequência é que uma equipe sozinha não consegue atender o mercado. Então precisamos de coordenação entre várias equipes para atender o mercado. Isso significa que precisamos voar um pouco mais alto. Quando voamos um pouco mais alto, é o Flight Level Two, a coordenação ponta a ponta. Esse é o mundo dos produtos, dos serviços e assim por diante. O que vamos fazer, ou o que fazemos aqui, é garantir que a equipe certa esteja trabalhando nas coisas certas no momento certo. Assim podemos conectar o Flight Level Two com o Flight Level One. O trabalho operacional é feito no Flight Level One. E aqui apenas coordenamos para que a equipe certa trabalhe nas coisas certas no momento certo.

E o legal disso é que, do ponto de vista do Flight Level Two, não me importa quais métodos são usados nas equipes. Então as equipes poderiam trabalhar com, sei lá, com Scrum ou as equipes poderiam trabalhar com Kanban ou as equipes poderiam simplesmente trabalhar, tudo bem também, certo? Então simplesmente garanta que a equipe certa esteja trabalhando nas coisas certas no momento certo. Normalmente, uma organização tem mais de um produto ou serviço, então vemos vários sistemas de Flight Level Two em uma organização. Se temos dependências entre esses sistemas de Flight Level Two, podemos construir um portfólio operacional. Mas isso ainda é um sistema de Flight Level Two, porque estamos coordenando o trabalho entre vários produtos ou serviços. E podemos voar ainda mais alto, e esse é o nível estratégico.

A ideia do nível estratégico é que alinhamos o trabalho em nossa organização com a estratégia, que também colocamos em foco aqui no nível estratégico. Claro que podemos conectar o Flight Level Three e o Flight Level Two, e também o Flight Level Three e o Flight Level One. E na maioria das vezes não temos apenas um quadro estratégico em uma organização, mas vários quadros estratégicos em uma organização. Sim. E esses são basicamente os Flight Levels. E uma coisa é importante aqui, não se trata de melhor ou pior. Então o Flight Level Three não é três vezes melhor que o Flight Level One, mas resolve um problema diferente, certo? Se suas equipes não entregam, você pode tomar as melhores decisões aqui em cima e criar foco e tudo mais no Flight Level Three, as coisas ainda não serão entregadas, certo? Então não se trata de melhor ou pior, trata-se de encontrar as alavancas certas que você pode acionar na sua organização.

E isso é basicamente tudo. Se você se interessa por mais coisas sobre Flight Levels, temos um estande aqui, Catherine, Cliff e eu estaremos lá um pouco mais tarde. E claro também temos workshops que você pode participar. Se você acessar flightlevelsacademy.com, verá a lista de todos os workshops ou a lista dos workshops. E o que fazemos é basicamente falar sobre o que eu falei nesta apresentação. É isso. Obrigado por ouvir.

Sociocracia 3.0

=> James Priest & Jeff Cumps falam sobre [Sociocracia 3.0](/pt/desenvolvimento-organizacional/sociocracy-3-0-james-priest-jeff-cumps/ "Sociocracy 3.0)

O ministério ágil

=> Quão ágeis são os ministérios alemães? - Uma entrevista com Sebnem Andresen.

A vantagem de empresas que experimentam

=> Aprende o que acontece quando a tua empresa experimenta!