Repensandoaagilidade PDF

Repensando a
AGILIDADE
Por que Times Ágeis não tem nada
a ver com Business Agility
IMPRESSUM
Repensando a Agilidade
Copyright © 2020, LEANability GmbH, Viena , Áustria
Versão Impressa: Abril de 2020

2
Versão eBook: Janeiro de 2020
Autor: Klaus Leopold • Texto: Dolores Omann • Ilustrações: Matthias Seifert
Design Gráfico: Mario Simon-Hoor • Tradução para o Português: Jose JR e Paula Viani
eBook: Marina Grosser • Foto: Christian Kollarovits
Todos os direitos reservados. Nenhuma parte do conteúdo deste livro pode ser reproduzida ou transmitida sob qualquer
forma ou por qualquer meio sem a permissão por escrito do editor. Visite-nos em www.LEANability.com ou contacte-nos
em hello@leanability.com para informações jurídicas, outras informações e encomendas em grande quantidade.
Saiba mais sobre Flight Levels e Agilidade em www.LEANability.com/en/flight-levels-training
ISBN 978-3-903205-58-1
Este livro também está disponível como: Atualizações
Kindle ISBN: 978-3-903205-59-8 LEANability.com
Leanpub ISBN: 978-3-903205-60-4 flightlevelsacademy.com
youtube.com/c/LeanBusinessAgility
twitter.com/klausleopold
SUMÁRIO
Prefácio I Klaus Leopold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 04
Prefácio II Jose JR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 06
3
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 08
Parte 1 | O problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Parte 2 | As causas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Parte 3 | A Primeira Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Parte 4 | O Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Referências Bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

REPENSANDO A AGILIDADE
4
V ocê pode transformar qualquer problema em um misté-
rio. Já existem modelos ágeis e frameworks suficientes
para transformar qualquer visão simples em um desafio,
que naturalmente só pode ser resolvido com este ou
aquele método ou framework. Sim, meu telhado é de vidro. Ganho o meu
dinheiro dando dicas valiosas às empresas e o meu nome está asso-
ciado ao Kanban. No entanto, o meu objetivo é nunca tornar as coisas
mais complicadas do que realmente são. E uma simples ideia acompanha
isto: Uma organização ágil não é criada otimizando completamente
elementos isolados uns dos outros—na maioria dos casos isso envolve
times ou equipes. Muitas vezes, porém, odisseias Ágeis começam com
essa (sub) otimização local, onde, ao mesmo tempo, seu método ágil
escolhido se torna o bezerro de ouro. Então a única tentativa é fazer
justiça ao método ao invés de se perguntar o que cria mais valor para
o cliente. Normalmente, a colaboração entre as áreas de desenvolvi-
mento de uma organização e quem toma as decisão de negócios não
são levados em consideração.
Neste livro, aliado ao poder da ilustração, eu quero deixar um ponto

bem claro e significativo sobre este simples insight, que você não pode
certificar, e nem registrar a marca. Nos últimos dois anos, estive de
conferência em conferência com a minha apresentação “Why agile
teams have nothing to do with business agility” (“Por que os Times
Ágeis não têm nada a ver com business agility”). Com frequência, recebo
feedback das pessoas da plateia sobre como eles encontraram os
mesmos desafios e dificuldades durante as transformações ágeis.
PREFÁCIO I
Não espere que este livro se aprofunde na teoria. O que você vai ler
aqui é uma visão geral sobre os erros de muitos projetos de mudanças
ágeis e sugestões simples de como evitar esses impasses ou corrigir a
sua trajetória. Não apresento nenhuma solução absolutamente correta
para todas as organizações. Não considere a minha sabedoria como
5
sabedoria suprema. Pensar por si mesmo é
expressamente permitido.
As odisseias
Por isso, este livro pressupõe um conheci- Ágeis começam
mento fundamental sobre a agilidade e os
mecanismos por trás dela. Talvez a sua em-
com essa (sub)
presa tenha acabado de começar a caminhar otimização local.
rumo a agilidade, ou já esteja afundada até o
pescoço na transformação e está se perguntando o que diabos deu
errado. Neste caso, você provavelmente vai encontrar dicas úteis neste
livro. E talvez ao ler este livro você vai perceber alguma coisa que te
faça sorrir para si mesmo, isto significa que meu objetivo foi atingido.
Divirtam-se!
Klaus Leopold
6
E m 2011 trabalhei em uma startup global que estava
crescendo em vários países, incluindo o Brasil, e algo me
incomodava: a falta de comunicação. Não compreendia
direito para onde estávamos indo, faltavam muitas
informações, as que tínhamos eram muito difíceis de compreender, e a
cada semana mais processos e controles eram modificados e/ou criados,
que na maioria das vezes, facilitava apenas a vida de poucos, além de
muitas dependências. Era uma empresa “moderna”, “inovadora” na época,
e toda a sua estrutura física havia sido construída para quebrar barreiras
e unir pessoas, com salas sem paredes, ambientes com os mais moder-
nos videogames, geladeiras cheias e petiscos a vontade, etc., porém seus
processos não condiziam com essa realidade física. Deixei a empresa
sem entender o porquê eu e outros colegas sofríamos dessa dificuldade
de comunicação.
Em 2012 estava em uma empresa bem menor, tradicional, mas que com
apenas 20 funcionários atendíamos uma das maiores operadoras de
telefonia móvel do mundo, entre outros clientes. Comecei então a levar a
cultura ágil, levar os conceitos, ferramentas, facilitar reuniões e capacitar
todos sobre esse assunto. Mudamos alguns processos e com muito
trabalho começamos a melhorar as coisas porém, depois de um tempo
comecei a encontrar algumas barreiras que não entendia, aparentemente
nós fazíamos tudo certo, tínhamos até métricas de melhoria do time,
cheguei a palestrar sobre os ganhos e conquistas que tivemos, mas a
empresa estava de alguma forma estagnada, com pessoas perdidas e sem
entender para onde estávamos indo. Neste mesmo tempo outras
PREFÁCIO II
empresas começaram a pedir minha ajuda em suas implementações

ágeis e mesmo assim por mais que fossem bem sucedidas as práticas e
resultados metrificados dos times, a empresa de certo modo sofria.
Foi ai que encontrei uma palestra de 2013 do Klaus Leopold no Lean
Kanban Central Europe onde ele falava sobre Flight Levels.
7
Quando descobri o que Klaus estava trazendo com a analogia e o con
ceito do Flight Levels tive a resposta que procurava, pois de maneira
simples e uma linguagem moderna ajudava a melhorar a comunicação
que faltava para que os problemas anteriormente vividos pudessem
assim ser solucionados, e tudo isso através da visão sistêmica iniciando
o movimento de levar o conceito de Business Agility.
Neste livro Klaus conta a história de uma empresa que tinha problemas
como as que eu descrevi aqui, times ágeis, métricas que mostravam a
verdade, pessoas engajadas, cerimonias realizadas, mas com resultados
não satisfatórios e que ao conhecer o Flight Levels encontra um modelo
de pensamento sistêmico de melhoria contínua.
Aqui você vai encontrar um caminho para novos experimentos com os

princípios para novas práticas de comunicação e melhorias contínuas
mais efetivas.
Desejo que esta história e todas as outras que a Flight Levels Academy
tem trazido te inspire profissionalmente e pessoalmente!
Jose JR
8
N os últimos anos, viajei por muitos países dando minha
palestra “Why agile teams have nothing to do with Business
Agility”. Sempre recebi um feedback muito positivo. Na
maioria das vezes eu ouvi comentários como, “isto é exata-
mente o que aconteceu conosco!” Então, eu pensei, “Talvez eu deva fazer um
livro sobre isso rápido!” Mas no final não aconteceu tão rápido assim.
Se você viu minhas palestras, você deve ter notado que eu sou fã de linguagem
ilustrativa. Livros como a versão ilustrada de “Reinventando as Organizações”
de Frederic Laloux e Etienne Appert me fascinam porque as declarações
mais importantes do texto são clara e impressionantemente reforçadas
através das ilustrações. Ficou claro para mim que o tema business agility deve
ser ilustrado a fim de expressar o mais nitidamente possível a insanidade ágil
que eventualmente acontece nas empresas. E eu mesmo queria publicá-lo.
No entanto, imaginei que fosse um pouco mais simples do que realmente
era. Pensei que só precisava de um ilustrador e o livro estaria pronto.
Lá se vai a teoria.
Na realidade, tornou-se uma média expedição para encontrar o ilustrador

certo. O que me deixa ainda mais feliz por ter encontrado Matthias Seifert.
Mesmo nunca tendo lidado com este assunto, ele foi capaz de compreender o
conteúdo rapidamente e traduzi-lo em imagens que mantiveram o equilíbrio
necessário entre a seriedade e o humor.
Gostaria de agradecer mais uma vez a Dolores Omann, que tem me ajudado
desde a primeira edição de “Kanban in der IT” (2012), por ter transformado as
minhas ideias em um texto legível. Agradeço também Matthias Patzak por
AGRADECIMENTOS
sua revisão intensiva do livro. Eu senti que ele se dedicou a considerar cada
palavra no texto e deu uma contribuição fantástica, melhorando a qualidade
deste livro.
Texto e imagens são componentes naturalmente importantes de um livro ilus-

trado, mas sem um layout atraente eles permanecem apenas componentes. 9
Mario Simon-Hoor pegou cada parte e as transformou em um todo, colocando
o toque final neste livro.
Muito obrigado a Jennifer Minnich pela tradução do Alemão para o Inglês. Ela
conseguiu mais uma vez traduzir não só o conteúdo, mas também o espírito do
livro, para o inglês. G
ostaria também de agradecer a
Troy Magennis e Mike Freislich por fornecerem 114 imagens
comentários valiosos sobre a versão em Inglês.
valem mais
Em um esforço conjunto, Jose JR e Paula Viani con que 114000
seguiram entregar a tradução em português em um
palavras
curto espaço de tempo. Muito obrigado por tornar
este livro acessível para as partes do mundo de língua portuguesa!
A capa do livro era uma tarefa um pouco mais difícil e eu precisei de vários
rascunhos até sentir e parecer o que eu queria. Um agradecimento sincero à
minha parceira de vida e de negócios, Katrin Dietze, pela maravilhosa capa do
livro e pela paciência interminável que ela está sempre disposta a me dar.
Klaus Leopold
PARTE 1
O problema
»Queremos
10
agilidade!«
Trata-se de uma empresa que
queria estar preparada para o
futuro e traçou o caminho com
boas intenções.
PARTE 1 | O PROBLEMA
12
N
averdade, nada poderia dar errado. A alta 1 A empresa deveria estar pronta para o futuro. A digi-
gerência estava comprometida, os orça- talização, a Internet das Coisas, o aprendizado de
mentos estavam disponíveis, os agile coa- máquinas e as criptomoedas eram apenas algumas
ches foram agendados. Nos últimos meses, das palavras que estavam surgindo nas discussões.
houve uma descoberta dentro da empre- Mas não haveria mais empresa no futuro se continu-
sa: “Outros são mais rápidos.” Ficou claro para eles que assem a operar tão rigidamente no mercado.
as coisas não podiam continuar assim. Eles poderiam
Recentemente, a gerência havia ouvido falar de empre-
finalmente melhorar a sua capacidade de entrega, ou,
sas com problemas parecidos. Em todos os estudos de
mais cedo ou mais tarde, a empresa desapareceria do
caso e artigos técnicos, Scrum, Kanban, Design Thinking,
mercado.
SAFe®, mOre or LeSS, e outras práticas miraculosas estavam
Nunca faltaram boas ideias e possibilidades para ir em sendo discutidas, todas prometendo grandes melhorias
busca do core business; muito pelo contrário. Estava para o problema em questão. A solução era essa:
levando tanto tempo para implementar boas ideias que
Vamos tornar o nosso negócio ágil!
a concorrência já estava dois passos à frente com um
produto semelhante, embora estes concorrentes mais 13
jovens e dinâmicos não tivessem atingido o mesmo nível
de penetração no mercado. Infelizmente, a empresa
tornou-se um seguidor nos últimos anos, acarretando
dificuldades até mesmo em seus negócios cotidianos.
A empresa já não podia mais contar com a sua posição
forte como líder de mercado. Apareceram alternativas
no mercado, o número de clientes estagnou—e em
alguns meses até caiu.
Algo precisava mudar, e isto estava claro. E a gerência

rapidamente descobriu o que precisava para melhorar:
1 O Time-to-Market (Tempo desde o comprometi-

mento até a entrega do produto/serviço) deveria
ser otimizado.
1 Utilizando o feedback rápido do cliente, as mudan-

ças necessárias deveriam ser percebidas e incorpo-
radas mais cedo. Isso significa: O cliente deveria
estar significativamente mais envolvido no proces-
so de desenvolvimento do que estava até agora.
PREPARAÇÕES PARA 1. Todas os times deveriam ser multifuncionais. Desta

TRANSFORMAÇÃO- forma, os promotores quiseram eliminar quaisquer
dependências existentes para reduzir o esforço de
MODELO coordenação e o tempo de espera, melhorando
assim o Time-to-Market. Para entregar um produto,
600 funcionários de TI foram incentivados a usar méto- times de desenvolvimento de produto com represen-
dos ágeis, a fim de colocar o negócio de volta aos trilhos. tantes de todas as competências deviam substituir
Os promotores do projeto examinaram cuidadosamente os times existentes, que eram equipes organizadas
os fundamentos de vários métodos ágeis e participaram de acordo com áreas especializadas.
de formações e certificações correspondentes. Isto ficou
claro para eles: „Não podemos simplesmente forçar um Uma ideia fundamentalmente boa! É vantajoso se você
novo método para a organização-esse não é o ponto. O for capaz de agrupar o máximo de competências possível.
que importa para nós é permitir que princípios e valores
2. Cada time deveria ser organizado de acordo com a
ágeis tenham um papel maior em nossa cultura corpora-
premissa: Um time, um produto.
tiva e realmente colocar esses princípios em prática.”
14 Para isso, foi dado ao responsável pelo desenvolvimento Isto também é uma boa ideia. Para começar, esta abor-
organizacional interno a função de implementar um dagem ajuda a reduzir as dependências. Sem mencionar
projeto de transformação de 18 meses. que na maioria das organizações, times especializados
trabalham em vários produtos e projetos ao mesmo
Na verdade, acho isto extremamente engraçado: „Vamos
tempo e raramente são capazes de concentrar o trabalho
implementar um projeto cascata para nos tornar ágeis.”
em um item. Isso custa tempo.
Mas não quero me adiantar na história.
Os departamentos e os times podiam até escolher o

framework ágil que queriam usar. No entanto, a gerência
estabeleceu alguns parâmetros que todos precisavam
seguir-porque os promotores do projeto prometeram o
maior efeito de alavancagem com base nestas
condições:
3. Mesmo que os times pudessem escolher o método Eu achei esta abordagem prática para selecionar os
ágil que queriam usar, os seguintes requisitos míni- métodos ágeis bastante visionária. Nem todos os méto-
mos precisavam ser cumpridos: dos são apropriados para todos os contextos e todos os
métodos podem falhar se mal implementados. No entan-
a. O trabalho deveria ser visível, ou seja, deveria ser
to, a parte mais importante dos métodos ágeis, a visuali-
gerenciado visualmente. zação do trabalho e dos métodos de trabalho, sempre
faz sentido: Todos na empresa deve poder ver em que o
b. Todas os times foram obrigados a fazer Standup

time, departamento ou outra unidade organizacional
Meetings diários (breves reuniões diárias, em pé)
estão atualmente trabalhando e onde se encontram os
diante dos quadros.
problemas.
c. As Retrospectivas regulares deveriam proporcionar

aos times uma perspectiva sobre as possibilidades
de melhoria.
d. Duas medições deveriam ser estabelecidas como

um mecanismo adicional de feedback para os
15
times e a transformação. Não para definir objeti-
vos quantitativos, mas para ter mais pontos de
referência para avaliar o efeito das medidas e
melhorias que estão sendo implementadas. As
medidas a seguir contribuiriam para isto:
1 Throughput: O número de itens de trabalho que

são concluídos em um determinado período de
tempo (tais como projetos por mês, Histórias
por Sprint, etc.). No Scrum, isto é c onhecido
como Velocidade.
1 Cycle Time: Isto indica a rapidez com que o

trabalho é concluído.
É inteligente conectar esta gestão visual com Standup as mudanças exigirem um elemento humano para tornar
Meetings diários, porque os ciclos de feedback rápido uma empresa ágil, o propósito econômico de entregar
permitem respostas mais rápidas e coordenação ade- um produto m elhor mais rapidamente é muitas vezes
quada para mudanças aparentes ou desejos do cliente. esquecido. Isso é ainda mais crítico nos dias de hoje,
porque o que se fala muitas vezes conta mais do que o
Também é importante dar um passo para trás no trabalho que se consegue a lcançar.
operacional regularmente, que é o que um time faz em
uma Retrospectiva. Uma Retrospectiva é usada para
considerar o que pode ser feito de forma diferente ou
melhor no futuro. Se você continuar fazendo o que
sempre fez, a probabilidade do resultado continuar

sendo o mesmo é muito alta. No que diz respeito às
medidas: fantástico! Mas apesar do entusiasmo com
16
O que é uma Standup Meeting?
Standup Meetings são breve reuniões que ocorrem
frequentemente – diariamente, por exemplo – posi-
cionando-se em pé diante de um quadro de tarefas
ou quadro Kanban. Dentro de um prazo máximo de
15 minutos, o grupo discute o que precisa ser feito
para concluir o trabalho, como serão tratados impe-
dimentos e problemas de qualidade e quem deve
trabalhar em que. O foco está no trabalho, não em
cada membro do grupo individualmente.
O que é uma Retrospectiva?

O objetivo de uma Retrospectiva é realizar uma
revisão colaborativa sobre como o trabalho foi exe-
cutado ao longo de um determinado período de
tempo e pressupor melhorias a partir desta revisão.
O trabalho operacional é intencionalmente exposto
a fim de observar, a partir de um meta-nível, os
métodos de trabalho, processos, efeitos de melho-
rias anteriores, feedback dos clientes e colegas,
bem como a moral do time. Embora a retrospectiva
seja o centro da melhoria, muitas vezes é negligen-
ciada por causa da má execução [Leanability E020,
2017].
O PROCESSO DE Não acredito que seja possível mudar uma mentalidade

coletiva com um treinamento básico de um dia. No en-
TRANSFORMAÇÃO tanto, é necessário um certo esforço para arrastar 600
colaboradores, juntamente com a direção, através de tal
Mesmo como um observador extremamente cético, devo formação. O único efeito positivo de um projeto assim
dizer: Tiro o chapéu! Por trás do jargão “transformação está na conta bancária da empresa de consultoria que
ágil”, havia um esforço genuíno e palpável para melhorar está promovendo a formação.
os resultados e pensar sobre as coisas de forma diferente.
As organizações ágeis muitas vezes se denominam assim Talvez consiga perceber um pouco de sarcasmo da minha
porque em algum canto da empresa, em algum lugar há parte, porque estou de fato sendo sarcástico.
um time usando Scrum. Nesta empresa, no entanto, as
mudanças foram até o cerne, e eles tentaram reconstruir
uma grande parte da organização de acordo com princí-
pios ágeis. Ao mesmo tempo, a escolha do m étodo foi
deixada a critério dos próprios times—de acordo com
aquilo que os colaboradores achassem apropriado para 17
a sua área de responsabilidade. Chorei lágrimas de ale-
gria ágeis com tal abordagem. Então, como a transforma-
ção foi realmente realizada?
Observe: Durante a implementação, as etapas seguintes

foram interligadas e, sendo assim, não foram concluídas
sequencialmente.
TREINAMENTO
Todos os 600 funcionários de TI tiveram a honra de parti-
cipar de um treinamento básico de um dia que focou em
“mindset ágil”. Qualquer um que tenha lidado com
Agilidade e práticas ágeis tem ouvido com frequência, e
tenham até mesmo internalizado esta ideia: Os métodos
ágeis em si não são os fatores determinantes para o
sucesso, mas a mentalidade por trás deles é que deter-
mina a sua eficácia. Basicamente, concordo com isto.
No entanto, você não pode simplesmente implantar
um novo mindset só porque o projeto determina isto.
Estabelecer o mindset, feito! Não funciona assim.
REORGANIZAÇÃO ATRAVÉS DA
AUTO-ORGANIZAÇÃO
A empresa realinhou os times multifuncionais de
acordo com a estrutura do produto. A gerência não
agiu arbitrariamente, ou seja, os trabalhadores não
foram simplesmente designados a um determinado
time. A gerência só decidiu quais times eram neces-
sários para cada produto. Então, ao invés dos times
serem impostos, uma feira foi organizada. Durante
dois dias, os líderes de cada time usaram displays para
divulgar seu time e os trabalhos disponíveis. Um orça-
mento foi atribuído a cada time com antecedência—
com base no foco estratégico—para que eles pudessem
“comprar” os funcionários necessários. Os funcionários
18 foram autorizados a decidir em que time eles queriam
trabalhar. Na minha opinião, esta foi uma abordagem
muito legal.
Na feira, o time já discutia e muitas vezes até decidia

