Fixed vs Estimated: Understanding the Methodology Triangles

  • 0
1024 768 Adrian

Ok get your hard-hats on, as I’m going to be using a construction analogy. I was talking with my friend Sean the other day about Agile (Scrum) vs Waterfall, and we began using the analogy of building a house to compare the two methodologies. At first I didn’t think the analogy was going to get us anywhere – I thought we were stretching the idea of house construction to try and fit the frameworks just to make it familiar, and that at the end of the day the model didn’t really work. But the more we talked, the more I started to like the comparison. It’s not perfect, of course, but it’s also kind of fun and easy to grasp. So I’ll present it here and let you decide if it works or not.

But first, before I get into building a house, I need to explain a few things about triangles…

The Iron Triangle

So as any project manager will tell you, the “Iron Triangle” of project management refers to the balancing act of managing scope (or requirements), schedule (time), and resources (budget). In a perfect world where we can all estimate effort to a tee, complications never arise, requirements don’t change, and deadlines are always met, each of those points on the triangle can be fixed. Fixed cost, fixed delivery date, fixed requirements.

[image_frame style=”framed_shadow” width=”390″ height=”249″ align=”center”][/image_frame]

Of course, as we all know, the world is far from perfect. This means that having each point fixed, while ideal, is unrealistic. So where can we compromise? Well, the answer – as it often is in life – is “it depends”. And one of those dependencies is whether you are using a waterfall or agile approach on your project.

Waterfall Triangle

In a waterfall project methodology, your triangle would typically look like the one above, and we can go one step further by defining the points that are going to be fixed, and the points that are going to be estimated. We call this triangle a “plan driven” approach.

[image_frame style=”framed_shadow” align=”center”][/image_frame]

So as you can see, in Waterfall we have fixed scope and requirements, but in order to make sure we deliver all of our required features, we need to be a little flexible with our resources (and budget), and schedule (deadlines). If we absolutely need the product to have functionality X, well then we just may need to delay the release date by a week or more. That’s the compromise in an imperfect world.

Let’s get into our house construction analogy now. When building a house using waterfall, the scope is our house blueprints. We are saying that the house is not finished until it meets all of the specifications in our architectural diagrams. If the price of marble goes up while in the middle of building our fancy marble staircase, well then our budget goes up. But we still have to build the marble staircase because that’s what’s in the plans. The blueprints are fixed at the time we start to build, but our budget and date of completion are estimated. If it takes a month longer than we expected to build the master bedroom, but that’s what’s specified in the scope, then our deadline gets pushed out a month.

Now here’s a scenario where waterfall starts to break down, or at least puts our project at severe risk. Let’s say, after 6 months of construction, our initial requirements change. The person we are building the house for has just recently won Iron Chef, and because of this they want to have a much larger and fancier kitchen than what’s in the original plans. And they want a gas range stove instead of the original electric version. The kitchen is located on the ground floor, along with the living room and dining room. 6 months into construction, these three rooms have already been built and we are already working on the second floor rooms. There hasn’t been any piping laid for natural gas. Now, with this change to the architecture, we are going to have to remove all the second floor construction and make modifications to the ground floor layout in order to accommodate the larger kitchen and install a gas line. This can all be done, but our effort, time, and materials has all just been significantly increased from the original numbers. We tell our Iron Chef champion that the cost to build the house has just risen by $100,000 and will be delayed by 2 months.

This scenario highlights how waterfall is a very poor methodology for responding to change. With the recognition that it is often very hard to know all of a project’s requirements up front before we start building, people figured that there had to be a better and more adaptable way to build things – especially for projects where it is known from the very start that the requirements may change, or are not fully defined. Enter Agile…

Agile Triangle

The Agile triangle is said to be “quality driven”. It’s focus is on maximizing value while adhering to fixed resources and deadlines.

[image_frame style=”framed_shadow” align=”center”][/image_frame]

In the Agile triangle we are committing to a fixed schedule (in Scrum we do this through timeboxed iterations called sprints), and fixed resources (we keep the Agile team together throughout the project to maximize team collaboration and cohesion). Thus when push comes to shove, it is the scope that needs to bend. In Scrum, however, we ensure that even if we have to compromise on scope, we are still delivering the highest priority items through a prioritized backlog of user stories. (Note that Scrum is a popular framework for Agile, but is just one of many established frameworks out there, like Kanban, XP, Lean, AUP, etc.).

Back to building someone’s dream house… I’m not recommending anyone actually build a house in the manner I’m about to describe, but to use the same analogy, building a house using Agile would be akin to building the foundation, kitchen, living room, dining room, master bedroom, guest room, etc. all as stand-alone, independent rooms that we eventually connect together to get our finished house. When it’s time to construct the living room, we begin with asking what the future residents are going to want in their living room, diagram out the blueprints accordingly, build the actual room, and test it for structural defects, all in one go. When the living room is finished, it is a fully functioning and complete living room, ready to be used to watch the big game by the whole family. But wait! What happens when it’s intermission and it’s time for a pee break? Well, um, unfortunately the bathroom hasn’t been built yet. Maybe we should make that the next priority on our list (that is, our backlog)?

