31st
Pourquoi le Kanban?
À notre passage au Agile Tour lundi dernier, nous avons assisté à la présentation de Benoit Lapointe, IBM Bromont. Ce dernier présentait leur façon de travailler au day to day avec l’approche Kanban.
Depuis le début de l’année, nous avons joué avec la métho Scrum, et en avons constaté des points positifs et négatifs chacun de notre côté. Lors de la présentation du Kanban, Marc (notre nouvel Architecte Senior) et moi avons vraiment eu l’impression que cette approche collerait mieux à nos processus de maintenance habituel et de priorités toujours changeantes.
Nous sommes donc en implantation du Kanban depuis mardi dernier. Comme l’implantation de n’importe quel processus de travail dans une équipe ne se fait pas sans douleur, j’ai décidé de partir à la recherche d’articles et de présentations écrits par du monde plus éloquents que moi et expliquant les “pourquoi” du Kanban afin de m’appuyer sur de bonnes bases pour vendre ma salade et aider tout le monde à mieux saisir les objectifs visés.
Henrik Kniberg a rédigé ce document que je suis en train de lire et qui me semble être la meilleure introduction :
Kanban vs Scrum – how to make the best of both
From his blog :
- Jim: “Now we’ve finally gone all-out Scrum!”
- Fred: “ So how’s it going?”
- Jim: “Well, it’s a lot better than what we had before…”
- Fred: “…but?”
- Jim: “… but you see we are a support & maintainance team.”
- Fred: “yes, and?”
- Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc….”
- Fred: “So what’s the problem?”
- Jim: “We keep failing our sprints”
- Fred: “Why?”
- Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?”
- Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
- Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints…”
- Fred: “Do your issues take less than a day to fix?”
- Jim: “No, they sometimes take several days”
- Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
- Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
- Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
- Jim: “So what should we do then?”
- Fred: “Have you heard of Kanban?”
- Jim: “What’s that? What’s the difference between that and Scrum?”
- Fred: “Here, read this article!”
- Jim: “But I really like the rest of Scrum though, do I have to switch now?”
- Fred: “No, you can combine the techniques!”
- Jim: “What? How?”
- Fred: “Just read it…”
Je vous conseille aussi cette présentation. Elle couvre plusieurs aspects du Kanban.
http://alissonvale.com/downloads/Kanban%20Development%20and%20The%20Paradigm%20Of%20Flow.pdf
Merci Benoit!
Je vais y jeter un oeil!
Très intéressant!
Je suis tombé sur cette citation de Corey Ladas dans la lecture proposée par Benoît ci-haut, et qui est selon moi excellente :
Why pull? Why kanban?
“People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy.”
(…)
“Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.”