as práticas ágeis que eles queriam usar. Depois
que os times se formaram, os membros do time
então participaram do treinamento necessá-
rio. Por exemplo, havia treinamentos de
Scrum Master e Product Owner, e se um
time tivesse decidido usar Kanban, eles
poderiam visualizar seu fluxo de trabalho
inicial em um workshop de system design e,
ao mesmo tempo, consolidar o time.
SUPORTE EXTERNO
Reorganizar 600 pessoas é um projeto ambicioso. Em um
curto período de tempo, as pessoas nesta empresa de-
veriam fazer—às vezes em funções completamente no-
vas—algo que nunca fizeram antes. A empresa contratou
16 Agile coaches externos para executar o treinamento
necessário, fornecer uma perspectiva de alguém de fora
sobre a implementação dos métodos ágeis e ajudar os
times a praticar esses métodos. À primeira vista, isto
pode parecer muito, mas é realista quando contextuali-
zado com a dimensão ambiciosa da empresa. Isto faz
sentido, na minha opinião, porque, muitas vezes, quando
mudanças são feitas, os novos métodos de trabalho só
são utilizados enquanto os consultores estão presentes.
Com base na quantidade de dinheiro que esta empresa 19
estava gastando na transformação, este é exatamente o
efeito que eles não queriam.
O que é um workshop de System Design?

O produto final visível de um workshop de System
Design é um quadro Kanban. A visualização em si é
útil, mas não é essencial, mesmo que isso pareça
um pouco estranho. O objetivo mais importante de
um workshop deste tipo é obter uma compreensão
comum sobre a forma como um grupo de pessoas
está atualmente trabalhando em conjunto. A visuali-
zação não representa um processo desejado ou de-
terminado, mas sim o que realmente está sendo
feito agora. Este sistema Kanban é o ponto atual de
partida para melhorias. É por isso que é tão impor-
tante que um sistema Kanban seja projetado por
quem o esteja usando.
OS RESULTADOS APÓS 1 Mais de 80% das equipes foram “totalmente trans

DOZE MESES formadas” (diretamente citado pelo Gerente de
Transição) e cumpriram as condições estipuladas. Eles
foram constituídos por profissionais de várias áreas,
Para implementar os requisitos mínimos-criar times
fizeram o seu trabalho—dependendo do método—
multifuncionais de produtos, visualização, Standup
tornaram visível nos quadros, mantiveram Standup
Meetings, Retrospectivas e medições—a empresa esta-
Meetings e procuraram possibilidades de melhoria em
beleceu um prazo de dezoito meses. A transformação em
Retrospectivas regulares.
si foi estabelecida como um projeto dentro da organiza-
ção. Sob a orientação de um Gerente de Transição, o
Time de Transição planejou exatamente quando as
etapas da implantação Ágil devem ser alcançadas usan-
do quais medidas. O projeto “Agile Business” foi estabe-
lecido e implementado.
Passados doze meses, os promotores da transformação

20
Ágil queriam avaliar o progresso do projeto, então eles
fizeram uma revisão prévia. O plano parecia estar
funcionando:
PARTE 1 | EL PROBLEMA
1 Era importante para o Time de Transição conhecer o No geral, o ambiente foi positivo. A maioria dos times
estado motivacional dos funcionários, a fim de tomar manteve as exigências de transformação inicial e a visu-
medidas corretivas caso estivessem sofrendo. A cada alização do trabalho foi considerada muito útil. Alguns
seis meses, foi realizada uma pesquisa com os colabo- funcionários não conseguiram se adaptar à nova visibi-
radores e a mais recente mostrou uma melhoria quali- lidade e deixaram a empresa. Mas isso era esperado,
tativa na comunicação e na coordenação. Os times muitas vezes é difícil para algumas pessoas.
mantiveram-se atualizados sobre o estado do seu tra-
balho, e sabiam quem estava fazendo o quê e quem Mas, para a maioria, estava indo bem. Estava?
era responsável pelo quê.
21
MOSTRE OS TEUS
NÚMEROS
Implementar métricas foi uma das condições de frame EVOLUÇÃO DO THROUGHPUT NOS
work da transição ágil impostas aos times. O Time de TIMES SCRUM
Transição checou como o cycle time e o throughput
tinham progredido a nível de time e de projeto—e O Time de Transição analisou primeiro a mudança de
não estavam mais aderentes para isso. velocidade nos times Scrum.
Certos padrões apareceram repetida-
Em cada Sprint, um time de Scrum se compromete a
mente, então o Time de Transição
completar uma certa quantidade de trabalho (em Scrum
fez medições representativas a fim
estaríamos falando do número de Histórias de Usuário
de entender melhor o que estava
ou Story Points). No final de cada Sprint, a quantidade de
acontecendo. Por exemplo, vamos
trabalho assumido é comparada com o que realmente é
observar evolução do throughput
entregue—este resultado é registrado no eixo y
22 para as times Scrum e as
(Número de Story Points). Isso nos dá a velocidade—
mudanças no cycle time para
a rapidez, ou throughput, de um time em um
os times de Kanban. Depois,
determinado período de tempo.
veremos se os projetos
estavam ou não sendo
concluídos mais rapida
mente.
23
O gráfico mostra a velocidade agregada dos times Scrum f orem mantidas e forem feitas melhorias contínuas, a
dentro da empresa. A linha pontilhada representa os linha deve continuar constantemente em ascensão e
resultados esperados. Quando tudo está funcionando nunca cair.
perfeitamente em um Time Scrum, a velocidade deve
aumentar continuamente. As expectativas de aumento No entanto, a tendência real dos times Scrum parecia
da velocidade estavam bastante baixas no início: O time completamente diferente. Os times conseguiram come-
precisava se firmar primeiro e se habituar aos novos çar bem e a velocidade aumentou acentuadamente.
métodos de trabalho. No entanto, após este período de Porém, de repente, a linha estagnou e estava agora em
treinamento inicial, a curva deveria aumentar acentua- uma tendência descendente. O desempenho caiu drasti-
damente e, eventualmente, nivelar-se, mas continuar na camente ao longo do tempo.
direção ascendente. Se as Retrospectivas também

EVOLUÇÃO DO CYCLE TIME DOS Se os cycle times de vários times forem reunidos, um
TIMES DE KANBAN bom padrão irá mostrar uma tendência de queda ao lon-
go do tempo. Assim como vimos com as expectativas de
Em seguida, o Time de Transição analisou mais de perto progressão do throughput, normalmente se espera um
o cycle time dos times de Kanban. A nível de time, o cycle ligeiro aumento no cycle time no início, porque os times
time é bastante fácil de determinar: Para cada tarefa têm de se adaptar aos seus novos métodos de trabalho.
concluída, calcula-se a diferença entre a data de início e Em seguida, porém, a linha tende a uma leve queda. Isto
a data de conclusão. Preferencialmente, os cycle times indica que os times estão terminando o trabalho mais
tornam-se mais curtos ao longo do tempo. rapidamente com o passar do tempo, diminuindo assim
o cycle time.
24
É exatamente isto o que é anunciado com métodos Ágeis

de trabalho. Os consultores de Scrum prometem que
você pode entregar mais trabalho mais rapidamente. Os
consultores de Kanban prometem que o cycle time será,
no mínimo, reduzido pela metade, e você pode realmen-
te esperar mais do que isso.
Pareceu muito diferente para os times de Kanban nesta

empresa. Como esperado, o cycle time aumentou ligeira-
mente no início, mas teve apenas uma leve queda ao O que é a velocidade?
longo do tempo. A linha seguiu uma tendência descen- Em Scrum, velocidade é a medida do throughput do time.
dente, mas a melhoria nem sequer atingiu a marca de 1 Ele mostra quanta funcionalidade um time pode oferecer
em um Sprint. A quantidade que pode ser entregue é
por cento-um cycle time reduzido pela metade não foi medida em Story Points.
alcançado.
O que é uma História de Usuário?
Independentemente de Scrum ou Kanban— ficou claro 25
Uma História de Usuário é usado para formular uma soli-
que a capacidade de entrega dos times não tinha mudado citação, por exemplo em um componente de software a
muito. E vamos nos lembrar: Melhorar o “Time-to-market” ser desenvolvido. No mundo Ágil, um formato simples foi
era o objetivo da transformação ágil. estabelecido::
Como um <tipo de usuário>

eu quero <alguma meta ou objetivo>
para que <benefício, valor>
Quais são os Story Points?

Os Story Points representam a complexidade de uma
História de Usuário, e não o tempo necessário. Ao estimar
várias Histórias de Usuários, a complexidade dessas
Histórias são determinadas com relação umas às outras.
26
OS PROJETOS NÃO ESTÃO

SENDO CONCLUÍDOS MAIS
RAPIDAMENTE
A análise das métricas do time não foi nada estimulante E mais uma vez, aconteceu o contrário. Sim, o Time-to-
para o Time de Transição. Também foi problemática a -Market tinha continuado a piorar no início da reorgani-
falta de valores de comparação. Foi difícil avaliar se a zação. No entanto, continuou a piorar... de outra forma:
transformação ágil teve um efeito positivo porque não Os projetos estavam agora sendo entregues mais lenta-
havia medições “de referência” anteriores a transforma- mente do que nos tempos pré-Agilidade. Foi simples-
ção. Uma vez que os times foram completamente reorga- mente uma catástrofe.
nizadas como parte da transformação, não foi realmente
possível determinar se, por exemplo, o desempenho dos Uma enorme pilha de dinheiro tinha sido colocada nesta
times de Scrum havia melhorado ou piorado. transformação ágil. A gerência e o Time de Transição
tinham refletido muito sobre como melhor alcançá-la.
A empresa, no entanto, tinha métricas que poderiam ser A gerência tomou a grande decisão de criar times multi- 27
usadas para comparar o desempenho antes e depois da funcionais e organizá-los de acordo com linhas de
iniciativa ágil: o cycle time do projeto. Esta é uma métrica produtos. Profissionais apoiaram a transformação e
especialmente importante porque o objetivo da organi- treinaram coaches internos. 600 pessoas aprenderam a
zação era reduzir o cycle time do projeto e encurtar o trabalhar com Scrum, Kanban, Standups Meetings,
Time-to-Market. Houve projetos antes da transição e pro- Retrospectivas e métricas.
jetos após a transição ágil, entretanto, após a transição,
os projetos receberam um nome mais ágil de “iniciativas”. E agora o objetivo geral- poder reagir mais rapidamente
Assim, dados comparativos estavam disponíveis. às necessidades do mercado—não tinha sido atingido e
estava, de fato, mais longe do que antes. Uma trans
Neste gráfico, vemos três tipos de linhas: a linha mais formação que levou a empresa de mal a pior?
grossa do lado esquerdo reflete o tempo antes da trans-
formação ágil. Como o Time-to-Market estava aumentan-
do constantemente-o que você pode ver no movimento
ascendente da linha mais grossa-a empresa decidiu fazer
algo a respeito. Ficou claro para todos os envolvidos que
esta linha não cairia imediatamente, mas sim aumentaria
ligeiramente após a transformação ter começado devido
às mudanças que estavam sendo implementadas. Mas,
com base em todos os esforços assumidos, como treina-
mentos e suporte de consultores, era de se esperar que o
Time-to-Market diminuísse drasticamente quando os
novos métodos de trabalho estivessem já em uso.
28
29
QUAL ERA A @$*# DE PROBLEMA AQUI?

30
PARTE 2 | AS CAUSAS
PARTE 2
As Causas
Procurando
obstáculos
31
Sobre inferir coisas de

forma simplista, dependên-
cias ocultas, um fluxo de
valor crescente e o poder
dos limites de WIP.
32
PARTE 2 | AS CAUSAS
E
u li seu livro e tenho uma certa ideia de quais Então, uma funcionária do Time de Transição desta
devem ser as causas para a nossa situação”, empresa entrou em contato comigo. Eles estavam tão
disse a senhora ao telefone. Em “Practical esperançosos quando começaram a transição dos 600
Kanban” [Leopold, 2016], eu revelei o meu colegas de TI para o ágil e não conseguiam entender por
desagrado com o mundo ágil porque me que o Time-to-Market não estava melhorando. Enquanto
deparei com os mesmos pontos de vista estranhos por ela contava sua história era difícil ignorar o leve tom de
várias vezes. Ou seja, que o sucesso de uma empresa ágil desespero, porque ela, pessoalmente, tinha dedicado
acontece simplesmente obrigando todos os times a usar um grande esforço na transição. Ela leu vários livros e
um método ágil de sua escolha. Multiplicar os métodos blogs sobre agilidade, completou o treinamento de
cria algo extremamente novo e rápido. Scrum e Kanban e manteve-se atualizada. A forma como
ela e os seus colegas assumiram esta transformação ágil
Ninguém olha para o fluxo de valor global porque os me pareceu muito profissional e bem pensada. No en-
times vão endireitar as coisas. E enquanto os times se tanto, sua esperança estava por um fio, dados os resul-
esforçam para colocar limites de WIP em seu trabalho, tados da transformação.
tudo permanece o mesmo em questão de portfólio. Na
verdade, é pior do que isso: Uma vez que os times são Ela me pediu para ir até lá ver a situação e então, reali-
ágeis a partir do prazo X, ainda mais projetos são inicia- zar um workshop com os responsáveis pelas decisões,
dos, porque agora tudo vai mais rápido, já que nós soas suposições e pontos de vista—porque tornar o TI ágil
mos ágeis. Os dedicados times multifuncionais tentam era um pedido da alta gerência. O que os gerentes 33
defender seus limites de WIP em Histórias de Usuário e imaginaram ser um negócio ágil quando começaram a
tarefas, enquanto são sufocados em projetos ao mesmo trabalhar para esse objetivo? No entendimento deles, o
tempo. E como poucos dos responsáveis por transforma- que era necessário para alcançar este objetivo? Por trás
ções ágeis estão cientes disto de antemão, recebo liga- de suas boas intenções, havia um entendimento sólido
ções diárias de pessoas que estão diante dos cacos de sobre as inter relações no fluxo de valor, ou eles simples-
seus esforços se perguntando o que aconteceu. mente entraram cegamente na onda ágil? Mais tarde,
pedi que me mostrassem o trabalho e as métricas de
vários times a fim de descobrir quais pressupostos reais
foram usados à medida que se aproximavam de sua
transformação ágil.
CAUSA #1:
A ARMADILHA DA
I NFERÊNCIA SIMPLISTA
NO PROCESSO DE
M UDANÇA
O que eles queriam alcançar nesta empresa: um Time-
to-Market otimizado, feedback do cliente mais rápido e
um novo mindset – acompanhado por uma estrutura que
estaria preparada para enfrentar os desafios do futuro.
Hoje em dia, as empresas e as pessoas nelas raramente
têm o entusiasmo imparcial e a abertura de Gimli. No filme
“O Senhor dos Anéis: O Retorno do Rei”, o guerreiro anão
diz: “Certeza da morte. Pequena chance de sucesso. O
que estamos esperando?! “
34 Quando uma empresa quer mudar, as pessoas dentro

dela querem saber qual será o resultado e como eles vão
chegar lá. Então, eles buscam segurança, e o planeja-
mento é que passa essa segurança. Ter um plano é uma
coisa boa. Só se torna problemático se os responsáveis
pelas decisões forem atraídos por conclusões simplistas
ou recorrerem a modelos, que se tornaram abundantes
no cenário Ágil.
Durante as minhas conversas com a gerência da

empresa, percebi que eles também estavam fazendo
conclusões muito simplista.
PARTE 2 | AS CAUSAS
Esta organização pegou o caminho errado no início de

seu processo de pensamento e ao longo do caminho
confundiu os meios para o propósito. No início, tratava-se
de melhorar o seu Time-to-Market—agora, no entanto,
todos falavam de regras estúpidas que foram escritas há
anos num tipo de framework ágil.
E isto acontece com frequência: Assim que a gerência

decide que standups meeting diários, Retros, times
multifuncionais etc., são os requisitos para atingir o seu
objetivo, a implementação destes métodos de trabalho
ágeis torna-se o próprio objetivo. O foco—tanto para os
Qual é o resultado depois de chegarem a estas conclu- times como para a gestão—está em saber se todas as
sões? Toda a organização estava falando sobre as ques- regras dos métodos estão ou não sendo corretamente
tões mais interessantes, como “O Product Owner pode seguidas. A agilidade é reduzida a algo que não deveria
participar de uma Retrospectiva?” ou “O Scrum Master ser: um método. Porque, então, já não é mais sobre o
também pode executar tarefas operacionais no time?” que a empresa ganha com isso, sem mencionar que o
Foi também fácil discutir sobre opiniões isoladas: “Nós cliente, fica completamente em segundo plano.
definitivamente não vamos usar o Scrum porque teremos 35
que trabalhar com Timeboxes” versus “nós definitiva-
mente não vamos usar Kanban porque ele não tem
Timeboxes”.
Muitas vezes, durante essas dis-

cussões, vou estar com um olhar
perplexo e pensando comigo
mesmo: “Huh?!?! O que é que
isso tem a ver com os objetivos
que vocês querem atingir? “
O PROCESSO DE MUDANÇA COMO Projeto – eu tinha uma ideia do que estava acontecendo
UM “PROJETO” aqui. Depois de reorganizar, algo completamente dife-
rente deveria ter sido criado: algo flexível, adaptável,
Antes do workshop, vários dos gerentes me cumprimen- algo incrível! É por isso que é melhor planejar seu pro-
taram como “Klaus, aquele que vai nos ajudar com nosso cesso de mudança de acordo com os métodos de gestão
projeto ágil”. Eles explicaram sua abordagem para o pro- de projetos estabelecidos internamente na empresa?
jeto ágil e como ele parecia estar dando frutos, especial- Como se a transformação simplesmente se movesse de
mente em termos de satisfação dos funcionários, mas um estado para o outro—especialmente de uma “menta-
que agora o projeto estava em um estado precário. lidade” para outra—de acordo com os prazos em um
calendário. O que eu vi acontecer em muitas organiza-
ções também aconteceu nesta empresa:
36
PARTE 2 | AS CAUSAS
Embora a agilidade viva a partir do princípio puxado,

eles tentaram iniciar o projeto usando um princípio
empurrado— “Faça deste o seu projeto” como no anún-
cio da loja de decoração. As equipes envolvidas foram
capazes de selecionar o método com o qual queriam
trabalhar, então um pouco do princípio puxado estava
presente. No entanto, todo o processo de transformação
foi criado como um projeto em cascata com marcos e
checklists. Eu gosto de ficar longe do dogma, mas eu tive
as melhores experiências com a seguinte abordagem:
37
Princípio Puxado versus Princípio Empurrado

Os Métodos Ágeis de Trabalho copiaram uma parte
considerável do sistema Toyota de produção (TPS).
Um mecanismo essencial para controlar o fluxo de
trabalho é o Princípio Puxado: Um time só pega a
próxima tarefa da fase anterior quando eles têm
capacidade disponível, ou seja, outro trabalho foi
concluído e seu limite de WIP não será excedido
(vamos chegar aos limites WIP um pouco mais
adiante). Em um ambiente de trabalho tradicional,
porém, o trabalho acabado é simplesmente empur-
rado para o próximo passo do processo (Princípio
Empurrado ou “jogado por cima do muro”).
A MUDANÇA É UM NOVO Aparentemente, um organograma ágil é criado quando

ORGANOGRAMA — MISTURA você simplesmente joga os funcionários para o ar, coloca
CAUSA E EFEITO novos rótulos neles e permite que eles pousem em um
local diferente na organização. E agrupados em times
Como mencionamos acima, as pessoas precisam de algo multifuncionais da melhor forma possível, que natural-
para se apegar em tempos de mudança. Querem ver mente ficam junto em uma sala—obviamente. Se o
como será o novo, porque dá a ilusão de supervisão e Herbert se sentar ao lado do Hubert e a Maria ao lado
previsibilidade, ou seja, segurança. O item mais tangível da Brigitte, tudo ficará bem. Então vai funcionar!
em uma reorganização é sempre o novo organograma, e
é por isso que muitos gerentes se apegam tanto a ele. Infelizmente, há agora uma série de modelos organiza-
Isto significa que a configuração, em vez dos processos, cionais prontos que tentam mostrar a gestão como é
se torna o foco da mudança ou melhoria. feita. No caso do Spotify, a intenção não era entregar
um modelo para muitas empresas ao redor do mundo.
O Spotify cometeu o erro em 2012 de falar sobre sua
38
PARTE 2 | AS CAUSAS
rganização interna que fez sentido para os objetivos

o Basicamente, o cliente não se importa se o Sr. Meier está
que eles estavam tentando alcançar naquela época sentado no escritório 238 ou 145 e está participando da
[Leanability E020, 2017]. A configuração mais ou menos” Guilda ou não. Como um cliente do Netflix, por exemplo,
temporária” desta organização e, acima de tudo, os no- eu devo me importar menos com que programadores
mes interessantes das unidades organizacionais como estão sentados lado a lado do que com quais títulos mo-
Tribos, Chapters e Guild ficaram na cabeça das pessoas. dernos eles têm. “Quero ver um filme” é a única coisa
O modelo Spotify foi um exemplo impressionante de que me interessa enquanto cliente. O que me interessa
como uma organização ágil inovadora poderia ser criada, um pouco mais são os processos no Netflix, que espera-
cumprindo um desejo daqueles que queriam ser capazes mos que estejam configurados para que eu possa assistir
de copiar o seu sucesso. ao filme sempre que eu quiser, sem problemas.
Surpreendentemente, os salários dos funcionários da
Salvo que Spotify não considera sua estrutura organiza- Netflix não são pagos pelo Netflix, mas sim pelos clientes
cional como o segredo de seu sucesso, mas sim como que usam o Netflix. Em muitas empresas, entretanto, o
algo extremamente transitório ou até de certa forma cliente não aparece em nenhum lugar nos organogramas.
desprezível. O modelo organizacional não torna o Spotify
ágil; o Spotify é ágil e assim escolheu essa estrutura Se em vez disso você colocar o foco nos processos
organizacional por um tempo, a fim de superar desafios organizacionais e otimizá-lo permanentemente para
específicos—hoje sua estrutura organizacional é diferen- atender às necessidades dos clientes, é possível que em
te. Cliff Hazel, Agile Coach Chapter Lead no Spotify (título algum momento a estrutura organizacional mude. 39
interessante, por favor copie imediatamente!), para Mas então a estrutura é orientada para necessidades e
fraseando W. Edwards Deming disse uma vez durante insights atuais, não para desejos. “Ágil” é o que a organi-
uma conversa comigo [The Deming Institute, 2018]: zação se torna através de seu próprio desenvolvimento,
“Todas as organizações estão perfeitamente preparadas não algo que surge de acordo com um determinado prazo.
para os resultados que produzem.” Então, se uma organi-
zação teve o mesmo problema que Spotify em 2012,
então seu modelo pode ser recomendado. Mas talvez
não. O sucesso depende de responder uma questão:
Como ganhamos dinheiro e que problema estamos
tentando resolver?
A mudança organizacional deve começar com
os processos organizacionais porque satisfazer
os desejos do cliente, bem como o Time-to-
Market, é uma questão de processos utilizados,
colaboração e dependências.
CAUSA #2: Quando cheguei nesta empresa, mais de 80 por cento
LIDANDO COM dos times já estavam trabalhando com seus métodos

