Is The Triple Constraint Agile?

Let's revisit this "triple constraint" business I blogged about in my previous blog entry. What's this doing in the "Agile" category? Isn't the triple constraint that thing from the Project Management Body of Knowledge (PMBOK), which is about classical non-agile waterfall stuff? In a word, no. I don't know what much about the PMBOK, but I believe the triple constraint applies to any project, regardless of how it's planned.

The triple constraint is a model for doing reasoning about planning. The style in which planning is done, whether waterfall or agile or something else, doesn't affect the fundamentals of the model. The style certainly affects the outcome of the plan, but that's a different story.

Consider a waterfall, plan-everything-then-execute approach for managing a project. The triple constraint certainly applies here. You're given a certain resource (cost) budget, a desired scope for what to deliver, and a target date for delivery. It's usually the case that you develop time estimates for everything and the end date that pops out is far later than the target date. So you have to add resources or cut features to pull in the date. You have to make the tradeoffs the model implies before you can formulate a credible plan for delivering. Then (theoretically) you execute according to plan.

Now consider an agile process. It doesn't matter which, really, since they pretty much all use an incremental planning model. During each planning cycle, you have to make the same tradeoffs among cost, scope, and time. The difference is that you do this incrementally instead of all up-front. For example, consider an urgent customer request that comes in the midst of a release cycle. At the next iteration planning meeting, you reshuffle the project backlog to put the customer's requests at the top, which pushes everything else down. This implies that you can deliver the original set of features at a later date, or you can deliver a reduced set of features at the same date as originally planned: a classic triple constraint tradeoff.

The key point is that incremental planning provides a structure for making these tradeoffs on a regular basis. By contrast, in a waterfall approach, making changes of this sort is viewed as a project planning error: you have to replan everything. This example embodies the line from the Agile Manifesto, "Responding to change over following a plan." The alternative is not to make the change at all, which gives rise to the idea that waterfall approaches tend to resist change.

Agile planning approaches embrace the triple constraint wholeheartedly as a normal part of the planning process, whereas waterfall approaches make all the tradeoffs up front and hope they stick.

Comments:

Post a Comment:
Comments are closed for this entry.
About

user12610707

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today