Loading ...
Sorry, an error occurred while loading the content.

56212Re: Well done waterfall+agile

Expand Messages
  • woynam
    Nov 9, 2012
    • 0 Attachment
      That'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 scrumdevelopment@yahoogroups.com, 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 (
      > http://ensemblemc.com/wp-content/uploads/2011/10/2010-Ensemble-paper_Commitment-Based-Project-Management.pdf
      > ).
      > 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
    • Show all 27 messages in this topic