16
[Off Topic] Cuidado com o Kanban-butt
on December 16, 2009
Por alguma razão, recentemente muitos tem discutido e evangelizado sobre Kanban. Isso está ficando particularmente irritante pra mim. Muito cuidado: apenas aplicar a ferramenta Kanban, como se fosse uma metodologia, não é certo. Essa ferramenta foi criada e difundida pela Toyota, décadas atrás, dentro de uma metodologia maior conhecida como Toyota Production System (TPS), criado pelo grande Taiichi Ohno.
Como eu disse num artigo anterior, as metodologias ágeis tem a mesma fundação. Para entender o TPS é bom retornar à literatura original e uma dessas fontes é o livro O Sistema Toyota de Produção, do Ponto de Vista da Engenharia de Produção, de Shigeo Shingo, publicado em 1996. No Prefácio ele diz:
Muitos acreditam que ao implementar um novo sistema, somente “know-how” é necessário. No entanto, se você quer obter êxito, você deve entender, também, “know-why”
Com o know-how, você pode operar o sistema, mas você não saberá o que fazer no caso de encontrar problemas sob condições diferentes das usuais. Com o know-why, ou “sabendo o porquê”, você entende por que você tem de fazer o que está fazendo e assim enfrentar situações de mudança.
Especificamente sobre Kanban ele diz:
O maior problema encontrado enquanto estudava o TPS do ponto de vista de Engenharia de Produção é o fato de ser frequentemente considerado como sinônimo de sistema Kanban. O sr. Ohno escreve:
* TPS é um sistema de produção
* O método Kanban é uma técnica para sua implementação
Muitas publicações são confusas nessa questão e oferecem uma explicação do sistema, afirmando que o Kanban é a essência do TPS. Uma vez mais: O TPS é um sistema de produção e o método kanban é meramente um meio de controlar o sistema.
Análises superficiais do TPS dão especial atenção ao método kanban devido às suas características únicas. Consequentemente, muitas pessoas concluem que o TPS é equivalente ao método Kanban.
Um método Kanban deve ser adotado somente depois que o sistema de produção em si tenha sido racionalizado. Esse é o motivo pelo qual este livro insiste repetidamente no fato dde que o TPS e o método Toyota são entidades separadas.
Devo acrescentar que 90% do excelente desempenho gerencial da Toyota foi atribuído ao TPS em si, e apenas 10% ao método Kanban – uma clara demonstração da maior importância do TPS.
Relembrando: Shigeo escreveu isso em 1996. Impressionante como mais de uma década depois ainda estamos cometendo os mesmos erros de interpretação.
Assim como no Manifesto Ágil, o Sistema Toyota também tem um conjunto de 14 princípios, conhecido no Ocidente como The Toyota Way. Também assim como em Agilidade, não basta fazer Sprints, colocar post-its na parede e dizer que é Ágil. Para seguir o método Toyota, não basta usar Kanban.
Para entender Toyota, é obrigatório entender o Toyota Way e um dos melhores livro para começar a entender isso é o The Toyota Way, do Jeffrey Liker. Além disso, se você realmente está interessado e pretende levar a sério, precisa entender o que foi a revolução gerencial da Toyota narrado no livro clássico The Machine that Changed the World, de James Womack.
Se ainda não está convencido, ainda no livro de Shigeo Shingo, na conclusão do capítulo sobre Kanban ele diz:
Os sistemas Kanban podem ser aplicados somente em fábricas com produção repetitiva. (…)
Os sistemas Kanban não são aplicáveis em empresas com produção sob projeto não repetitivo, onde os pedidos são infrequentes e imprevisíveis.
O tipo de produção que com maior probabilidade se beneficiaria do Kanban, é aquele que utiliza processos comuns de transformação dos materiais.
Como dica: desenvolvimento de software é uma tarefa não repetitiva. Ainda assim, os princípios do TPS ainda são muito aplicáveis se o know-why for claramente entendido.
O método Toyota é mais genericamente conhecido como Lean Manufacturing. O melhor trabalho adaptando Lean ao mundo de software é o livro Lean Software Development, escrito pelo Tom e Mary Poppendieck. Antes de falar levianamente em Kanban, é obrigatório ler esses trabalhos, de outra forma será apenas mais uma ferramenta que vai falhar e teremos uma onda de Kanban-butts.
Tudo que vem fácil vai fácil. “Parece” fácil implementar Ágil. “Parece” fácil implementar Kanban. Não existe almoço de graça. Leve as coisas de forma superficial e não espere nada além de resultados medíocres. É assim que as coisas funcionam.
Acho que vivência e leitura contínua (e bem feita) nos levarão a ser cada vez melhores, e as suas dicas de leitura estão me ajudando a melhorar.
Parabéns e obrigado pelas dicas...
O ebook se encontra disponível em: http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
Agora, em se entendendo os know-why, em se avaliando as circunstâncias, em se entendendo que se está, por exemplo, num cenário onde você tem histórias razoavelmente de mesma complexidade, talvez faça sentido aumentar o "flow" diminuindo o WIP (work-in-progress). Isso pode ser feito tanto dentro de um Sprint mesmo, ou substituindo o mecanismo chamado Sprint por outro mecanismo que se assemelha ao que se chama de "Kanban".
Mas, novamente, não existe Scrum vs Kanban. Lembrando o know-why, tirar o Sprint significa tirar bastante coisa: não há mais Sprint Planning, não existe Spring Backlog, e Spring Review e Sprint Retrospective ficam comprometidos, além disso perde-se Burn Down e com isso não se sabe mais o Velocity da equipe.
O Henrik tem soluções para muito disso: em vez de Velocity você tem Lead Time. Mais uma vez isso funciona melhor se as histórias forem previsíveis, por exemplo, tickets de manutenção. Por isso muitos falam que Kanban funcionaria bem em cenários de manutenção. Mas a raíz do problema é: porque você teria tantos tickets de manutenção assim? O que deu errado no começo do processo para se ter tanto bug a ponto de precisar de um processo inteiro para corrigí-las?
Agile em geral fala em Cross-Functional Teams, o Henrik flerta com a idéia de permitir Specialist Teams. Não existe "proibição" quanto a isso em Agile, mas o "porque" de se focar em Cross-Functional é justamente para "agitar" mais as equipes, permitir idéias diferentes, novos aprendizados e, tornar menos difícil o caminho para auto-organização. Se todos da equipe são especialistas na mesma coisa, a comunicação tende a diminuir, a colaboração tende a diminuir, cada um tende a pegar seu montante de trabalho, executar e ir embora, as discussões são menos ricas, etc.
O Henrik diz que Scrum não permite adicionar novas histórias em um Sprint já em andamento. Mas não existe de fato essa proibição. O ideal é não adicionar, mas nada impede um PO de pedir uma história urgente, negociar com a equipe e a equipe aceitar. Um Sprint é um compromisso da equipe com os stakeholders. Se a equipe achar que cabe, é porque cabe. Além disso esse tipo de episódio deveria ser raro, os Sprints deveriam ser curtos (menos de 2 semanas, na média). Será que existe tanto incêndio assim que precisa alterar o Sprint Backlog o tempo todo? Se existir, a raíz do problema não é o Sprint e sim "por que o que era prioritário 1 semana atrás já não é mais?". Mais uma vez, a raíz é mais embaixo.
Uma das idéias de qualquer metodologia Ágil é expor problemas na organização. Uma das coisas que todo agilista vai dizer é que tudo aquilo que ia para debaixo do tapete vai aparecer. O que estamos fazendo quando se fala em Scrum vs Kanban? É justamente que o Scrum expôs problemas, mas em vez de resolvê-los estamos procurando "técnicas" que minimizam esse problemas, como os exemplos que dei acima.
Nenhuma metodologia Ágil é restritiva, ela é um guia, um coaching. São feitos para ir do know-how para o know-why. Eu posso tranquilamente tirar um Sprint e colocar outra coisa no lugar e ainda ser Scrum, desde que os princípios sejam mantidos. Lembrando que o Manifesto Ágil tem 4 valores e 12 princípios, e a maioria das pessoas esquece dos 12 princípios. Lembram do último princípio?
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Resumindo, Kanban é uma técnica, assim como Sprint é uma técnica. Scrum é ume metodologia, assim como Lean é uma metodologia. Agile é um tipo de filosofia, assim como o Toyota Way é um tipo de filosofia.
A necessidade da busca por agilidade gerou um boom no mercado nos últimos anos, e todo boom é fruto de alguns especialistas incomodados com um problema ou uma necessidade, seguidos por um monte de oportunistas que só querem se promover nessa onda,e é neste segundo grupo que estão aqueles que pegam um pedaço do todo, fazem barulho em cima deste pedaçao (no caso em questão o Kanban), e por falta de massa crítica como esta que estamos nos propondo a ser aqui com o Akita ao escrever este post e nós ao comentarmos, é que estes caras vão contaminando o mercado com uma série de lixo em forma de palestras, blogs e etc. fazendo com que o conceito seja erroneamente apresentado e consequentemente mal compreendido.
Um texto fora do contexto é um pretexto, Kanban é uma ferramenta que sem os demais processos do Scrum e principalmente sem disciplina, não passa de uma losa com um monte de papelzinho colado, simples assim.
O que nós precisamos realmente fazer, é não perder oportunidades para por em cheque esses pseudos especialistas toda vez que nos depararmos com um post ou estivermos em um palestra apresentada pelos mesmos e na medida do possível, expor o quão errados eles estão na sua postura e tentar mostrar para o mercado que desenvolver software de uma maneira mais divertida, mais rápida e com mais qualidade atendendo a expectativa do nosso cliente é possível e não é difícil, é só fazer direito hehehehe
Ricardo P. Silva (rpsinfo)
ricardo@rpsinfo.com.br
Wow, seu comment ficou quase maior que seu post :)
Realmente, não tinha parado pra pensar nesse ajuste de premissas. Pesquiso sobre Agile há um tempo e vejo como Scrum pode (e deve) trabalhar com XP (inclusive, o próprio Henrik cita isso no primeiro livro dele).
Acredito que quando o Henrik cita manutenção, ele não quer dizer somente correção de bugs. Adição de funcionalidades pode ser feita por um time de manutenção, não? Assim como um bug não pode ser previsto, não há como prever que seu cliente irá querer algo mais. Há mais N coisas que um time de manutenção possa fazer além de consertar bugs.
Tá certo, agile foca em cross-functional teams. Mas uma das coisas mais notáveis que eu aprendi lendo o material do Henrik é a flexibilidade que as equipes tem. Eu tomei um susto quando vi a forma pragmática (sem entrar na discussão do termo) que ele desenvolvia software. Vendo por esse ângulo, por que não permitir Specialist Teams quando aplicável? Qual é o argumento dele pra isso?
Mas hein? Ele diz que não se deve adicionar novas tarefas no Sprint? Na própria capa do ebook dele, ele mostra um quadro de tarefas com uma área para "unplanned" e cita as não planejadas no decorrer do livro.
Mas enfim, valeu pela explicação :)