escolhidos—então, podíamos ter boas discussões con-
DEPENDÊNCIAS ENTRE cretas sobre os quadros.
TIMES E PRODUTOS Muitas vezes eu vi quadros construídos como o que você

vê na imagem abaixo. Reparei em uma área em todos os
Depois que eu verifiquei a situação da gerência e fiz quadros: “Aguardando Externo”. Cada time tinha sinalizado
minhas primeiras descobertas, eu segui para os times. esta área de forma diferente-alguns como uma área de
Achei uma coisa incrível nesta empresa: Todas os times- estacionamento, outros apenas com uma nota auto-
-conforme exigido pelo framework- tornaram seu traba- adesiva para bloquear—mas sempre com a indicação de
lho visível. Não importava qual time eu visitasse: Havia que um time não poderia levar essa tarefa adiante. Esta-
sempre um quadro Kanban, ou um quando Scrum ou vam esperando entregas, informações ou serviços, tais
algum outro tipo de visualização. Isso facilitou minhas como a abertura de portas no firewall ou a introdução de
discussões com os times sobre o seu trabalho. Nós não alterações nos campos de bases de dados num produto
discutimos processos abstratos, e sim, os quadros que diferente. Em muitos casos, isso significava que o pro-
refletiam seus métodos de trabalho. Foi perceptível cesso deveria continuar em outro quadro dentro da
tanto pela gerência quanto pelos times que eles queriam organização, uma vez que não estava apenas lidando
40 mudar as coisas para melhor. com dependências de entregas externas.
PARTE 2 | AS CAUSAS
41
Fui à procura de padrões e fiz perguntas como: “De quais Pessoalmente, acho os gráficos de dependência fasci-
time frequentemente você tem que esperar?” e “ Com nantes, mas a gestão e os times ficaram assustados no
qual time você tem mais interações, em que você regu- início. A ideia deles era eliminar o maior número possível
larmente está esperando por algo?” Meu objetivo era de dependências. É por isso que os times foram reorga-
visualizar essas interações em gráficos de dependência, nizados como times multifuncionais, onde cada um só
e então eu trabalhei de time em time consolidando os estava trabalhando em um produto. Os times não deviam
fractais. Gradativamente, uma imagem começou a se for- nem ter que esperar por outros times. E ainda havia um
mar e ficou claro quais times estavam sendo utilizados número de dependências visíveis que naturalmente
com bastante frequência. aumentaram os cycle times. Porque o que sai de um sis-
tema deve primeiro ser priorizado no próximo sistema.
Por exemplo, se o trabalho chega em um time de Scrum,
ele deve esperar pelo menos uma Sprint até que seja
processado.
O QUE ELES SE ESQUECERAM DE Você pode eliminar o máximo possível de dependências

CONSIDERAR? entre times e departamentos se, por exemplo, você ofe-
recer produtos ou serviços completamente idênticos.
1. Um produto, muitos times. Estava certo que cada Isto é possível em Buurtzorg, a empresa de assistência
time, na maioria dos casos, só trabalhava em um médica sobre a qual Frederic Laloux escreveu em
produto. No entanto, muitas vezes eram necessários “Reinventing Organizations” [Laloux 2016], que se tornou
vários times para um produto. Isso criou dependên- o principal exemplo de auto-organização. Cada time
cias entre os times trabalhando no mesmo produto. oferece os mesmos serviços, mas pode haver variações
se os cuidadores decidirem personalizar os serviços que
2. Dependências entre produtos. Os produtos em si não
oferecem. Mas mesmo na Buurtzorg, as conexões neces-
eram completamente independentes uns dos outros.
sárias—dependências—existem além do trabalho diário,
Quando uma mudança era feita no Produto 1, algo
tais como as unidades administrativas da organização.
também precisava ser alterado no Produto 2. E quan-
Assim como em todas as outras organizações, existem
do algo no Produto 2 era alterado, algo no produto 7
departamentos de marketing, vendas ou jurídico—nem
também precisava de uma alteração.
todas as empresas podem se dar ao luxo de colocar um
3. Peculiaridades do trabalho do conhecimento. Esta- advogado em cada equipe. Sem mencionar que certas
mos falando aqui de 600 pessoas de TI. No chamado questões que afetam toda a organização têm de ser
trabalho do conhecimento, eu não conheço nenhuma tratadas de forma centralizada e não individualmente
42 nos times.
organização com mais de 30 funcionários que não
tenha absolutamente nenhuma dependência e um
A ideia de eliminar todas as dependências em uma
único time gerando 100% de valor para o cliente.
organização não é realista. Uma organização não é um
Normalmente, vários times estão envolvidos na
container para times completamente independentes—
entrega de um produto de uma forma ou de outra.
pelo menos não no trabalho do conhecimento.
Deve haver o maior número possível de

dependências eliminadas. O mais importante,
porém, é a boa gestão de cada dependência
que persistir.
PARTE 2 | AS CAUSAS
43
O F MAIS RÁPIDO DO MUNDO

OU
COMO VOCÊ SUB-OTIMIZA SISTEMAS
Vamos analisar o problema usando um teclado. Vamos
Sim, eu sei, estou repetindo para mim mesmo. Se você supor que os 600 funcionários de TI nesta empresa
44 leu um dos meus outros livros ou assistiu alguma das oferecem cartas de correspondência como seu produto.
minhas palestras, conhece bem esta citação do Russell Cada time é responsável por uma letra específica do
Ackoff. A questão é que, é absolutamente verdadeira. alfabeto.
Como acabamos de ver, apesar de todos os esforços de Qual é o princípio da correspondência? Certamente não
separação de times multifuncionais e times por produto uma série aleatória de letras do alfabeto. Queremos que
nesta empresa, muitas dependências graves ainda a nossa correspondência tenha palavras significativas,
existiam. A situação não melhorou quando os times usadas para criar frases significativas que, por fim, criem
começaram a usar métodos ágeis. Um time pode aumen- um texto significativo. Essa é a exigência do cliente. E é
tar surpreendentemente o seu desempenho e melhorar completamente irrelevante a rapidez com que as teclas
continuamente, mas o efeito desta melhoria local é individuais são pressionadas.
limitado ao próprio time.
A mesma coisa acontece em uma empresa: Se cada time
Juntar unidades localmente otimizadas não cria um siste- comanda especificamente uma tecla, não importa a
ma globalmente otimizado-por mais que eu odeie dizer rapidez com que um time trabalhe. Mesmo que tenhamos
isto. Muito pelo contrário: Se um time otimiza ao máximo o time “F” mais rápido do planeta em nossa organização,
seu trabalho, toda a cadeia de valor pode ficar bagunçada. um time tão rápido que saia até fumaça do teclado, a
Ao invés disso, o objetivo é criar uma cadeia de valor correspondência não será finalizada mais rapidamente
orientada para os desejos dos clientes. por conta disso.
PARTE 2 | AS CAUSAS
45
Então, não é importante o quão rápido os times traba- No entanto, a realidade em muitas empresas é, muitas
lham individualmente dentro de uma organização. Se vezes, o oposto. Há muitos produtos e muitos times—um
queremos aumentar o output ou saída do sistema, time trabalha em muitos produtos, e um produto precisa
temos de assegurar que o time certo está trabalhando de muitos times para seguir adiante.
na coisa certa no momento certo. Em outras palavras:
Tem a ver com as dependências, ou melhor, como você A convocação de times de alto desempenho me dá até
lida com elas. dor de cabeça quando vejo que ninguém está pensando
no processo. A agilidade de uma organização não é
Esta empresa ainda estava muito bem. Na maioria das criada juntando um monte de times ágeis. A agilidade é
vezes, grande parte dos times trabalharam em um só criada quando as interações entre os times são ágeis.
produto e poucos trabalharam em mais de um produto.
Era esse o problema nesta empresa: As interações entre
cada time não estavam sendo gerenciadas.
46
PARTE 2 | AS CAUSAS
CAUSA #3:
UM FLUXO DE VALOR
INCOMPLETO
Então, descobrimos que havia muito mais dependências
do que alguém imaginava e que elas não estavam sendo
gerenciadas. Algo me intrigou o tempo todo em que estive
em frente aos quadros dos times: Os quadros eram bem
pequenos. Se estivesse visitando uma operação com cinco
pessoas, podia até ser compreensível. Naturalmente, não
estamos focados em quem tem o processo mais... longo.
Neste caso, entretanto, processos tão curtos e simples,
juntamente com um fluxo de criação de valor curto, pare-
cia bastante improvável. Aqui estavam times de 7 a 14
pessoas trabalhando em um departamento de TI com 600
colaboradores, em uma empresa que era duas vezes
maior do que o próprio departamento.
47
“Está bem, então você está em desenvolvimento”, come- É bom saber! Juntos moldamos a integração como parte
cei com o meu interrogatório. “Quando você terminar o da ilustração de criação de valor, então o quadro agora
desenvolvimento, então tudo está completamente finali- se parecia com isso:
zado e o valor para o cliente foi gerado?” A princípio,
todos acenaram vigorosamente, alguns até soltaram um
enfático “ Sim, claro!”. Porém, depois de um momento de
reflexão, outra pessoa levantou a voz timidamente:
“Bem, mais precisamente, a integração vem depois.”
“Mas depois da integração, está tudo pronto?”, continuei Então parei por um momento. Com “Integração”, “Teste
a perguntar. Os membros do time pararam para pensar de Aceitação” e “Release”, tínhamos três etapas visuali-
um momento antes de responder. “Na verdade, depois zadas no quadro que poderiam ter um impacto substan-
da integração vem a aceitação do departamento de ne- cial no Time-to-Market. Por esta razão, eu quis olhar os
gócios.” O quadro ganhou mais uma coluna com os testes passos mais de perto e perguntei, “Em quais intervalos é
de aceitação. feita a integração? E qual a frequência dos testes de
aceitação e com que frequência são feitos os releases? “
Gradativamente, o time se acostumou à ideia de que O segredo do enigma começou a se revelar. A integração
este quadro seria um pouco mais longo. Nem precisei estava com um tempo relativamente adequado, sendo
perguntar sobre o próximo passo. “Depois disso, é claro mensal. Porém, tanto os testes de aceitação, como os
que precisamos fazer um release (lançamento)”, foi releases eram feitos apenas quatro vezes por ano. Esta é
imediatamente jogado para mim. uma informação extremamente útil quando se trata de
melhorar o Time-to-Market. Como você poderia chegar
mais rápido ao mercado assim?
48
PARTE 2 | AS CAUSAS
ONDE HÁ UM FLUXO, HÁ TAMBÉM Vários outros membros do time começaram a limpar o

UMA FONTE espaço no lado esquerdo do quadro porque estava
sendo adicionada uma coluna depois da outra. Entre
Tudo bem, nós tínhamos trabalhado downstream (“rio tanto, bastou um olhar e começaram a me contar tudo
abaixo”) até certo ponto. E se existe um downstream, o que estava acontecendo upstream. Estava mais ou
provavelmente também há um upstream (“rio acima”). menos assim:
Antes que o desenvolvimento possa sequer começar,
supostamente algumas decisões precisam ser tomadas. 1 Primeiro, as ideias para o produto eram coletadas em
Eu coloquei isso na seguinte pergunta (pouco sutil): uma piscina de ideias.
“No início do quadro fica o Backlog. Então, você simples-
mente começa e nada acontece antes? “ Claro, esse não 1 Estas ideias eram grosseiramente ordenadas durante
era o caso. “Não, você não pode dizer que isso realmente uma triagem (uma seleção preliminar).
começa aqui. O Backlog é apenas o ponto de partida
para o desenvolvimento. “ Essa é uma informação impor-
1 Esboços de cases de negócios eram criados para as
ideias selecionadas.
tante, então nós renomeamos o Backlog para “Backlog
de Desenvolvimento” e seguimos upstream.
1 O esboço do case de negócio era então enviado ao
Comitê Diretivo, que decidia se deveriam ou não dar
Se existe algo como um backlog de desenvolvimento,
andamento a uma ideia.
também deve haver algo onde as ideias são criadas e até 49
mesmo avaliadas em um ou mais passos. Lentamente,
1 Uma vez que o Comitê Diretivo aprovasse o esboço,
todo o processo começou a se desenrolar à nossa frente. era criado um caso de negócio detalhado.
“Olha, é assim que isso funciona aqui”, começou um dos
membros do time. “Há um Backlog de Produto onde mais 1 O caso de negócio detalhado precisava novamente de
ou menos todos os pedidos de produtos são coletados. uma aprovação final de um comitê.
Antes que algo pouse em nosso Backlog de Desenvolvi-
mento, devemos primeiro analisar os pedidos individuais
a fim de saber como e quando vamos lidar com isso. “ Ufa! O fluxo de valor todo havia crescido um pouco.
50
PARTE 2 | AS CAUSAS
51
51
O time estava quieto. “Ok, isso não parece muito ágil”, No entanto, não tem nada, absolutamente nada, a ver
alguém comentou. Exatamente. O peso de todas as coi- com business agility. E o business agility nunca será
sas em todo este processo, foi colocado sobre os times alcançado se todo o processo lento e a lógica do sistema
de desenvolvimento para se tornar mais rápidos. Aos forem simplesmente mantidos sem consideração pelo
times de desenvolvimento só restava tentar recuperar sistema de ponta a ponta. Apesar destas práticas ágeis
um pouco do tempo que estava sendo desperdiçado em de desenvolvimento, esta organização continuava fra-
todo o processo. E era desperdiçado muito tempo. cassada. Estava faltando uma gestão de ponta a ponta
do fluxo de valor.
A triagem pré-seleção era realizada mensalmente—
que pareceu relativamente rápido. No entanto, o Comitê
Diretivo se reunia apenas quatro vezes por ano e as deci-
sões sobre os conceitos detalhados só eram tomadas Business Agility é criada através de processos
uma vez por ano. Demorou uma eternidade para uma lean que rapidamente implementam ideias,
ideia passar por este processo de tomada de decisão
permitindo assim que as equipes sejam
antes dela pousar no Backlog de Desenvolvimento.
capazes de entregar algo rapidamente.
Essencialmente, antes que algo pudesse ser desenvol
vido, havia um pré-processo de meses (e muitas vezes
52 até anos) que consistia principalmente de esperar. Em

outras palavras: Eficiência de fluxo—a proporção entre
o tempo de trabalho e o tempo de espera—estava em
apuros. Contudo, a gerência esperava um Time-to-Market
mais rápido, focando em fazer uma pequena parte—
chamada nos times de desenvolvimento-ágil. Business
Agility não é criada quando os times mantêm seus O que é Eficiência de Fluxo?
Standups Meeting Diários e procuram melhorias Eficiência de Fluxo indica a proporção de tempo em que o
durante suas Retrospectivas do Time. Isso é, na melhor trabalho ativo está sendo feito dentro do cycle time total
das hipóteses, um desenvolvimento ágil (local), o que é para um pedaço do trabalho.
razoável.
PARTE 2 | AS CAUSAS
CAUSA #4: Há também um limite “implícito” de WIP no Scrum. Ele
LIMITES DE WIP NO vem de trabalhar em Sprints e do compromisso associado

a uma certa quantidade de trabalho que deve ser concluí-
LUGAR ERRADO da no Sprint. Durante uma Sprint, não é permito puxar
nenhum trabalho adicional para o sistema, definindo as-
sim mais ou menos um WIP máximo por Sprint. O efeito
dos limites de WIP implícitos ou explícitos é, entre outras
Trabalhar em muitas coisas ao mesmo tempo é uma das coisas, que os cycle times diminuem e a previsibilidade
maiores aflições nas organizações—o trabalho não é limi- da conclusão do trabalho aumenta.
tado. Como mencionado, muitas pessoas nesta empresa
tinham passado algum tempo se aprofundando em méto- O fator positivo era que quase todas os times desta
dos e princípios ágeis, incluindo a limitação do Trabalho empresa trabalhavam com limites de WIP explícitos ou
em Processo (WIP). Limites de WIP são geralmente asso- implícitos. Infelizmente, isto não parecia estar ajudando.
ciados ao Kanban, indicados com números no topo de Então, os limites de WIP eram apenas um desejo, ou
cada coluna mostrando a quantidade máxima de trabalho estava acontecendo mais alguma coisa aqui?
permitido no sistema em qualquer momento. Quase todos
os times desta empresa que usavam Kanban trabalhavam Mas primeiro, vamos fazer um pequeno desvio para
com sistemas de WIP-limitado. aprofundar um pouco mais sobre os limites de WIP.
53
Por que eu uso “Trabalho em Processo”?

Se você já está familiarizado com Kanban ou métodos ágeis,
você pode estar se perguntando por que aqui é chamado de
„Trabalho em Processo“. Você está certo, originalmente a
comunidade Kanban tinha definido como „Trabalho em
Progresso“, o que era bom, uma vez que o termo „processo“
tem uma conotação negativa em muitas organizações.
Para mim, pessoalmente, „processo“ é uma palavra neutra

porque deve simplesmente descrever como o trabalho é reali-
zado em uma organização. O problema em muitas empresas é
que eles têm muito trabalho em processo que não faz nenhum
progresso. Está parado, por assim dizer. É por isso que eu
comecei a usar „Trabalho em processo“ constantemente, por-
que ele descreve melhor a realidade dentro da organização.
.
COMO O LIMITE DE WIP FUNCIONA,

parecido com a próxima ilustração. O quadro está coberto
POR QUE ELES FUNCIONAM E AS com 200 notas e um segundo quadro pode ser necessário
VANTAGENS QUE TRAZEM para colocar todas elas. A questão é que esta visualização
é enganosa. Poderia te levar a crer que dez colaboradores
Em uma empresa, visualizar o trabalho é um bom primeiro estão trabalhando em todas estas coisas. Infelizmente, a
passo para a melhoria. No entanto, você também deve realidade é que ninguém está trabalhando na maioria dos
entender e discernir o que esta visualização lhe mostra, a 200 itens do sistema. Isso significa que há muito “Trabalho
fim de realizar as ações certas. Obviamente, você pode em Processo”, mas não muito “progresso”—poucos traba-
ver o que está sendo trabalhado, quem está trabalhando lhos avançaram, embora eles passeiem pelo sistema.
em que e onde há problemas. No entanto, quando visito
uma empresa pela primeira vez, em muitos casos vejo A consequência é que você não pode determinar quando
que há muito trabalho no sistema. o trabalho será concluído em um sistema funcionando no
limite da capacidade (congestionado). A previsibilidade e
Vamos imaginar um sistema em que dez funcionários a adesão aos prazos de entrega não estão presentes
trabalham em 200 coisas ao mesmo tempo. Seria algo nesses sistemas!
54
PARTE 2 | AS CAUSAS
As pessoas não são capazes de realizar

multitarefas porque a verdadeira multi-
tarefa significaria que você pode se
concentrar totalmente em fazer duas
tarefas distintas ao mesmo tempo. Você
poderia trabalhar em duas tarefas com-
pletamente independentes em dois lap-
tops—como escrever uma história dife-
rente com cada mão? Provavelmente
não. E mesmo que você pudesse, em
algum momento você ficaria sem partes
do corpo que poderiam ser usadas para
completar tarefas adicionais. Quando
pensamos que estamos sendo multita-
refas, o que estamos realmente fazendo
é “troca de tarefas”. Mudamos continu-
amente de uma tarefa para outra; deixamos de lado um De volta ao nosso quadro: Se um colaborador trabalha
componente do trabalho (inacabado) e enquanto isso em 20 coisas diferentes em geral, você pode deduzir que
ninguém mais trabalha nele. ele raramente está se concentrando em um componente 55
específico do trabalho. Na maioria das vezes, um compo-
nente do trabalho é finalizado e os outros 19 permanecem
inacabados. Tendo em vista que não é apenas um colabo-
rador que está trabalhando assim, mas sim 10, temos 190
dos 200 componentes de trabalho, que ficam parados.
Isso pode ser ilustrado facilmente no quadro. Na parte
superior do quadro, estão expostas somente as tarefas
que estão sendo trabalhadas ativamente. Na parte
inferior do quadro, é exibido o trabalho inativo até este
momento.
Visualizar o trabalho mostra a verdadeira

