AgileSoftware

In the new book "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle, they describe the "aha" experience of learning the difference between "defined process" and "empirical process".

A "defined process" like a chemical reaction, has well-known inputs and well-known outputs. This "manufactoring model" has influenced methodology develoment and CMM.

An "empirical process" relies on observation and verification, for managing unpredictable and unrepeatable outputs.

The "aha" experience was realizing that software development is an empirical process, best managed by frequent inspection, rather than by defining a "manufacturing" style plan that can't cope with the unexpected.

--KeithRay

I've heard that Lucent was a public advocate of "Critical Chain project scheduling". Can anyone tell me what that is? (Would it assume that software development is as predictable as chemical manufacturing?)

Never heard of it, and I've worked with Lucent for a long time. - JerryWeinberg

BTW, there's an Agile Alliance sign on page at http://www.pragprog.com/cgi-bin/display.nrb

A web-search found <http://www.focusedperformance.com/articles/CCPM.htm> which describe Critical Chain Path Scheduling and buffer management. The underlying assumption is that each task estimate normally has padding, so CCPS takes all the padding from each task and puts the padding at the end.

It seems wonderfully complicated, perfect for selling CCPS applications. I think a more sensible approach is to use XP's "velocity" tracking, where actual work done in an iteration is used to predict how much can be expected to be done in future iterations. (and velocity is recomputed after each iteration.)

CCPS might be useful for coordinating multiple teams, but Scrum's heirarchy of daily 15-minute meetings seems like a better, more hands-on way to coordinate multiple teams -- you can see immediately if people are facing roadblocks.

Maybe CCPS is more suited to REALLY large organizations... at a high level of tracking (task == small sub-project measured in months?)

Keith Ray

The Critical Chain scheduling model is part of Eliyahu Goldratt's Theory of Constraints. I have read some of Goldratt's work and also some related books. This is my understanding of some of the principles.

In any process there is a weakest link. The weakest link can be the slowest part of the process or a machine, that when it goes down, takes a long time to fix. If it is not possible to strengthen that weakest link, you protect it with buffers of time or resources so that it will work at its comfortable capacity without being stressed.

In software development I have experienced the creation of User Documentation as the critical link in the chain. The number of new products being produced by software development exceeded the capacity of the Documentation group. The writers of the user manuals were often stretched and stressed beyond their abilities. So, how I interpret the use of Goldratt's work, is that software development would be slowed down to match the capacity of the Documentation group. In this way Documentation would not run the risk of burn out.

How does XP or Agile Software balance the capacities of all who contribute to a software product? I am familiar with the testing/coding combination. But what about the writers of User Documentation, the creators of Software Installers, or those developing the marketing campaign?

MarianneTromp 27Dec2001

XP would have writer(s) of User Documentation on the same team as the programmers, testers, etc. They would create the docs incrementally, the same as the programmers are creating the app incrementally. If there are too many teams and not enough writers, XP doesn't have much advice on that issue...

