Reading Scrumban: Essays on Kanban systems for Lean Software Development
I’ll be honest. I didn’t enjoy this book. Nevertheless, there are a lot of interesting ideas on it, enough to recommend its reading.
In the introduction, Corey Ladas resumes his book as a critic to the so called “old Agile methodologies” and presents his own work not only as the new proposal being different, but as the finest paradigm for software development. Reading further seems that the one Agile methodology that the author knows is XP, I guess he knows a lot more, but the only one he talks about is XP. I find difficult to criticize the Agile movement taking only a very partial sample as XP.
The Agile movement is more than a single methodology, but a form of thinking and living software development. You can be an old fashioned Agile developer or a vanguardist one, but Agile the same. The “costume” is a matter of personal and team preferences.
Scrum-ban is just another strategy of organizing workflows that indeed seems to be a good one, but present it as an anti-pattern for Agile is absurd and by no means necessary.
Scrum-ban takes almost everything from Kanban, a methodology more focus on product development than software. The main idea is to enforce auto-control of the workflow by the team using a quite simple pull system.
The attractive of Kanban and Scrum-ban is their simplicity of implementation. You can become your team a Srum-ban team even if this is your first experience with Agile methodologies with no sophisticated tools or an extensive knowledge.
The protocol of Scrum-ban is inherited from Scrum, but evidently you can be as protocolary as in XP or as free as in Crystal. In fact, Scrum-ban tries to reduce the protocol in Scrum reducing the time that meetings require. This protocol reduction leaves you in a scenario more alike to Cockburn’s self-made methodologies, which is my personal election, to have a self-made Agile methodology with a Srcum-ban pull system.