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

38336Re: [scrumdevelopment] Re: Scrum for Fixed Price projects

Expand Messages
  • Michael James
    May 6 9:43 AM
      Scrum is the best way to manage the unfortunate situation of having a
      fixed price, and (theoretically) fixed scope expectations. Splitting
      the stories into very thin vertical slices and doing short iterations
      can reduce the unrequested gold plating that programmers like me
      typically introduce. Get the absolutely essential items done early,
      even if they're ugly. If there's time at the end (ha!) you can pretty
      them up.

      A couple good articles other people wrote on story splitting:


      . 5-page illustrated summary of Scrum: http://tinyurl.com/dkyqjs
      . An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor

      On May 6, 2009, at 6:01 AM, peterstev wrote:

      > Hi Pooja,
      > > Can Scrum play a key role in FP projects achieving their target?
      > Absolutely! In fact, the more I think about it, the more I think
      > Scrum is the best way to take on a fixed price project.
      > The process starts in pre-sales so that you set the expectations
      > with the customer and leave yourself some maneuvering room to even
      > out the risks of various peices of the project. Some things will go
      > quicker, others slower. You need to make sure that even if some
      > things turn against you, the project as a whole stays within bounds.
      > Ron Jeffries will probably point out at this point that you need to
      > add good engineering to your sound management practices. An he will
      > be right. So you need good engineers working on your project. If
      > they've been working together and working on a similar project and
      > working with Scrum before, you improve the odds in your favor. If
      > they were involved in the sales process, that's even better.
      > Basically you strive deliver Running Tested Features every sprint
      > (and this implies a fair amount of automation in your quality
      > assurance). Every Sprint you deliver functionality to the customer.
      > And you give him his most important features first. Add in some
      > sensible buffers (Must Have / Should Have / Nice to Have ) on the
      > feature side and/or some air the schedule side for risk management,
      > and you have the basis for delivering what the customer needs when
      > he needs at.
      > Why is Scrum better than a waterfall? Scrum delivers functionality
      > at least every month. Tested and Done. Think constant positive
      > velocity. Waterfall has long periods of zero velocity (initial
      > planning phases) and zero or even negative velocity (periods of
      > testing in which the team and customer discover that significant
      > pieces of functionality don't work properly or otherwise do not
      > satisfy customer requirements). Highly variable velocity is a
      > significant risk, because you cannot really predict when the product
      > will be ready.
      > Having said all that, I'm not sure I'd recommend fix price contracts
      > if you can avoid them. Last week, I published on ASD an analysis of
      > the suitability of various contracting forms for agile development.
      > I think there are better alternatives for both vendor and customer.
      > BTW - I plan to publish an article on hitting a fixed price or fixed
      > deadline project (it's a side effect of preparing my Product Owner
      > course). Wish I had it ready today ;-), but it should be ready next
      > week.
      > Cheers,
      > Peter
      > --- In scrumdevelopment@yahoogroups.com, "poojawandile"
      > <poojawandile@...> wrote:
      > >
      > > Hi,
      > > Can Scrum play a key role in FP projects acheiving their target?
      > If yes, what are those key features of Scrum that will help them
      > acheive their target? I don't know if Scrum can be successful or not
      > in a FP project but here are my thoughts:
      > > a. Scope creep is always a major problem and because of agility
      > nature of Scrum, scope creep can be handled early
      > > b. Since Scrum is a managament tool, the entire duration of the
      > project can be split into Sprints and user stories can be planned
      > for each of the sprints and in turn helps in proper management of
      > the project
      > > c. Close collaboration helps in getting timely feedback hence
      > communication plan can be set up early in the project
      > > d. Every sprint can be treated as a smaller unit of one big
      > project and can be completed spint on sprint. Customer will get
      > satisfaction of seeing some part of project being delivered and can
      > start using it.
      > >
      > > Any more thoughts?
      > >
      > > Thanks,
      > > Pooja
      > >
    • Show all 31 messages in this topic