Everyone working on a product must understand who’s the user of a given feature. When we understand the user’s needs we can write better requirements, and deliver the solution with minimal effort and no hidden costs.
When we have multiple levels of command within the company, it’s hard to get everyone on the same page. What results is best described with the famous swing drawing. What that image does not describe fully is the incurred costs and delays to the project/feature schedule. So let’s talk about that.
Let’s start with the assumption that all companies do one kind of agile development. This means that most of the software projects are adaptive. And that’s good. However, everyone knows that all the misunderstandings regarding requirements will be eventually fixed. Change management is a simple process in agile. Eventually, people get lax with writing and understanding requirements.
For each misunderstood or incomplete requirement, work is:
- More costly, as a feature must be adapted, reworked, or even completely redesigned. Expect costs to jump from 20% to ranges of 10x the initial estimate.
- Delayed a little (a lot), because fixing a misunderstanding is often not added to the plan. Contingency buffers, if used, are too relied upon, making them worthless. I have seen features being delayed for multiple months.
- Of low quality and built by stressed out and unhappy developers, when the delay is not an option. Don’t ask your developers what they think about the 3rd working Saturday in a row.
- It causes long-term damage to the codebase, which increases the cost of future changes. While this is hard to estimate, I won’t be wrong to put it to about 1-5%.
It’s easy to fall into a trap of agile and assumes that agile will solve all your problems. It’s not a silver bullet (even though it’s often sold as such). So what should you do? Be proactive and start working on:
- Empowering developers to become experts in the domain
- Involving experts as much as possible in requirement elicitation process, to improve the quality of requirements
- Making sure to receive as much feedback from clients as possible
- Running an occasional survey, find out what your clients need
- Being transparent with the feedback and surveys, especially towards experts
And the most important of all, make sure to put systems in place that makes it easier to notice bad trends and act on time. Things like requirement revision count, code quality KPIs, bug rates, etc.
Where possible, you should also consider value pricing. The questions you ask to determine the value of the project to the customer are very similar to the questions you ask to clarify requirements.
All this is much easier in smaller companies, with a structure closer to the flat one. For the companies that do outsource, my suggestion is to always target a specific domain or industry. Otherwise, developers can’t identify with the users.