[ I recall a Rant -- probably by Ron Jeffries -- about how come the Doc people can get their estimates for doc-writing respected, but programmers can't get their estimates for program-writing respected. Here is his more recent writing on that subject: ]

An XP team should create an installable version of their product every iteration (within reason -- some custom-hardware+software teams may not be able to do that.) At my company, the "installer group" can turn out an installer within a few hours, probably because they automated the process, which XP recommends (if it hurts, automate it)... XP recommends automating everything that would otherwise slow down the testing+developing process.

I haven't heard about coordinating Marketing campaigns... (Marketing should be helping the XP Customer prioritize stories.) Symantec just completed a year of XP used in three teams. I think these were new versions of old products, so their marketing probably didn't do much different than they usually did.

KeithRay Dec. 30, 2001

Bob Lee sent this to me by email, and asked that it be forwarded to Marianne... I'll post it here... KeithRay Dec. 30, 2001

Keith, Goldblatt and his folks are obsessed with controlling "Parkinson's Law" the theory that people slack-off to waste all available time.

Read Tom DeMarco's "Slack" or "Peopleware" books.

Note also, that CCPM is selling a Methodology ["big M"] designed to squeeze-out all that slack from those pernicious people. Is that how it reads to you? [Keith -- yeah] It does to me.

The thrust of CCPS/CCPM seems to be that task planning happens from above by people who actually understand in detail what needs to happen and can realistically predict the time to complete these tasks. This view trivializes the knowledge workers who actually discover what *really* needs to be done by immersion. CCPS appears highly at odds with software project development, where the validity of the estimations that go into planning is so questionable.

[KeithRay -- Might it work if the task estimating comes from the task workers? But programmers are almost always optimistic. You need XP's "velocity tracking" to correct for that optimism -- though in my XP-ish projects, over-estimating seems to happen almost has often as under-estimating.]

Think about how XP dices problems and embraces change. This is active accommodation to the uncertainty problem. Instead of controlling from "above" and assuming that people are interchangeable parts, XP assumes wide variations in experience and background. In the planning game, team estimation *and* self-selection of estimated tasks improve the quality and reality of mini-estimates. CCPS appears to advocate the "big-bang" drop-dead date: "The only thing that matters is the Due Date!" That's not appropriate for most projects I can think of!

Sorry I can't reply within the WIKI - I didn't pay the admission to AYE, so I don't get write privileges. Could you share this with Marianne Tromp? I don't have her e-mail ID handy.

Yours Rantingly, Bob Lee

Robert E. Lee 455 Parrish Rd. Honeoye Falls, NY 14472 (585) 624-5051 Dundee @R ochester.rr.com

But Bob, you're a special person in AYE history, because you named the conference. I will hereby reward you by sending you the password so you can participate. (In separate mail, of course.) - JerryWeinberg

Well, I've used CCPM, and found it to be quite effective. When I put the padding/buffers at the end, and maintain a healthy but not rushed pace for the project, people are more likely to make their estimates. Not all of them, but most of them. And, I can keep reviewing the critical paths to make sure I'm working the critical paths continously.

CCPM does not assume that someone from "above" estimates the tasks, but that an individual plans their tasks in clock time, assuming there are no interruptions, etc., and that the padding will be added on at the end of all the tasks.

There are always people who will use an Methodology (especially with a capital M) to beat on people, but CCPM doesn't necessarily do that. Certainly not if you read Goldratt. -- JohannaRothman

With that interpretation, I accept CCPM as reasonable. That wasn't the impression I got from the web site above, however. Perhaps some disciples getting too enthusiastic? BobLee

Ok, here's my rant: Many people who "discover" a new "process" (which may just be a technique) go bananas. They use this new process as a hammer, and everything is a nail. And, many of these people are process police who are convinced they know how everyone else should work and aren't shy about telling them. Drives me beserk. (I know, tell us how you really feel, JR :-) In any case, many people who discover a technique that seems to address a problem they've met and been unable to solve get religion abou this technique. In the process, they believe the press about the technique. Sometimes, the founders of the technique believe their own press, which is unbelievably stupid, but human. So, CCPM is a useful technique, but there's no need to use CCPM as a hammer on other people.

Many of us project managers actually put buffers at the end back in the 70's and 80's, when we noticed (at least for me, I noticed), that when I just kept working, that sometimes my estimates were higher and sometimes were lower, and if I just put all the buffer at the end, I ended at about the same time, but I didn't have to work overtime. I have things I like to do in my life aside from work.

I really do NOT believe there is One Right Way to work (at anything), but a collection of techniques that many people find useful in appropriate situations. I realize that's vague, but it's what I believe. CCPM is one of those useful techniques, as long as it's applied appropriately. -- JohannaRothman

We agree. I also find that there's usually a nugget worth panning for in most rivers of sludge. -- BobLee

I offer my own extension to Johanna's rant. I'm old enough to remember things that better professionals than me consider lost history. I go pineapples when "the next big thing" claims to have invented techniques in use long before that thing became big. My biggest complaint is OOP, which press denigrates Structured Programming, while OOP is 70-80% techniques advocated by that predecessor. I prefer Isaac Newton's "shoulders of giants" approach. Now, having said that and being human, I admit, with a red face, to being a hammer more than once in my life. MikeMelendez 020108

Dick Hamming once told me that in computing, we are midgets standing on the toes of other midgets.

I guess each generation has to discover the same truths for themselves. - JerryWeinberg 020108

As if on cue, Barry Boehm has an article in the January 2002 IEEE Computer: "Get Ready for Agile Methods, with Care". MikeMelendez 020111

I have been reading this, finding related stuff & reading it & reading Adaptive Software Development since this link was first set up. I passed some of the info on to my favorite Technical Architect & he started reading about XP. We have been very unhappy about the level of process we are using on our high change projects. The 2 of us ganged up on our manager, talked to him, gave him stuff to read & now have permission to submit a proposal for a small project using some variation on this methodology. I just want to say thank you. SherryHeinze 020117

Updated: Thursday, January 17, 2002