Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

[Kanban] Kickback ou Stop the Line

5 maio 2019 | Kanban

TAG:

Pergunta: Estou ajudando um projeto e surgiu uma questão sobre Kanban e queria uma opinião sua. A questão é sobre dar kickback em uma história em validação onde um bug é encontrado. Na discussão da equipe, teve gente dizendo que no kanban não se pode dar kickback. Fiz uma pesquisa na internet e vi que esse é um assunto bem polêmico e há pessoas que advogam que não se pode fazer um kickback e há pessoas que adaptam o processo para que possa ter sim kickback. Qual tua opinião sobre isso? por Rafael Lima

Resposta: Na Toyota (de onde vem a inspiração do Kanban) não tem o kickback. Lá é a famosa frase: “Stop the line”.

 

O David Anderson recomenda não fazer kickback. Se achou um problema, vai lá e resolve, sem voltar a história para uma etapa anterior.

Eu prefiro fazer um kickback (demonstrado na imagem acima) e colocar um post-it vermelho com a descrição do motivo (do problema encontrado).

 

Eu gosto da expressão “Stop the line” e o que ela representa, mas trabalhamos com software, não manufatura. Não temos uma linha de produção como na indústria manufatureira. Por vezes fazer o kickback (ex: a história com problemas volta para a etapa In Dev- pois precisa da atenção de uma desenvolvedora) dá melhor visibilidade ao estado atual do fluxo de trabalho do squad. De qualquer forma, a ação será a mesma: uma desenvolvedora vai ter de resolver o problema.

 

Mas a principal discussão da equipe deve ser em relação a prioridade e o limite WIP.

 

Um problema encontrado deve ser prioridade! Pare de começar e comece a terminar.

Pare de começar e comece a terminar.

Logo uma história com um post-it vermelho deve ter prioridade alta e ser tratada logo (seja com kickback ou não).

 

Agora o outro ponto: se uma pessoa desenvolvedora está trabalhando em um problema, isso afeta o WIP (aumentou o trabalho em uma unidade). Se esse aumento estourou o limite, a equipe tem de conversar para ou (1) não começar algo novo até o limite se restabelecer ou (2) parar o trabalho de menor prioridade.

Paulo Caroli

Paulo Caroli is an author, speaker, and consultant specializing in agile transformations, Lean Inception, and OKRs. With over 30 years of experience—including nearly a decade in Silicon Valley and 18 years at ThoughtWorks—he has helped organizations transition from project to product and from strategy to execution. Creator of the Lean Inception methodology and author of bestselling books like Lean Inception and Team OKR, Paulo is dedicated to empowering teams to align, validate, and deliver real business value.
Kanban e CFD

Kanban e CFD

Confira a seguir dois quadros Kanban com seus respectivos CFDs (Diagrama de Fluxo Cumulativo, ou Cummulative Flow Diagram, em Inglês), uma valiosa ferramenta de gestão para (1) acompanhar o progresso de itens de trabalho, e (2) verificar a necessidade de melhorar o...

ler mais

Pin It on Pinterest