Posts Tagged ‘Ken Schwaber’

Straw man (part II)


Straw man (part II)

I have received a link of this article by e-mail: 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.

Scrum Gathering Lectures Part I


In this post I continue my comments on the lectures I attended to at the “Scrum Gathering 2009 Brazil”.

  • Scrum e a crise mundial: Por que Scrum é a melhor opção para projetos em tempos de crise  – Rafael Sabbagh PUC Rio and Marcos Garrido – Palm I (Morning Session of the 12th)
       The presentation seemed closely related to the future dissertation of Rafael Sabbagh and Marcos Garrido, both doing their Masters in PUC Rio. The main line was that Scrum is easier to sell to clients in times of crisis, and this is a particular good time to do that.   On the good side, it was one of the few presentations with low demand on the knowledge of Scrum from the people watching. The bad, in my opinion, was that the presentation did not really define itself as being directed to clients or as being directed to the sales force. I also missed the traditional graphic with the ROI over time.


The early delivery of value by using Scrum.   

The early delivery of value by using Scrum.

   I also think that the theme itself is very relevant but kind of bold because the presenters are not from the sales department. As a personal, very personal choice, I would not dare do this without most of the slides coming from the commercial department.
   After the presentation the discussion was very good, and kept going and going, no one wanted to leave the room.

  • Keynote Address – Ken Schwaber, co-founder Scrum & President Scrum Alliance – Grand I & II (Virtual Presentation)
       It was one of the usual presentations from Ken Schwaber. Usual to him, awesome to the rest of us! The crowd went wild when in a question (pinning Ken versus the PMI presentation earlier) where Ken answered that the project was done by the ProductOwner, ScrumMaster and the Team, so, there was no place for a Project Manager. 
       Of course the ScrumMaster is a Project Manager, but it was a great stunt that few are capable of pulling out. There was lots of cheering in the audience here.
    We also did the command & control exercise following Ken’s instructions. It was done to illustrate the power of self-management, and this often gets me thinking that at the end of the day Ken is all about being ethical in the workplace. The exercise itself was kind of awkward because most of the audience had done it already. 
    Bottom line, if you get the chance to see him speaking, don’t miss it. It’s simple, not pretentious, very valuable and, to some extent entertaining.

  • Usando DoD (Definition of Done) para amadurecer a qualidade do produto  – Gustavo Coutinho, Provider, e Luciano Felix, CSP Especializa Treinamentos – Palm II
       This presentation was about the Definition of Done and it’s correlation to the technological deficit created during the execution of most projects. The approach of the presentation seemed to follow the actual thinking process the guys at Provider Sistemas went through it respect to the DoD.
       It makes it look tough, like the Definition of Done became a major item for them as can be seen on slide 31 with DoD at the center of the Scrum Activities. My view is that they like this part of Scrum best and it really works for them.
       In the presentation there is a suggestion of DoD multi-levels where there are requirements for the tasks, the Sprint and the Release. My view is that the DoD levels referring to the Sprint and the Release should be tasks, and enforced by the ScrumMaster because it relates to the company culture. Generally speaking, these are technological deficits that they think make sense grouping by each Sprint or Release. This is the case of a full integration of the software where they might do it only once in a Sprint.
       In any case, my observation does not mean any change in the actual tasks, only on how to call them because they “made up” a new taxonomy where as in my view there was no need to (If it works, that’s what matters).
       On the second part of their presentation, they introduce one group dynamics exercise designed to find out good items for the DoD for a project or as standards for a company. It’s really worth a look. Check out their presentation on the link above.