disfuncionalidade de um sistema. A
verdadeira forma de melhorar as coisas é
limitando a quantidade de trabalho que
é permitida no sistema.
MAIOR EFICIÊNCIA DE FLUXO- uma ideia será ou não implementada já atrasa imen-
SISTEMA MAIS RÁPIDO samente o trabalho ativo. Um pouco do trabalho é
feito e, em seguida, eles têm que esperar por uma
A relação entre o trabalho ativo e inativo no sistema pode decisão, que às vezes pode demorar vários meses.
ser medida. Calculando a eficiência do fluxo, podemos
afirmar quanto do cycle time é realmente tempo de tra- 2. Quanto trabalho está no sistema? Quanto mais tra-
balho ativo. balho está rodando em um sistema, a eficiência de
fluxo é comprovadamente pior. Há uma diferença
Vamos supor que o cycle time para um componente do entre estar saltando constantemente entre três
trabalho é de dez dias. Traduzido para o nosso quadro, a componentes de trabalho e entre dez componentes
eficiência do fluxo detalha quantos dias um componente de trabalho.
do trabalho passa na parte ativa e quantos dias na parte
inativa. Surpreendentemente, a eficiência do fluxo na
Isto significa que o Trabalho em Processo tem uma grande
maioria das organizações é muito baixa. Com “baixo”
influência na eficiência do fluxo. Se uma organização
quero dizer menos de dez por cento, por exemplo, apenas
quer se tornar mais rápida, o foco principal não deve ser
dez por cento do “cycle time” é tempo de trabalho ativo.
na otimização do trabalho ativo. Esse é exatamente o
A eficiência do fluxo é influenciada principalmente por problema com muitos programas de eficiência: Eles focam
dois fatores: apenas no trabalho ativo e querem torná-lo mais rápido.
56 Vamos supor uma eficiência de fluxo de 10%, e você leva
1. Quão grande é a parte da cadeia de criação de valor as pessoas a trabalhar duas vezes mais rápido. Você ainda
que você pode ver? Quanto maior for a porção, me- só poderá ganhar um máximo de cinco por cento no
nor será a eficiência do fluxo. Nós só temos que pen- desempenho do sistema porque 90 por cento do tempo,
sar sobre a extensa corrente de valor desta empresa o trabalho é inativo. Tentar melhorar o desempenho
que estamos observando (ver Causa # 3). O processo individual não nos faz avançar. Faz mais sentido focar no
de tomada de decisão utilizado para determinar se sistema e trabalhar para melhorar o seu desempenho.
PARTE 2 | AS CAUSAS
REDUZINDO O WIP: ESTACIONE O Para o seguinte exercício de raciocínio, vamos supor que
TRABALHO EM FRENTE AO SISTEMA há apenas uma pessoa trabalhando nas tarefas e esta
pessoa nunca tem impedimentos. Vamos supor que há
Isso é tudo muito bom, reduzindo WIP... mas como deve ser três tarefa s – A, B e C – em nossa “Piscina” de Opções à
feito? Isso significa recusar ordens? Deixa-me te acalmar. frente do sistema. Cada tarefa requer cinco semanas
Não, isso não significa recusar os pedidos dos clientes. para a implementação. Se trabalharmos com um limite
O trabalho deve ser mantido à frente do sistema, usando de WIP de 1, precisamos decidir com qual tarefa vamos
uma “Piscina de Opções”, por exemplo. começar: A, B ou C. Vamos trabalhar nas tarefas em
ordem. Nós selecionamos A e temos condições de nos
Qual deve ser a vantagem de fazer isto? Antes, o trabalho concentrar totalmente nela (B e C permanecem na
estava esperando na área de “Trabalho Inativo” e agora Piscina de Opções).
em uma “Piscina de Opções”. Qual é a diferença?
57
58
A tarefa A está concluída em cinco semanas. Depois de A, elevado. Vamos comparar:
começamos a trabalhar em B e novamente podemos fo-
car completamente nisto—a tarefa B é concluída após a A: 13 vs. 5- uma melhoria incrível no desempenho!
décima semana. Finalmente, a tarefa C é trabalhada. B: 14 vs. 10-também não é uma melhoria ruim
Uma vez que somos capazes de nos concentrar apenas
em C, ele é concluído após a 15ª semana. C: 15 vs. 15-permaneceu o mesmo
Vamos aumentar o limite de WIP para 3 em um novo O ponto é, ninguém diz que todo o trabalho em um sistema
exercício de raciocínio e começar a trabalhar em todas com o WIP-limitado será concluído super rapidamente (e
as três tarefas ao mesmo tempo. Chegamos à conclusão se alguém te disser isso, esqueça o que eles te disseram).
de que as pessoas não são capazes de realizar multi O fato é que o cliente A será atendido mais rapidamente
tarefas. Assim, a pessoa alterna as tarefas A, B e C, trado que o cliente B, e o cliente C tem que esperar um pou-
balhando em cada tarefa por uma semana de cada vez. co mais. No entanto, você pode prever quando o cliente
Nesta variação, a tarefa A é concluída após a 13ª semana, C será servido.
B após a 14ª semana e C após a 15ª semana.
Estranhamente, muitas vezes ouço o argumento, “Mas
Agora vemos a diferença. Com um limite de WIP de 3, isso é injusto!” O que se traduz mais ou menos assim; “É
todas as três tarefas têm um cycle time elevado. Com um melhor se servirmos todos os clientes igualmente mal.”
limite de WIP de 1, algumas tarefas têm um cycle time Preciso dizer mais alguma coisa ou devo parar por aqui?
PARTE 2 | AS CAUSAS
É claro que apresentei as diferenças com pressupostos Você não tem que acreditar em mim, porque graças a
bem simplificados. Claramente, isso não significa que John D. C. Little, isso foi matematicamente provado (Little
apenas uma tarefa deve ser trabalhada de cada vez. Não & Graves, 2008). De acordo com a “Lei de Little”, o cycle
estou usando este exemplo para dizer que 1 é o limite de time médio de um sistema no qual um novo trabalho
WIP ideal! Mas, um limite de WIP de 10 é melhor do que está sempre entrando é a média do número de tarefas
um limite de WIP de 100. Além disso, a mudança perma- no sistema dividido pela média do throughput (vazão).
nente entre tarefas não é gratuita—há uma enorme so-
brecarga que a acompanha. Mesmo se você não levar em Trata-se de encontrar o limite certo para cada
conta as despesas adicionais, ainda é claro que: Menos sistema através de observação contínua, e
WIP significa cycle times mais curtos.
permitir que o trabalho entre no sistema
numa sequência economicamente adequada.
59
Um Breve Resumo:
Por que eu acho que os A previsibilidade melhorará. Se várias
limites de WIP são

tarefas são trabalhadas paralelamente, você perde a visão
geral de quanto tempo é realmente necessário para cada
Realmente Bons tarefa individualmente. Pensando em tarefas paralelas, são
calculados reservas de tempo para que o trabalho seja feito
de acordo com o cronograma. Os limites de WIP melhoram
o foco em menos tarefas e ajudam a entender quanto tempo
será realmente necessário para uma tarefa.
O Cycle time é reduzido

Se tivermos menos tarefas para trabalhar ao mesmo
tempo, aquilo em que estamos trabalhando será finali-
O risco de entrega é reduzido. Os projetos estão frequente-
zado mais rapidamente. No exemplo com as tarefas A, B
mente ligados a prazos. Vamos supor que você combinou de
e C, o cycle time médio para um limite de WIP de 1 é de
entregar as três tarefas—A, B e C—na semana 13. No cenário
dez semanas. Com um limite de WIP de 3, o cycle time
em que o WIP=1, A é entregue após cinco semanas e B após
60 médio é de 14 semanas. O cycle time está diretamente
dez; não há tempo suficiente para terminar a tarefa C, mas a
ligado ao time-to-market. Se quiser melhorar o time-
maior parte dela está lá. No cenário WIP = 3, nem A nem B
to-market, não se pode evitar limitar o Work in Process
estão prontos na semana 13, e de modo algum C pode ser
(Trabalho em Processo).
entregue. Na realidade, pouco antes da data de entrega na
semana 13, o pânico toma conta e tudo é feito para, pelo
menos, entregar algo—mesmo que a qualidade do trabalho
seja pobre. Um limite de WIP mais baixo reduz a pressão por-
que o trabalho pode ser continuamente entregue.
O custo de atraso é reduzido.

No primeiro cenário do exemplo ABC, já ganharíamos
dinheiro com tarefa A em cinco semanas porque ela
estaria concluída. No segundo cenário, demorou 13 se- Eles reduzem multitarefas caras ou mudança de tarefas. Os
manas. A diferença horária de 8 semanas é o Custo de limites de WIP evitam que muito trabalho seja iniciado de
Atraso. Se conseguíssemos ganhar 10.000 Reais por uma só vez, assim o foco permanece no que é realmente im-
semana com a tarefa A concluída, teríamos perdido portante e precisa ser concluído agora. Além disto, os limites
80.000 Reais de receita no cenário em que o limite do de WIP reduzem respectivas despesas gerais causadas pela
WIP era de 3. Este é um ponto fundamental: Os limites mudança de tarefas. Assim, os limites de WIP tornam um
de WIP têm um componente econômico! sistema mais eficiente.
PARTE 2 | AS CAUSAS
LIMITES DE WIP – GRANDE IMPACTO

NA IMPRESSÃO FINA
O fato de 99% das empresas não pensarem completa- No entanto, os times são geralmente parte de um con-
mente em sua estratégia de limites de WIP certamente texto organizacional maior, o que significa que a questão
está relacionado com a história de métodos como Kanban dos limites de WIP também deve ser entendida neste
ou Scrum. Durante muito tempo, Kanban e Scrum foram contexto. Se o desempenho geral da empresa—a agilidade
basicamente vistos e comercializados como plug-ins de do negócio-deve melhorar, você deve ler as letrinhas
alta velocidade para times. Assim, os limites de WIP pequenas sobre como usar os limites de WIP.
tornaram-se instrumentos para limitar a quantidade de
trabalho nos times para que os times fossem mais rápi- Então, deixa-me aumentar a letra para você:
dos. Fundamentalmente, isso está ok se esses times só
trabalharem para si mesmos e não fizerem parte de um
contexto maior.
61
Então, agora nossa empresa trabalha em iniciativas— Como esta funcionalidade específica é criada através de
o termo ágil para projetos. O que aconteceu com essas várias pequenas peças de trabalho, as Histórias de Usuário
iniciativas depois que elas foram escolhidas? são divididas em Tarefas. Estas são peças de trabalho que
podem ser concluídas dentro de um dia, por exemplo.
A ideia da iniciativa global foi primeiramente dividida em
aspectos parciais, ou seja, Épico, que são unidades de Era assim que funcionava nesta empresa. Em outras em-
trabalho estimadas, cuja soma deve resultar no produto presas, poderia ser completamente diferente, onde os
final. Um exemplo hipotético disso seria (apenas para projetos, por exemplo, podiam ser divididos em pacotes
fins ilustrativos): de trabalho, e pacotes de trabalho em tarefas. O impor-
tante é realmente esta mensagem fundamental: Grandes
A iniciativa é “Dominação Mundial”. trabalhos, tais como projetos, não são concluídos em
sua totalidade em uma única mesa, mas são, em vez
Um Épico desta iniciativa poderia ser chamado de
disso, divididos em subunidades lógicas de trabalho.
“Conquistar a Alemanha”.
Onde é que esta empresa queria ver os efeitos positivos
Para poder implementar um Épico, há outros passos
dos limites de WIP? Na verdade, eles queriam melhorar o
menores necessários. Então, o Épico é dividido na próxima
time-to-market para as iniciativas.
unidade menor, as chamadas Histórias de Usuário, que
descrevem a funcionalidade específica que é desejada. Então o que precisa ser limitado?
62
Bingo! As Iniciativas.
PARTE 2 | AS CAUSAS
Então, agora vamos examinar o que realmente aconteceu interestadual congestionada, mesmo que você seja capaz
nesta organização. A Responsabilidade pela agilidade da de dirigir 100 kp/h. Você fica até feliz quando consegue
empresa foi colocada principalmente nos times. Foram andar um pouquinho, mesmo que seja a passos de tarta-
os times que limitaram o seu trabalho—as Histórias de ruga e não dá para ter nem ideia de quando você vai
Usuário e as Tarefas—enquanto cada vez mais projetos chegar ao seu destino. E gritar constantemente com os
estavam sendo empurrados sistema abaixo. Equipes outros motoristas para dirigirem mais rápido também
ágeis muitas vezes passam a gerência à falsa impressão não ajuda.
de que ainda mais projetos podem ser iniciados, porque
teoricamente tudo deve ir mais rápido. É por isso que era Então, não deveria surpreender ninguém o fato do time-
impossível para esses times melhorarem qualquer coisa -to-market não ter melhorado. As unidades que têm um
no time-to-market, porque um fator essencial influencia- efeito no time-to-market, ou seja, as iniciativas, não foram
va—o número de projetos no sistema—não tinha mudado. absolutamente limitadas. Se os times não têm influência
no time-to-market, qual parte da organização tem?
Você pode imaginar isso como uma rodovia interestadual
completamente congestionada. As estradas (=times) são Outra vez, bingo! A gestão estratégica de portfólio.
equipadas com os mais modernos sistemas de tráfego e
aparelhos de alta tecnologia que lhe permitem dirigir
muito rápido. Mas você não vai muito longe numa
63
QUAL É O PROBLEMA QUANDO FALTA Gostaria de usar outro exemplo do meu trabalho de con-
A GESTÃO ESTRATÉGICA DE sultoria para explicar os problemas que ocorrem quando
PORTFÓLIO? não há gestão estratégica de portfólio. Eu tinha criado
um quadro de portfólio enorme junto com o comitê
Gestão estratégica de portfólio é a parte de uma organi- executivo de uma grande corporação em cinco quadros
zação que decide quais iniciativas serão implementadas brancos alinhados um após o outro. Ao olhar para os
e quando. Ao mesmo tempo em que houve uma incrível quadros, estávamos discutindo como eles gostariam de
quantidade de mudança a nível de times, houve também operar no futuro. “Agora eu finalmente entendo o que
uma enorme parte da organização que permaneceu esta coisa deveria ser!” um dos gerentes executivos—
igual. Houve uma sobrecarga de documentos do Excel vamos chama-la Karin—desabafou no meio da discussão.
discutidos uma e outra vez nas várias rodadas de priori- Todos olharam para ela em completo silêncio. “Como é
zação, e não existia uma gestão estratégica de portfólio que normalmente funciona?”, ela continuou. “Para mim é
efetivamente ágil. A minha hipótese era: Como estava assim: Eu tenho uma reunião de 30 minutos planejada
faltando a gestão estratégica de portfólio, muitas inicia- para Segunda-feira de manhã. Alguém que está se pre-
tivas estavam sendo iniciadas nesta empresa. parando para esta reunião há uma semana chega e me
apresenta uma ideia. Eles estão realmente entusiasma-
dos e, pelo que vejo, tenho de concordar pois é uma
grande ideia. Temos verdadeiramente que implementar a
64 iniciativa, porque ela assegura o nosso futuro. Na Terça-
-feira, outra pessoa vem me apresentar uma ideia em
que estão trabalhando há duas semanas, desta vez leva
apenas 15 minutos. Mais uma vez, penso que a ideia é
ótima e temos que implementar. E na Quarta-feira, outra
reunião.”
PARTE 2 | AS CAUSAS
O ponto dela era: Nestes campos, há muito trabalho Ao descrever isso, Karin realmente apontou o problema.
preliminar investido e um desejo compreensível de que a A gerência executiva toma decisões diárias sobre iniciar
iniciativa seja aprovada. E essas ideias provavelmente ou não projetos. Eles não só tomam essas decisões
também são muito boas. isoladas de seus colegas da gerência executiva, como
também de todos os outros na empresa, que devem
Mas o que acontece? Basicamente, a Karin tomou três implementar o projeto—eles tomam decisões sem con
decisões isoladas individualmente na Segunda, Terça e siderar todos os outros projetos que estão sendo
Quarta-feira. Está faltando a ela o contexto geral de implementados atualmente.
todas as iniciativas atuais e planejadas.
Decisões individuais isoladas aumentaram continuamente
o WIP das iniciativas—apesar das iniciativas precisarem
ser limitadas.
65
66
PARTE 2 | AS CAUSAS
NÃO HÁ ESPAÇO PARA Quando eu desenhei o throughput médio do sistema,
MELHORIA isto é, a “taxa de partida” média de iniciativas (linha ver-

melha inferior), tudo parecia mais ou menos bem—o tra-
balho estava sendo concluído. Fazendo a mesma coisa
Vamos retornar da nossa viagem ao mundo do WIP e
com a média de início, ou “taxa de chegada” de iniciativas,
voltar para a nossa empresa.
a linha criada tinha um gradiente muito mais íngreme.
Eu queria testar minha hipótese, “muitas iniciativas Este foi um sinal claro de que havia mais iniciativas sendo
começadas”. Então, pedi uma reunião com a gerência. iniciadas do que concluídas. Se não aumentar o número
Nesta reunião, perguntei quantas iniciativas eram con- de colaboradores pelo menos proporcionalmente, o que
cluídas por semana. foi o caso aqui, isso é motivo de preocupação.
Como essa informação pode ser determinada? No caso Eu, consciente e felizmente, uso os termos “taxa de
desta empresa, foi muito simples: Cada iniciativa era chegada” e “taxa de partida” neste contexto, porque esta
marcada com uma data de início e uma data de conclu- situação sempre me remete a um aeroporto. Se você
são. Primeiro, ordenei as iniciativas de acordo com a sua imaginar um aeroporto, é óbvio que se a taxa de chegada
data de conclusão semanal e, as registrei cumulativa- dos aviões é maior do que a taxa de partida deles por um
mente num diagrama (assinalado pela linha “finalizado”). longo tempo, um enorme problema é criado. Se os por-
tões e as pistas estiverem lotados de aviões, vai c hegar
Parecia muito bom. A linha estava constantemente um momento em que nada poderá se mover. 67
subindo, o que significava que as iniciativas estavam
realmente sendo concluídas.
Você pode fazer o mesmo com as datas de

início. Novamente, ordenei as iniciativas
de acordo com a semana, registrei os re-
sultados cumulativos no diagrama com
uma segunda linha, “iniciados”. Esta linha
também foi ascendente porém neste caso
isso não é bom.
Por que não fiquei feliz?

Se muitos projetos são iniciados dentro de uma organi- Os limites de WIP são uma forma de alinhar as taxas de
zação, em algum momento nada estará se movendo. Ob- chegada e de partida, ou seja, as taxas de início e de
viamente, quanto mais se faz, mais dinheiro a empresa conclusão. Eles ajudam a garantir que não haja mais pro-
pode ganhar—isso é uma conclusão razoável. No entanto, jetos iniciados do que pode ser concluído no tempo em
esta conclusão não foi completamente pensada. O dese- que uma empresa precisa permanecer viável.
quilíbrio entre o início e a conclusão do trabalho só pode
ser mantido por um certo período. Quando o próximo Foi dada uma recomendação de melhoria surpreendente
avião pousa, ou seja, mais um projeto é iniciado, todo o no final deste workshop de gestão executiva. Pensando
sistema começa a desmoronar e há mais trabalho “em em voz alta, um dos gerentes disse: “no futuro, em vez de
processo” do que jamais poderá ser concluído. realizar nossas rodadas de avaliação isolados em nossas
salas de reuniões, vamos nos encontrar em frente a um
Não se pode ganhar dinheiro com projetos incompletos quadro com todas as iniciativas atualmente em execução
e, eventualmente, os clientes ficam irritados esperando e já planejadas. Dessa forma, podemos ver como as no-
por seus produtos. Foi o que aconteceu nesta empresa. vas ideias apresentadas se encaixam no que já está em
Por se espalharem demais, ao começarem muitas inicia- andamento e no que já está planejado. E se encaixam ou
tivas, prejudicaram a sua posição no mercado e com os não. Será que temos que começar imediatamente a ini-
seus clientes. ciativa, porque é uma ideia muito boa, e parar uma outra
coisa que esteja sendo trabalhada, ou será que ela entra
68 primeiro em uma piscina de ideias? “

PARTE 2 | AS CAUSAS
Precisamos de limites
de WIP?
Em muitas organizações, se o tema dos limites de WIP Você pode fazer uma verificação rápida:
entram em jogo, a gestão automaticamente levanta a
questão sobre quais projetos devem ser interrompidos P Todos, nós e nossos clientes, estamos satisfeitos
ou não implementados de modo algum. Mas essa não é a com o desempenho da organização.
questão. Os limites de WIP não devem impedir os proje- Parabéns! Está tudo em ordem e você já encontrou
tos; devem apoiar decisões que façam sentido para as o seu WIP ideal.
empresas. Tal como, o que deve ser entregue a seguir a
fim de atender os interesses comerciais da empresa e P Está tudo indo muito devagar. Os clientes estão
criar valor para o cliente? Isso requer uma mudança de r eclamando e os números do negócio são motivo
pensamento porque na maioria das organizações eles de preocupação.
gostam de ouvir “ Sim, estamos trabalhando nisso.” Esta A fim de ganhar velocidade, você deve reduzir o WIP.
frase me irrita. Os colaboradores não deveriam estar tra-
balhando constantemente, deveriam estar entregando. P Estamos entregando ao mercado mais rápido
Trabalhar custa dinheiro, entregar gera dinheiro. do que nossos clientes são capazes de comprar
nossos produtos. 69
Esse é um ótimo problema - você pode começar
Apesar de todas as dificuldades, esta empresa mais trabalho.
já estava bastante avançada no que diz respeito
a forma como estavam pensando. Mesmo que
os limites de WIP tenham sido utilizados no
local errado até agora, sempre houve uma
consciência de que o trabalho no sistema deve
ser limitado. Muitas organizações não dão essa
guinada no pensamento e acreditam que po-
dem administrar muito bem sem limites de WIP.
Pode ser facilmente testado, se os limites de
WIP são ou não necessários.
UMA PRIMEIRA isso, eles tentaram implementar a agilidade com uma

d
AVALIAÇÃO abordagem clássica de gestão de projetos. Mas uma

questão essencial permaneceu sem resposta: Quais
mudanças têm efeito e por quê?
Vamos resumir porque os efeitos desejados não foram
alcançados nesta empresa. A gestão teve muitas boas Porque a palavra “ágil” automaticamente parece incluir
intenções com a sua iniciativa de mudança e foi exem- a palavra “time”, o maior ponto de alavancagem para o
plar na sua análise do tema da agilidade. Eles tentaram que eles queriam alcançar neste momento ficou total-
internalizar o mindset por trás dos métodos e, ao fazê-lo, mente sem ser analisado. Isso não seria encontrada ao
lenta mas firmemente, avançou o desenvolvimento da nível de time. Havia quatro causas graves para que eles
cultura organizacional. No entanto, em sua empolgação não terem se aproximado, e em alguns casos estarem
para começar, eles não conseguiram lidar com a mecânica mais longe, de seu principal objetivo de “melhor time-
e dependências dentro da empresa primeiro. Em vez to-market”:
70
PARTE 2 | AS CAUSAS
ENTÃO, FOI ISSO QUE DEU ERRADO 71

NESTA EMPRESA
PARTE 3
A Primeira
Solução
Está voando,
72 está voando
... uma melhoria
Sobre quadros de produtos,
quadros de estratégia e o desejo
de colaboração entre todos os
Fligth Levels.
PARTE 3 | A PRIMEIRA SOLUÇÃO
73
Nós certamente não tínhamos identificado todos os pro- Não apenas me contactam para ajudar quando uma
blemas. Em minha opinião, porém, tínhamos identificado transição ágil está à beira do fracasso. Frequentemente,
aquele com maior impacto—especificamente aqueles que sou incluído na fase de planejamento destes projetos de
impediram a empresa de dar o primeiro grande passo mudança, e introduzo o Flight Levels logo no início.
para uma melhoria efetiva.
Como o nome diz, o Fligth Level ( Nível de Voo ) descreve
o quão alto um avião está voando. Dependendo da alti-
tude de voo, o grau de detalhes que podem ser vistos
abaixo, no solo, mudará. Se você está voando muito alto,
você pode enxergar quilômetros à sua frente, mas ao
mesmo tempo você não pode ver todos os detalhes no
chão. Por outro lado, se você estiver voando mais baixo,
você quase pode enxergar dentro da janela de um quarto,
por exemplo. Porém, você não consegue mais reconhecer
a extensão de área da cidade.
Cada flight level tem as suas próprias características

e vantagens, mas também tem limitações como pode
ser visto.
74
Podemos usar o mesmo princípio nas organizações. O modelo Flight Levels é um instrumento
Usando o Flight Levels, podemos descobrir qual nível da de comunicação para identificar o efeito de
organização oferece a melhor alavancagem para a me-
melhorias específicas nos vários níveis
lhoria. Não importa quais métodos são usados em cada
nível. Ao invés disso, é mais importante a forma como a dentro da organização, e descobrir onde
comunicação e a cooperação são estabelecidas entre os dentro dela, isto faz sentido e/ou é possível
Flight Levels e entre os vários departamentos dentro de alavancar melhorias.
cada nível. Se você conseguir fazer melhorias aqui, toda
a criação de valor começará a ser otimizada e esse é,
verdadeiramente, o nosso objetivo.
75
FLIGHT LEVEL 1: A fim de gerar valor para o cliente, estes sistemas indivi-
NÍVEL OPERACIONAL duais geralmente devem cooperar de alguma forma—

nenhum time é uma ilha. Se você ignorar este fato e co-
locar seu foco apenas em otimizar individualmente os
Vamos começar mais perto do chão. O primeiro Flight
times, surge o risco de sub otimização. Sim, você terá um
Level pertence aos times que realizam o trabalho diário.
time de alto desempenho. No entanto, o desempenho
Um time pode se otimizar, ou melhor, pode otimizar seu
global da organização, ou seja, o desempenho combinado
fluxo de trabalho individual, implementando quatro
de todos os times, permanece o mesmo no melhor dos
ações essenciais:
casos, mas provavelmente irá diminuir.
1 Eles visualizam o seu trabalho.
1 Eles usam Limites de WIP.
1 Eles integram à rotina ciclos de feedback como, por
exemplo, métricas, Standup Meetings diários ou
Retrospectivas em seu processo.
1 Eles determinam melhorias através destes ciclos de

feedback e as implementam.
O método que um time usa para desenvolver um produto

ou fornecer um serviço—ágil ou não—é completamente
76 irrelevante porque o modelo Flight Levels funciona
independentemente de qualquer método particular.
Normalmente há mais de um time em uma empresa e
cada time prefere trabalhar de uma forma. É por isso
que você vai encontrar vários sistemas de Flight Level
1dentro de uma organização.
Bem-vindo ao mundo do system thinking

(pensamento de sistema)! A otimização
local muitas vezes leva à sub otimização
global (veja o exemplo do teclado na
Parte 2). A razão para isto são as depen-
dências entre os times: Haverá sempre
algumas dependências que não podem
ser resolvidas. Estas dependências
devem ser administradas—essa é a res-
ponsabilidade do Flight Level 2.
77
FLIGTH LEVEL 2:
COORDENAÇÃO
Os times fazem sua contribuição em várias áreas no fluxo Uma vez que o fluxo de trabalho é otimizado em todo o
de valor—um em desenvolvimento, outro em marketing e fluxo de valor, os tempos de espera nas interfaces são
um terceiro na área de operações. O segredo é fazer com reduzidos. E mais importante, os estrangulamentos tor-
que o time certo trabalhe na coisa certa no momento nam-se claramente visíveis.
certo. Assim, com Flight Level 2, nos afastamos do nível
de time para visualizar o fluxo de valor, que é a forma Quanto maior a organização, mais fluxos de valor há em
como um produto em particular é criado (montado a forma de vários produtos e projetos. Assim, você tipica-
partir de peças) ou o serviço é concluído. mente verá mais de um sistema de Flight Level 2 em uma
empresa, e assim existem dependências entre os vários
O foco no Flight Level 2 está na coordenação fluxos de valor. Se, por exemplo, algo é alterado em um
produto, muitas vezes também será necessária alguma
de atividades ponta-a-ponta, da ideia à
modificação em um outro produto. Nesses casos, os
realidade, atividades geradoras de valor. vários quadros usados para gerenciar os fluxos de valor
No Flight Level 2, as interações entre os são reunidos em um único local, a fim de tornar as
times são otimizadas. dependências visíveis e gerenciáveis. Os ciclos de Feed
back também são estabelecidos aqui a fim de coordenar
Importante: O Flight Level 1 e o Flight Level 2 devem se e catalisar melhorias. O que é criado é algo como gestão
comunicar um com o outro. É por isso que no Flight operacional de portfólio, que também é de responsabili-
78 Level 2, em termos de otimização da colaboração em dade do Flight Level 2.
um fluxo de valor, usamos o mesmo que é usado no
nível do time:
1 O trabalho será visualizado.

1 Os limites de WIP serão utilizados.
1 Há ciclos de feedback rotineiros, como Standup
eetings e Retrospectivas com os representantes
M
dos times.
1 Melhorias são derivadas e implementadas a partir do

que é aprendido nos ciclos de feedback.
PARTE 3 A PRIMEIRA SOLUÇÃO
79
FLIGHT LEVEL 3: A visão geral no Flight Level 3 torna possível a gestão
GESTÃO ESTRATÉGICA estratégica de toda a organização. Não se destina a micro

gerir a implementação operacional. Fundamentalmente,
DE PORTFÓLIO ter mais demanda do que você é capaz de cumprir é um
bom problema, caso contrário a empresa deve reduzir
O portfólio de uma empresa normalmente é composto sua força de trabalho. Por isso, no entanto, a concorrên-
por uma série de projetos e produtos, assim como inicia- cia entre as opções ocorre no nível de portfólio estraté-
tivas estratégicas que devem tornar a empresa pronta gico. A disparidade entre a urgência de cada opção e as
para o futuro. Esta mistura é gerenciada no Flight Level possibilidades de implementação tem de ser claramente
3. Você quer obter uma visão geral de tudo o que está declarada, caso contrário poderá haver a impressão de
acontecendo dentro da empresa. Você quer saber quais que existe uma quantidade infinita de recursos disponí-
projetos e iniciativas estratégicas são influenciados e de veis. No entanto, não é esse o caso, e é exatamente com
que maneira, até onde a implementação chegou e se um isto que o Flight Level 3 lida. Este Flight Level, é sobre
produto, projeto ou iniciativa compensa estrategica- sabiamente escolher e combinar iniciativas estratégicas,
mente e é tão bem-sucedido como você esperava. Um projetos e produtos a serem desenvolvidos, reconhe-
novo projeto já pode ser iniciado ou você deve esperar cendo dependências e otimizando o fluxo através da
até que outro seja concluído? No Flight Level 3, uma das cadeia de criação de valor com base nos recursos reais
perguntas mais importantes a serem respondidas é: disponíveis.
Quanto trabalho pode ser sustentado na Você também trabalha com visualização a nível estra-
tégico, neste caso usando um Quadro de Estratégia.
organização e o trabalho está alinhado
80 O design depende da organização não existem ou não
com a estratégia? deveriam existir Quadros de Estratégia “ padronizados”
(a menos que sua estratégia seja “Queremos ser uma
cópia ruim da empresa XY”). Quanto maior for a organi-
zação, mais sistemas haverá no Flight Level 3. Estes
podem estar em vários locais ou em várias divisões da
empresa. Recomenda-se, no entanto, que toda a estra-
tégia da empresa e as estratégias de apoio, como as dos
vários locais, sejam claramente visíveis no quadro de
Flight Level 3. No melhor dos casos, estas estratégias
estão ligadas a quaisquer índices que indiquem se as
coisas estão avançando na direção certa ou não.
81
E agora um pedido do inventor: Por favor, não use o Os Flight Levels simplesmente visualizam e organizam os
modelo de Flight Level para reestruturar a sua empresa vários tipos de trabalho dentro de uma empresa. As de-
ou dividi-la em Flight Levels (à la “Queremos o modelo cisões estratégicas devem ser tomadas sobre o que será
Spotify”)! desenvolvido, depois a implementação deve ser coorde-
nada e finalmente entregue. Ao mesmo tempo, uma
O modelo Flight Level não é nem um modelo organiza- organização pode preferir tomar decisões estratégicas
cional, nem um modelo de maturidade—o Flight Level 3 baseadas em um contato mais próximo com o nível de
não é três vezes melhor ou mais importante do que o coordenação do que do alto de sua torre de marfim.
Flight Level 1. Pode ser que o Flight Level 3 e o Flight Level 2 se fundam
num só quadro. Existem tantas possibilidades de confi-
Os Flight Levels são uma ferramenta para ajudá-lo a
guração quanto existem empresas.
pensar e se comunicar e devem simplesmente fazer com
que você saiba em nível (e não em um sentido hierár- Também não é necessário envolver todos os Flight Levels
quico) se a alavancagem está disponível para resolver em todos os projetos. Algo que afeta somente um time
um problema. Cada Flight Level tem um foco diferente: dentro da empresa e pode ser resolvido dentro do pró-
prio time, como corrigir um pequeno problema de quali-
1 No Flight Level 3, o foco é priorizar os próximos proje- dade, realmente não é lugar no quadro de estratégia. Por
tos e iniciativas de acordo com a direção estratégica
outro lado, estratégias de grande alcance, como melhor
da empresa.
time-to-market, não podem ser implementadas se toda a
responsabilidade for entregue aos times individualmen-
1 No Flight Level 2, o foco é desmembrar os projetos
e iniciativas escolhidos em peças executáveis e a te. Um único time de desenvolvimento provavelmente
coordenação do trabalho com as unidades operacio- não estaria decidindo se um determinado produto será
nais participantes. desenvolvido ou se uma nova fábrica será construída na
China como medida de precaução. Se você quer fazer
1 No Flight Level 1, os times envolvidos no trabalho uma melhoria em uma organização, você deve primeiro
operacional separam as tarefas do projeto/iniciativa ter claro qual o nível tem a maior quantidade de alavan-
em pacotes menores e concentram-se na sua entrega. cagem para alcançá-la. Os Flight Levels devem ajudar a
identificar o nível correto. De um modo geral, pode se
dizer que:
Quanto maior o Flight Level, maior o efeito

de a
lavancagem.
83
Se existir a possibilidade de iniciar uma transformação Se você precisa fazer alterações em um sistema existente,
ágil no Flight Level 3, você deve fazê-lo. Porque o único porque ele teve problemas, você deve olhar primeiro
time ágil que você realmente precisa no início de uma de onde você tem acesso mais rápido. A experiência mos-
transformação ágil ou iniciativa de mudança, é um time trou que normalmente o acesso mais rápido é no Flight
ágil de alta gestão que pratique gestão ágil de portfólio Level 2. E foi exatamente aqui que começamos na nossa
estratégico. Todo o resto vem daqui liderados pelo hesitante companhia.
exemplo.
84
MELHORIA 1: Era importante para mim que os envolvidos entendes-
TORNAR AS sem uma coisa: O valor para o cliente só é criado quando

ele recebe o produto certo. Para o cliente, não importa
DEPENDÊNCIAS VISÍVEIS como as pessoas que trabalham e entregam o produto
E GERENCIÁ-LAS foram organizadas e estruturadas. Não importa se eles

estão insatisfeitos ou completamente satisfeitos com o
produto. Eles só se preocupam com o valor criado para
Durante a análise do problema, o time percebeu que ha-
eles. É por isso que uma reorganização estrutural não
via mais dependências entre si do que eles estavam
deve ser o início de uma iniciativa de mudança ágil.
cientes ao criar os quadros do time. No entanto, haverá
também vários times trabalhando em conjunto num pro-
duto no futuro, já que as dependências irão persistir. Va-
mos recordar a confusão de dependências que tomou Business Agility é alcançado quando a entrega
conta dos times em desenvolvimento de produto.
de valor ao cliente é otimizada. Mais cedo ou
mais tarde, torna-se claro o que precisa mudar
na estrutura organizacional para dar suporte
a isto.
85
GERENCIANDO DEPENDÊNCIAS ENTRE Se dependências não podem ser eliminadas, você deve
TIMES: DESENVOLVENDO QUADROS administrá-las. Como você pode obter um controle sobre
DE PRODUTOS a gestão dessas dependências?
Uma coisa deve estar clara: Nunca será possível não ter Como um primeiro passo nesta empresa, nós simples-
absolutamente nenhuma dependência entre times, ser- mente descobrimos quais times estavam envolvidos no
viços e produtos dentro de uma organização. No entanto, desenvolvimento de cada produto. Não precisava ser um
você pode e deve tornar um hábito eliminar dependên- grande detetive para isto, uma vez que a organização
cias sempre que possível. Por exemplo, a Sipgate, uma estava configurada através de linhas de produtos.
empresa de telecomunicações Alemã altamente inovado- Dependendo do número de times que existiam por pro-
ra e rentável, vislumbra tornar-se uma empresa sem duto e da dimensão dos times, ou realizávamos work
dependências [Mois & Baldauf, 2016]. Todos entendem shops com todos os envolvidos, ou os representantes
que esta visão pode nunca ser completamente alcançada, dos times participavam na criação dos quadros de
mas a veem como uma tarefa contínua. produtos.
86
Visualizando. Em primeiro lugar, Limitando. Se você quiser alcan-

os envolvidos com cada produto çar um time-to-market mais
pensaram sobre como ele foi rápido, por exemplo, você deve
desenvolvido, como os times co- limitar as unidades que têm a
laboraram no processo de de- maior influência sobre ele. No
senvolvimento e em que pontos Flight Level 2, isso significa não
do processo, assim como em começar mais do que você pode
que direção, existiam dependências. Para cada produto, terminar. Os representantes de time levaram esta men-
este processo foi visualizado em um quadro de produtos. sagem a sério e trabalharam juntos para definir a quanti-
Para times menores, descobrimos que esta visualização dade ideal de trabalho para o Flight Level 2.
poderia substituir o quadro do time, porque havia infor-
mações muito mais úteis, geralmente com muito mais Estabelecendo ciclos de feed
qualidade, no quadro de produtos. Ao mesmo tempo, o back. Um quadro combinado de
quadro de produtos também ofereceu uma visão geral produtos não é suficiente. O
do contexto mais amplo. A partir desse momento, estes quadro não afeta muito, apenas
times fizeram suas Standup Meetings e Retrospectivas retrata uma situação. É por isso
em frente ao quadro de produtos. Em comparação, o que que eu aconselho a não colocar
eu observei em muitas outras organizações é que os todo o recurso intelectual em
times maiores muitas vezes ainda precisam de seus visualizar e configurar buffers,
próprios quadros, porque há uma maior necessidade de raias e impedimentos.
coordenação interna do time.
“Gerenciando dependências” significa examinar continu-
87
amente o que está no quadro e chegar às conclusões
certas sobre o que é retratado. Para citar Russell Ackoff
mais uma vez: Precisamos de interações ágeis. Isso re-
quer comunicação para coordenar ativamente o fluxo de
trabalho através do sistema.
Assim, foram definidos pontos de coordenação adequados: As métricas são um ciclo de feedback ideal e já estavam
sendo utilizadas nesta empresa. Então, as métricas tam-
Na Standup Meeting do Produto, os representantes do bém foram introduzidas no nível de produto, o que foi
time (em revezamento, por exemplo) se reúnem duas uma grande vantagem, porque elas são especialmente
vezes por semana em frente ao quadro do produto e co- significativas quando usadas aqui. Primeiro, você está
ordenam o fluxo de trabalho através do sistema, muito mais perto do cliente no nível de produto. E segun-
para o respectivo produto, neste nível. do, as medições já contêm todas as dependências. As
medições a nível de time sempre representam apenas o
Na Reunião de Reabastecimento, os representantes
trabalho que um time realizou num determinado período
decidem em conjunto qual o próximo trabalho a entrar
de tempo. No entanto, se você usar medições como o cy-
no sistema e, principalmente, quanto trabalho entra no
cle time e o throughput no Flight Level 2, você pode dizer
sistema. Os representantes levam em consideração quais
quanto “produto” foi criado dentro de um determinado
as pessoas internas e externas devem ser envolvidas
período, ou quanto do que você está produzindo pode
para alcançar uma priorização adequada. A propósito, se
realmente ser vendido.
você está em um sistema com WIP limitado, aplica-se o
princípio de “parar de começar, começar a terminar”.
Esta reunião só é realizada depois de concluídos outros
trabalhos—antes disto, não há necessidade de reabas-
tecer.
Em Retrospectivas de times multifuncionais, os repre-

sentantes examinam como a entrega colaborativa de
88 valor tem funcionado até então, e se alguma melhoria
pode ser feita. A Retrospectiva foi escolhida como o
formato de reunião porque os envolvidos já tinham
experiência com ela nos times. Este é um ponto impor-
tante: Na maioria das organizações, as Retrospectivas
são feitas exclusivamente a nível de time, reforçando
assim a otimização local.
Mais reuniões? 1 Nem todos precisam participar. Representantes de

times são enviados para as reuniões de Flight Level 2
A propósito, o ponto de usar quadros de produtos para (e também Flight Level 3), uma vez que eles são ne-
gerenciar dependências não é o quadro em si. O impor- cessários para tomada de decisões rápidas. Então,
tante é que as pessoas certas falem umas com as outras há apenas alguns indivíduos com reuniões adicionais
sobre o que veem no quadro—é esta a interação que ao invés de todos os membros do time. Estas reuniões
queremos. Isto parece uma inundação de reuniões adi- não são reuniões regulares que duram várias horas,
cionais, uma vez que há vários produtos e vários Flight onde os participantes apresentam PowerPoints
Levels, multiplicando assim o número de Standup Mee- intermináveis. Estou falando de reuniões curtas e
tings, Reabastecimentos e Retrospectivas. Precisa mes- rápidas que são feitas em 15 minutos e é exatamente
mo atormentar as pessoas com mais reuniões? Duas ob- por isso que todas as decisões essenciais são toma-
servações a este respeito: das lá.
1 É necessário manter todas as reuniões antigas? Já vi Com ou sem reuniões, continua a haver necessidade de
divisões corporativas com mais de 2000 funcionários coordenação. Para evitar as reuniões, você certamente
se livrarem radicalmente de todos os seus antigos pode escrever milhares de E-mails, ou apenas alguns
formatos de reunião. Em vez disso, havia apenas times se coordenem uns com os outros, ou cada time
Standup Meetings, Reabastecimentos e Retros. Outras continua a tomar suas próprias decisões isoladas, mas
reuniões só aconteciam quando havia necessidade estas são soluções atrapalhadas que necessitam coor-
de esclarecimento, além destas três reuniões de base. denação adicional ao invés de trazer melhorias.
89
GERINDO DEPENDÊNCIAS ENTRE Depois de termos configurado os quadros para cada

PRODUTOS: GESTÃO OPERACIONAL DE produto individualmente, analisamos melhor quais de-
PORTFÓLIO pendências existiam entre os produtos. Depois filtramos
produtos que tinham muitas dependências entre eles.
Nos quadros de produtos, ainda havia uma área chamada Aposto que consegue adivinhar o que fizemos depois?
“Espera Externa”. Comparado com áreas de estaciona-
mento com o mesmo nome nos quadros de times, este Nós pensamos que poderíamos focar e melhorar o
não significa necessariamente que estamos esperando trabalho neste fluxo de valor e seguir o nosso conhecido
que outro time termine a sua parte do produto. As de- processo para isto:
pendências entre times presente no desenvolvimento
do produto foram geridas no quadro de produtos Visualizando. Detalhamos o processo de trabalho para
(Dependências Entre Produto). Como você viu, essas estes produtos (o portfólio) em um quadro. Ao fazer isto,
dependências foram muito reduzidas através da gestão as dependências entre os produtos tornaram-se depen-
ativa delas. dências internas. Estas dependências não precisavam
ser representadas separadamente porque elas são ge-
“Espera Externa” significa que existe uma dependência renciadas ativamente, comunicando através de mecanis-
fora do fluxo de valor do produto representado, na maio- mos de feedback como Standup Meetings de Portfólio.
ria das vezes para um produto diferente (Dependências Na gestão operacional de portfólio, dependências exter-
Entre Produtos). Seja no time ou no nível de produto, nas são as conexões e influências necessárias que estão
dependências são inconvenientes. Como você pode localizadas fora do desenvolvimento do produto, tais
controlar as dependências no nível de produto? como dependências de fornecedores.
90
Limitando. Em seguida, nos certificamos de que havia Se você pudesse colocar todos os quadros individuais
uma quantidade ideal de trabalho neste sistema; a nível de produtos em uma sala, cada quadro deveria ter uma
de Portfólio, por exemplo, é o número de Épicos. Sobre- coluna à esquerda que é geralmente chamada de Back-
tudo, o trabalho deve entrar no sistema em uma sequên- log. Nesta coluna, há um estoque de trabalho que deve
cia estrategicamente relevante, com base em critérios ser implementado para cada produto. De preferência,
acordados. Para mim, um dos critérios mais importantes este trabalho é colocado em uma ordem de execução
para a priorização foi o resultado desejado que uma baseada em certos critérios, ou seja, priorizado. Ao fazer
peça de trabalho deve entregar. isto, apenas as dependências dentro do fluxo de traba-
lho de um produto serão geridas.
Estabelecendo ciclos de feedback. Mais uma vez, os ci-
clos de feedback foram criados para discutir o que os Se quisermos gerir dependências entre vários produtos,
quadros de produtos estavam mostrando. As dependên- uma boa ideia é reunir todos eles em um único quadro e,
cias poderiam ser geridas, e necessidades e possibilida- como resultado, estabelecer um Backlog coletivo.
des de melhoria poderiam ser identificadas. Mais especi-
ficamente, os ciclos de feedback foram compostos por O que acontece se cada produto tiver seu próprio
Retrospectivas de Portfólio e Métricas de Portfólio. Na Backlog? Se, por exemplo, uma peça de trabalho para o
gestão operacional de portfólio, por exemplo, é interes- Produto 3 é finalizada, o time do Produto 3 puxaria a
sante saber em quantos dias aumenta o cycle time devido próxima peça de trabalho e continuaria trabalhando sem
à espera de dependências externas. Se as métricas levar em consideração os fluxos de valor dos Produtos 1
orientadas por valor não são já utilizadas no nível de e 2. Em outras palavras: O que os outros estão fazendo é
time, deve-se pelo menos focar na medição do resultado problema deles.
econômico que está sendo entregue, ao invés da quanti- 91
dade que está sendo entregue
no nível de portfólio. Dez re-
cursos a 1000 reais cada ou um
recurso por 10 000 reais?

Com um Backlog coletivo de produtos mistos, a regra de Se essas situações raramente ocorrem onde um produto
que a próxima peça de maior prioridade deve ser puxada é classificado atrás de todos os outros por um período,
ainda se aplica. Agora a seguinte situação pode ocorrer: não há razão para se preocupar. Só observaria melhor se
Uma peça de trabalho para o Produto 3 está finalizada, esta situação ocorre com frequência. Poderia indicar que
mas a próxima peça de maior prioridade no backlog co- o conhecimento na organização é distribuído de uma
letivo pertence ao Produto 1, porque é mais importante forma que as prioridades de negócio não podem ser
com base nas características do negócio. Os times que resolvidas da forma ideal. O que vemos é outro exemplo,
trabalham no produto 3 não teriam nada para fazer por em um nível superior, de sub-otimização local versus
um certo de tempo. otimização global. Se cada produto tem seu próprio
Backlog, a distribuição de conhecimento desigual dentro
A primeira pergunta que deveria ser feita nesta situação da organização não seria perceptível. Os times de produ-
é: “Podemos ajudar outros times?” Talvez não seja possí- tos otimizam sua própria área, o que não é necessaria-
vel porque diferentes tecnologias são usadas nos times, mente o melhor para toda a organização.
por exemplo. Neste caso, a alternativa é que o time
“ocioso” possa trabalhar em melhorias ou outras coisas
que normalmente não têm tempo para trabalhar, nesse
meio tempo.
92
A vantagem de um Backlog coletivo na gestão de vários No caso desta empresa, não consegui que eles seguissem
produtos é que tais irregularidades se tornam visíveis. a minha recomendação de criar um Backlog coletivo—e
Em seguida, você é capaz de se perguntar se a estrutura isso também está ok. No entanto, a ideia está esperando
de portfólio existente ajuda ou atrapalha o sucesso da na Piscina de Ideias como uma melhoria futura.
empresa. Quer você torne a situação visível ou não, sua
empresa está nesta situação. Prefiro ter os problemas à
minha frente porque, só então, o cérebro pode focar em
encontrar uma solução.
93
94
MELHORIA 2:
INTEGRANDO O UPSTREAM
Business Agility é a capacidade de uma empresa se Eu gostaria de mostrar mais uma vez para vocês uma
adaptar às mudanças no mercado e às demandas de seus imagem do fluxo de valor real desta empresa, porque é
clientes. Se a solução da empresa para isto é simples- muito bonito. Ao examinar melhor o que aconteceu no
mente tornar um departamento ou mesmo apenas um upstream, um processo de revisão e aprovação foi
único time ágil, eles não entenderam o desafio. É claro que estabelecido ali, antes mesmo que os desenvolvedores
você pode aplicar práticas ágeis exclusivamente para o levantassem um dedo para começar a trabalhar em algo.
desenvolvimento de produtos ou prestação de serviços,
mas como observamos nesta empresa, o efeito é limita-
do. Quando os times ágeis chegarem até as fronteiras da
parte não ágil da organização, eles eventualmente fica-
rão presos e não serão capazes de alcançar seus objeti-
vos. Isso pode tornar mais fácil apontar um culpado,
porém não é o mais vantajoso para a empresa ou seus
clientes.
95
AS TRÊS ARMADILHAS DE TEMPO A 1. O ORÇAMENTO ANUAL CRIOU LOTES

UPSTREAM: DEMAIS, MUITO EXATO, DE TAMANHOS MUITO GRANDES
MUITO DESNECESSÁRIO
Nas organizações, há uma grande luta uma vez por ano
O processo de upstream por si só ter um zilhão de pas- sobre o orçamento, quando a gestão, ou acena positiva-
sos não é tão ruim-caso esses passos pudessem ser mente, ou rejeita ideias baseadas nos conceitos apresen-
concluídos rapidamente. No caso da nossa empresa, no tados. Coletar ideias ao longo de um maior período mata
entanto, houve um período de espera de vários meses qualquer tipo de agilidade empresarial, para não mencio-
entre as reuniões do Conselho Administrativo, onde as nar que a vida real praticamente nunca segue um plano
ideias foram avaliadas e analisadas. Com toda a probabi- anual. Com um orçamento anual, o seu tempo de reação é
lidade, em algum momento esses passos foram imple- uma vez ao ano. Vamos imaginar isso representado em um
mentados com a melhor das intenções e não precisamos quadro do nível de portfólio: Cada opção escolhida no Ba-
eliminá-los completamente. cklog é movida para a coluna “ Comprometido” no dia 1º
de Janeiro, portanto, deve ser implementado. No dia 1º de
De um modo geral, é melhor examinar estes tipos de Janeiro, o que precisa ser entregue até 31 de dezembro já
processos preliminares e determinar o que é redundante foi decidido. E apesar disso, os times ainda serão tortura-
e o que poderia talvez ser encurtado ou fundido. Me de- dos com discussões inúteis sobre métodos e requisitos,
parei com três problemas principais quando escalamos o como “você deve preparar seus backlogs, limitar o seu WIP
fluxo de valor para incluir os processos upstream: e trabalhar em Sprints”. Se o que deve de ser entregue já
foi decidido, todo o pó mágico da agilidade é completa-
mente desnecessário e não tem qualquer efeito, especial-
96 mente no que diz respeito à agilidade empresarial. É por
isso que a agilidade de time não tem nada a ver com
business agility.
Quando falamos de business agility, estamos falando

sobre o funcionamento interno da organização. O tem-
po de reação tem que ser mais rápido e isso começa
com um novo processo orçamentário—em outras pala-
vras, realimentação. Por exemplo, se você quer ser capaz
de tomar medidas responsivas mensalmente, deve haver
um intervalo mensal de realimentação. No entanto, isso
não significa começar algo novo todo mês! Os mesmos prin-
cípios se aplicam aqui: Os trabalhos em progresso devem
estar finalizados e os limites de WIP devem ser considera-
dos durante as reuniões de reabastecimento. O truque é
fazer tarefas pequenas o suficiente para que possam ser
finalizadas e colocadas no mercado o mais rapidamente
possível, criando assim valor.
2. COLEGAS COMO
FORNECEDORES
Tanto quanto business agility geralmente impedem rela- para implementar um certo recurso. Outro clássico: esti-
ções positivas entre vários departamentos da empresa. mativas de custo. Custa 80.000 Reais para estimar que
Semelhante a uma relação de fornecedor, os departa- um recurso custaria 30.000 Reais para ser implementado.
mentos dão “ordens” para o departamento de TI interno Se a ordem é dada, o departamento recua, deixa o forne-
e querem saber até o centavo que isso vai custar. Deter- cedor interno trabalhar nele sozinho e só se interessa
minar o tempo e / ou o custo é um procedimento igual- novamente quando o produto é entregue. Isto é qual-
mente prolongado de estimativas, aprovação e novas quer coisa, menos ágil. Caso contrário, estaria claro que
estimativas, assim como pedidos de ordem externa. O dentro da mesma organização você realmente trabalha,
produto primário deste processo é um exagero de docu- em conjunto, em soluções para seus clientes externos.
mentos, porque, em última análise, as estimativas esta-
rão provavelmente incorretas. Para mim, o exemplo mais
vivo vem de uma instituição financeira: Levei cinco dias
para estimar que o departamento de TI levaria um dia
97
3. FAZENDO UMA ESTIMATIVA PARA

ALGO QUE DEVE SER FEITO DE QUAL-
QUER JEITO
Não só existem estimativas exageradas para as coisas Não estou dizendo que as estimativas são completamen-
que você quer fazer, mas ironicamente também para te desnecessárias. Acredito, no entanto, que o esforço
aquelas coisas que você deve fazer. Um gerente de uma para fazer estimativas tem que ser limitado, se a empre-
instituição financeira me disse que, de acordo com as sa se tornar ágil. Uma estimativa só precisa ser tão exata
suas orientações internas, eles devem estimar quantas quanto necessário, não o mais exata possível. Para deci-
centenas de Reais um determinado trabalho custaria. dir a favor ou contra uma ideia, basta apenas uma di-
“Estimamos 567,300 Reais”, disse-me com orgulho. Eu mensão aproximada da implementação. Só pode ser
perdi a oportunidade de ficar quieto e perguntei se eles determinado se uma ideia tem ou não um futuro, se
ainda fariam a implementação se custasse apenas mostrar ao cliente algo que ele possa avaliar.
10.000 Reais ou se custasse 10 milhões de Reais. “É claro
que temos que implementar porque é um requisito
legal!”
98
MELHOR TIME-TO-MARKET ATRAVÉS

DA TOMADA DE DECISÕES FREQUENTES
E DE UM MELHOR TRABALHO EM EQUIPE
Com base nos processos de upstream, Business Agility Tivemos uma conversa com os colegas do upstream—o
significa: setor de negócios. Ficou imediatamente claro para eles
quanto tempo valioso estava sendo consumido no pro-
1 que os Reabastecimentos seguem o princípio puxado, cesso de tomada de decisão, então eles se mostraram
levam em consideração os limites de WIP e são reali- dispostos a simplificar as coisas. Até então, novas ideias
zados num ciclo apropriado que corresponda ao nível eram pré-selecionadas uma vez por mês. Os casos de
desejado de agilidade nos negócios; negócios eram então escritos para as ideias selecionadas
e aprovados ou rejeitados a cada três meses. A aprova-
1 que uma estimativa aproximada do tamanho do pro- ção do conceito detalhado só acontecia uma vez por ano.
jeto é suficiente para começar;
Mais uma vez, descrevi os processos de pré-seleção em
1 que não somente o custo e o esforço são estimados, um quadro e discuti com os representantes do upstream
mas, sobretudo, os benefícios, a receita também são
quais desses processos eram realmente necessários.
estimados;
Depois de algumas idas e vindas, os empresários decidi-
ram que um conceito bruto era mais do que suficiente
1 que um conceito use o mínimo de papel possível,
criando resultados reais o mais rápido possível; para que eles decidissem se uma ideia deveria ser imple-
mentada ou não. O objetivo do desenvolvimento em si
1 que o cliente seja incluído o mais cedo possível no era incluir mais a área de negócios-participando das
99
processo de desenvolvimento. Standup meetings, por exemplo. Dessa forma, poderiam
agir mais cedo caso o desenvolvimento de uma peça do
Se você descobrir depois de um determinado tempo que trabalho não estivesse caminhando na direção certa.
uma ideia não está indo no caminho certo-maravilha! Se
o for o oposto- também é muito bom! Não desperdiçamos A partir dos cinco primeiros passos upstream, apenas
dinheiro estimando e, em vez disso, ganhamos experiên- dois permaneceram ao final: “caso comercial aproximado”
cia e desenvolvemos uma peça de produto. e “esperando aprovação”. Concordamos que a aprovação
ou rejeição de conceitos brutos poderia ser feita a cada
A questão não é quantos passos são parte do duas semanas—somente quando os limites de WIP em
fluxo de valor upstream, mas sim quão desenvolvimento o permitissem, porque outros trabalhos
já estavam finalizados. Na minha opinião, esta foi uma
rapidamente esses passos—desde o primeiro
das decisões mais importantes para tornar a agilidade
passo até uma unidade de valor já montada nos negócios uma possibilidade para esta empresa no
(ideia, conceito, etc.)—são capazes de ser futuro.
executados.
100
No entanto, o fator tempo foi apenas um aspecto. A to- 1 Standup meetings foram realizadas em conjunto com
mada de decisões a um ritmo de duas semanas, em vez representantes dos departamentos de negócios em
de uma vez por ano, tem naturalmente uma enorme in- frente aos quadros de produtos.
fluência no time-to-market. Mas algo muito mais impor-
tante aconteceu aqui: Foi criada uma visão integrada do 1 Além disso, foram realizadas Retrospectivas conjuntas
desenvolvimento de produtos. Não havia mais negócios regulares.
aqui e desenvolvimento lá. Estas duas áreas se juntaram, 101
unindo esforços para que a organização pudesse sobre-
1 As métricas foram escolhidas para dar uma ideia
exata de quantos projetos e produtos, desde a con
viver e o cliente pudesse obter o que realmente precisa
cepção até a finalização, foram realizados em toda
mais rapidamente, no futuro.
a organização e quanto tempo levou.
Esta união de esforços, principalmente através de ciclos
rotineiros de feedback, configurou entre os departamen- Business Agility significa passar do conceito
tos de negócios e desenvolvimento de produtos, o separa a entrega de valor ao cliente o mais rápido
guinte: possível. Isto funciona quando uma organiza-
ção não é dividida em grupos de pessoas dando
ordens e grupos de pessoas executando ordens
e, ao invés disso, gradualmente remove a
demarcação entre “nós” e “eles”. Lidar com e
superar dependências uns dos outros pode
ajudar a organização a se tornar mais coesa.
A multifuncionalidade
não tem nada a ver com a
configuração do time
Parece tudo muito romântico, não é? A verdade, porém, é vista do portfólio, há apenas idiotas completos sentados
que se trata de uma enorme mudança. Por que é que os no topo. Com bônus de “desempenho”, você pode facil-
departamentos de negócios devem simplesmente con- mente reforçar essa animosidade ou até mesmo piorá-la.
cordar com isso? Ao fazê-lo, apenas partes individuais de uma organiza-
ção serão otimizadas, mas não a criação de valor para o
A demarcação entre “nós” e “eles” é um problema histó- cliente.
rico fundamental que existe na maioria das organiza-
ções, independentemente do tipo de organização que Esta concorrência tem que, primeiramente, ser eliminada.
ela seja. Isto pode ser atribuído a grupos fragmentados Como mostrei com esta empresa, não é tão fácil como
especializados que tipicamente se organizam em depar- parece. É um processo cultural que já começa desde o
tamentos. Eles se separam uns dos outros e de toda a recrutamento. A máxima necessária deve ser “não con-
organização. Os pedidos e os resultados são geralmente tratar habilidades, contratar atitudes”. É claro que a
“entregues” (ou jogados por cima) para outros departa- competência em um assunto é importante, mas é muito
mentos, cuja abordagem e requisitos podem ser com mais fácil adquirir competências do que mudar atitudes.
pletamente diferentes do que em seu próprio departa- Os times multifuncionais não são de modo algum o San-
mento. Em seguida, a demarcação pode ser vista: os to Graal da agilidade, fazendo com que os pontos sociais
102 departamentos são uma bandeira vermelha para o de fricção entre as áreas de desempenho de um fluxo de
desenvolvimento de produtos, desenvolvedores de soft valor simplesmente desapareçam magicamente—por ve-
ware são melhores do que testadores de software, os zes eles simplesmente mudam. Reunir várias escolas de
departamentos de negócios veem todos os outros sim- pensamento em um só time é ainda melhor do que con-
plesmente como fornecedores, e assim por diante. centrar-se no desempenho individual ou no desempenho
de silos especializados individuais. Quando se trata de
Tentar tornar uma empresa ágil não torna inevitavelmen- focar no cliente, a geração de valor integrada é apenas
te esta situação melhor. É muito importante ter times uma pequena gota em um grande balde.
multifuncionais e são uma parte importante da empresa.
No entanto, isso não significa necessariamente que os Multifuncionalidade é uma mentalidade de empresa e
velhos preconceitos simplesmente desaparecem. Agora não uma configuração organizacional para os times. Isto
você só tem o Time multifuncional A que tem melhor significa criar um ambiente agradável, ou mesmo deseja-
desempenho do que o Time multifuncional B. Ao invés de do, para executar apenas localmente (enquanto aprendi-
silos funcionais, existem silos multifuncionais. Parabéns! zagem) se ele ajuda o desempenho geral da organização.
Se você reduzir as dependências e combinar times de Não é suficiente ter todos puxando a mesma corda—
acordo com linhas de produtos, o Produto Y é natural- todos também devem puxar na mesma direção.
mente mais idiota do que o Produto Z. E pelo ponto de
103
MELHORIA 3: No entanto, nem sempre é fácil ter a gerência executiva
GESTÃO ESTRATÉGICA DE a bordo. O alto conhecimento do MBA está profunda-

mente ancorado em suas mentes. Mas uma empresa ágil
PORTFÓLIO não precisa de um administrador de empresas no topo,
precisa de um líder de negócios. Se a participação da ge-
Business Agility não funciona se uma organização é com- rência executiva falhar, geralmente é devido à falta de
posta por ilhas ágeis, enquanto a lógica dos processos capacidade e vontade para a reflexão crítica. Muitos da
ao redor permanece a mesma e certos grupos se isentam alta gestão v ivem—muitas vezes indesejadamente no ce-
de praticar a agilidade. Business Agility começa no topo libato da e
ducação contínua. Parte da razão para isso é
porque a gestão executiva ainda é responsável pela dire- que a alta gestão— diferente dos atletas de alto nível—
ção estratégica na maioria das organizações. No cenário estão em constante competição e não dedicam um tem-
ágil, muitos acreditam que as organizações devem ge- po para o treinamento, ou seja, adquirir novas habilida-
renciar sem qualquer hierarquia. Também penso que des para competir. Em muitos casos, eu também consigo
muitas organizações são hierárquicas demais, mas não compreender isto. Os gerentes estão constantemente
acredito que possam funcionar sem nenhum tipo gerên- correndo de uma reunião para outra, eles estão comple-
cia. A decisão de “trabalhar sem hierarquia” tem que ser tamente sobrecarregados e são pressionados de todos
tomada por alguém—provavelmente não é o colaborador os lados. No entanto, eles devem ser os pilotos da jorna-
da manutenção que toma esta decisão. da ágil para evitar apenas afundar dinheiro no buraco da
sub-otimização local.
Daí nasce a ilusão de ser capaz de reagir rapidamente ao

104 mercado—e, no entanto, continuam a seguir ciclos orça-
mentais anuais. O que deve e vai acontecer no próximo
ano é determinado na perspectiva de um certo ponto no
tempo. Em última análise, você libera uma enorme quan-
tidade de dinheiro, criando uma onda de projetos que
deve se distribuir em rios tranquilos continuamente lan-
çando novas ideias e produtos. Na natureza, as ondas gi-
gantescas não fazem mais do que destruir tudo quando
encontram o continente. Dentro de uma organização,
isso cria um ciclo exaustivo: Quando a onda recua, mui-
tas pessoas ficam sentadas de braços cruzados esperan-
do a próxima onda gigantesca. O principal é que, quando
começa o ano, todos sabem no que certamente não es-
tarão trabalhando na tarde de 17 de Agosto. Ou seja, o
que consta do plano anual.
O business Agility real integra o upstream e o

downstream em um único fluxo de valor para
criar um fluxo de trabalho rápido e estável.
Em outras palavras: Estratégia,
operações, desenvolvimento e
entrega trabalham em estreita
colaboração e, sobretudo, para
alcançar o mesmo objetivo. Para
que isto funcione adequadamente,
a gerência executiva deve estar a
bordo.
105
COMO FUNCIONA A GESTÃO Você deve limitar o trabalho onde os efeitos, os benefí-
ESTRATÉGICA DE PORTFÓLIO? cios e as vantagens dos limites de WIP querem ser vistos.
Num sistema organizacional, a relação entre as iniciati-
A razão para o porquê o time-to-market na nossa empre- vas que foram iniciadas e as que foram finalizadas tem
sa não ter funcionado como planejado estava clara. En- um efeito direto no time-to-market. A gestão estratégica
quanto os times de desenvolvimento seguiam todas as de portfólio é responsável por manter esta relação em
regras e limitavam seu trabalho com sangue, suor e lá- um equilíbrio adequado e alinhar estas iniciativas com a
grimas, o nível estratégico continuou a começar uma ini- estratégia global. A fim de alinhar o trabalho em toda a
ciativa após a outra. E isso é exatamente o que acontece organização com a estratégia, a alta gestão deve estar
em muitas empresas que querem se tornar ágeis. Esta disposta a comunicar de forma inequívoca e explícita a
abordagem cria duas condições: confusão e stress. Va- estratégia e todas as iniciativas atuais dentro da organi-
mos recordar: zação para os colaboradores. Assim como com os outros
Flight Levels, eu também uso os três passos familiares
com a alta gerência para colocar sua gestão estratégica
de portfólio no caminho certo:
1. Visualizar. Todas as unidades geradoras de valor atu-

almente na organização são representadas em um
quadro coletivo. O Flight Level 3, trata principalmente
de projetos e iniciativas. Nós também determinamos
como esses projetos serão executados. De acordo
106 com quais critérios são avaliadas as ideias do projeto?
O que segue a estratégia e o que não segue? Qual o
aspecto do processo de seleção e tomada de decisão,
e quando uma iniciativa é considerada bem-sucedida?
De onde vêm as ideias e recomendações para iniciati-
vas, o que está sendo trabalhado e onde dentro da
empresa?
2. Limitar. Na segunda etapa, o número ideal de projetos

geradores de valor que a organização pode lidar é
determinado. A nível de estratégia, “projeto gerador
de valor” significa quando o projeto ou iniciativa é
concluída e “pousa” na última coluna do quadro, você
idealmente, seria capaz de ver que resultado foi al-
cançado no mercado. Você só pode iniciar novos pro-
jetos quando projetos ou iniciativas são finalizadas de
acordo com este requisito— e se o WIP permitir.
3. Estabelecer ciclos de feedback. Se toda a organização O design específico destes passos pode e deve
deve estar alinhada com a estratégia, os representan- ser diferente para cada empresa. E o design
tes de todos os níveis devem ser integrados no ciclo,
pode mudar ao longo do tempo com base nas
desde a tomada de decisões até a medição do suces-
so. Todos eles estão incluídos em Standup meetings e necessidades da empresa e seus clientes.
Retrospectivas. E assim como em todos os outros ní-
veis, o mesmo princípio se aplica à gestão estratégica
de portfólio: Trabalhar no quadro de estratégia uma
vez não é suficiente. O truque é encontrar possibilida-
des de melhoria e tomar as medidas necessárias. E
isso não significa melhorar o quadro, significa melho-
rar o trabalho ao nível da estratégia.
107
O QUADRO DE ESTRATÉGIA Vamos olhar primeiro para o lado esquerdo do quadro

de estratégia que eu construí junto com a alta gerência
Neste momento, vou dizer mais uma vez: Este não é o desta empresa. Muito claramente à esquerda, a estraté-
quadro estratégico que pode ser usado em todas as gia da empresa foi resumidamente escrita e na coluna
empresas deste mundo ou de todo o universo. Estou seguinte a métrica de negócio foi fragmentada. Por
mostrando o quadro estratégico usado no contexto exemplo, se a estratégia afirma que o market share na
específico desta empresa. Ásia deve ser aumentado, a métrica correspondente ao
“Market Share da Ásia” deve ser capaz de descrever
Fique à vontade para se inspirar, mas copiar essas mudanças. A partir deste ponto, o projeto e os
é expressamente proibido! tickets de iniciativa que circulam em todo este quadro
devem incluir qual métrica estratégica de negócios deve
ser influenciada por eles. Desta forma, o alinhamento
estratégico da organização é alcançado. Não só é claro
para todos o que está sendo trabalhado, mas também
porque algo está sendo trabalhado.
108
Os princípios para a construção de um quadro de nível Finalmente, descrevemos os passos que os tipos de tra-
estratégico são os mesmos que os dos outros níveis. Em balho individuais devem seguir no quadro. A peça mais
primeiro lugar, identificamos que tipo de trabalho é feito fascinante estava do lado direito do quadro. Deixe-me
na gestão estratégica de portfólio. Em segundo lugar, interromper por um momento: A principal diferença
nos perguntamos como é que este trabalho vai ser con- entre gestão operacional e a gestão estratégica de port
cluído. fólio é o prazo. Na área operacional, tudo gira em torno
do que está sendo implementado agora, enquanto a es-
Juntamente com a gestão superior, identificámos dois tratégica também lida com o que acontecerá no futuro.
tipos de trabalho: Naturalmente, trata-se de um enorme desafio, já que o
futuro, muitas vezes, está cheio de contradições. Em que
1 Iniciativas foram as geradoras de dinheiro da organi- quer apostar? Em algo que traga dinheiro imediatamente
zação; essencialmente, os produtos e soluções para
ou em projetos que talvez só tragam benefícios anos
os clientes.
mais tarde? Tais considerações devem ser levadas em
conta na gestão estratégica de portfólio. Desta forma,
1 Investimentos indicaram projetos necessários, mas
não urgentes, que não tiveram um benefício direto este nível lida com o resultado e não com o produto
para o cliente, mas tiveram um efeito de fundo. Como final.
cliente do Netflix, por exemplo, você compra streaming
de vídeo que não falhem e não testes de software
automatizados. Mas para entregar este produto, o Net
flix precisa providenciar a infraestrutura apropriada.
109
Na maioria dos quadros do mundo, você geralmente vai De onde vieram as ideias para os projetos e iniciativas,
encontrar, depois de uma coluna que chamada “Em De- os “geradores de dinheiro”, nesta empresa? Na maioria
senvolvimento”, uma coluna resumidamente chamada das vezes, essas ideias vieram dos times, porque eles
“Finalizado” ou “Concluído”. Nesta empresa, no entanto, estão mais próximos dos clientes e sabem, melhor do
eles viram um pouco diferente. Um projeto ou iniciativa que ninguém, o que o cliente quer. Assim, os casos de
só seria considerado “Finalizado” se tivesse alcançado negócios brutos já foram avaliados pelos times para de-
aquilo que pretendia alcançar. E para determinar isto, as terminar o que poderia ser alcançado ou quais métricas
métricas devem ser empregadas e o feedback dos clien- de negócios poderiam ser modificadas através da imple-
tes e usuários de um produto deve ser recolhido. É pos- mentação de uma ideia. O caso de negócio também teve
sível que alguns ajustes sejam necessários após receber que considerar a resposta do mercado, para poder tomar
feedback. É por isso que esta empresa tinha três colunas uma decisão no prazo de 90 dias, se o resultado desejado
a mais após o desenvolvimento no quadro de estratégia: seria ou não possível. A ideia não precisava ser comple-
“Medir & Aprimorar Sucesso”, “Ajustar & Aprimorar” e tamente implementada em 90 dias, mas deveria ser pos-
“Resultado (não) Alcançado”. sível perceber uma tendência para o sucesso após 90
dias. Estes casos de negócios bruto foram colocados na
“Piscina de Ideias Avaliadas” e todos os que apresenta-
ram ideias se reuniram quinzenalmente para discutir
com seus colegas o ajuste estratégico de cada ideia.
110
CICLOS DE FEEDBACK NA GESTÃO Nesta empresa, a alta gestão participou dos Standup
ESTRATÉGICA DE PORTFÓLIO Meetings juntamente com representantes da gestão
operacional de portfólio Flight Level 2. Estava planejado
Os formatos de reunião na gestão estratégica de portfó- realizar estas reuniões a cada dois meses, mas as coisas
lio são os mesmos que os dos outros níveis. A Standup não aconteceram conforme o planejado já na primeira
Meeting Estratégica de Portfólio é onde são passadas as Standup Meeting. Havia tanta informação no quadro, que
atualizações sobre o progresso dos projetos e iniciativas, um dos gerentes desabafou: “A cada dois meses não faz
assim como, onde as ações precisam ser tomadas. Re- sentido!” Só pude concordar com essa afirmação. No en-
presentantes dos Flight Levels 1 e 2 passam informações tanto, meu comentário sobre os orçamentos anuais nas
para o nível de estratégia e, em seguida, levam as deci- reuniões até agora surpreendeu todo mundo: “Acho que
sões tomadas em relação à estratégia de volta para a deveriam se encontrar pelo menos uma vez por semana.
organização—é assim que um alinhamento estratégico Melhor seria duas vezes por semana. Mesmo depois
contínuo acontece. desta onda ter sido trabalhada.”
111
Você pode estar se perguntando por que uma cadência Reuniões importantes devem ser realizadas com frequência
tão curta? O Standup Meeting de Portfólio estratégico é As pessoas dentro das organizações gostam de reclamar das reuniões,
uma reunião onde as decisões serão (devem ser) toma- o que se deve em parte à forma como são organizadas. Mas também
analiso a frequência com que reuniões importantes realmente aconte-
das exatamente quando eles são necessários. Não va- cem. Muito provavelmente, você vai descobrir que os intervalos entre
mos nos esquecer o que aconteceu quando os gestores as reuniões são muito longos (tornando também as reuniões mais
tomaram decisões isoladas (ver Parte 2). Houve mais longas). As decisões tomadas nessas reuniões perdem valor porque as
pessoas são forçadas a tomar decisões definitivas (isoladas) nesse
projetos iniciados do que a organização poderia dar con- meio tempo.
ta. Quanto maior o período entre os Standup Meetings
de estratégia, maior o risco de cair novamente em velhos
hábitos. Mesmo que houvesse uma reunião mensal, há
uma grande probabilidade de que uma semana depois já
seja necessária uma decisão urgente para outra coisa—e
então surge a tentação de não esperar pela próxima
Standup Meeting. E se esperasse seria qualquer coisa,
menos agilidade.
Recomendo manter Standup Meetings

Estratégicos de Portfólio em uma frequência
semanal, a fim de tomar as decisões neces-
sárias em tempo hábil e dentro do contexto
112 dos projetos atualmente em execução.
Retrospectivas no nível de gestão estratégica de port Assim como em muitas outras partes deste livro, gosta-
fólio também visam melhorar a colaboração. Permite ria de lhe pedir que não copie simplesmente estes inter-
que as pessoas que trabalham com o quadro de estraté- valos de reuniões, independentemente do Flight Level.
gia, especificamente a alta gerência e os representantes Não existe uma regra geral aplicável a todos os casos,
de Flight Levels 1 e 2, revejam regularmente o que acon- mas posso dar a seguinte orientação:
teceu num determinado período. Concordamos que as
retrospectivas deviam acontecer uma vez por mês. Como Faz sentido realizar reuniões individuais e
um leitor atento, você certamente percebeu que eu con- workshops mais frequentemente no início e,
sidero as Retrospectivas, em todos os níveis da organi-
em seguida, sentir qual frequência melhor se
zação, extremamente benéficas. Cliff Hazel do Spotify,
em uma entrevista que fiz com ele, afirmou que se ele adapta à sua situação. Além disso, não deixe
pudesse introduzir apenas uma coisa em uma empresa, as reuniões tomarem toda a tarde—estamos
seria a Retrospectiva. Eles são o motor para uma organi- falando de reuniões que levam cerca de 15
zação de aprendizagem—e, portanto, uma organização
minutos, quando são realizadas duas vezes
ágil.
por semana, por exemplo.
E finalmente, decidimos fazer uma Revisão da Estratégia
regularmente. Descobrir se as coisas certas estão ou não
sendo feitas é mais importante no Nível Estratégico do
que qualquer outro nível. A organização não deve perder
tempo com coisas que não levam a nada. O foco da Revi-
são era responder a perguntas sobre como a posição do 113
mercado e o próprio mercado haviam mudado, como a
concorrência estava se comportando e se a estratégia
precisava ser corrigida à luz dessas mudanças. Para
começar, combinamos um intervalo trimestral para a
Revisão da Estratégia.
A empresa está caminhando. Se eles vão ou não atingir

os objetivos que estabeleceram, realmente depende de
quão grande é a tentação de cair novamente em velhos
comportamentos e mentalidades. Juntamente com as
pessoas dedicadas do time de transição, fomos pelo
menos capazes de estabelecer os requisitos essenciais
para alcançar seus objetivos.
114
115
Naturalmente, ainda havia coisas que poderiam ser melhoradas dentro desta empresa. Mas, por ora, o meu trabalho estava
feito. Uma vez que conseguimos estabelecer as melhorias mais importantes no Flight Level mais alto, estava confiante de
que esta companhia poderia continuar sozinha. A mensagem tinha sido recebida:
116
BUSINESS AGILITY NÃO É UM ESPORTE DE

TIME — É UM ESPORTE DE EMPRESA!
117
PARTE 4
O Resultado
Qual foi o
resultado depois
de tudo isto?
118
Sobre metas finalmente sendo

alcançadas, métricas de negócios
gratificantes e uma jornada que
nunca termina.
PARTE 4 | O RESULTADO
119
120
A
pesar de pertencer à categoria de “con- Três anos depois de colocar sua tentativa fracassada
sultor empresarial”, é sempre um prazer de transformação de volta aos trilhos, a gerência me
quando sou capaz de me demitir. Há convidou para ver o desenvolvimento da empresa desde
basicamente duas situações em que sou então. Fiquei muito satisfeito com o que ouvi.
chamado para ajudar. Uma, é antes de
uma empresa dar os seus primeiros passos em direção TIME-TO-MARKET REDUZIDO! VIVA!
a mais business agility, outra é depois de terem percor-
rido um longo caminho para a agilidade por si mesmos e Ser mais rápido no mercado tinha sido o principal objetivo
começarem a tropeçar. Em ambos os casos, geralmente da empresa, e eles batalharam para alcançar. Agora, três
mantenho contato com a empresa, mesmo depois que anos depois, as coisas finalmente pareciam diferentes.
meu trabalho preliminar foi concluído. Por exemplo, eu Em média, as iniciativas estavam sendo concluídas sete
encontro funcionários dessas empresas em conferências meses mais rápido—mais do que o dobro que anterior-
e eles me atualizam sobre o andamento das coisas. Às mente. O objetivo de time-to-market mais rápido tam-
vezes eles perguntam minha opinião sobre outras ações bém colocou muitas outras coisas em movimento e, por
que eles estão planejando ou me convidam depois para conta disto, ficou bem claro outras coisas que precisa-
um workshop de melhoria. vam mudar para que esse objetivo fosse alcançado. O
efeito colateral positivo: Uma análise mais profunda das
Foi o caso desta esta empresa, também. Depois de esta- fraquezas reveladas trouxe melhorias drásticas em
belecermos os passos essenciais, que você acompanhou outras áreas.
neste livro, os colaboradores e a gerência continuaram o
trabalho, na maior parte, por conta própria. Eles compre- UM LÍDER DE INOVAÇÃO MAIS
enderam o que era necessário para a agilidade do negó- UMA VEZ
cio e que mecanismos eram necessários para alcançá-la.
Quando surgiram problemas, eles não recorreram à agili- Há três anos, havia sinais de que esta empresa sólida
dade reacionária. Em vez disso, eles primeiro examina- seria simplesmente expulsa do mercado por Startups
ram a causa e tentaram entender a correlação. Isso os com maior poder inovador. Depois que construímos o 121
ajudou a encontrar uma solução adequada para a em- quadro de estratégia, surgiu alguém com uma ideia
presa, ao invés de usar uma solução convencional. Meses simples e eficaz, durante uma das reuniões regulares de
depois do meu trabalho lá, os colaboradores com quem melhoria. Usando um código de cores, cada nova iniciativa
conversei, me disseram que uma profunda mudança cul- foi claramente identificada, considerando se o resultado
tural tinha sido colocada em prática dentro da empresa. ajudaria a diferenciar a empresa de seus concorrentes ou
Eles disseram: “Já alcançamos muito, mas agora sabemos se apenas a colocaria no mesmo nível deles o mais rápi-
que nunca vamos finalizar. O desenvolvimento sempre do possível. A proporção de inovações em relação aos
continuará. “ produtos chamados “me-too” inicialmente, não foi nada
tranquilizadora. Três fatores começaram a alterar esta
proporção:
1. Tomada de decisão mais rápida. Uma das primeiras A propósito, o uso de ciclos de feedback em todos os Fli-
atitudes tomadas foi reduzir radicalmente o processo de ght Levels e a tomada de decisões estratégicas mais rá-
tomada de decisões, que era extremamente longo e pre- pidas criaram um novo processo cultural na empresa.
cisava ser concluído antes do pessoal de TI poder come- Antes, a empresa era um conglomerado de silos. Os silos
çar a trabalhar. As boas ideias não ficam mais paradas de negócios isolaram sua inovação em um processo len-
por meses. Agora, tendo em conta os limites de WIP e a to, controlado centralizadamente e, que em seguida, em-
direção estratégica, as ideias são transmitidas mais rapi- purravam o trabalho para os silos de TI onde a imple-
damente para o desenvolvimento. Para fazer isto, foi ne- mentação ocorreu. O TI foi forçado a desempenhar o pa-
cessário substituir a longa tomada de decisão, antes rea- pel de um mero fornecedor—um centro de custos.
lizada durante alguns dias de conselho por ano, por
Standup Meetings contínuos e frequentes, utilizando a Hoje, a inovação vem de toda a organização, incluindo os
transparência do Quadro de Estratégia. Standup Meetin- colaboradores de TI. A gerência finalmente percebeu que
gs passaram a ser natural para todos e a gestão pôde os desenvolvedores de produtos estão perto do merca-
manter uma visão geral mais facilmente. do e sua compreensão do desenvolvimento é especial-
mente valiosa. Assim como antes, certas decisões conti-
2. Coragem para experimentar. A empresa agora confia- nuam sendo tomadas de forma centralizada, mas o pro-
va mais em si mesma para simplesmente experimentar cesso que conduz à tomada de decisões já não é gerido
coisas ao invés de especificar demais cada nova ideia. centralizadamente. Os colaboradores sentem que a ge-
Este foi um dos exercícios mais difíceis para as pessoas rência os ouve e novamente entendem por que eles es-
da empresa, porque a falha acompanha a experimenta- tão fazendo o que estão fazendo.
ção. Admitir a si mesmo e aos outros que algo não fun-
cionou foi um desafio cultural. A alta gerência precisava
primeiro, aceitar que o fracasso é também uma forma de
sucesso, se você parar um tempo para examiná-lo e
aprender algo com ele.
122
3. Feedback mais rápido. Desde que o time-to-market
foi radicalmente reduzido, o feedback do usuário para
um produto é recebido muito mais rapidamente, tornan-
do assim possível fazer alterações de produto usando as
lições aprendidas com este ciclo de feedback contínuo.
ALINHAMENTO ESTRATÉGICO MAIOR EFICIÊNCIA

A conscientização e a eficácia do indivíduo dentro da No início de seu processo de transformação, a empresa
empresa é reforçada pela gestão de portfólio, uma vez descobriu, da maneira mais difícil, que business agility
que todas as iniciativas estão alinhadas de forma consis- não funciona se apenas uma parte da organização assu-
tente com a estratégia. A estratégia claramente formula- mir esta responsabilidade. No entanto, as áreas de res-
da da empresa ainda está exposta à esquerda no quadro ponsabilidade fora do desenvolvimento de produtos—
de estratégia e está dividida em métricas de negócios tais como Controladoria, RH ou Compras—seguem regras
definidas. A métrica de negócio que está sendo usada completamente diferentes. Embora o desenvolvimento de
para medir o trabalho é anotada nos bilhetes para cada produtos seja, em grande parte, um processo complexo,
peça de trabalho, que “passeia” pela empresa durante o as tarefas administrativas são muitas vezes complicadas
desenvolvimento, e, assim, vai até o último colaborador [Snowden, Boone 2007 e Stacey 2000]. Nos últimos quatro
trabalhando nele. Os colaboradores envolvidos no de- anos, as áreas administrativas também foram alinhadas
senvolvimento podem ver o que são capazes de alcançar. para interações ágeis usando limites de WIP e ciclos de
Por conta disto, criou-se um ambiente de foco, trazendo feedback. O foco aqui foi muito mais na eficiência.
todos a bordo. A maioria dos colaboradores entende A disponibilidade do colaborador e o tempo de folga
para onde a empresa está caminhando e corresponde. criado pela utilização de limites de WIP foi e é proposita-
damente usada para automatizar e melhorar continua-
mente os processos de rotina com métodos simples
como Kamishibai (ver abaixo).
O que é Kamishibai?
Kamishibai é na verdade um teatro narrativo japonês que 123
usa cartões de imagem. No sistema de produção Toyota,
uma técnica de visualização para processos repetitivos foi
desenvolvida com base em Kamishibai. De acordo com um
ritmo de processo, as tarefas a serem executadas são
escritas em cartões e visualizadas em colunas diárias, se-
manais ou mensais em um quadro. O tipo de tarefas é
escrito na parte da frente do cartão e como a tarefa deve
ser feita é escrito na parte de trás do cartão. Uma vez que
a tarefa é concluída, o cartão é simplesmente colocado na
coluna “Pronto”. Kamishibai serve com uma mini-auditoria:
Aqueles que trabalham nas tarefas são obrigados a seguir
os processos, trazendo assim estabilidade. Ao mesmo tem-
po, eles ficam de olho nas possibilidades de melhoria dos
processos. A melhoria do processo já não é trabalho de um
único auditor, mas de cada funcionário [Leanability E018,
2017].
Em suma, isto trouxe mais estabilidade e um ambiente EVOLUÇÃO DOS VALORES FINANCEIROS
de trabalho mais tranquilo dentro da organização. Porém, DA EMPRESA
às vezes, era uma espada de dois gumes. Colaboradores,
que antes atuavam como uma força-tarefa anti-incêndios, Sim, os números. Todo o esforço ágil valeu a pena?
salvando heroicamente projetos e processos, não se Deixe-me mostrar quatro figuras chave.
deram bem com isso, e acabaram caindo na rotina. Isso
afetou a estrutura dos colaboradores. Porém, quem qui-
1Em algum momento durante a transformação, a empresa
chegou à conclusão de que faria sentido quantificar o
sesse podia mudar para outro departamento e continuar
Custo do Atraso. Em outras palavras, eles trabalharam
a desenvolver as suas habilidades, alguns simplesmente
para determinar o impacto financeiro sobre a empresa,
saíram. Ser tão eficiente a ponto dos colaboradores dei-
caso um produto fosse lançado no mercado mais cedo
xarem a empresa por causa disso soa como um proble-
ou mais tarde. Os seus cálculos mostraram que o time-
ma que qualquer um ficaria feliz em ter—no entanto,
to-market mais rápido poupou cerca de dez milhões de
ainda é um problema. Para os processos de rotina, pes-
Euros por ano em custos de atraso. Quando os produtos
soas que se sentem confortáveis fazendo esse tipo de
chegam ao mercado sete meses antes, as receitas tam-
trabalho foram contratadas. Esta mudança foi um desafio
bém surgem sete meses antes. É simples assim.
por algum tempo, mas foi também, uma transformação
importante e muito eficaz.
1 O que nos leva ao faturamento. Apesar das dificuldades
existentes, o crescimento da receita da empresa sempre
FOCO NO RESULTADO foi de cerca de dois a quatro por cento, mesmo antes da
E NÃO NA SAÍDA transformação ágil. Nos últimos dois anos, no entanto, as
receitas aumentaram muito com o crescimento do último
Se você quer um negócio ágil, você deve se concentrar
ano de, aproximadamente, vinte e cinco por cento (uma
na qualidade e seu efeito, isto é, o resultado, em vez da
melhoria de 6 a 12 vezes).
quantidade, ou seja, a produção. Na nossa empresa de
hoje, a agilidade já não é vista como entregar a maior
124 1 Nos últimos três anos, o lucro aumentou três vezes. Isto
quantidade possível de iniciativas. Em vez disso, é dada devido a receitas mais elevadas, bem como a custos mais
mais ênfase a consideração prévia—mesmo pelos traba- baixos, graças a uma maior eficiência.
lhadores que deram as ideias—o que e quanto uma ini-
ciativa contribui mais e onde deve ser colocado o foco. 1 A capitalização na bolsa foi mais do que o dobro: de 3,4
Uma única iniciativa pode criar mais valor do que três mil milhões de Euros para 7,1 mil milhões de Euros.
outras em conjunto; apenas fazer esta avaliação já é um
passo importante. Em certo ponto, é difícil medir os efei- Estes aumentos são devidos apenas ao business agility que
tos desta abordagem sobre as receitas e os resultados eventualmente se enraizou? Seria muito superficial fazer esta
dos ganhos. No entanto, o fato é que as receitas aumen- afirmação. Naturalmente, as decisões estratégicas corretas
taram e pode-se concluir que o “foco no resultado” tam- precisam sempre ser tomadas. Posso dizer, no entanto, que
bém contribuiu para isso. essas ações que foram tomadas tiveram um papel significa-
tivo no sucesso da empresa.
125
126
VAMOS RESUMIR: COMO ‘Criar Orçamento Anual’ e ‘Verificar a Utilização dos Fun-
VOCÊ PODE TORNAR O cionários’”. Parabéns pela fantástica lista de tarefas com
Post-Its, mas nem tudo que você coloca num Post-It é
SEU NEGÓCIO ÁGIL? ágil. O trabalho da alta gerência é realmente considerar
o que significa business agility, que problemas precisam
A história que foi contada aqui deve te inspirar. Talvez ser tratados e, acima de tudo, qual é o seu papel neste
sua empresa esteja no meio de um processo de transfor- processo.
mação e você se encontre enfrentado um ou outro pro-
blema novamente. A minha esperança é que eu tenha
sido capaz de colocá-lo de volta no caminho certo, para
a solução dos seus problemas. Talvez sua empresa esteja
pronta para iniciar um processo de transformação e você
percebe que uma ou mais das considerações anteriores
poderia levá-la na direção errada. Seja qual for a sua si-
tuação no momento, eu quero resumir mais uma vez, no
que você precisa prestar atenção se o objetivo da sua
empresa é alcançar business agility.
RESSALVA: Não se trata de uma lista exaustiva e não tem

qualquer ordem específica. Alguns passos devem ser
feitos mais de uma vez.
COMEÇAR PELO TOPO

127
O primeiro time ágil a ser estabelecido deve ser a alta
gestão. E quando digo ágil, quero dizer ágil. Tem que haver
mais do que meros discursos e, generosamente delegar a
responsabilidade pela transformação para a hierarquia
inferior—”tens a nossa bênção, Ide e tornai-vos ágeis! Não
tem nada a ver conosco.” Quando eu chego a uma em-
presa para ajudá-los a sair de uma rotina, a qual eles
estão atualmente presos em sua transformação ágil, os
gerentes ficam, muitas vezes, muito orgulhosos de me
mostrar suas habilidades de visualização. “Temos um
quadro que usamos para acompanhar as nossas tarefas
de gestão. Em seguida, trabalharemos nos bilhetes
A AGILIDADE COMEÇA COM O FOCO NO OBJETIVO,

PROCESSO DE MUDANÇA NÃO NO MÉTODO
Você não pode implementar novas formas de trabalhar e Durante a Segunda Guerra Mundial, a população da
pensar com cronograma. Todos os projetos de transfor- Melanesia viu os soldados americanos vindo do céu como
mação bem-sucedidos que vi até agora já experimenta- deuses que trouxeram coisas maravilhosas com eles.
ram durante o próprio processo de transformação o que Não houve mais entregas de carga depois que os ameri-
eles queriam alcançar no final. Uma organização deve canos se retiraram, então os habitantes da ilha começa-
praticar o princípio puxado? Então os colaboradores ram a imitar as atividades que tinham visto os soldados
também devem ser autorizados a “puxar” as mudanças. executando no campo de aviação. Eles tinham esperança
Os times devem fazer entregas incrementais? Então não de poder trazer os deuses de volta. Esta é a história por
escreva um plano de transformação de dois anos. Mudar trás do termo “cargo cult”. Em algumas empresas,
de sistema empurrado para puxado significa encontrar “Agilidade” se transformou em um tipo de cargo cult.
aliados, comercializar a ideia e fazer com que todos Os métodos são adorados, mas não o objetivo. Não im-
invistam na entrega mais rápida de valor para o cliente. porta se uma Standup Meeting dura 5 ou 20 minutos.
Quer tornar o seu negócio ágil ou quer simplesmente
implementar métodos ágeis na sua empresa?
128
A AGILIDADE NÃO É UMA IDENTIFICAR OS

QUESTÃO DE TIME FLIGHT LEVELS
Se você quer um negócio ágil, seu foco deve ser na gera- Uma vez que business agility não é uma questão de time,
ção de valor (processos organizacionais) e não na estru- você deve identificar qual Flight Level, em sua organiza-
tura organizacional. Claramente, você precisa de times ção, será capaz de resolver qual problema. As iniciativas
para que os processos funcionem. Mas faz pouco sentido devem ser concluídas mais rapidamente? Então, o número
otimizar times a qualquer preço, porque de iniciativas deve ser limitado, em vez de otimizar times.
times otimizados rodeados por proces- O que deve ser feito ao longo de toda a cadeia de
sos ruins mais amplos, contribuem criação de valor, desde a ideia até o resultado, a
muito pouco para business agili- fim de maximizar os efeitos? Pensamento
ty. Do ponto de vista sistêmico, abrangente significa que a alta gerência
é muito mais eficaz ter bons tem, absolutamente, que estar a bordo.
processos com times ruins. Caso contrário, acabará atingindo um teto
de vidro e não irá muito longe.
129
GERIR E ELIMINAR DEPENDÊNCIAS s ignifica inevitavelmente que os limites do WIP preci-

(EXATAMENTE NESTA ORDEM) sam ser reduzidos. Estabelecer limites de WIP significa
compreender qual WIP tem impacto sobre o quê. E às
Você deve se acostumar com o fato de que sempre haverá vezes isso significa aumentar um limite de WIP nova-
dependências dentro de uma organização, independen- mente ou simplesmente deixá-lo como está (veja o
temente de como ela está estruturada. E uso as palavras questionário no final da parte 2).
“sempre” e “nunca” com muita moderação. Então, deixe-
-me repetir: Não vale a pena copiar a estrutura mágica 3. Ciclos de feedback frequentes. Ninguém quer tornar
de uma empresa diferente, mesmo que pareça ser a so- uma empresa ágil só porque não tem nada melhor
lução certa. Uma abordagem mais adequada é tornar as para fazer. Transformações ágeis buscam objetivos
suas interações ágeis. Eventualmente, todas as depen- específicos, por isso é extremamente útil saber onde
dências que impedem o fluxo de trabalho se tornarão você está agora. Você precisa de feedback regular de
visíveis e você será capaz de decidir deliberadamente experiências. As métricas podem mostrar claramente
como pode reduzi-las ou eliminá-las. se uma ação teve um efeito ou não. Você pode então
decidir de acordo com isto, fazer mais ou menos de
INCORPORAR OS PILOTOS PARA A algo, ou deixar completamente de fazer algo. Outro
LEAN BUSINESS AGILITY EM CADA ciclo de feedback clássico é falar uns com os outros.
FLIGHT LEVEL Uma das maiores descobertas da humanidade é a
linguagem. Pode experimentar. Num contexto empre-
Vamos supor que você identificou os vários Flight Levels sarial, é ainda mais brilhante falar com as pessoas
dentro da sua empresa. Independentemente da constru- certas sobre os assuntos certos no momento certo.
ção de um time, de um produto ou de um quadro de Isto é exatamente o que cria interações ágeis e isto é
estratégia, os quatro passos seguintes devem ser incor- o que eu tenho enfatizado ao longo deste livro.
porados em todos os Flight Levels:
4. Melhorar. Tudo o que você fez nos primeiros três
130 1. Tornar o trabalho e os processos explícitos. Na maio- assos ainda lhe dá uma última situação de erro.
p
ria das vezes, o trabalho do conhecimento é invisível Então, não invista muita energia em tentar encontrar
e, assim sendo, é difícil de entender. Em um quadro, as visualizações perfeitas, WIPs perfeitos e reuniões
você pode ver o que está sendo trabalhado e como perfeitas em sua primeira tentativa e, em seguida,
está sendo trabalhado. No entanto, é essencial des- manter assim para sempre. Não existe algo como o
crever os processos existentes e não os processos absolutamente correto independentemente, apenas
necessários ou desejados. O progresso é melhor algo que funciona agora. O truque por trás do busi-
alcançado quando você começa com o status quo. ness agility é a melhoria. Portanto, comece a fazer o
mais rápido possível, reflita sobre o que está fazendo
2. Gerir conscientemente o WIP. Os limites do WIP são
e melhore com isto.
uma das ferramentas de gestão mais poderosas
disponíveis. Eles influenciam muitas variáveis cujas
interações resultam em business agility—por exem-
plo, time-to-market ou previsibilidade. Isso não
RECONSIDERANDO AGILE
132
REFERENCIAS BIBLIOGRÁFICAS
REFERÊNCIAS
[Laloux 2016] [Snowden, Boone, 2007]

Laloux, Frederic: Reinventing Organizations: An illustra- Snowden, David J.; Boone, Mary E.: A Leaders’s Framework
ted Invitation to Join the Conversation on Next-Stage for Decision Making. In: Harvard Business Review,
Organizations. Nelson Parker 2016. noviembre 2007.
https://hbr.org/2007/11/a-leaders-framework-for-
[Leanability E018, 2017] decision-making
Leanability Videoblog: Lean Business Agility E018 –
Kamishibai. [Stacey 2000]
https://bit.ly/2ORVF0B Stacey, Ralph D.: Strategic Management & Organisational
Dynamics. The Challenge of Complexity. 3.ª edición,
Financial Times 2000.
[Leanability E020, 2017]
Leanability Videoblog: Lean Business Agility E020 –
[The W. Edwards Deming Institute 2018]
The Spotify Model.
The W. Edwards Deming Institute: Quotes by W. Edwards
https://bit.ly/2OOILjM
Deming
http://quotes.deming.org/authors/W._Edwards_Deming/
[Leopold 2016] quote/10141
Leopold, Klaus: Practical Kanban: From Team Focus to
Creating Value. LEANability PRESS 2016.
[Little, Graves, 2008]

Little, John D.C.; Graves, Stephen C.: Little’s Law. In:
Chhajed, Dilip; Lowe, Timothy J. (eds.): Building Intuition.
Insights from Basic Operations Management Models and
133
Principles. Springer US 2008, pág. 81-100
[Mois, Baldauf, 2016]

Mois, Tim; Baldauf, Corinna: 24 Work Hacks ... auf die wir
gerne früher gekommen wären. sipgate GmbH 2016.
RECONSIDERANDO AGILE
BIBLIOGRAFÍA DICAS DE
LITERATURA
Artigos selecionados, vídeos e Podcasts sobre o tema Flight Levels
Business Agility
At which Flight Level does innovation start?
Meus pensamentos sobre o tema Business Agility são re-
tirados do meu blog. Você pode ler em https://bit.ly/2DYXzJy
www.LEANability.com
Lean Business Agility E007: Flight Level 2 at AutoScout 24
Novas entrevistas com profissionais de Business Agility
https://bit.ly/2IXke9z
podem ser encontradas regularmente no meu vídeo
blog em Lean Business Agility E026: Medical Device Development,
https://www.leanability.com/de/category/video-blog/
Flight Levels and Scrum https://bit.ly/2QRj4PJ
Podcast: Flying at Portfolio Level https://bit.ly/2CLzAxW
Limites de WIP
WIP Limits Must Die https://bit.ly/2E9nFdP
Flow Exercise: Building Paper Boats
https://bit.ly/2waOHuU
134
BIBLIOGRAFÍA RECOMENDADA
Recomendações de Livros
Christensen, Clayton M.: Competing Against Luck.

The Story of Innovation and Customer Choice. Harper
Business 2016.
Doerr, John: Measure What Matters. OKRs – The Simple

Idea that Drives 10x Growth. Portfolio Penguin 2018.
Goldratt, Eliyahu M.: The Goal. A Process of Ongoing

Improvement. North River PR Inc 2014.
Kaltenecker, Siegfried: Self-Organising Enterprises. Le-

anpub 2017.
Liker, Jeffrey: The Toyota Way to Lean Leadership.

Achieving and Sustaining Excellence through Leadership
Development.
Marquet, L. David: Turn The Ship Around! A True Story of

Building Leaders by Breaking the Rules. Portfolio Penguin
2015.
Moore, Geoffrey A.: Escape Velocity. Free Your Company’s

Future from the Pull of the Past. Harper Business 2011.
Reinertsen, Donald G.: The Principles of Product 135

Development Flow. Second Generation Lean Product
Development. Celeritas Pub 2009.
Ries, Eric: The Lean Startup. How Constant Innovation

Creates Radically Successful Businesses. Portfolio
Penguin 2011.
Taleb, Nassim Nicholas: Antifragile. Things that Gain from

Disorder. Penguin 2013.

Repensandoaagilidade PDF

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Repensandoaagilidade PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Repensando a

Copyright © 2020, LEANability GmbH, Viena , Áustria

Versão Impressa: Abril de 2020

Autor: Klaus Leopold • Texto: Dolores Omann • Ilustrações: Matthias Seifert

eBook: Marina Grosser • Foto: Christian Kollarovits

Saiba mais sobre Flight Levels e Agilidade em www.LEANability.com/en/flight-levels-training

Este livro também está disponível como: Atualizações

Kindle ISBN: 978-3-903205-59-8 LEANability.com

Leanpub ISBN: 978-3-903205-60-4 flightlevelsacademy.com

Prefácio I Klaus Leopold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 04

Parte 3 | A Primeira Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Parte 4 | O Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Referências Bibliográficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Neste livro, aliado ao poder da ilustração, eu quero deixar um ponto

­empresas começaram a pedir minha ajuda em suas implementações

Aqui você vai encontrar um caminho para novos experimentos com os

Na realidade, tornou-se uma média expedição para encontrar o ilustrador

Texto e imagens são componentes naturalmente importantes de um livro ilus-

Algo precisava mudar, e isto estava claro. E a gerência

1 O Time-to-Market (Tempo desde o comprometi-

1 Utilizando o feedback rápido do cliente, as mudan-

PREPARAÇÕES PARA 1. Todas os times deveriam ser multifuncionais. Desta

Os departamentos e os times podiam até escolher o

d. Duas medições deveriam ser estabelecidas como

1 Throughput: O número de itens de trabalho que

1 Cycle Time: Isto indica a rapidez com que o

O que é uma Retrospectiva?

O PROCESSO DE Não acredito que seja possível mudar uma mentalidade

Observe: Durante a implementação, as etapas seguintes

Na feira, o time já discutia e muitas vezes até decidia

O que é um workshop de System Design?

OS RESULTADOS APÓS 1 Mais de 80% das equipes foram “totalmente trans­

Passados doze meses, os promotores da transformação

É exatamente isto o que é anunciado com métodos Ágeis

Pareceu muito diferente para os times de Kanban nesta

Como um <tipo de usuário>

Quais são os Story Points?

OS PROJETOS NÃO ESTÃO

QUAL ERA A @$*# DE PROBLEMA AQUI?

Sobre inferir coisas de

34 Quando uma empresa quer mudar, as pessoas dentro

Durante as minhas conversas com a gerência da

Esta organização pegou o caminho errado no início de

E isto acontece com frequência: Assim que a gerência

Muitas vezes, durante essas dis-

Embora a agilidade viva a partir do princípio puxado,

Princípio Puxado versus Princípio Empurrado

A MUDANÇA É UM NOVO Aparentemente, um organograma ágil é criado quando

­ rganização interna que fez sentido para os objetivos

CAUSA #2: Quando cheguei nesta empresa, mais de 80 por cento

LIDANDO COM dos times já estavam trabalhando com seus métodos

TIMES E PRODUTOS Muitas vezes eu vi quadros construídos como o que você

O QUE ELES SE ESQUECERAM DE Você pode eliminar o máximo possível de dependências

Deve haver o maior número possível de

O F MAIS RÁPIDO DO MUNDO

ONDE HÁ UM FLUXO, HÁ TAMBÉM Vários outros membros do time começaram a limpar o

52 até anos) que consistia principalmente de esperar. Em

CAUSA #4: Há também um limite “implícito” de WIP no Scrum. Ele

LIMITES DE WIP NO vem de trabalhar em Sprints e do compromisso associado

Por que eu uso “Trabalho em Processo”?

Para mim, pessoalmente, „processo“ é uma palavra neutra

COMO O LIMITE DE WIP FUNCIONA, ­­

As pessoas não são capazes de realizar

Visualizar o trabalho mostra a verdadeira

empresas começaram a pedir minha ajuda em suas implementações

1 O Time-to-Market (Tempo desde o comprometi-

1 Utilizando o feedback rápido do cliente, as mudan-

PREPARAÇÕES PARA 1. Todas os times deveriam ser multifuncionais. Desta

d. Duas medições deveriam ser estabelecidas como

1 Throughput: O número de itens de trabalho que

1 Cycle Time: Isto indica a rapidez com que o

OS RESULTADOS APÓS 1 Mais de 80% das equipes foram “totalmente trans

rganização interna que fez sentido para os objetivos

COMO O LIMITE DE WIP FUNCIONA,

UMA PRIMEIRA isso, eles tentaram implementar a agilidade com uma

1 Eles determinam melhorias através destes ciclos de

1 O trabalho será visualizado.

1 Melhorias são derivadas e implementadas a partir do

Mais reuniões? 1 Nem todos precisam participar. Representantes de

AS TRÊS ARMADILHAS DE TEMPO A 1. O ORÇAMENTO ANUAL CRIOU LOTES

1. Visualizar. Todas as unidades geradoras de valor atu-

2. Limitar. Na segunda etapa, o número ideal de projetos

GERIR E ELIMINAR DEPENDÊNCIAS s ignifica inevitavelmente que os limites do WIP preci-