How does agile deal with late change requests?

The short answer is, we don't panic. The longer answer is more interesting though.

One of the defining characteristics of an agile approach is that it handles change requests really well. In fact it doesn't just handle them, it welcomes them with open arms. As the agile manifesto puts it, we "welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage".

The reason for this is simple. The whole point of adopting an agile approach is to be able to change what you're doing based on feedback and learning. If you're working in a marketplace that's rapidly changing and evolving (such as technology and digital), then making big plans and spending a long time delivering them might mean you build the wrong thing, or what you're building becomes no longer relevant. So you want to be able to change as you go along, and the better you can handle change, the more agile you can be.

Of course, this doesn't necessarily mean it's helpful if someone comes along and makes changes constantly, or expects massive changes to be made just a day before something is meant to go live. Good agile teams are generally pretty quick and flexible in what they do, but they still live in the same universe as everyone else, and there are only 24 hours in a day.

If you look at an agile framework like Scrum, teams using Scrum still plan out a chunk of work and try to deliver it in a chunk of time called a sprint. If too many changes need to be made to what the sprint was meant to deliver, they cancel the sprint and plan out a new one.

The three things teams really need to get to grips with to handle last minute changes though are continous improvement, a focus on quality and only working on small chunks of work.

If teams are working on continuously improving how they work, then they typically get better and better and delivering things, so making changes becomes much more simple. In short, they become proficient at 'turning on a dime for a dime'.

If teams focus on quality, then changes often become much easier to handle. Think of a production line. If each work station produces something that works first time, then the work flows through the system much more easily. If things get passed down the line broken, and have to be handed back up the line to be fixed, then pretty quickly the system can grind to a halt, especially when changes start adding to the confusion. From a technology perspective, it's much easier to change code that has a full set of tests running on it, as if something breaks, you know straight away where the problem is.

Finally, breaking work down into small chunks really helps as well. If all work gets handed to a team as small chunks, then it's much easier to separate out and prioritise the most important changes first, and get a better handle on what the changes are.

There's much more to all of these concepts if you want to delve futher into them. For now though, just know that good agile teams should welcome late change requests, and be constantly getting better at how they handle them too. Just remember, the people on these teams are only human, and most humans can't perform miracles.