This post originates from reading this excellent article: The philosophy of Kanban is Kryptonite to Scrum. I have not implemented Kanban. I haven’t had the opportunity to date (that should happen soon), but please take this article with a grain of salt as I don’t have field feedback on this subject.
My problem:
- Scrum and agile methods are experiencing exponential success at the moment: just take a look at Google Trends…
- IT service companies want to get their piece of the pie, businesses are rushing into it
- It’s not easy for IT service companies or businesses to implement Scrum for -in my view- two main reasons: contractualization, team stability/sustainability (the third would be “accountability” of the product owner, and therefore of the client whoever they may be)
Reading the article cited above, I think that the solution may perhaps lie in Kanban. It doesn’t solve the contractualization question but it can solve the team stability one. Why? Scrum brings a lot of flexibility in response to a project’s needs, but it doesn’t necessarily introduce much flexibility within the organization. It requires a strong and constraining ritual: sprints, daily scrums, retrospectives, all organized around a very stable and highly involved team. For an IT service company (or a business) this isn’t so simple to implement. Rare are the moments when a team can actually devote itself entirely to its sprint. Rare are the projects where a person/external event doesn’t come along and disrupt the schedule, the priorities. Kanban proposes a less rigid framework (oops, would Scrum agile method be rigid, no don’t make me say that), in any case it proposes fewer recommendations on the one hand (to use Henrik Kniberg’s terms (see the links below)), and doesn’t subject it to timeboxes and a regular ritual (stand up, etc.). But Kanban’s cycle differs from Scrum’s velocity. Kanban’s rhythm/“flow” seems much less constraining to me. Scrum’s velocity is paced by the ritual, highlighted by the burndown charts, we must respect the iteration: if a user story isn’t completed at the end of the sprint it won’t appear in the demo, it was off-rhythm and therefore excluded. Whereas Kanban -it seems to me- will be more docile: we deduce the rhythm from the facts, we don’t submit to it.
In short, the exercise of following Scrum’s rhythm is not easy, I repeat myself, hence also the importance of sensitizing management to respecting the rules of a Scrum project. My point is also to say that sometimes it’s not possible and that it might be better to turn towards Kanban instead (without opposing the two, in which I’m only repeating what the article cited above explains much better).
Another point that leads me to mention Kanban, it’s possible (double conditional, reverse gear…) that I may be called upon to coach teams composed of 1 to 2 people in the near future. With 1 person Scrum loses its substance… We simply find ourselves in hero mode (hear ye CMMi level 1…), hoping that this solo actor has a good understanding of IT project management, the tools they can implement, etc., but no question in my mind of doing a daily stand up alone, especially if a second person comes episodically to complete the team.
Here again Kanban with its -apparently- simpler approach, and much less ritualized, may perhaps be able to meet this need. By introducing a simple Kanban “radiator” I can initiate rhythmic project management, I don’t have a sprint to respect, I can introduce a second person episodically. In short I repeat myself: I can pace the project more simply and where there’s rhythm, there’s workload and planning and therefore indicators and forecasts, etc.
To finish and to remind once again, I haven’t yet implemented Kanban unlike Scrum, excuse me in advance if I’m saying things here that seem crude to you Kanbanmasters (?). I simply want to highlight why Kanban would be an interesting avenue. I detect two: impossibility of applying Scrum’s ritual and guaranteeing team stability, one often being the corollary of the other.
Another very interesting article: Kanban and Scrum a practical guide and especially the associated PDF that compares Scrum to Kanban, the one with the quote from Myamoto Musashi, …