Simplicity — the least understood Agile Principle

“Simplicity — the art of maximising the amount of work not done — is essential”

This, you may recognise, is one of the Principles behind the Agile Manifesto, and it is almost certainly the least understood. I’d like to cover this topic in two separate points — simplicity on its own, and the rest of it afterwards.

Simplicity we understand, don’t we? Well, apparently not. In agile development terms it means understanding a requirement and building the simplest solution that might meet that requirement, and then if necessary, incrementally building upon it until the customer is satisfied. Too many teams want a detailed description of the requirement and spend way too long building it, only to find that it misses the mark.

There is nothing so wasteful as doing with great efficiency, that which should not be done at all.

Now let’s address the rest of that principle — maximising the amount of work not done. It’s apparently an oxymoron — maximising what you don’t do sounds illogical and a contradiction. And yet…

The best explanation I have ever found for this principle can be found in Jeff Patton’s book User Story Mapping. In it, Jeff describes how what development teams should be focussed on is the desired outcome. This, incidentally, is why development teams need direct access to real customers whenever and wherever possible — to fully understand the desired outcome… “why do you want that report?”

Focussing on the why gives the team an objective — a need — rather than a specification. It allows the team to negotiate how that problem is solved, for there are often different ways of achieving an outcome. It also allows the team to focus on simplicity and — here’s the critical bit — doing the least amount of work possible in order to achieve the outcome.

Doing the least amount of work — writing the least amount of code — has a number of other benefits. The less code you write, the fewer mistakes you are likely to make and the fewer bugs you are likely to find later. The simpler the solution, the easier it will be to find those bugs too, even by someone else, and the quicker it will be to fix and retest. It is a virtuous circle.

So, in short, make sure you understand the reasoning behind the requirement — the desired outcome — write the least amount of code that could possibly meet that outcome, obtain feedback, and then incrementally and iteratively improve and extend it until it does, all the while making it as simple to understand and maintain as possible.

Simplicity — the art of maximising the amount of work not done — is essential.