Teams with poor software requirements don’t deliver well on them.
Remote, outsourced and offshore teams with poor requirements fare worse.
Remote, outsourced and offshore teams of inexperienced and junior developers with poor requirements fare worse still.
No one wants to admit this, not in public anyway.
Businesses that tolerate poor software requirements get poor results.
Poor-quality products are pushed out, oblivious to the harm they can do to a company’s brand and market position.
High levels of rework and delays erode profit margins and competitive advantage.
No one wants to admit this either.
Expecting developers to magic something from a vague idea or a one-sentence user story is a terrible approach.
Whilst technical staff are great at solving relatively well-bounded technical problems, they are almost always dire at stepping into the customer’s shoes.
Specialist development roles have put an end to software developers actually speaking to end users. And most wouldn’t want to anyway.
Pointing the finger at “poor performing developers” and low-quality engineering distracts from the real upstream issue that isn’t being talked about: poorly communicating what needs to be done.
Agile won’t fix this for you.
Agile is often held up as the holy grail of solving a problem, but unfortunately, it won’t work this time.
You’ll see the truth in that statement if you already have an underperforming agile team.
Agile may help you realise something is wrong in time to avoid a spectacular disaster, if you are lucky.
Co-locating the team for a while may hasten the issue of an unavailable product owner or a product owner who doesn’t communicate what is required.
The solution is knowing what to build and communicating it effectively to those who matter.
Developers benefit from clear explanations about what needs to be done, how it will be validated, sufficient context for understanding, and relevant implementation details.
Detailed guidance is even more critical for remote development teams and asynchronous working.