O que aprendi auxiliando

Transcrição

1 agilidade_ O que aprendi auxiliando Como práticas do método Kanban podem ajudar a sua empresa a ganhar mais agilidade. Rodrigo 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 Você é 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 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. / 30

2 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 \

3 capacidade Evolução Kaizen status quo Figura 1. Tamanho da Mudança (Kaizen x Kaikaku). Evolução Kaikaku TEMPO 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 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 / 32

4 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 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: Se encontrar resistência emocional, crie um sistema onde os problemas fiquem visíveis, e engaje emocionalmente as pessoas na mudança. David J. Anderson As armas que temos para lutar contra a resistência emocional das pessoas não são argumentos lógicos, mas sim, argumentos também emocionais. A visualização do processo que explicarei adiante é um desses argumentos emocionais. É importante ressaltar que com o tempo é esperado que o desgaste da água fará as pedras rolarem colina abaixo. Evitar as pedras simplesmente é respeitar a velocidade com que as pessoas assimilam as mudanças. Como eu disse, as pessoas são os elementos ativos e responsáveis dentro de um sistema de trabalho do conhecimento. Tentar derrubar as pedras prematuramente pode minar todas as iniciativas de melhoria, causando as pessoas reagirem sempre negativamente. Essas duas primeiras lições deste artigo: mudar de forma evolucionária e contornar as pedras, já foram acusadas de serem lentas demais, especialmente 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 Kanban na sua equipe, e assim, começar a jornada de melhoria do seu processo de forma fácil e rápida. Essas três práticas que vou apresentar visam criar um ambiente inicial para que eventos Kaizen sejam ao menos discutidos. O Kanban e a filosofia Lean têm outras práticas e técnicas importantes que não estão cobertas neste artigo. Prática 1: Visualizar o Fluxo Muitas das práticas que estou descrevendo aqui são a base de conhecimento que emergiu da comunidade Kanban na área de TI. Com grande influência da Teoria das Restrições [Goldratt], do Lean/Toyota Production System [Ohno], do Agile, do Lean Product Development [Reinertsen] e do Systems Thinking, essa comunidade cresceu em número e em cases de sucesso ao redor do mundo nos últimos 8 anos. Devo também destacar que a comunidade brasileira é uma das mais fortes e influentes do planeta! Para começar a aplicar Kanban e iniciar a evolução do seu processo alguns passos Kaizen muito 33 \

5 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 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 / 34

6 Figura 3. Quadro Kanban com Limites. 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 os limites a tendência do trabalho ficar parado será menor e a visualização fará a equipe colaborar para que as demandas fluam com mais rapidez para o fim 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. Prática 3: Reunião Diária Colaboração é primordial em qualquer tipo de trabalho onde um grupo de pessoas está pensando para tentar entregar valor para alguém. A reunião 35 \

7 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. 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 - wiki/virginia_satir > Entrevista com Bruce Lee - watch?v=w4lylwvwd_k > VersionOne, ANNUAL STATE of AGILE DEVELOPMENT - > Tom Wujek 3 modos pelos quais o cérebro cria significados (selecione legendas em Português) 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 - > Lista de discussão sobre Kanban em Português: br.groups.yahoo.com/group/kanbandev-br/ > Mais conteúdos sobre Kanban: br/category/kanban/ / 36