![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
qatsiBook Review: Kanban – Successful Evolutionary Change for Your Technology Business, by David J. Anderson
A re-read of this after several years. In 2015 I was joining a team that used Kanban and I wanted to find out more about it. This time I am in a team that is experimenting with Kanban, partly at my advocation. Some of what I wrote then, I still agree with, but in other aspects I am inclined to disagree. I'm not going to say that the CMMI model is entirely discredited, but I do think that most organisations probably over-estimate their maturity, and like ISO9001 and its ilk, having and adhering to a process does not automatically make that a good or practical process. In the current situation, my main motivation for moving to Kanban is in fact the lack of maturity, the continual incapability to align work into two-week sprints; I feel we need a more natural cadence of just "whenever it's right" to pull in more work and deliver predictably. Additionally I think that Kanban works well with continuous delivery, and with DevOps; for the latter, the "class of service" idea espoused in the book is potentially useful. As a team we are also going to need to be careful about work-in-progress limits, but reorganising our board has already revealed a handful of tickets that were started at some time in the past and have never been completed.
A re-read of this after several years. In 2015 I was joining a team that used Kanban and I wanted to find out more about it. This time I am in a team that is experimenting with Kanban, partly at my advocation. Some of what I wrote then, I still agree with, but in other aspects I am inclined to disagree. I'm not going to say that the CMMI model is entirely discredited, but I do think that most organisations probably over-estimate their maturity, and like ISO9001 and its ilk, having and adhering to a process does not automatically make that a good or practical process. In the current situation, my main motivation for moving to Kanban is in fact the lack of maturity, the continual incapability to align work into two-week sprints; I feel we need a more natural cadence of just "whenever it's right" to pull in more work and deliver predictably. Additionally I think that Kanban works well with continuous delivery, and with DevOps; for the latter, the "class of service" idea espoused in the book is potentially useful. As a team we are also going to need to be careful about work-in-progress limits, but reorganising our board has already revealed a handful of tickets that were started at some time in the past and have never been completed.