The advantage we have in building our house this way, though, is that now when our Iron Chef comes to us and asks for changes to the kitchen, the only thing we need to do is modify the kitchen – all the other rooms are unaffected. Yes, we are going to need to spend extra time and energy to make the changes, but not nearly as much as under a waterfall methodology. Also remember that our resources and schedule are still fixed, so what are the other consequences of having to do this unanticipated work? Well, we go to our backlog and ask our Iron Chef if the wine cellar he wanted built in the basement is a must-have or a nice-to-have. He tells us it’s more of a nice-to-have, and so we move it to the bottom of the backlog and say that we are going to do our best to still build the wine cellar, but we may not get to it. But at least our chef will still have his dream kitchen, and that’s more important. We are maximizing value while staying on time and within budget.

Putting It All Together

Putting the Waterfall and Agile triangles together gives us the following:

[image_frame style=”framed_shadow” align=”center”][/image_frame]

Of course, things are rarely so black and white in life, and the same goes for methodologies. We are probably better served to think of Waterfall and Agile as being on a continuum. When doing a Drupal project, for example, it’s hard to be pure agile. You typically need to set up some foundational architecture like content types, taxonomy, user roles, etc. at the beginning – if they end up needing to be changed later in the project it can cause a big headache for your developers because things like Views and search parameters can be affected. Back to our house analogy one last time, this would be the equivalent of needing to establish a central plan for your electricity wiring and plumbing. You can still build your rooms as independent modules, but when you fit them all together the wires and pipes need to all line up or you’re going to be faced with some major renos (or the equivalent of refactoring in software development). So in the case of a Drupal project we may divide our project into a waterfall-ish “plan driven” methodology at the beginning, turning into an agile-ish “quality driven” methodology once we are comfortable with the foundational architecture. Some people like to call this hybrid methodology Scrumfall, and with software platforms like Drupal, Alfresco, and SproutCore it usually works pretty well.

The Triangle Traps

The last thing I will mention is a warning to avoid the “triangle traps”. The triangle traps happen either when you start to try and stretch and warp the points of the triangle, usually as a result of separating costs from resources, or when you think that you can build good products just by throwing more people at it.

I like to call the first one the “Snow Cone” trap.

[image_frame style=”framed_shadow” align=”center”][/image_frame]

In this scenario we are saying that our scope, deadlines, and budget are all fixed. So what do we do when life happens and unforeseen events challenge our project or our requirements change? One option is to increase the resources invested, such as adding more developers, testers, designers, etc. But remember that our budget is “fixed”! So either those people are volunteering their time to make the project successful, or somebody or some organization is eating the hours (in other words this triangle is a fallacy – our costs aren’t really fixed at all).

The second trap I like to call the “Just Get it Done!” trap. In this case, “just get it done” may be followed up with “no matter what the cost!”

[image_frame style=”framed_shadow” align=”center”][/image_frame]

Here we have a fixed set of features that absolutely must get delivered, and they must be delivered by a certain deadline. This scenario is very similar to the first one, except that in this case we are aware that you can’t really separate costs from resources – adding more resources means increasing the project’s cost. But our project sponsor has deep pockets, and he wants his dream product delivered with all the bells and whistles in time for Christmas. So they tell us to just do whatever it takes to make that happen, meaning throw as many resources and money at the project as is needed.

Now, this can actually work, but I would argue that only to a limited extent. Increasing a team of 5 people to 8 people will more than likely increase productivity. But at a certain point the model typically starts to fail. Given the stress and pressure of a looming deadline, increasing the number of bodies can actually have the reverse effect of decreasing productivity from its original level as project managers run around trying to figure out how to ramp up and resource the new team members. For Agile projects, they warn that changing a team’s members in the middle of a sprint/release/project usually results in a temporary drop in productivity while the team re-adjusts, before eventually getting back (hopefully!) to around it’s previous velocity. They also recommend composing your Agile teams of only 7 plus-or-minus 2 people (for large projects, then, you would have multiple teams, but each one consisting of no more than 9 people).

So if your project manager crunches the numbers and determines that the team can deliver all the features by the deadline, and all that will be needed is to add 80 more man hours to the project, it’s probably a no-brainer. But if it’s one month to Christmas and its going to take a few thousand man hours to finish the product, on a team that was originally scheduled to burn just a few hundred, I can’t imagine that even throwing enough people at the project to reach those thousands of hours is going to result in a successful outcome. Possible, but unlikely. And certainly expensive.


So our Iron Chef’s dream house is now built, large kitchen and all. Did we build it using Waterfall or Scrum, and did the wine cellar eventually get built? How did we do with our budget? Are we on target or did we end up with a sizable additional bill? And is the house ready for our chef to move in by the April 3rd deadline so he can host Easter dinner at his house this year?

Project methodologies are great frameworks to help us deliver successful products (websites, applications, hardware, gadgets, etc.), and one of the great things about them is that they give us many different ways to do things. There is no “silver bullet” of project management, nor should there be. Just like every project is different, each project’s methodology should be different as well. But we all need starting points. There’s no sense in developing a whole new methodology every time a new project comes through the door. So the hope is that by better understanding the nontrivial balancing act between scope, schedule, and resources, we can leverage our knowledge of waterfall, agile, scrum-fall, etc. to help us achieve the best results according to the project’s demands.

Okay, gotta run… The Iron Chef just called. His wife has taken up swimming and we need to put an indoor pool where the games room used to be!

  • 0


Adrian, or AJ, is the founder and Director of Technology of Pop Digital. He has spoken at tech conferences around the world, and published numerous articles about Agile methodologies, UX design, Information Architecture, and Web Development.

All stories by: Adrian