Avoidable Waste by Software Teams
Colin Hammond
Creator of AI Software Requirements Analysis Tools - automated estimation, QA and insight.
Approximately $1bn per day is being wasted by companies and governments across the world doing work that is completely unnecessary.
Every day software teams around the world are wasting 30- 60% of their of their time (and employer’s time and money) due to inefficient practices. ?Most of this waste is avoidable. At any point in time, each member of the team may be doing useful work but, the work they are doing could have been avoided. In most cases managers are unaware that this is going on.
This article takes a look at some of main causes of waste in software work. Let us start by looking at the activities of software teams that are wasteful. Everyone who has worked on a software project will have experienced several of these.
Effort and time is often wasted by software teams:
Much is spoken about lean practices by software teams, which is all about eliminating waste.?Yet it is rare to find teams that carefully examine the actual source and magnitude of the waste, determine its impact on progress and determine how it might be avoided in future. ?Most teams are incurring some or many of the above wasteful activities.?The accumulated impact averages around 40-50% of all work being done by software teams. And most of this is avoidable.
Wasted Effort in Knowledge Work
Wasted effort in knowledge is common and is substantial. For example, changing code that is already stable is very costly because it, and all features around it, need to be reconsidered, and retested.?The retesting is needed to ensure that the change has not introduced some adverse affect.? A one line code change can require retesting of thousands of lines of related code. Test driven development (TDD) is a technique that helps to alleviate this problem, but it does not prevent the problem, nor will it catch all possible defects.?
On projects with larger teams, the work of one person is dependent on someone else's previous work. Before making a change to some code, ?a developer has to understand what his/her predecessor wrote, then work out where else it was being used, then finally they can start to make the desired changes.? The same applies to requirements, designs and tests. The pre-change learning can take hours or even days.? What seems to be a minor modification can become disproportionately very expensive. ?
Jumping from one piece of code to the next involves context switching. To do knowledge work well, we need to focus and avoid context switching. Bug fixing involves more context switching than writing the code in the first place. Context switching is completely wasteful. ?The combination of relearning and context switching goes some way to explaining how a small code change can be extraordinarily expensive. Ideally we want to modify a method as few times as possible beyond the sprint in which it was created.?
Do teams measure real waste??
In general, no, they do not.?That’s right, $1Bn a day is being wasted by corporates and governments around the world and very few are measuring it. ?This waste will not magically reduce or disappear by itself, pro-active work is needed.
Root cause analysis can be helpful in identifying where, why and how much waste is being incurred. Before considering a piece of upcoming software work that requires a change or fix to existing code, we should ask ourselves some important questions, here is a non-exhaustive list:
The Most Common Root Cause
The root cause of most of this waste is poor work early parts of the software lifecycle.? Poor requirements work, hurried architecture decisions, sloppy solution options work or design work.
Most software teams rarely consider the actual impact of requirements defects on their productivity and the waste caused by them.?Furthermore they may overlook the cost of poor design decisions until long after the design has been implemented.?This is get's labelled as technical debt.
Unclear requirements that are implemented with a poor and inflexible design can lead to extraordinary rework costs. ?This rework cost can then be made even higher if it causes a delay to other related and unrelated work.?In some cases, and quite frequently on larger projects, poor requirements and poor early design decisions can lead to an entire project being scrapped.
Requirements defects discovered late are usually the most expensive type of defect to fix.
About $720Bn is spent p.a. globally on enterprise software work.?About half of this is rework which is avoidable and is caused by poor requirements, poor design decisions and the consequences of both.? Globally this is about $360Bn p.a. or about $1Bn per day.
What about Agile
Agile does not cure the waste that we have described here. The primary benefit of Agile software development methodologies is a fast feedback loop between users and developers. We see that in many cases, Agile adoption brings with it a drop in the quality and diligence of requirements and other pre-coding work. Organisations are in a hurry to deliver new software based capabilities. Those involved with doing the work, present an "adapt as we go" approach, which seems attractive. If done well, Agile practices do help ensure that the customer gets something that they want, but when accompanied with sloppy pre-coding working the results is a significant levels of rework during the project and increased wasted effort.
Data from thousands of projects shows that there are about as many defects introduced before coding as during coding.[i]?This is known as the defect potential.?16% - 35% of all production defects are caused by poor or incomplete requirements.[ii]
Few software teams consider carefully that requirements and design defects are the root cause of so much wasted effort.? You cannot develop until you have some idea of the requirements.? In other words, development follows requirements. ?A poorly researched or poorly expressed requirement can lead to an entire team doing days or weeks of wasted work.? Often this kind of waste is written off as “learning” or “evolving user requirements” when actually it is neither, it is sub-standard requirements work.?There are several reasons why the requirements work might be poor.? One reason is that many organisations fail to ensure that the staff who write the requirements are adequately trained and experienced to do high quality requirements work. Another reason is that there is little agreement and consistency across the industry about what constitutes a good requirement. ?
Other Common Causes of Waste of Software Projects
We have mentioned poor prior work and context switching as leading causes of waste, some other common causes include:
Software Requirements Are Often Poor Quality
Software requirements and user stories are often poor quality. Perhaps the author is inadequately skilled or experienced. Perhaps they do not have access to the information that they need. The problem with nearly all requirements is that they are written in unconstrained natural language. Usually the authors lack formal training on writing quality requirements.? Unconstrained natural language is not the ideal means of communicating software requirements but it is what we mostly use. ?Most organisations do not manage requirements quality.
At Scopemaster, we have analysed over 300,000 requirements from hundreds of software projects in different countries and industries.? What we have found is that:
领英推荐
Common requirements defects include:
Most readers will interpret a written requirement differently. If the difference in interpretation is non-trivial then it is likely to lead to a software bug. If that bug is not identified until later on, much work can have been done that will need re-doing, in order to fix it. Getting it right first time, or finding defects early, really matters.
Quality Attributes of Good Software Requirements
There are various sources and opinions about what constitutes a good quality requirement.? There is great work by the IEEE and they regularly revisit this topic. There is a commonly adopted, although in our view deficient, list of attributes that is frequently promoted by various agile coaches, encapsulated in the INVEST pneumonic.
Here is our list of requirement quality attributes.
Checking each requirement addresses all of the above well, is rather tedious work, but necessary if you want to minimise waste. Thankfully, tools such as ScopeMaster can now do the lion share of this requirements quality assurance for yo
Avoiding the Waste
To avoid this waste we just need to better requirements work and better design work.?Is it that simple? Yes.
If you write better requirements that communicate clearly and consistently to all readers, and then spend adequate time to ensure that designs options are carefully considered, designs are reviewed and optimised before coding, good things will happen and waste will be minimal.?
Rarely is there adequate focus on requirements quality.?Furthermore many Agile approaches, frameworks and trends are undermining proven, efficient ways of delivering high quality software first time around.? Requirements quality and design quality can be measured, tracked and improved, but rarely are.
Teams Need Help to Solve this Problem
Writing good requirements is not easy, it requires training and experience.?Many teams have a product owner who is either a subject matter expert or an experienced BA, they may know the business but not how to write good quality requirements.?Here are some reasons why this problem remains largely unaddressed:
1.????There is little job reward for challenging the requirements quality
2.????If the requirement is poor and you have to build it twice, you get paid more
3.????Requirements authors rarely have intimate knowledge of the user need, existing systems and how to write good requirements.
4.????Often requirements authors are the developers who write down jargon-rich development tasks, not readily understandable user requirement that can be understood by all.
5.????Teams rarely constrain the language of requirements to that which achieves consistently clear common understandings.
6.????The team relies on discussion as a means of clearing up misunderstandings.?The discussions often go undocumented.
7.????There is a wide variability in the opinions of what constitutes good quality of requirements.
2022 and Automation/AI Comes to the Rescue
Tools are emerging that can help with requirements quality assurance (QA).? Vendors of requirements management tools are working on new capabilities to help with some aspects of requirements QA. IBM Doors, Jama Connect, Visuresolutions and ScopeMaster are examples.? Our own tool ScopeMaster is the most advanced tool available that addresses the problems described in this paper. It automates requirements QA early in the software lifecycle. It is like a static analyser of requirements; it does for requirements what SonarQube does for code.
ScopeMaster and some other tools use Natural Language Processing, and other analytical techniques to interpret and test requirements.? ScopeMaster guides the requirements author to improve the quality of the requirements at speeds and thoroughness that has hitherto been impossible.?(ScopeMaster will perform on average 100,000 tests on a set of 100 user stories in 4 minutes). ScopeMaster typically finds 2-4 defects per requirement in just a few seconds.
ScopeMaster will find about half of all the latent defects in a set of requirements.?The types of defect covering 9 out of the 10 quality attributes shown above.?This can help teams raise the quality of a set of requirements to a much higher standard very quickly, helping to alleviate this $360Bn p.a. problem.
Conclusion
If you are involved in software projects in a corporate or government sector, you may be wasting up to 50% of your budget on avoidable work.?The root cause of much of this waste is poor requirements and system design work.? Recognising that there is a problem, and that this is the likely root cause, is the first step in being able to resolve it.? The next step is to introduce a quality improvement initiative that addresses the start of the development lifecycle: objectives, requirements, architecture and design.? Start to measure defects in requirements and the impact that they are having on your progress.?Recognise defect potentials and introduce initiatives to find and fix those defects as early as possible. Tools such as ScopeMaster are game changers for software certainty.
Written by Colin Hammond, 37 year IT veteran and founder of ScopeMaster.
[i] Defect Sources Defects per function point Requirements defects 0.75 Architecture defects 0.15 Design defects 1.00 Code defects 1.25 Document defects 0.20 Bad fix defects 0.15 Total Defect Potential 3.65
https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf
[ii] Capers Jones and Accenture, January 2021
Economics of Software Quality by C Jones and Olivier Bonsignour.
Author of "Software Requirements Essentials" and 13 other books. PhD in organic chemistry. No certifications at all. Preferred tools are Gibson Les Paul and Fender Stratocaster.
2 年Excellent article, Colin. Thanks for posting this. The leveraging power of good requirements in minimizing unnecessary rework (= waste) is still not fully appreciated. I wouldn't have minded seeing some citations to sources for some of the data. For instance: "$1Bn a day is being wasted by corporates and governments around the world and very few are measuring it." So if very few are measuring it, how do we know what the level of waste is? I've seen reports that 30-50% of total software project effort is rework, but again, few people measure their own rework levels. Maybe it's too scary! Teams shouldn't just accept excessive rework as normal. They should track it as a separate activity (e.g., split debugging effort from fixing and reviewing effort from correcting) and then see if they're okay with the numbers they see. I hate rework, doing again something that I thought was already done. There's always going to be some rework, waste, and fumbling around on software projects, but it could be far less. Thinking is cheaper than redesigning and recoding. Iterating at high levels of abstraction (business problems, solution concepts, requirements, analysis and design models) is cheaper and faster than iterating on code.
People Connector | Team Builder | Culture Creator | Problem Fixer | Ideas Generator | Systems Integrator | Optimism Evangelist
2 年Just came across your post, Looking forward to reading it. It’s an important, and I fear pervasive, problem across the software/tech sector., so much of which is 100% avoidable.
Care Farm Assistant (former IT, QA and Software Testing Professional)
2 年Great article Colin, the keyword for me in this is "Rework", avoidable rework or waste! You mention the word rework or reworking 10 times in the article and waste or wasting 38 times. As you know from our conversations, my five "static tests" for requirements/user stories have always been; is it Clear, Unambiguous, Assumption-Free, Complete and Testable? As a QA/Test Professional it is hugely frustrating to know (as I have known for many years) that the root cause of a huge number of defects is introduced before a line of code is written, yet people continue to write poor requirements/users stories and fail to prioritise them effectively. Quoting your article to illustrate the frustration "Data from thousands of projects shows that there are about as many defects introduced before coding as during coding.[i]?This is known as the defect potential.?16% - 35% of all production defects are caused by poor or incomplete requirements.[ii]".
Consulting Digital / AI Project and Programme Manager, CEO and Founder, FAPM, FBCS, BA Hons (Oxford), MSc (Surrey)
2 年Great article - I wrote this, reflecting on my experiences, and these echo yours! https://www.apm.org.uk/blog/surprising-lessons-on-language-for-project-managers/
Professor, International Speaker, Project Manager
2 年Excellent article Colin. Thanks