Requirements gathering makes total sense – especially when you sit in with a group of stakeholders and you talk about what you collectively agree what you need. It all seems very logical in the “heat” of the moment (although many wouldn’t describe requirements meetings as “hot” 😴…).

All the bells & whistles make sense. Then you go to the next meeting, more great ideas come out and you add in another set of buttons, then another, then another… It feels as though it is all coming together.

To reduce the amount you need to build you go through your MoSCoW on your requirements. This should easily allow have to deliver it this year. However, this is where the wheels start to come off. Everything is a “Must”… you can’t pair down your requirements because everything seems really important.

At this point you are well into the “analysis paralysis” territory, not wanting to make the wrong decision. You need ways to stop the team getting into that state.  

As an architect I can fall into the same trap – just adding a small thing that feels critical for the long term success. I also want what is best for the user and get excited about “yes we can deliver all these features”, or “yes that will be a great user experience”. We get the UX team, developers, testers and the length of delivery starts to rise rapidly. Then we discover something we didn’t understand, and we have to build an extra set of components and workflows to get everything we need. The project becomes longer and longer, deliverable benefits start to drop off.

Taming this problem is unlocked by moving to Agile, helping you go step by step, seeing what you can actually achieve with the team you have The following are other aspects that work hand in hand with Agile to improve the situation further.