What is it with 'last minute change'? Surely its no way to run a business?

When a developer recieves a brief that isn't detailed enough its no surprise - we can't necessarily expect the business to fully understand how to articulate its requirements to a technical team. But when the business suddenly realises there's an important detail they didn't mention before just when the developer is proudly admiring his wonderful work on the last day of build - you can't deny him is startled expression. Especially as its communicated as "I have an urgent business critical change that must be delivered on the planned deployment date come what may."

If the team is successfully running SCRUM this won't be happening but I see it in every team where agile practices are favoured but not fully implemented.

So how can this be overcome? Well don't even try. Best to adapt. Normally under the pressure of a last minute change the team gives into the unreasonable demand to deliver 5 days extra developement and keep the original schedule. The agile manifesto talks about Responding to Change rather than Following a Plan. This is great advice - and particularly so when the change is significant and comes in at the end of the cycle. Its not easy to stand this ground with the customer and sometimes the arguments about quality and risk aren't appreciated until the second or third 'I told you so' event resulting from a buggy deployment after a forced late change.

Taking this approach is challenging for any team but the hard work is rewarding when 6 months down the line the customer has changed the way he communicates a late change - "I have a late change; can you please tell me what impact this will have on the schedule?"