Do you remember seeing this statement somewhere before?
Simplicity -- the art of maximizing the amount of work not done -- is essential.
This is the tenth principle
behind the Agile Manifesto.
Long ago, when I first saw this statement, I was really confused. I seriously thought there was a typo here. The not
in the statement had surely been placed there by mistake. Because normally we think more is always better. So with that logic, maximizing the amount of work done also is better.
But it's not true. In fact, it's very wrong.
Doing the right things matters more than doing more things. That's applicable in product development as well as in other scenarios in life. When we try to do a lot of things, there are many items that may be:
- Unnecessary -- not providing much value to the end user.
- Not cost effective -- providing less value but adding a lot of cost to the product.
These points turn out to be germane in every product backlog. But it's not easy to identify them. If we look at the results of the Standish Group 2014 "Exceeding Value
" report, we discover that only 40 percent of successful projects provide high or very high value to users. Remember, we are taking about successful projects only. Out of all projects, the number of successful ones would be fewer than 40 percent of all projects. So what's going wrong with so many successful projects?
It's all about the features they provide. The report shows that 80 percent of features in successful projects provide very low value to the customer. That's why those 80 percent of features are hardly used. So for using 20 percent of the features, users had to pay a huge cost for the other non-useful 80 percent of features as well.
Back to the tenth principle from the Agile Manifesto: It's one of my favorites, and we can see how it relates here. Most of the time people don't understand its real meaning. Whenever we talk about prioritizing and removing some functionality, it's mostly because we're running out of time or resources. We have a delivery to make and the team can't deliver this much. Then people consider removing items from the backlog.
But this should have been done earlier. Why should we make something that is going to be hardly used by anyone? Even in a (theoretical) situation where we don't have any constraints on time and resources, we should be able to remove items from backlog to make the product more simple and usable. That's the real crux of this principle. Peter Drucker wrote a nice quote that is highly relevant here: "There is nothing so useless as doing efficiently that which should not be done at all."
Moving something to "not doing" is not easy. At first, everything looks important. A great amount of analysis and thought needs to be put into the process of culling. However, we can apply a number of prioritizing techniques to find out the features that really aren't going to provide much value to the end user -- and this includes comparing the value a feature would provide with the cost it would incur.
So, along with moving things to "Done," it's important to create a list of items that are not going to be done, even though we may have no constraints on time and resources. Because, many times, less is more