I am sure you have heard this argument over and over again: “I don’t like Agile because things get too confusing – It’s too chaotic.”

Indeed, this is such a powerful argument against Agile that many Scrum implementations turn out crazy contraptions with several control points and mixing so many archaic methods that they would make an Agile purist suicidal.

Chaos vs. Freedom

Scrum and Agile are not supposed to mean chaos. They mean freedom from inefficient artifacts. If these inefficient artifacts are forcefully squeezed into the process, it’s no surprise that Scrum will fail miserably. And it might even start to feel like chaos to those involved.

Part of this uncertainty regarding Agile is rooted in the very nature of Agile. Agilists expect things to change, to evolve, to transform; and they inherently reflect this anticipation in their way of working and understanding the product. Working on something that is not fully described is the core of Agile.

If you could design and think up front every little feature the market will need in a product, you would be a prophet.

Linear & segmented brainwashing

Working with uncertainty is hard for most people, because of our extensive brainwashing into thinking in terms of linear and segmented processes.

These are reflections of the old industrial age where everything had to be rationalized as in a factory: input – process - output. The process can be broken down into as many smaller sub-processes as one sees fit.

Agile and Scrum offer the same framework but go beyond: a series of feedback loops are added to make sure that what is being created is actually what needs to be created.

The feedback loops are not there for control purposes (even though they might lead to better control compared to archaic methods). They are there for evolution purposes. Or to what Agilists call “emergent features” – those features which can only be discovered while working towards solving a product problem.

In Agile features are discovered, not pre-defined

That is a big difference. The thing some people fail to understand (Agilists and non-Agilists alike) is that even though a product is not fully pre-defined we are still creating a product.

That is exactly what you read: the product vision should never be lost.

A product developed in Agile should be a far superior product than one developed in waterfall. If there’s very little difference between them or if your Agile product underperforms in comparison to the competition, there’s a lot of space for improvement.

Consider these as guidance:

  1. Agilists tend to forget about the product and focus too much on the current iteration or current tasks.
  2. Non-agilists tend to forget about the iterations and focus too much on the design and plans.
  3. Both are forgetting that a product is something that solves a problem to someone.
  4. If that problem is solved, means of monetizing it come naturally.

Things would go much smoother if we all could agree around these simple principles.