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

56229Re: [scrumdevelopment] Re: Well done waterfall+agile

Expand Messages
  • Michael James
    Nov 11, 2012
    • 0 Attachment
      As I meant to write earlier, I always appreciate hearing experience reports, such as the one you wrote Jose.

      I wouldn't choose to do waterfall for software development, but if that were beyond my control I'd at least introduce some feedback loops (as you did) to reduce the risks.

      --mj
      (Michael)

      On Nov 11, 2012, at 12:37 PM, "JoseS" <JOSE.SOLERA@...> wrote:

       

      Thanks, Mark. In my experience, though, there's room to be flexible even when told you have to do it a certain way. Senior managers don't have time to micromanage what is going on. The role of the PM is to figure out how to make the space so that the team can be successful. Don't call it a Map Day, but a Planning Day. You'll come out with a very good plan out of the first day. Subsequent meetings will be to assess where we are and "refine the plan." Senior managers will be OK with that.

      It may be still, as you say, a train wreck. But that's no reason to run away. Still, we may agree to disagree.

      All the best,

      Jose

      --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
      >
      >
      > 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.
      >
      > Mark
      >
      >
      > --- 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