Better Software Requirements: A handbook for software development teams and their managers, was released this week after being in draft for nearly 12 months. A Kindle version should follow in due course.
When software development works best, why software development fails, what a failing project looks like, and what developers actually need are covered.
It’s waterfall and agile agnostic (mostly), free to access, advert-free and with no implied sales hooks – just good advice written from the perspective of the individual software developer.
My aim is for development teams, and their managers, to read and adopt the handbook. For each team that does, I will be happy to respond to any questions and feedback received from the trenches, including making rolling updates to the handbook.
Here’s a few tasty quotes:
- Many developers don’t speak to users or collaborate with the business, instead they take direction from email threads and poorly written tickets.
- The distance between the end user and software developer is the biggest indicator of whether your software product will delight users, or be a poor proxy of misunderstood needs.
- Developers not sitting with actual users break the close collaboration that avoids software requirements and software specifications in the first place.
- Someone needs to tell the developers what to do, otherwise certain chaos ensues.
- What developers cannot do, however, is make decisions on behalf of a business that doesn’t know what it wants.
- “Have you got the requirements yet?” is a well-intended but misguided question anxious stakeholders.
- Some organisations don’t want agile. They say they do, but shop floor behaviour indicates otherwise.