In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features – those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%.
In other words, a great deal of our effort is generally spent creating things that customers do not use or want.
A lot of times this is a forgotten principle as people get caught up in the world of implementing stories and forget that there may be a plethora of stories that don’t need to ever be implemented.
What value is there is doing work faster and better if we are doing four times the amount of work that we need to do?
This principle fits well with the concept of business and development working daily. Business needs to be intensely involved with the process, if for nothing more than identifying the 80% of the work that we really don’t have to do. Just think of the amount of money that could be saved every year by reducing project scope to only those features and functions that are actually used! Think of how quickly we could deliver functionality! Think of how many more “projects” we could complete!
While simplicity provides huge benefits with regards to the stories and work that we choose to implement, it also applies to the implementation of stories that we choose. As I have written about so many times, by using techniques like BDD and TDD we write only that software that is necessary to implement the acceptance criteria and are not tempted to “gold plate”.
TDD provides us with a certain simplicity at the code level while also providing us the ability to allow our code to evolve over time to satisfy changing requirements. Simplicity of code allows us to refactor code mercilessly which is essential to agility over the long term.
In the end, simplicity of what we do and how we do it results in producing the most valuable software in a high quality manner and this is essential to being agile.
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Android | RSS