01 The Wheel of Change, 04 Projection

Chasing Waterfalls

Reading Time: 4 minutes

In the previous chapter, we ended up with a model describing that Change is mostly not being born out of Change, but out of Feedback. Change entails Feedback that entails Change.

We ended the previous chapter with the question of “has it always been like this?”. So let’s take a little detour. Let’s go back to the days before Agile for a quick history lesson. We’d know better where we are today, when we know where we came from. To better understand how The Wheel of Change works.

Phasing Out

One day the team’s project manager had “good news”, something I really hope to never hear again. “We’re stepping into the Client Request Change Phase of the project. We’ve got the Feedback from the client, a list of rejections and Changes. The contract had them paying for two months of Changes, let’s try to get as many of them done”.

It didn’t take two months, because Change entails Instability. Four months later, the client’s new shiny website went live. A month afterwards the client received hundreds of emails from unsatisfied customers (Feedback). And then nothing happened. The contract with the client was over, and there was no one left to Change what’s needed. A year later the client found a new IT company to outsource the project to. And the cycle continued after a one year pause.

Honestly, I can not say whether The Wheel of Change was born along with Agile, or whether it has always existed. It could have been that projects were progressing too slowly for The Wheel to be visible. Because when each phase’s duration and time between phases is measured in months, two consecutive Change-Feedback-Change cycles are measured in years. Let’s presume that The Wheel of Change has always existed, and inspect the project I was working on through an Agile perspective.

What we got is a timeline that looks exactly like a waterfall project, for a waterfall client. The Wheel barely curves because the first Deliverable to get Feedback on, was on one very very big Change. The entire website/project as a whole. Let’s see what that entailed:

  • It took 6 months to get the initial internal Feedback, because it took 6 months to code the entire website.
  • Because there was a lot to inspect, it took the client two weeks to give Feedback.
  • Because there was a lot to inspect, there was a lot of Feedback so there was a lot of Change to do. It took two months to code these Changes.
  • As there was a lot to give Feedback on, it took a month to gather all of it. Obviously, it would entail a very big list of Changes, once again.
  • But the cycle pauses for one year. As there was no awareness that Change entails Feedback entails Change, the original contract had only one Change phase.

So, that’s 26 months from the project’s initiation until the end customers were finally satisfied. All because the waterfall model was not the ideal one for software. It was born to manufacture hardware products, which once leave the factory have no way back. The waterfall model fits the need, until the need itself has started to Change.

The waterfall model caused delays in delivering and satisfying needs, because problems grew bigger. This has led to the rise of The Agile Methodology. In its core it’s about shortening the cycle time by minimizing the Change. It can be done because software can be delivered faster than hardware. And the more software became decoupled from hardware, the faster it was delivered.

As we deliver smaller, we get a smaller Feedback which would make us deliver a small Change yet again. We’d come back to this again later, and we’d be inspecting this process through the perspective of Feedback. Thus The Wheel of Change spins faster. And it should spin fast enough to meet the ever growing business needs. And that is a challenge of its own, which we’ll talk about in the next chapter.

Leave a Reply