Another Sprial

Frank Patrick says here that there are add-ons for Project that help model the uncertainty related to the number of spirals or iterations in a project. I have not looked at these add-ons but I'm sure that they do what he says they do.

He also says:

Although one aspect of the spiral is the unknown nature of how many times one goes around. That's what basic PM software does not handle so well.

My question is why should it 'handle' this up front? Sure you don't know how many times around the spiral you will go but you know you will go at least X times around. So you build your schedule around that number and then if you are pretty sure you will go around X+1 then you add that extra on the end. Then after you go a few times around you figure out that the real number will be more like X+3. So then you add those on to the end to make your model better.

Schedules are not deterministic so why should the model we build up front be anything more than our current best shot at the future?

Now that said I would love to see these add-ons and check out what they do to help this. But I do tend to concentrate on the core product. I have to since I cannot count on my customers using this add-on or that add-on. I CAN count on them using Project and Project Server. So I tend to try and find workarounds within that framework first before I look to 'custom' solutions. But I will take a look at some of these and try to report back on them with my thoughts.

Comments

[Glen Alleman]

This month's CrossTalk has several articles on agile development, including Spiral. The Spiral article is embededed in the WinWin model focused on COTS acquistion.

The number of "build" (travels around the spiral) depends on the lifecycle plan for the procurement. Depicting these spirals in Project is not limited by Project's capabilities, but only by the users effort to layout the process.

The structure of the number of Builds is NOT unknown in Spiral, so there woudl be no problem defining the WBS and project structure in the beginning.

[Glen B. Alleman]

Clarke and Brian,

I've looked at Frank's link to the Segway reference. I couldn't find any details there but one thing struck me.

The quest for "predictable, repeatable systems executed at or below advertised cost," is not actually what agile development is about. Agile searchs for reliable methods. Repeatable turns out to not be much good unless you're done the same system over again. Since software development is not "production work," like building Segway's the repeatable process steps are not the first thing you would work on in an agile shop.

In a CMMI shop repeatability is high on the list. But CMMI and agile are orthoganal paradigms - even though I'll be speaking about how they are compatible in an upcoming Cutter Journal article.

My question still is "how do the mechanics of CCPM fit with agile, say XP or Scrum?" Not from the theoritical "it could, or they should," but from a real life day to day XP projcet point of view. Since we practice XP I'm interested in how CCPM could add value.

Finally from the description provided on Frank's site the description of a "story" it's quite what you would find in a XP story. They sound more like the metaphor like descriptions, much to high level. One test of a story is the ablilty to write the test first - Test Driven Design (TDD). So how would you test "secure funding" other than have the funding and "complet proof of concept" other than come to an end of the proof of concept phase.

Personally (and this is just me) it sounds like NewLane has some really nice development process based on CMMI, ISO 9000, BSC and the like and the took on the moniker of "agile."

Interestingly the only "agile" on the NewLane site is Agile, Inc. a Product Lifecycle Management system. So hoepfully this "agile" was not confused with the agile of XP or Scrum.

I would be very intertested though if someone could get the text of the "article" referred to in the positng.

[Glen Alleman]

Clarke,

Not to be a purist (too late) but the Segway story sounds more like CCPM than XP. The planning game at the beginning of iteration is "time bexed."

Where would buffers come from? How would you size the buffer in the absence of a SOW?

[Clarke Ching]

Take a look at Franks discussion about how TOC's Critical Chain AND agile methods were used to build the Segway Human Transporter.

http://www.focusedperformance.com/2003_04_01_blarch.html#200120057

Sometimes you need both.

[Glen Alleman]

Brian,

You are correct in your assesment of Spiral and the later itertaive and incremental methods.

One of the core premises of spiral and it's agile cousins (if you accept that spiral was one of the first iterative development methods) is that the number of iterations depends on the needs of the custom, not some pre-planned value.

The conjecture that MSFT Project is not well suited to planning the number iterations ignores the fact that agile methods are not based on “management as planning.” Planning for the number of iterations in a schedule is counter to the agile methods.

Planning “within” iteration is critical to any agile method.