The point of this blog is to demonstrate that making things simple helps becoming agile (i.e. helps bring back common sense to what you do). Slight glitch: making things simple is a different kettle of fish than taking the easy option. Simple is not Easy!


Project Noise Level: iterations to make it simple (based on Ralph Stacey diagram):

Looking at what Mike Cohn and Ken Schwaber’s project noise level (from,

Project Noise Level

It took me a while to understand this slide (ok, I did not pay attention to it first).

I am interpreting it that way: if you can make things simple around you, then you can be agile: you have to reach simplicty to know what you are doing – we are not as good as we think to handle complexity.

Scrum is made of short sprints forcing a team to break down requirements and technology simple enough to deliver a product increment.

As De Vinci said “Simplicity is the ultimate form of sophistication”

So Simplicity could be a path to agility, not an easy path!


A Real life example that saves time, lots of it:

Just about 2 years ago, we set up a 3-day workshop to capture user stories with our customers. Our supplier did attend this workshop. For each story we created, we added a few (1 to many) acceptance criteria using specification by example (Given/When/Then/And/But model). It did work great because even for the user stories that initially looked obvious, adding an example showed that there were still misunderstanding between participants about what the stories were about.

An example was (along the line):

As a driver, I want to get directions to a city in another country so I can travel to that city

GIVEN I am in France AND my system is in French

WHEN I say “go to Brussels, 123 main street”

THEN the system says “I did not recognise that – please try again”

The reason the system does not recognize an address abroad: this is a technical limitation that the supplier of the system raised. The customer had forgotten this limitation.

Bottom line, adding one (or more) true example to a story avoids misunderstanding to a great extend (see Ron Jeffreys on User Stories)

That “specification by example” does is making the story simple to understand. Even a story well written may not be concrete enough hence having an example makes obvious what we want to achieve (and also generate discussions).

We also know what that agile architecture principles like to “keep it simple stupid”.

So if you make things simple (and this is hard), then can you become agile?


Last but not leat, these are De Bono principles to simplicity:

  1. You need to put a high value on simplicity
    To get simplicity you have to want to get it. To want to get simplicity you have to put a high value on simplicity.
  2. You must be determined to seek simplicity
    People quite like simplicity if it does not cost anything but are usually unwilling to invest resources in making something more simple.
  3. You need to understand the matter very well
    If you do not seek to understand a situation or process, your efforts will be ‘simplistic’ rather than simple. Simplicity before understanding is worthless.
  4. You need to design alternatives
    It is not a matter of designing the ‘one right way’. It is more a matter of designing alternatives and possibilities, and then selecting one of them.
  5. You need to challenge and discard existing elements
    Everything needs to justify its continued existence. If you wish to retain something for the sake of tradition let that be a conscious decision.
  6. You need to be prepared to start over again
    In the search for Simplicity, modify if you can – start afresh if you cannot.
  7. You need to use concepts
    Concepts are the human mind’s way of simplifying the world around. Warning: If you do not use concepts, then you are working with detail.
  8. You may need to break things down into smaller units
    The organisation of a smaller unit is obviously simpler than the organisation of a large unit. The smaller units are themselves organised to serve the larger purpose.
  9. You need to be prepared to trade off other values for simplicity
    A system that seeks to be totally comprehensive may be very complex. You may need to trade off that comprehensiveness for simplicity.
  10. You need to know for whose sake the simplicity is being designed
    A shift of complexity may mean that a system is made easier for the customer but much more complicated for the operator.