Friday March 23, 2007

Mike Cohn at bayXP

I attended Mike Cohn's talk at bayXP on Tuesday (March 20, 2007) entitled "Planning and Tracking Agile Projects." Mike is quite open about all the stuff he presents. His presentation is available at http://mountaingoatsoftware.com/presentations along with a bunch of other stuff.

This wasn't so much a presentation as a workshop. A couple times Mike asked the audience to form small groups and perform some planning activities. In one instance he passed out decks of "planning poker" cards and had us play planning poker with (that is, give estimates for) various made-up tasks. The dynamics of planning poker are quite interesting. It really helps you flush out unstated assumptions and disagreements about what a task involves.

The event was hosted at Google, which provided excellent food (hummus, baba ghanoush, pita, spinach in phyllo, falafel, etc. plus an excellent selection of beer, wine, and soft drinks). Combined with Mike's excellent talk, and the low, low price of admission -- $0! -- this evening was an exceptional value.

Thanks to Mike, the bayXP organizers, and Google. Posted by smarks ( Mar 23 2007, 01:40:24 PM PDT ) Permalink

Tuesday March 13, 2007

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.

Wednesday March 07, 2007

The Triple Constraint

Here's a bit of elementary project management: the triple constraint. This was explained to me by an experienced project manager colleague some time ago, who drew a diagram similar to the one below on my whiteboard.

The "Q" in the middle stands for quality. The point is that the variables are interrelated: changing one affects both of the others. If you don't account for the changes to the others, you "break the triangle" and it's quality that suffers.

Now I don't really have any formal project management experience, but I've been on a lot of projects. I've been on projects where the end date and the size of the team ("cost") were fixed, but scope was increased. And what do you know, when we got to the end date, there was a huge pile of bugs. When my colleague presented this model to me it seemed blindingly obvious. Yet, it seems that many people just don't get it.

(Some literature considers "triple constraint" to be an obsolete term, preferring instead to consider cost, quality, scope, and time as a set of four variables. This goes against the Received Wisdom of Quality, which states that Quality shall not be a variable. But I digress.)

Upon further reflection, it's not that people don't "get" the triple constraint. The real problem is that people are unwilling to confront the results of thinking through the model.

Now, like any model, there are some qualifications. I'm thinking of two in particular: "in the long run" and "all other things being equal." I'll cover these in separate blog posts.