The second Agile principle is “welcome changing requirements, even late in development”.

Sounds simple enough and as a principle it is. Except for the fact that very often this doesn’t happen.

Welcoming change is not about creating a robust formal change process. I’ve worked for one organisation who insisted they embraced change they had a formal change process which was applied religiously in all projects. It involved any deviation from the business requirements document being logged as a formal change request document (CR). The CR was then sent  to the project board for approval and when required escalated to the change steering board for acceptance. And in parallel the CR also had to be submitted to the data architecture board and then technical architecture board to have the proposed approach ratified. Of course any one of these four change boards could raise questions or concerns meaning the CR could need to be revised and the process re-started. You can guess this process could take many weeks. (or sometimes even months!) Some of the boards only met monthly meaning getting even the simplest change agreed and included into a project was a challenge.

In that environment, a change of requirements uncovered during final user acceptance testing would often not be resolved until long after the software had already gone live.

This is NOT the way to welcome change. So what does welcoming change mean?????

It is about a mindset. If everyone in the project and organisation really accepts that change is unavoidable and actually a healthy part of running a project then you’re on the right track. With Agile the short sprint approach makes change a potentially simpler affair. With every suggested change the question always is,”can we fit it into the current sprint?”. If the answer is “yes” it probably already suggests the change is minor and therefore a large change process would be overkill. So allow the development team to take some responsibility and just get on with the alteration.

The Agile development team should always be cross functional including coders, testers and business representatives. If all of these people collectively agree that the change can be “squashed” into the current sprint just get on with it without any further debate.

If the change can’t be “squashed” into the current sprint the approach is slightly more complex but still simple compared to the change process described above. The change should be added to the product backlog. The product backlog would include all outstanding bugs fixes, new business requirements and change requests. (Basically all the alterations needed on a solution.) Each item is assigned a priority and given a rough estimate. When you plan future sprints you simply use this to drive the alterations to include.

ok, commonsense needs to applied here! Some changes might have a material impact on budgets or benefits realisation. These may still need some form of approval from the powers that be. But to be honest the vast majority of changes that occur are not of this type or scale. So be prepared to be flexible and manage these by exception.