56212Re: Well done waterfall+agile
- Nov 9, 2012That's a nice write-up, Jose, but I don't see how it's going to help the original poster. The OP describes a by-the-book (serial) waterfall approach involving a completely new team in a new domain. This is classical crash and burn territory.
It doesn't sound like they have the option to have multiple planning sessions every 6 to 8 weeks (i.e. Map Days). As described, they have to have *one* plan at the beginning, and they'll be held against it.
On top of that, they won't deliver *any* working software until the very end of the process, but somehow it will have to work exactly as the customer wants it. Hmmm. Yea, right.
This is a train wreck waiting to happen. The only way they're going to make money on the project is if they sell tickets to the crash.
--- In firstname.lastname@example.org, Jose Solera <JOSE.SOLERA@...> wrote:
> I beg to disagree with those who say not to do it. If you have to, you have
> to. I had to do it once (no choice, believe me!)
> What I did: I layered an approach developed at Intel for their
> semiconductor design projects and now known as "Commitment Based Project
> Management" or CBPM for short. It is a domain-agnostic (it's been used not
> only in semiconductor design and software development, but also
> construction, defense projects, medical device development, education,
> event-planning, and numerous other domains).
> It starts with what we call "map days". These are planning days through
> which the entire team develops a rolling plan. Details are planned as far
> out as the team is comfortable with, typically 6-8 weeks. Owners make
> commitments as to when they'll deliver an item. They work with the
> consumers or users of these deliverables to ensure agreement on what is
> being delivered. Subsequent map days are scheduled, one at a time, at the
> end of the previous map day.
> Regularly (at least three times a week some times daily) progress is
> reviewed and adjustments made to the plans. Issues are encouraged to be
> brought to light as soon as possible.
> Deliverables and status are tracked through an automated Excel spreadsheet.
> More details are available in Timm Esque's book describing its development:
> *No Surprises Project Management*, at the LinkedIn group Project
> Acceleration thru Commitment Based Project Management (
> http://www.linkedin.com/groups?gid=1944064&trk=hb_side_g), in workshops
> that Timm and I deliver, in a white paper I published (let me know if you
> are interested), in Timm's company website (http://ensemblemc.com/) and in
> a white paper he's published (
> To get back to my story: I had to use a home-grown waterfall methodology.
> We planned the effort using CBPM, avoided saying yes to the unrealistic
> date requested by the customer by demonstrating its impossibility in the
> first map day, made a commitments early on (second map day since we needed
> to see if we could deliver portions of the software -- Agile!) and hit each
> and everyone of our commitments on the nose. "There were no fires!" was the
> best comment I heard.
> Would I use this instead of Scrum or XP? No! Those approaches are designed
> for software development. But if I have to use waterfall, yes. Or for some
> other less-SW-development time of IT projects such as migrating
> applications to a new security system, deploying servers, etc.
> Contact me or Timm (through his website) if you want more details.
> All the best,
> Jose Solera, MBA, PMP®, CSM, CSPO, CSP
- << Previous post in topic Next post in topic >>