Straw man (part II)
I have received a link of this article by e-mail: http://agilemanagement.net/index.php/Blog/thoughts_on_how_kanban_differs_from_scrum/ and to me there are many straw man arguments in there.
I´ll do something I rarely do which is to go over the arguments almost one by one to show the fallacy in them.
1. There is a statement about the control mechanism. In Kanban it is the WIP and in Scrum it is commitment.
Straw: This is just a mix of oranges and apples. The equivalent of the WIP in Scrum is the SprintBacklog and not commitment.
While Kanban bases its cycle of feedback on the execution of batches of work (the WIP), Scrum bases on time, the time box of the Sprint.
2. Within this argument, Kanban is quoted as capable of having a scientific and objective way of improving while for Scrum it is said “let´s just accept that it works”.
Straw: This is just no argument at all. Uses authority to propose that one works because it is scientific and the other is accepted to work in a demeaning way.
3. In the same area of the article, there is misdirection on the proposed 3 questions of the daily Scrum. The questions are redirected as being “What will you do for US today?”
Straw: The 3 questions promote transparency. They are not answered simply as a commitment to others. In first place, the commitment in Scrum is to yourself, and to creating a good product for you, this is a commitment to making your own job and life fulfilling.
4. Also there, the “second commitment” is stated as leading to feedback when the commitment of the Sprint is not met.
Straw: The process of feedback happens always. The commitment of the Sprint is a way of getting people to focus and propose a healthy challenge. Meeting the commitment of the Sprint is coincidental and the main point on using empirical control. After a few Sprints, the particular solution to that particular problem is much more known, and the tendency is that the team gets the commitment right, but in the big picture, this is not the point and not how the feedback and improvement process in Scrum works.
5. It says that Scrum is a revolution while Kanban is evolution and says that Scrum fails because it changes too much.
Straw: This is probably the main line of the article, and also the easiest to answer. The problem with this argument is that if you map the process and start evolving it you still have a defined process.
And we all know that with a defined process you don’t get the benefits of using an empirical process control.
For making software, a very complex problem, evolving a process is not good enough.
In this sense, a revolution is necessary to have actual improvement. Without changing from a process (whatever process) to no process, no real improvement will be gained.
On the impact argument, it may be very painful or less painful, a more or less paced adoption, in any case, to learn how to adopt Scrum with less impact and do a “controlled revolution” people should at least study how to do it a little.
6. The statement is that if you deviate to the textbook definition you are a “Scrum-Butt” and that this discourages innovation.
Straw: This one gets half points because the Scrum-But term is demeaning (intentionally or not). It does not get points on the innovation part of the argument. The set of rules for Scrum are very, very simple. If you cannot follow this simple set of rules, it is probably because there is something wrong in the way you currently work. It is your current process that is resisting change, not Scrum that is resisting change.
If the scenario was: after using Scrum for 2 years and working out that pain, we decided to add another role such as The Cleaner, then this argument could stick. That’s not the case.
7. Kanban uses 5 seed properties to catalyze emergent behavior of process evolution.
Straw: emergent behavior (from Chaos theory) cannot be sought. If it is sought, it is not emergent. That is in the definition of the term. If Scrum promotes emergent behavior is just because when using it emergent behavior happens to appear. It is not designed to do that. It is empirical. Kanban may have the same effect but that is not planned.
Closing thoughts: If Ken Schwaber had not used the kanban board in Scrum or had used it and called it Rugby Team Board we would probably not be even talking about this.
Kanban as a philosophical way of living (from Taiichi Ohno, not kanban, the message and visibility system) is only lightly touched by people talking about Kanban in the software engineering community.
If you use Kanban as described in the article, you are in the path of using an evolving, but defined process. It may be a lot better than waterfall, but misses the point of Scrum entirely. Mind that there are many Kanban definitions for software out there.
If you use Scrumban (mostly the same as Scrum without the time box) you just end up discussing if a time box is beneficial or not. The process control should still be empirical.