The 12 Days of Agile Principles! Principle #10

Inspired by The 12 Days of Christmas we’re exploring the principles behind the Agile Manifesto. Originally defined in 2001, The Principles of the Agile Manifesto are still highly relevant to Agile approaches today. So like an advent calendar of Agility, we're unwrapping one principle each day for the 12 working days - Monday to Friday, leading up to Xmas. By the time we conclude we should all be in the festive spirit!

*****

Welcome to DAY 10 of ‘The 12 Days of Agile Principles’ where I’ll try and keep things real simple... 

PRINCIPLE #10

Simplicity--the art of maximizing the amount of work not done--is essential

We can illustrate this quite easily when you observe Agile ways of working and the work that we don't do. For example, we don’t put effort into documentation and artefacts that will quickly go out of date and need updating constantly. Instead, we form agreements as a group quickly in collaborative workshops (see #AgilePrinciple 6), and if we need to capture something from it, we do it in low effort ways, such as a one pager that is circulated in a team's on-line space or a large diagram in a team's physical space. 

The use of user stories to capture requirements allows us to maximise 'work not done', by breaking large sets of functionality up into smaller chunks, this approach allows us to deliver only the stories that provide value to the customer - this 'not done' work can sit happily doing nothing at all in a backlog or even better, be completely deleted so it's not distracting the team any more. If it's important work, it will come back. 

In Agile teams we use this process of prioritising the backlog continuously, i.e. we stop building software features when we’ve done enough to ship a "Minimum Viable Product" (MVP). Then we only build new features if we find out they are of use to the customer, and then we evolve our products by layering on further slices of functionality. 

It’s interesting to look at the order of delivering features to illustrate MVPs: at the outset of an application build you may consider that registration and logons are necessary first features to build, but are they? Perhaps higher value features would be to get some engagement with your product in order to get feedback on the product’s fit to the market first? Sometimes a build of software can be replaced by some customer testing on a prototype. If you mistakenly build a heap of features for a product no one wants to use, you’ve wasted a whole lot of time and effort.

Another practice which allows us to maximise ‘work not done’ is moving in small iterations. If our delivery increments were massive then we would have less opportunities to critique what features are in a delivery and therefore less opportunity to drop non valuable features/stories. 

And another thing! Retrospectives allow us to inspect our processes often and remove wasteful activities from our process, that is, when we ask the question “What are we doing (work) that's not helping and we can stop?” We’ve created an opportunity to stop doing non value work. 

And another thing! Simple designs, that are constantly ‘refactored’ see #AgilePrinciple 9, allow us to remove complexity (work) from the codebase and move faster. We should strive for simple before fancying up some design with architectural cleverness that may not help us. 

See how interlinked the principles are?! 

 ***

We are closing in on our 12 Days of Agile principles so make sure you continue on to Agile Principle #11 or join the conversation at @TheRebootCo. 

#12daysofAgilePrinciples