Fog Creek Software
Discussion Board

The Goal and Critial Chain

Both books mentioned in Joel's most recent posting are worth reading (and re-reading).  Both also afford some insights applicable to software development.

As Joel notes, _Critical Chain_ is a worthwhile read even if only for the discussion of schedule padding and buffer management.  An equally important take-away, though, is the idea of protecting your contraint resources.  Your best option for protecting your commitments is to identify and protect the things that your commitments are most sensitive to. 

_The Goal_ isn't as obviously applicable to software development, but there's good information in there if you look hard enough.  The important idea is a focus on throughput and the things that constrain it.  If you are designing tiered systems that need to scale you will learn that no matter how hard you optimize, if you don't focus on your bottleneck, you won't have a positive impact.  In fact, you can actually degrade performance by being naive in your optimizations.

Constraint management also provides some insight into how to manage traditional waterfall-like development processes.  If your developers are the bottleneck, you need to do whatever you can to relieve them, so offload the testing, for instance.  If, however, your testers are your constraint, then your developers should give some of their excess capacity to the testers by doing more careful pre-screening of their work.

Anonymous Jonah
Wednesday, November 20, 2002

There are two lessons from The Goal.  First: measure the right things.  If a factory considers inventory an asset, then it will tend to increase inventory (a Bad Thing in the lean production world).  This is not a new lesson in the software world since we don't have a decent measure of software output (function points are closest).

Second, the 'goal' is throughput.  Reduce your time to market so you can become responsive and flexible to changing business and customer demands.  Anything that slows your ability to get features in front of users quickly is moving you away from the goal. 

Wednesday, November 20, 2002

For those interested, the following paper is a good summary of lean production

Wednesday, November 20, 2002

We actually used the process here at my company for a largish project (around 60 engineers, plus maybe another 20 in India).  I don't think the system can work unless you have very disciplined management.  The specific problem in our case was that unlike typical proj mgmt methodologies, where each bullet point represents a feature or an established and well-understood development task (documentation, system verification test, etc), the single largest task in a critical chain plan is the "project buffer".  As I understand it, the size of this buffer can vary dependending upon the past experience of the organization, but in our case we chose 50% of overall development time.  As you can imagine, this made a very tasty target for pointy-hair-boss types.  They could see that the other boxes were real tasks, but in their minds they could eliminate the project buffer without changing requirements.  I think the exact words used were, "We'll manage like we don't have a project buffer."  The complexity of the critical chain algorithm hid the fact that this meant that each task was now allotted less than 75% of the time the engineer estimated.  And there there was no space for additional tasks that became needed as the project progressed.

The other problem is that the algorithm is complicated enough that management types would spend hours fiddling with it until they came up with the answers that they wanted - not in a substantive way, like adding resources or removing requirements, but in an almost cabalistic manipulation of the model, with the mystical expectation that reality could be thus molded to their will.

Needless to say the project is a disaster - months overdue, mandatory 55-hour work weeks and morale at an all-time low.

Granted, I work for idiots.  But my experience here has taught me that overly complicated project management systems can allow undisciplined mgmt an end-run around the rule that "engineers create estimates".  And I think that few would argue that disciplined software project management is a rare commodity.  I was originally a little skeptical about Joel's suggestion to use Excel for scheduling, since one can't determine dependencies in excel, but now I'm thinking that the less sophisticated the project management tool, the more power the engineering team has to control the schedule.

(sorry for the anonymous posting, the people I work for are vindictive as well as stupid).

anonymous coward
Wednesday, November 20, 2002

coward, you make a good point.  For this (or any, really) method to be effective, management must understand it and get onboard with it.  If not, you get results like the ones you are experiencing.  In addition to getting them educated about the buffers, though, I've also found it very difficult to get them to stop using plan dates and milestones as measures of progress.  The critical chain uses buffer penetration as the main indicator of schedule health, but the managers get bent out of shape without milestones firmly linked to dates. 

We've used this method several times successfully, but the management interface has often been a trial.  One successful tactic is to put the ball in their court.  For instance, with the "expendable buffer" problem you mention above, I often tell them that the size of the buffer is inversely proportional to the risk they assume.  So I ask them what risk level they are comfortable with and size the buffer appropriately.  Since most of them are a bit cowardly (no offense) about that sort of thing, they generally give me a very small number for risk tolerance.  This of course means I can make the buffer larger.  The important thing is to get them to commit to a number.  Publish that number with the project plan every week alongside your other assumptions (capacity, utilization, budget, etc).  If they refuse to make a commitment, compute the assumed risk based on whatever schedule they force on you and make sure they know about it.

You might also try "helpfully" loaning them books or papers that could help educate them.  Keep bugging them about reading it and try to get them into conversations about it - no one likes to look dumb ;)  Remind them that your goals and theirs are identical - to get a high quality product out the door as quickly as possible at an acceptable cost and risk exposure.  This sometimes helps to diminish the adversarial relationship that springs up.  Make sure you report indicators of cost, risk, resource capacity and utilization, quality, and so on each time you report on schedule.  These things all constrain each other so if they see risk or costs climbing you have an opportunity to do some tradeoff with schedule.  This is especially true these days when everyone is trying to manage to cost goals.

burned out PM
Wednesday, November 20, 2002

"The Goal" really provoked me into rethinking a lot of my beliefs about software projects.

Basically, I started to read the book with the idea that I'd learn about the Theory of Constraints, and then "Critical Chain" would tell me something about Project Management.

I pretty much flipped the 'bozo bit' on the idea that I could learn much about software development from a factory.

But now, having read the book... I'm intrigued. Up to now, I've always said that software development isn't like manufacturing, and that's why manufacturing methodologies don't work for softwre development. And for proof, I've pointed out how projects based on a simplistic manufacturing model fail.

But the premise of the book is that factories built on a simplistic manufacturing model also fail. What if the problem is with the model and not with the applicability?

So now I wonder... for example, what if software development projects have Inventory? How much is Intellectual Property (like designs, requirements, and code) like inventory of Work-In-Progress?

What if 100% utilization of people to produce IP is actually counterproductive to software development?

Like I said, I am fundamentally disturbed by this book. In a good way.

Reginald Braithwaite-Lee

Programmed. In me somewhere, he thought, there is a matrix fitted in place, a grid screen that cuts me off from certain thoughts, certain actions. And forces me into others. I am not free. I never was, but now I know that; that makes it different. --Philip K. Dick, "The Electric Ant"

Reginald Braithwaite-Lee
Tuesday, November 26, 2002

*  Recent Topics

*  Fog Creek Home