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

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

Expand Messages
  • Cass Dalton
    Nov 9, 2012
    • 0 Attachment
      It also depends on how closely the customer is looking at the project execution.  You can do an agile process internally and project waterfall milestone out.  If the customer is at your site every day or you are at theirs, you're SOL.  And if the coding/implementation phase is large enough, you can do agile within this phase and stay waterfall on the front and back end.  Don't listen to the people that say it's impossible.  I work in DoD contracting and it can be done.  We do it here more and more.  But nothing you do will every really be scrum, and many people will claim that what you're doing isn't agile.  But that goes back to my point about taking the philosophy of the agile community over the actual process.  Good developers will have been working in a somewhat agile personal process inside your waterfall shell already.
      One compromise is break the work into phases (still one Gantt chart) and call it spiral development.  The DoD has been doing this for years.  Another compromise is to "scrum" out your waterfall phases (e.g. 1 sprint for requirements analysis, 2 sprints for design, that sort of thing) so that when you get to coding, you already have a cadence.  And behind the scenes you can start "prototyping" code for the purpose of "fleshing out requirements" or "fleshing out the design".  But you have to know and accept that you're cheating.  You're cheating the waterfall process because you're tainting their perfectly planned process with some empirical filth, and you're cheating the agile process because you are not bringing the customer close to you and you're still doing a lot of BUFD.  You will make everyone happy if the coding sprints develop each small piece to a deployed state and your integration and maintenance phases are painless.  You also need to be careful about your requirement analysis phase.  Those set-in-stone requirements are what will keep you from really being agile.  It is of the utmost importance that you craft the requirements with the same type of thinking that goes into user stories: Don't design through requirements. Write from the perspective of what you need to do with the system, not what you think the end system should be.  Write requirements so that a number of different solutions can satisfy them and sort out the correct solution in design and/or code.

      There are hybrids.  Where the critics and pundits get their fuel for predicting the end of the world is all of the people that try to shoehorn a couple of agile buzzwords into a traditional mindset and expect to get agile hyper-performance.  You won't get the performance that others are getting.  But you can incorporate some good ideas from the agile community to improve the process.  You may not want to show your external customers the product of the first few sprints, but you can be looking internally to make sure that the "prototypes" are actually looking and acting the way the designers expected.

      And I don't know what industry you work in, but even my strict, traditional waterfall DoD world, there's always a path to change course if something comes up that has a serious impact on the original design.  They call it "re-baselining".  The government has gotten burned so many times from throwing good money after bad that even though they may say that they want a plan set in stone and you can't change it, they will listen if you say that new evidence says that the current design is risky.  If you give them options along with the bad news, and one of those options is still within budget and schedule, they can make the decision to modify the scope.  And if it comes from them instead of you telling them "well, the project is now going to cost twice as much", they feel like they are actually in control.


      On Fri, Nov 9, 2012 at 4:44 PM, 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