01 The Wheel of Change, 04 Projection

Chasing Waterfalls

Reading Time: 4 minutes

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

We stopped by asking ourselves “has it always been like this?”. So let’s take a little detour. Let’s go back to the days before Agile and get a quick history lesson. We’d know better where we are when we know where we came from. To understand how The Wheel of Change does any good.

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”.

Two months later the final drop off was made (in reality it was four months because Change entails Instability), 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 hold.

Honestly, I can not say whether The Wheel of Change was born along with Agile, or whether it has always existed but 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, but it barely curves. As most of us today came from an Agile-driven world, this would allow us to better understand what kind of project I was a part of many years ago.

What we got is a timeline that looks exactly how a waterfall project for a waterfall client looks like. And it happens as such 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 when the project was initiated, 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 held back the need, 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 was decoupled from hardware, the faster it was delivered. As we deliver smaller, we get a smaller Feedback which would make us deliver yet again, a small Change. 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. 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