12 Agile Principals - 2nd Principal - Welcome Change

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


Wow - there is a lot here.

Welcome change - not chaos. A business relationship between two organizations should not be one-sided. Instead, both organizations benefit when collaboration occurs and a value-based partnership emerges.

There is even a lot in the paragraph above to explore.

The partnership must be earned over time and it will require each side to demonstrate a genuine effort to establish trust and mutual respect.

Thrusting last minute changes on your suppliers and/or vendors is not good for either side of the exchange. The same applies for internal stakeholders if Agile is used between Business (internal client) and Technologists (internal vendor).

But, I thought you were Agile - what good is Agile if you cannot handle my changes?

Would I expect a baker to re-create a custom birthday cake 1 hour before the party?

Why not? They are the experts and there are elements of their work that they must orchestrate in addition to your order. They must balance everything so they can actually thrive within their own ecosystem. They have knowledge and expertise that you don't and you are trusting in them to deliver by leveraging their collective expertise. It is an odd phenomenon that many times business fail to appreciate the complexity involved with software development. That is, even "simple" changes are not easy to execute within complex IT environments. Here is why two-way communication and mutual respect is a key component to healthy code changes.

I like to compare the code base to the human body. A single mishap can generate a lot of havoc in the code much like a small abrasion on the skin could serve as an entry point for an infection that could generate a lot of damage to the body. It is the exact same thing with software. To expand, an infection could enter by virtue of a small (outpatient) surgery or after a large and complicated procedure. Even though the procedures are successful the whole idea is to not introduce additional harm while trying to correct the central issue. Here is where the code base and the body are indifferent as to how the unwanted outcome is introduced. Many times it is the small fast changes in between major releases that can create the most havoc for the IT teams managing all of the change. Agile does encourage change, but this change must be managed appropriately.

Chaos (in software development) is the condition that is created in the absence of a healthy partnership.

Now that the point has been made that a partnership is a pre-condition for delivery excellence, we can now address the meaning of: "even late in the development cycle"

There is no magic within Agile. A late change request can be addressed gracefully assuming there was some dialogue prior to the change. Are the expectations clear? For this to go now, then what else is going out? Or, for this to go now - what test cases are we going to ignore?

Last minute changes can be accommodated by software development teams within Agile and Scrum, but the key to the mystery as to how this is achieved is not a real mystery at all.

  • A mutual appreciation for each other. This is a partnership.

  • Partnerships establish straightforward communication channels. Here is where clear expectations are defined and understood by everyone well before the actual change emerges. This also includes prior knowledge to contingency plans should the rapid change go awry.

  • Code and system knowledge is known at the team level so the best path is self-evident to all involved.

Agile processes harness change for the customer’s competitive advantage

The change should be justified in business terms. Competitive advantages can take many forms, but the idea is clear - change for the sake of change is simply bad business. Does everyone understand why the change can't wait for the next sprint? We established the risk of change, but now the change should be understood from business terms. Does the change make sense from the Product Road Map perspective? Does the change map to an accurate MVP strategy? Did market conditions justify the change? Are the people asking for the change willing to pay a premium for it? If not, then perhaps the change can wait for the next sprint or code release.

Change, in general, is not synonymous with Agile or Agile Scrum. Instead, Agile treats change as a fact of business and embraces change by placing boundaries around how best to accommodate it. These rules (for healthy change) appear to be subtle, but it is good to step back and evaluate each change to make sure all stakeholders consider both Risk and Value associated to change.