A friend of mine, who is an Agile software development consultant, tells a great anecdote … one which helps get to the heart of the difference between traditional approaches to projects, and Agile thinking.

He tells a story of being pulled in to help a project that was in trouble. A large business was aiming to develop an intranet tool for use by their field sales team. The tool would allow mileage claims and other routine business expenses to be entered and processed via an intranet page, reducing back office costs and helping the business to become more efficient.

The trouble was, delivery schedules were slipping. The business was several weeks into requirements gathering and specification writing. Each new round of speccing was throwing up more complexity, as the business considered an increasingly broad range of ‘what ifs?’ as special considerations that had not been immediately apparent at the outset. Not a line of software code has been written. Developers were waiting; senior stakeholders were getting frustrated.

Having quickly appraised the situation, my friend decided on a different (and outwardly alarming) course of action.

He found the principal stakeholder who wanted the system, and went to see them with his laptop. He opened up a browser window and showed them a completely blank page, and asked “is this what you want?”

“What?!? No!!!”

“Why not?”

“Because it doesn’t do anything!”

“What’s missing?”

“Everything!”

“Like what?”

“Well for a start, entering details of a journey they’ve made, like start and end points…”

“OK, stop right there. I’ll be back…”

A few hours later he returned and showed the web page. This time it was blank, apart from two text entry boxes… ‘from’ and ‘to’. Each accepted a valid postcode.

He asked the same question: “Is this what you want?”

“No.”

“Why not?”

“Well, what date did they travel?”

“Stop there. I’ll be back…”

And, of course, a short time later he returned. This time it was possible to enter start and end locations and a valid date.

“Is this what you want?

“No, I don’t know who it was that made the journey….”

“Stop there, I’ll be back…”

And so on. After the short number of days, the system was largely complete and ready to use. The vast majority of business benefit had been delivered in a short space of time, and the key stakeholders were happy, The development team had been kept busy and productive.

The requirements document went into the dustbin.

Whilst this almost sounds too easy, there are a number of agile practices at work here which are key to this approach succeeding:

  • The software was written in the way that he could be adapted easily i.e. highly maintainable.
  • The key stakeholder and was readily available and could act as a ‘single version of the truth‘ when it came to decision-making.
  • Decisions on priorities and next steps were made very quickly.
  • Rapid feedback allowed the development to be steered towards a better outcome.
  • Most importantly, iterative incremental improvements were given for higher priority than postponed perfection.

The requirements document was never finished. Nor was it ultimately needed. In the spirit of Pareto, 80% of the value was achieved in 20% of the time; the rest really didn’t matter that much – it could be ignored completely or at most de-prioritised and saved for a later day.

Much of the time, especially for teams within the same company, large requirements documents and specifications are unnecessary and do not work. They soak up time, and if they are ever signed off, it’s only because the business has surrendered and needs something to happen. All software systems evolve via feedback to some extent, so a specification can never be comprehensive. It is folly to try.

Instead, just take the first step and get feedback. And the faster you can get feedback, the quicker you can correct course and make sure the system and project meets the business aims. Key to that is delivering little and often, and showcasing frequently.

The approach outlined above works well particularly for internally facing systems developed by internal teams. However, for systems which are much more externally customer-facing – for example websites – a similar but importantly different approach makes sense; because no matter how much people try to second-guess the customer, the only true information that matters to steer the project is accurate data that comes back from customers real-life experience. Everything else is just an opinion.

For more on this last approach, see the articles on test and learn.