How Agile thinking improved an inflexible Waterfall approach to software development
Some years ago one of the South Eastern US states began to plan updating it’s outdated procurement systems.
None of the local state offices had a shared single procurement system. Instead there were multiple inefficient versions that all did a poor job.
There were 27 state agencies involved. They got together and after going through a planning process created detailed unified requirements for the development team.
The procurement application was then developed precisely as outlined in the planning document agreed by all 27 state agencies.
However after many months development when the procurement application was delivered, the local stakeholders found it wasn’t what they expected or needed.
After a series of meetings 140 feature requests created by the 27 state agencies were sent to the dev team.
Many of these 140 requests turned out to be incompatible with each other. Additionally as a whole it was clearly too large a capacity for the small dev team to fulfil.
A new developer was brought in and he reviewed the application and the client requests. Then he created a stack of the 140 requests as cards.
At the next meeting he handed them the cards and asked the 27 agencies to prioritize 10 items that could be realistically delivered by the dev team in the next month.
They agreed and also managed to reduce the feature requests from 140 down to about 50 items.
Once the first 10 items had been developed and accepted by the the stakeholders they moved on to the next 10 requests and then continued until the project was complete.
This illustrates how a large software project that had some badly written requirements at the start was saved from wasting further resources.
This was achieved by having the stakeholders narrowing the priorities into manageable tasks for the developers using agile methods.