Agile principles: 2. Welcome changing requirements

The second principle of Agile is about welcoming changing requirements, even late in the development.

In every software development change requests will pop up regularly. No one knows exactly how the end-product should look like. Even if you have a quite good picture of what you want, there will be changes and misunderstandings. In the traditional waterfall methodology, change requests will go through a rigorous process and you have to get approval for further funding, changing the timelines. In many organisations you have to complete a change impact assessment, go through the selected regression test cases for the impacted areas and of course document, document and write some more documents.

Changes in an Agile framework have an impact as well. But thankfully, you always have a choice.

In the environment I am working currently, we run inception workshops before the project work actually starts. And at this workshop we create a trade-off slider, where the business stakeholders define, what is the most and least negotiable item from the list below. Scope, time, quality, budget, user experience (and these items can change as well). Most of the time quality became the least negotiable item and quite often scope was the most negotiable.

If scope is the most negotiable, in the event of a new change popping up we prioritise the new story and if it represents high business value, we remove the story with the lowest business value from the scope. We still implement what’s most important for the business and remain within the expected time-frame and budget.

On the other hand, if scope is the least negotiable (which I haven’t seen and would challenge unless it’s an airplane design :-)), you would expect increase in budget and time (and the impact would be same as in Waterfall). However, even in this situation the work would be picked from the backlog based on the business value, ensuring that the most valuable stories are delivered quickly.

In the projects I worked in, there were always changes – but in my experience in an Agile framework it’s much better to deal with them.