Posts Tagged ‘emergent’

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.

What does it really mean to be self-organizing and self-managed in a Scrum Team and why is that important?


Strictly speaking, a self-organizing system is one where the complexity of the system increases without being guided or managed by an outside source. Usually emergent properties can be observed.
The emergent property is a pattern that arises out of simple interactions within the system.
Self-organization spawns into several different concepts for different areas of knowledge. You can talk about it in Math, Chemistry, Linguistics or in Human Society.
Scrum is inserted in a subset of the self-organization principle within the Human context. The idea of not influencing the Team and allowing it to self-organize is based on the notion that emergent properties for the Team can improve the probability of success in a project.
In Scrum, avoiding external influences creates room for creativity and synergistic behavior. At the same time, periodic feedback influences the Team in the direction of the Product Owner’s vision, and both are the basis for a more flexible response to the difficulties presented in a project.

Increased chance of success by the use of Scrum

Increased chance of success by the use of Scrum

The concept of self-management in Scrum comes directly from the social context in work related matters. Worker councils, worker co-operatives, participatory economics and many other human work situations where the presence of a boss is lessened or dismissed entirely relates strongly to the origin of the concept in Scrum.

It seems to me that the founders of the Agile movement and of Scrum were much more capable and knowledgeable than their managers in the many projects they were involved in. This frustration led to studies on many aspects of group dynamics, and many of those principles were incorporated to the basis of these frameworks.

In software, it is not uncommon that the manager knows less about building software than the team members. Almost always the manager knows less about it than the collectiveness of the group.
The Team knows how to build software, and the manager does not. So, when establishing a command and control process within these conditions, the manager will undoubtly get in the way of the success of the project.
Under this line of thought, self-management becomes an obvious choice because you allow people who know how to do the job go on and do it. There is also the bonus that you might get synergy and emergent behavior.

Scrum does not propose a strict sense of self-organization or self-management. The Team is governed by rules that serve an external purpose. They have to follow the Scrum rules, they have to generate value to the client and they have regular feedback.
The Scrum team has a manager. The ScrumMaster is a manager with authority to enforce policy. The ScrumMaster enforces the continuous feedback process and the proper use of Scrum. The ScrumMaster enforces adherent behavior to the “company’s culture” and is a constant checker of the accomplishment of the DoD.
The ScrumMaster should not impose, however, on the “software building” part of the management because he is not the one with the knowledge on how to do it.
The team is self-managed to build the software, not to do whatever they want.

Also, it must be clear that self-management in Scrum does not imply democracy, or voting, or any other particular form of collaboration within a team. The whole of the group dynamics area of studies should be explored to the advantage of the project.
In my ScrumMaster Certification, Ken Schwaber illustrated how the time ticking and the Sprint deadline were strong factors for deciding conflict, and there was no suggestion on voting or a specific form of conflict resolution. In that particular exercise, the decision was made by the one who said it first (like children calling it first).
What was emphasized was the importance of transparency and broadband communication at all times.

Anakin Skywalker: “Doing what the Jedi Council says, that’s one thing. How we go about doing it, that’s another. That’s what I’m trying to teach you, my young Padawan.” – “Star Wars: The Clone Wars” (2008)