Waterfall = T; Agile = Q

​Ever heard of the iron triangle​ ​or the Fast-Cheap-Good triangle? If so, you’re probably a project manager. It’s ok, so am I ;-) . For the remaining masses who have decided that a job that is analogous to cat herding is not for them, I’ll explain.

The iron triangle is intended to express immutable laws of projects (a project, for the sake of complete clarity, is a temporary endeavour that produces a​ ​unique artifact). The triangle I will refer to has sides labelled with Time (T), Money ($) and Quality (Q) where the “area” of the triangle represents the project artifact. Other versions of the triangle may exchange Scope for Quality or Resources for Money or have the area of the triangle represent Quality. These differences are, in essence, not relevant to this discussion. The triangle governs what is allowable if the project artifact or one of the constraints (ie. sides of the triangle) change. If you fix T, only $ or Q can vary to accommodate an increase in the area of the triangle. If $ decreases and the artifact (ie. area of the triangle) stays the same, only T and Q can vary. You likely get the idea that the sides of the triangle are​ ​inexorably linked. If one changes, the other 2 must change to accommodate. If 2 must be fixed and the area of the triangle must change, only the other side can change to accommodate.

The Fast-Good-Cheap triangle simplifies things by stating that you can only​ ​”pick 2″​ ​so that:

  • Good + Fast​ ​delivers an expensive solution
  • Good + Cheap​ ​delivers a solution that will take a long time
  • Fast + Cheap​ ​delivers a solution that is likely to not be good

Now that we know how the triangle works, how does it relate to the esoterically titled topic? I believe that waterfall software development methodologies attempt to guarantee the delivery of fixed T whereas agile methodologies attempt to guarantee the delivery of fixed Q. I’m not here to tell you which is better​ ​as​ ​that entirely depends on your circumstances and requirements. I will, however, attempt to convince you that the primary goal of each method is as I state above: Waterfall = T; Agile = Q.

Waterfall = T
For those unfamiliar with waterfall, its main principle is that each stage completes before the next can begin. For example, system design cannot begin before all of the business requirements are elicited and approved. These sequential stages continue until User Acceptance Testing (UAT), which is the final stage after the system is built and is where the end users validate ​that the delivered system satisfies the elicited requirements​​.

With waterfall, the end user of the delivered system is involved in 2 distinct stages that are, respectively, at the beginning and end of the process: Requirements and UAT. What that accomplishes is the ability for the engineers of the solution to work in isolation and uninterrupted by the end users. The end result is that potential changes are delayed until the end of the project. This allows for more accurate estimation (read: fixed T) of the construction of a solution to the requirements ​(​as elicited from the user and interpreted by the engineers​)​ as a line can be drawn in the sand for what must be delivered in the solution.

What comes next in UAT is highly variable and dependent on the structure of the contract between client and solution developer. If changes are permitted, each will be managed via a change control process. However, sometimes changes are not permitted and they fall into a completely separate project. Regardless of the provisions for change, the goal in waterfall remains the same: ​A​ttempt to predict and fix T based on an up front gathering of requirements. How frequently that goal is achieved is absolutely up for debate but not one I’ll tackle in this post.

Agile = Q
There are many different agile methodologies: Scrum, XP, TDD, Lean, etc. All share a core set of principles encapsulated by The Agile Manifesto. These principles are intended to govern an adaptive, iterative, progressively elaborative process that aims to embrace and adjust to change as it occurs. Its principles couldn’t be more juxtaposed to those of waterfall as they are squarely focused on delivering a solution that completely satisfies the business requirements no matter how much they may change. The goal is Q above all else. Note that I’m asserting that Q is most correlated to the satisfaction of business requirements. Again, I accept that this is debatable, but must leave that for another post as well.

Delivering a software solution using agile begins with a high-level understanding of requirements at a barely sufficient level to plan the next step in the process. That next step is typically a decomposition of the solution into releases and iterations within each release. Releases usually encapsulate a large group of functionality (ie. bill payment for online banking) whereas iterations within a release are intended to deliver a fully usable and production ready subset of the release’s functionality. Each iteration is timeboxed so work must be carefully selected and prioritized to deliver not only something production ready but something of high value to the end user.

The word “timebox” may have stood out as a contradiction. Didn’t I say that Agile = Q and not T? Well, although each iteration fixes T, there is most certainly nothing in any agile method that fixes the number of iterations in a release or the total number of releases. Both must be allowed to vary as the requirements ​change as a result of progressive elaborat​ion​. Certainly, that means that total T is never intended to be fixed ​in an​ agile project. Q is the only focus. Everything else must vary to accommodate.

So agile must be better, right? Not so fast. Everything has its place. The intent of my argument was to arm you with the information to choose which best satisfies the requirements for your project. Just like it’s always been with the engineering of software solutions, there are no silver bullets.