This post is the first in an ongoing series revisiting the principles behind the Agile Manifesto. This post is focused on the following important principle – “Simplicity–the art of maximizing the amount of work not done–is essential.”
For knowledge work, the scope for potential work is limitless. There is always more work than there is the capacity to deliver that work. If you ask stakeholders what they want, it is likely that in a short time they will come up with a list of features that would take a Scrum Team many years to build.
“Ideas are cheap, implementing those ideas is rarely cheap!” – Simon Kneafsey
In order to succeed, someone needs to rationalise that list of features and make choices about what to do and what not to do. Most of the work will fall into the what not to do category. In Scrum, the person accountable for these often difficult decisions is the Product Owner.
The Product Owner provides an important service to the Scrum Team. They maximise the amount of work not done. They help to keep the Product Backlog to a manageable size and prevent refinement from becoming an expensive and potentially wasteful activity.
Saying no is not easy. Here are some reasons why:
- Stakeholders make commitments to other people that they do not want to break
- Stakeholders get emotionally attached the features they have requested and refuse to agree to them not being developed.
- Stakeholders make invalid assumptions about the value of the feature and insist it is a must-have, even though this is often an opinion unsupported by facts or data.
As a result, many Product Owners cannot or will not say no. The Scrum Team ends up working on low-value features and the Scrum Team, stakeholders, organisation and customers all suffer.
An often quoted statistic is that according to the Standish Groups’ Chaos Report (2014) – 50% of the features that are built are rarely used. The accuracy of this statistic is debatable. However, my experience of over 25 years of software product development agrees with the general trend this indicates. As a Software Developer early on in my career, I was aware that many of the features I was tasked to build were low-value and should not have been built. Once released they were rarely or never used. In many cases, this would have been more than 50%
For some clients I encounter now, this pattern continues. Many organisations are fixated on maximising the output from their Developers. The false belief is that more output automatically equals more value. While this could be the case, it rarely is, as these organisations are poor at maximising the amount of work not done. As a result, lots of low-value work enters the system leading to significant waste. This focus on maximising outputs typically results in unrealistic expectations, overwork and poor working environments that actually serve to reduce output (but that is a story for another time).
Instead, organisations should focus on maximising the amount of work not done. Once they have got effective at this they can move the focus to increase output if need be. Going fast is only important if you are heading in the right direction.
--
Hi, my name is Simon Kneafsey and I am a Professional Scrum Trainer with Scrum.org & TheScrumMaster.co.uk. I am on a mission to simplify Scrum for a million people. I have helped over 10,000 people so far and I can help you too.
Learn more at TheScrumMaster.co.uk and signup for our newsletter with 80,000+ practitioners.
