Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

The first thing to check is that we are not reading the principle too quickly, but actually reading it and absorbing the written detail.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

1. Welcome changing requirements, 

2. even late in development. 

3. Agile processes harness change for the customer

4. competitive advantage.

The 1990s

Change request! 

The scope is locked, CR.

It was a nightmare, as you began to build software new challenges would be discovered or the environment would change and every project tool would insist on a bureaucratic process.  Seriously, this was every software project and the cost and effort meant too often the team delivered bad outcomes to spec rather than face the steering committee.

The intent of this principle

As covered above, a process that actually prevents you from adjusting as you learn is not good.  Welcome the learning and adjust and make things better. So many systems fail because teams we disempowered and this principle instead asks everyone to make the software better. After all, that is what gives it the edge over the competitors.

Today (+20 years on)

It is great that CRs are mostly dead, but there is still a lot of mock learning when teams are organised into sprints but deliver to plan and are not rewarded for harnessing change which is a competitive advantage.  Clear behaviour counter to this principle

• Any fixed plan where dates are the success metric,

• Reviews that don't allow adjustments to the plan,

• Reviews that don't include users.

The incremental way of working is the only way to evolve and is what we walk upright.