agilidade_
O que aprendi
auxiliando
Como práticas do método Kanban
podem ajudar a sua empresa a ganhar
mais agilidade.
Rodrigo Yoshima | @rodrigoy
técnico em Processamento de Dados, bacharel em Administração de Empresas e autor, escreveu artigos com renomados autores nacionais e internacionais, como Scott Ambler, Jon Kern e James Shore. Accredited Kanban Trainer e Kanban Coach Professional pela
Lean-Kanban University, trabalha com projetos de software há 16 anos, tendo treinado mais de 150 equipes em práticas Lean e Agile
em diversas empresas e setores. Atualmente tem utilizado técnicas Lean/Kanban como consultor na Aspercom, auxiliando empresas
pequenas, médias e grandes a melhorar seus processos de forma evolucionária, florescendo uma cultura Kaizen. É palestrante em
eventos nacionais e internacionais. Mantem seu blog em http://blog.aspercom.com.br.
V
ocê é um analista desenvolvedor em uma pequena empresa de produtos. Como toda empresa
ainda em ritmo de Startup, o volume de demandas
que chega para sua equipe analisar, construir e testar é monstruoso. Possivelmente um gerente de Produtos, um Product Owner, ou até mesmo o próprio
fundador da empresa tem “trocentas” ideias por dia.
A equipe reclama de falta de foco, de falta de tempo para construir um produto confiável e reclama
também do nível de stress. O produto até atende um
segmento do mercado, mas ele já nasceu com uma
grande dívida técnica. A falta de foco, o sentimento
de “querer abraçar o mundo” e o crescimento descontrolado parece inviabilizar o negócio no médio-longo prazo. O consenso é que o processo atual é
um caos.
Você é um coordenador de equipe TI em uma empresa média do ramo de serviços. Sua empresa tem o
anseio de crescer, porém, está colocando a “carroça
na frente dos bois”, e mesmo sendo uma organização
com pouco mais de 400 pessoas, já sofre com hierarquias inflexíveis e alta burocratização do trabalho. O
crescimento passa a ser vítima do próprio sucesso,
impedindo a empresa de expandir mais. A organização possui processos e mais processos, e processos
para controlar processos. Infelizmente, essa rigidez
/ 30
estrutural faz a empresa ter pouca agilidade para
responder ao dinamismo do mercado. A sua avaliação é que há excesso de controles e burocracia, mas
será difícil mudar o que é necessário para a empresa
deslanchar.
Você é um gerente de TI de uma grande empresa
que presta serviços financeiros ou atua na indústria.
É uma corporação consolidada que atua no mercado há décadas e sua posição no mercado não parece
ser ameaçada. Diversas áreas demandam projetos e
manutenção entre os mais de 200 sistemas de informação existentes. Nas conversas de corredor constantemente falam que “seria muito bom se a TI não
fosse tão lenta”. Sua posição como gestor de TI é
defensiva, e requer cada vez mais trato político para
solucionar conflitos e problemas de projetos. Você
não sabe ao certo qual é o problema, pois as equipes
são como caixas pretas. Você sequer consegue atuar
na organização como líder para otimizar processos.
Se você se identificou com alguma das situações
acima, este artigo é para você. Em mais de 14 anos
trabalhando com processos de gestão e desenvolvimento em TI, inicialmente com RUP, depois com
Agile e agora com a abordagem Lean/Kanban, esses
três parágrafos acima demonstram ambientes que
comumente encontro em trabalhos de consultoria.
empresas em
transições ágeis?
Rodrigo Yoshima, um renomado evangelista de práticas ágeis no
Brasil e no exterior que foi colunista da MundoJ entre 2006 e 2010,
nesta edição comemorativa, apresentará novas práticas e problemas comuns que ele encontra em transições Lean/Agile em seu trabalho como consultor. Neste texto, veremos as principais diferenças entre uma implementação Agile revolucionária e uma transição
Lean evolucionária, e como essa nova abordagem pode ajudar sua
empresa a melhorar seus processos na melhor forma Kaizen.
Mudar processos, sistemas de gestão e consequentemente a cultura de uma empresa é bastante desafiador, mas temos técnicas e práticas de Gestão de
Mudanças que podem nos ajudar.
Sobre o “tamanho” da mudança
Em diversos treinamentos, sessões de coaching e
palestras costumo perguntar às pessoas porque mudanças organizacionais são tão difíceis. Em uníssono
várias pessoas em todo país e no exterior me respondem que mudanças são difíceis porque envolvem
pessoas. Por que pessoas são a chave para o sucesso
ou falha de mudanças organizacionais? Porque pessoas são a parte ativa do sistema de trabalho no século XXI, a Era da Informação. O problema é que na
maioria das vezes pessoas agem mais na emoção do
que na razão. Isso torna mudanças difíceis. Além disso, o ser humano em sua evolução busca um estado
de homeostase – se agarrar a um ponto estabilidade
do sistema. Se as pessoas não reagissem emocionalmente quando propomos mudanças tudo seria muito
fácil. Imagino que se todos na sua empresa tivessem
um comportamento como o do Dr. Spock (personagem da série Star Trek do planeta Vulcano, cujos habitantes vivem pela razão e pela lógica), mudanças
seriam bem mais simples! Mas isso não é verdade,
nesse planeta lidamos com humanos, humanos tomam a maioria das suas decisões pela emoção.
Uma das principais lições que aprendi nos últimos 3 anos é que o tamanho da mudança é um fator
decisivo para alavancar sistemas de trabalho. Uma
grande e pretensiosa mudança é mais arriscada e
tem maior chance de sofrer resistência das pessoas
e falhar miseravelmente. Se por um acaso você olhar
para o seu processo atual, ver que está tudo errado e
querer abandoná-lo rapidamente por um novo processo que todo mundo no mercado tá tentando usar,
quero que você esteja a par dos riscos e do potencial
de falha que essa grande empreitada pode ter.
Atualmente existem duas abordagens para gestão de mudanças: a revolução do processo e a evolução do processo. Como exemplo de revolução temos
o que descrevi no parágrafo anterior. É uma grande
e pretensiosa mudança gerenciada. Isso se configura quando uma empresa investe em abandonar um
processo atual estabelecido e pesquisa a adoção de
um novo processo, geralmente baseado em ideias já
existentes e experimentadas no mercado. Esta abordagem revolucionária é a forma comum que a maioria das empresas pensa sobre mudanças de processos. A revolução do processo é algo que vem sendo
utilizado há décadas no mercado. É uma forma antiquada, arriscada e com baixa performance econômica para lidar com processos e sistemas de gestão.
Revolução é a forma século XX de pensar sobre transição de métodos de trabalho.
Já a evolução do processo é simplesmente melhorar continuamente e por tempo indeterminado
um processo já existente. A evolução do processo
não tenta substituir a realidade de uma empresa por
31 \
capacidade
Evolução “Kaizen”
status
quo
Evolução “Kaikaku”
TEMPO
Figura 1. Tamanho da Mudança (Kaizen x Kaikaku).
um ideal imaginário. A evolução é lidar com a realidade o tempo todo, fazer experimentos de melhoria e
alavancar um sistema de trabalho de forma orgânica
e incremental. A evolução é um conjunto de pequenas
mudanças ordenadas e progressivas que influenciam
gradativamente um sistema de trabalho conforme
esse próprio sistema de trabalho responde a essas intervenções. A evolução tenta lidar com um problema
de cada vez em um ambiente, e isso faz os riscos e a
resistência das pessoas diminuir consideravelmente.
Evolução é a forma século XXI de lidar com mudanças
de processos.
Na figura 1 temos o contraste entre os dois modelos. A abordagem revolucionária está em roxo
(Kaikaku) e a abordagem evolucionária está em verde (Kaizens). Um ponto importante que este gráfico
mostra é a relação que temos entre os tipos de mudanças e a capacidade. Toda vez que aplicamos uma
mudança em uma equipe inicialmente a capacidade
dessa equipe cai. Se a mudança é grande, essa queda
de capacidade é proporcional ao tamanho da mudança. Um exemplo simples desse efeito é a contratação
de pessoas. Se você contrata uma pessoa nova para
sua equipe é lógico que inicialmente sua capacidade vai cair. Essa pessoa precisa se adequar ao grupo,
aprender como trabalhar, como usar as ferramentas e
conhecer o produto. Se uma pessoa entrando na equipe configura em uma queda de capacidade, imagine
agora se você contratar 10 pessoas de uma só vez. É
claro que integrar 10 pessoas no grupo é mais difícil e demorado que integrar somente uma. A ciência
por trás desse efeito é defendido no ““Virginia Satir’s
Change Process Model”.
A primeira grande lição que gostaria de deixar
neste artigo é que o tamanho da mudança é algo crucial para o sucesso das suas iniciativas de melhoria
de processos. Mudanças menores, mais seguras para
a equipe e que apresentam resultados mais rápidos
/ 32
criam engajamento para que as próximas mudanças tenham força. É realidade no mercado hoje que
as empresas são conservadoras. A alta direção especialmente de grandes empresas resistem emocionalmente a revoluções. O Brasil especificamente é um
país conservador. A abordagem evolucionária, com
mudanças pequenas, constantes e que lidam sempre
com a realidade atual e não com um cenário futuro
especulativo (como será meu processo daqui há 4
meses) é uma forma segura de mudar um ambiente conservador. Kanban é baseado em uma cultura
Kaizen de melhoria contínua e pequenas mudanças
evolucionárias. Kaizen: hoje foi melhor que ontem e
amanhã será melhor que hoje.
Evite as pedras
Bruce Lee, além de ator e mestre de Kung Fu,
era também um filósofo. Uma de suas colaborações
para a filosofia é resumida na ideia de “ser como a
água”. Essa ideia também é seguida por Anderson Silva, lutador campeão de MMA. Na visão de Bruce Lee,
a água se molda ao seu ambiente. Se você coloca a
água em um copo, ela se torna o copo. Se colocar essa
mesma água em uma garrafa ela se adapta ao formato da garrafa. Imagine a água descendo por uma colina. Quando ela encontra uma pedra pelo caminho,
inicialmente ela não tenta derrubar a pedra colina
abaixo, mas sim, contorna a pedra. É um pouco difícil
pensar como essa filosofia pode se aplicar a processos
de desenvolvimento de software, mas tem uma grande relação!
Quando tentamos mudar um ambiente de trabalho (a água tentando fluir colina abaixo) é inevitável
que encontremos pontos de resistência (pedras) pelo
caminho. Ao encontrar essas resistências a tendência natural do ser humano é tentar derrubá-las a
qualquer preço. A abordagem Lean/Kanban segue a
filosofia de Bruce Lee para a melhoria e evolução de
processos: evite as pedras! Você deve estar se questionando o que seriam as “pedras” de uma iniciativa
de melhoria de processos: as pedras são pontos de resistência emocional das pessoas. Quando você sugere
uma mudança e as pessoas se opõem emocionalmente a essa sugestão, isso é uma pedra na sua transição.
Vamos dar alguns exemplos.
Imagine que na sua organização há vários gerentes de Projeto tradicionais. O dia a dia deles é organizar cronogramas, cobrar tarefas, elaborar relatórios
de status dos projetos e a empresa repentinamente
deseja implantar Scrum. Sabidamente no Scrum não
há o papel de gerente de Projeto. É bastante comum
nesse cenário a empresa investir em treinamento e certificação para que esses gerentes se tornem
ScrumMasters. Logicamente, se o gerente de Projetos
não concorda com o conceito de equipes auto-geridas
que o Scrum propõe ele vai resistir emocionalmente
a essa mudança. O mesmo pode acontecer com desenvolvedores. Imagine que você é um programador
Java. Não só isso, você é líder do Grupo de Usuários
Java da sua cidade, participa ativamente da comunidade Java e até publicou artigos aqui na MundoJ. Você
assina no seu e-mail como “Desenvolvedor Java”. Um
belo dia, por conta de um reposicionamento do produto da sua empresa, chega a notícia que a versão
2.0 do produto será em Ruby/Rails. Não importando
os argumentos do porquê dessa mudança, se você se
identifica como um programador Java você irá resistir
emocionalmente a essa mudança.
Quando começamos um trabalho para melhorar
os processos de uma equipe usando Kanban evitamos
forçar a derrubada das pedras (resistência emocional
das pessoas), preferindo inicialmente contorná-las.
As pessoas de uma empresa podem resistir emocionalmente a uma gama de coisas. Elas podem resistir
a time-boxes, a mudanças de papéis, a juntar equipes
de desenvolvimento e teste, a implantar auto-organização, a reduzir o poder de gestores, a mudar práticas
técnicas e muitas outras coisas. É importante ressaltar que essa resistência é emocional e não racional.
Você não convence uma pessoa que está reagindo
emocionalmente com argumentos lógicos. Quando
uma pessoa reage emocionalmente e você começa a
discutir usando argumentos lógicos a situação piora!
Isso é essencialmente verdadeiro inclusive quando
você discute com sua esposa/marido ou namorado/
namorada.Lutar contra a resistência emocional das
pessoas leva tempo. A solução para este problema
pode ser resumida em uma citação de David J. Anderson, o criador da abordagem Kanban para TI:
por líderes revolucionários da comunidade Agile. A
abordagem Kanban para mudança de processos e a
abordagem Agile são bastante diferentes em essência. Como exemplo, o Scrum exige a derrubada de
várias pedras colina abaixo para você simplesmente
começar com ele se seu contexto está longe do que
o Scrum prega. No Kanban as restrições iniciais são
leves. Kanban respeita seu contexto, sua maturidade,
sua cultura, as suas “pedras” e se foca em mudanças
evolucionárias. Kanban permite a você controlar a
velocidade da evolução do seu processo. Empresas
mais maduras podem suportar velocidades maiores
de mudança, empresas menos maduras não. O Agile
neste aspecto é uma abordagem revolucionária (veja
a figura 1). O próprio fato do Agile se materializar
como um Manifesto, acusando coisas erradas do mercado, confirmam o tom revolucionário dessa abordagem. O ponto é que revoluções raramente funcionam.
O “7th ANNUAL STATE of AGILE DEVELOPMENT
SURVEY”, último relatório sobre o estado de implementações Agile no mundo realizado pela VersionOne, diz que as barreiras que restringem as empresas a
adotarem Agile são relacionadas primariamente com
resistência a mudanças [veja referências]. Um ponto
que quero destacar é que se Agile é difícil para sua
empresa isso não é culpa da sua empresa, mas sim
uma falha do próprio Agile que não possui um modelo de transição convincente e viável.
“As pessoas não resistem a mudar, elas resistem
serem mudadas.” Peter Senge
No restante deste texto pretendo oferecer algumas ferramentas práticas para você iniciar o uso de
“Se encontrar resistência emocional, crie um
Kanban na sua equipe, e assim, começar a jornada de
sistema onde os problemas fiquem visíveis, e
melhoria do seu processo de forma fácil e rápida. Esengaje emocionalmente as pessoas na mudança.”
sas três práticas que vou apresentar visam criar um
David J. Anderson
ambiente inicial para que eventos Kaizen sejam ao
menos discutidos. O Kanban e a filosofia Lean têm
As armas que temos para lutar contra a resistênoutras práticas e técnicas importantes que não estão
cia emocional das pessoas não são argumentos lógicobertas neste artigo.
cos, mas sim, “argumentos também emocionais”. A
visualização do processo que explicarei adiante é um
desses argumentos emocionais. É importante ressal- Prática 1: Visualizar o Fluxo
Muitas das práticas que estou descrevendo aqui
tar que com o tempo é esperado que o desgaste da
são
a base de conhecimento que emergiu da comuágua fará as pedras rolarem colina abaixo. Evitar as
nidade
Kanban na área de TI. Com grande influência
pedras simplesmente é respeitar a velocidade com
que as pessoas assimilam as mudanças. Como eu dis- da Teoria das Restrições [Goldratt], do Lean/Toyota
se, as pessoas são os elementos ativos e responsáveis Production System [Ohno], do Agile, do Lean Product
dentro de um sistema de trabalho do conhecimento. Development [Reinertsen] e do Systems Thinking,
Tentar derrubar as pedras prematuramente pode mi- essa comunidade cresceu em número e em cases de
nar todas as iniciativas de melhoria, causando as pes- sucesso ao redor do mundo nos últimos 8 anos. Devo
também destacar que a comunidade brasileira é uma
soas reagirem sempre negativamente.
Essas duas primeiras lições deste artigo: mudar das mais fortes e influentes do planeta!
Para começar a aplicar Kanban e iniciar a evode forma evolucionária e contornar as pedras, já foram acusadas de serem lentas demais, especialmente lução do seu processo alguns passos Kaizen muito
33 \
Figura 2. Quadro Kanban de uma equipe da empresa 7Prods.
simples e que geram pouca resistência emocional das
pessoas são adotados. Em meu trabalho de consultoria esses pequenos passos iniciais são: visualizar e
mapear o fluxo atual, limitar trabalho em progresso e
reuniões diárias. O primeiro passo, visualizar o fluxo,
é também a primeira propriedade do método Kanban.
A visualização do processo pode se dar de diversas
formas e de diversas maneiras, mas a maneira mais
comum, prática e eficaz é utilizar um quadro na parede com Post-its.
Na figura 2 vemos um quadro de visualização
do processo de uma equipe da empresa 7Prods. Esta
equipe usou um quadro branco, Post-its de várias cores, fichas pautadas e a criatividade para montar um
mapa visual do processo de desenvolvimento dessa
corrente de valor em particular. Criar um quadro Kanban é simplesmente desenhar em equipe uma visualização compartilhada por todos do fluxo do processo
da maneira que o processo é hoje, com suas qualidades, defeitos, filas, hand-offs etc. A visualização do
processo é um catalizador de melhorias na equipe,
promovendo o entendimento e a colaboração de todos os envolvidos. Quando fizer este trabalho com
sua equipe não tente modelar no quadro o processo
perfeito ou a situação desejada. Mapeie a realidade!
Deixe o sistema de trabalho se revelar da forma que
/ 34
ele é, mesmo que a realidade seja feia. Compreender
os problemas é o primeiro passo para poder melhorar. A visualização franca do processo é um argumento emocional que pode ser usado para convencer as
pessoas das mudanças necessárias.
Visualizar o trabalho é uma prática que tenho
aplicado nos últimos 5 anos em mais de 150 equipes.
Essa prática lúdica e simples pode parecer até boba,
porém, no meu trabalho, materializar o processo da
equipe de modo visual, interativo e persistente se
mostrou como a melhor maneira possível na tecnologia atual de se aumentar a compreensão e o engajamento da equipe e da liderança na solução de problemas. Cientistas que estudam a cognição humana
provaram que nosso cérebro cria significado às coisas
através da visão [veja referências]. Você não consegue
gerenciar aquilo que não consegue ver.
Prática 2: Limitar Trabalho em
Progresso
Um dos priores problemas de gestão no trabalho do conhecimento (qualquer atividade criativa
como criar campanhas publicitárias, fazer projetos
em CAD, marketing, design de produtos e desenvolvimento de software) é administrar o trabalho em
Figura 3. Quadro Kanban com Limites.
do processo, aumentando a entrega de valor dessa
equipe.
Limitar trabalho em progresso é contra-intuitivo. A tendência natural do ser humano gestor é achar
que quanto mais coisas a equipe está fazendo ao mesmo tempo mais rápido essas coisas estarão prontas.
Porém, isso é um erro. Um desenvolvedor, analista ou
tester que constantemente troca de tarefa em execução sofre perda com a troca de contexto. Segundo
pesquisas [Mark, 2008], pessoas quando trocam de
contexto, isto é, estavam trabalhando na tarefa A e
são interrompidas com a tarefa B, demoram até 23
minutos para ajustar seu aparato cerebral cognitivo
à nova tarefa. Se você troca de tarefa ou de projeto 3
vezes ao dia e tem 6 horas produtivas por dia, praticamente 16% do seu tempo é desperdiçado com troca
de contexto.
Além do desperdício com troca de contexto, ter
muitas coisas dentro do seu sistema de trabalho (WIP
alto) gera variabilidade e seu processo se torna imprevisível. Há um conjunto de métricas no Kanban
como o Lead Time e o Throughput que costumam se
estabilizar estatisticamente dentro de um intervalo
de confiança quando você limita o WIP. Isso torna seu
processo mais confiável e previsível de maneira muito fácil. WIP baixo torna tudo no seu processo mais
simples. WIP baixo garante que seu processo seja
ágil, no sentido de permitir que você mude de direção
rapidamente se necessário.
Evitando que o trabalho se acumule dentro do
seu processo também é uma prática simples que comumente não gera tanta resistência emocional das
pessoas. Para definir os limites de WIP corretos para
o seu contexto é necessária alguma experimentação.
A lição que deixo aqui é essa: coloque restrições na
quantidade de coisas iniciadas e não terminadas no
seu processo para conseguir estabilizar o fluxo de valor. Os ganhos econômicos dessa prática são extraordinários.
As reclamações mais comuns que escuto de gestores no mercado são duas: falta de processos e falta
de previsibilidade. Visualizar o fluxo em um quadro
tem o efeito de materializar o processo e aumentar o
senso de organização da equipe. Isso geralmente soluciona a questão “falta de processos”. Se seu processo tem poucos elementos de variabilidade no fluxo,
limitar o WIP e capturar métricas como Lead Time e
Throughput podem tornar seu processo estatisticamente previsível. Essas duas práticas sozinhas podem
realizar o sonho da maioria dos gestores: ter um fluxo
de trabalho estável.
progresso. Infelizmente a maioria dos gestores simplesmente ignoram o trabalho em progresso. Pegue
a sua equipe atual e tente de alguma forma mensurar
todo trabalho iniciado, mas não terminado que existe
no seu processo. Se você trabalha em uma empresa
de produtos é bem capaz que teu processo hoje tenha
umas 20 ou 30 user stories iniciadas, mas ainda não
“deployados” em produção. Se você é uma empresa
de outsourcing, é bem capaz que haja uns 40 ou 50
casos de uso já analisados que ainda não foram desenvolvidos e entregues aos usuários finais. Em ambos os cenários, demandas iniciadas, mas não terminadas roubam o foco da equipe, aumentam o senso
de desorganização e aumentam a imprevisibilidade
do processo. É impossível ter uma gestão sadia se há
muito trabalho em progresso, pois simplesmente não
há valor fluindo para os usuários ou clientes. Muito
trabalho em progresso significa que o sistema está se
comprometendo além da sua capacidade de entrega,
configurando um “Sistema Empurrado” de trabalho –
um câncer da gestão que a Toyota venceu com o TPS
e Sistemas Puxados na década de 50.
Na figura 3 temos o quadro Kanban de uma equipe de desenvolvimento de software. Cada coluna representa o estado do trabalho e os Post-its amarelos
e rosa representam as demandas entregáveis fluindo
pela corrente de valor (podem ser User Stories, Casos de Uso, Cenários, Bugs, Solicitações de Mudanças
e qualquer outra coisa). Os números em branco com
fundo preto no cabeçalho de cada coluna representam a quantidade de trabalho que o processo suporta
em cada etapa. Esses limites são alertas para a equipe não aumentar a quantidade de trabalho em andamento (geralmente chamamos isso de “Work-in-Progress” ou simplesmente WIP), mantendo a fluidez do
processo estável. Os limites estabelecem o fluxo. Com Prática 3: Reunião Diária
Colaboração é primordial em qualquer tipo de
os limites a tendência do trabalho ficar parado será
menor e a visualização fará a equipe colaborar para trabalho onde um grupo de pessoas está pensando
que as demandas fluam com mais rapidez para o fim para tentar entregar valor para alguém. A reunião
35 \
diária é uma prática de gestão que está presente
em vários métodos ágeis. No Kanban a reunião diária não é estruturalmente muito diferente de uma
Daily Scrum, porém, há algumas diferenças que vou
destacar aqui. Em primeiro lugar a reunião diária do
Kanban é uma reunião em pé como o XP prega, porém, é feita na frente do quadro Kanban. No Scrum a
reunião diária itera sobre as pessoas (o que você fez e
o que pretende fazer), no Kanban nós iteramos sobre
as demandas (quem está fazendo este Post-it). Esse
formato pode variar de equipe para equipe, entretanto, sinto uma grande diferença prática com o Kanban
ao fazer a reunião diária na frente do quadro e com
limites de WIP definidos.
O quadro, conforme já explicado, é a manifestação de como a equipe enxerga o fluxo de trabalho. Ele
representa a realidade do processo atual. Se o processo atual como exemplo tem equipe de desenvolvimento e de teste apartadas (o Kanban não exige um
time multifuncional como o Scrum, veja o quadro da
figura 3), a visualização pode mostrar problemas de
falta de colaboração, geralmente na forma de filas. Os
limites de WIP fazem toda a equipe buscar entregar
valor, fazendo as “demandas andarem” até serem finalizadas. A reunião diária é o momento onde a visualização se torna iterativa (as pessoas movimentam
as demandas no quadro) e os problemas de fluxo são
discutidos. Algumas frases comuns que escuto em
reuniões diárias Kanban são:
»» “ Precisamos dar foco aqui para não alimentar
essa fila.”
»» “Esse limite vai estourar, vamos aumentar WIP
ou vamos colaborar mais?”
»» “Quem está cuidando dessa demanda que está
parada? Precisa de ajuda?”
»» “Vamos mudar o quadro para destacar o problema X?”
É muito comum nas reuniões diárias do Kanban
surgir discussões sobre melhorias. Isso pode ser feito
todos os dias, sem necessidade de aguardar a reunião
de Retrospectiva. O processo é dinâmico e a forma de
alavancá-lo também assim deve ser. A reunião diária
é uma cerimônia mínima para que um processo colaborativo ocorra. Conforme destacado, o Kanban não
exige times multifuncionais. Com Kanban você pode
começar com um time de desenvolvimento apartado
do time de testes. A reunião diária é importante para
que esses times conversem e colaborem entre si para
a saúde do fluxo. A visualização do fluxo, as restrições
de WIP e as reuniões diárias habilitarão todo o grupo
a melhorar os relacionamentos e refinar o processo.
Essas três práticas simples descritas neste artigo costumam em poucas semanas na maioria das equipes
trazer melhorias espetaculares, principalmente sobre
o entendimento da equipe e da liderança sobre os
problemas do processo atual.
/ 36
Conclusão
Kanban não é um processo. Kanban não é só um
quadro na parede com Post-its. Kanban não é só uma
alternativa ao Scrum. Kanban é uma forma de mudar
seu sistema de trabalho atual para melhor, baseado
numa abordagem evolucionária, lidando com a resistência emocional das pessoas e fazendo sua transição
para um lugar melhor mais suave. O Kanban não é um
livrinho de regras a ser seguido. Não há julgamento
no Kanban. Ninguém da comunidade Kanban vai falar para você que você está fazendo algo errado. Kanban simplesmente mostra as características do seu
processo atual, respeitando o seu contexto, permitindo habilitar melhorias que você julgar saudáveis.
Atualmente várias empresas no Brasil e no mundo
estão experimentando essa nova forma de lidar com
mudanças e estão colhendo ótimos frutos.
Infelizmente alguns líderes da comunidade Agile
(especialmente alguns da comunidade Scrum) ainda
não compreenderam completamente este novo paradigma e costumam diminuir o Kanban, ou espalhar
“FUD” (do inglês fear, uncertainty and doubt – medo,
incerteza, dúvida), ou pregar que Kanban é inadequado para trabalhos criativos. Alguns até dizem que
Kanban é difícil e requer muita maturidade, algo que
este artigo prova o contrário. Não há qualquer evidência que prove essas teses. A ciência por trás do
Kanban é bem fundamentada e temos diversos casos
que sustentam o uso de Kanban na prática nos mais
diversos cenários.
/referências
> Um pouco sobre Virginia Satir - http://en.wikipedia.org/
wiki/Virginia_Satir
> Entrevista com Bruce Lee - https://www.youtube.com/
watch?v=w4lYLwVWD_k
> VersionOne, ANNUAL STATE of AGILE DEVELOPMENT
- http://www.versionone.com/state-of-agile-survey-results/
> Tom Wujek – 3 modos pelos quais o cérebro cria
significados (selecione legendas em Português) - http://
www.ted.com/talks/tom_wujec_on_3_ways_the_brain_
creates_meaning.html
> David J. Anderson, Kanban – Mudança evolucionária de
sucesso para seu negócio de Tecnologia
> Entrevista com Gloria Mark sobre Custo com Troca de
Contexto - http://www.fastcompany.com/944128/workerinterrupted-cost-task-switching
> Lista de discussão sobre Kanban em Português: http://
br.groups.yahoo.com/group/kanbandev-br/
> Mais conteúdos sobre Kanban: http://blog.aspercom.com.
br/category/kanban/