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

Re: [scrumdevelopment] SCRUM with Fixed Price Contracts

Expand Messages
  • Ron Jeffries
    ... Hi ... I was really wondering what you did /before/ you tried to go Agile, and how it had been working, and why you weren t able to do at least as well in
    Message 1 of 78 , Jul 1, 2006
      On Saturday, July 1, 2006, at 12:05:12 PM, Vickydhiman wrote:

      > Hello Ron [and Group] :)

      Hi ... I was really wondering what you did /before/ you tried to go
      Agile, and how it had been working, and why you weren't able to do
      at least as well in an Agile situation as you did then. I'm not sure
      whether that's what you were addressing, but there's plenty of stuff
      to chat about:
      > First of all, one of the reasons why I joined Agile was not only
      > because we have trouble with our Hybird methods [mix of RUP +
      > SCRUM - and no we don't call it SCRUM :) ]. First of all our
      > organization deals with Web based projects only. What we generally
      > do is define requirements up front in detail [at least till a
      > level that goes through the reviews passed as detail enough]. We
      > traditionally do it by explaining using a sample wireframe of the
      > screen and how different set of users would be able to use the
      > functionality on the wireframe. I guess it would be better to
      > explain it with an example:

      > I would draw a simple screen [using PowerPoint or some other
      > simple too] with two text boxes [for user name and password]. I
      > would also dig up my image library for sample submit buttons/
      > reset buttons. I will place the links Register Now and Forgot
      > Password. I will then explain function of buttons and links. I
      > would also make it a point to mention that registration link goes
      > to the registration wireframe [wireframe number would be
      > provided]. In case of unsuccessful log in [exceptions], the
      > wireframe screen is also referenced. Similarly, ideal case is
      > referenced.

      OK ... I think I'd be inclined to do this with pen and paper, or my
      Tablet, but to each ...

      > Based on this, we would use our historical estimates [revised
      > every month] for sign-in screen and add-up these estimates for all
      > screens. In case, the estimate does not exist, the screen is shown
      > to three senior "Technical Leads" [managers are not kept in loop
      > during estimation]. Average estimate is taken for these screens.
      > After all the estimates are added, the project is multiplied with
      > a complexity factor and an analyst who has not been involved in
      > estimation process would review the estimates. Once approved, the
      > estimate is sent to the client in the form of proposal
      > [wireframes, basic use cases and estimates].

      OK, sounds good. I'm curious about a statistic. I've always
      suspected that projects like these have a roughly constant cost in $
      / time per screen, or worst case $ / time per screen widget. Do you
      have enough data to address that fantasy of mine?

      > Once the project is approved, the project is run largely on SCRUM
      > principles. From all the screens - various modules are identified.
      > Based on modules selected by the clients and dependencies [GUI
      > design must proceed integration of GUI with backend] sprints
      > [generally 2 weeks] are identified.

      OK ...

      > For the sprints - tasks are written in detail over the first two
      > days. Client is involved in these tasks [written more like
      > acceptance tests]. This is the phase where trouble actually creeps
      > in. Some of the clients [we work with dedicated clients] can
      > indulge in long discussions on what is in scope and what is not.
      > For instance, in the example above there could be added
      > requirement of double opt-in procedure. Although it hasn't been
      > mentioned in proposal, the clients come back with arguments like a
      > self respecting website would always have double opt-in for all
      > the member registrations.

      Well, yes ... but if there isn't a card for it, it's an oversight.
      Whose oversight is it supposed to be, the customer's or yours, and
      why? Do they "sign off" on the requirements / features / stories in
      some way?

      > I agree that this is not much additional work, but these long
      > discussions tend to drag the task formation from two days to
      > sometimes three days or even one week depending on complexity of
      > module. We tried to start framing tasks one sprint before [I mean
      > if team is working on Sprint n, then Managers get working on tasks
      > for Sprint n+1], but then it created conflict for manager to focus
      > on current sprint in hand. We have tried better communication.
      > After everything what it comes down to is even lengthier proposal
      > document which outlines more "what is not in scope" than "what is
      > in scope".

      Well, I'd think I'd go back to framing earlier if it's delaying
      things. I'd also wonder why the manager has much to do in the
      current sprint. Is manager also serving as Scrum Master, or ...

      And who's the Product Owner? How do they interact with the process,
      with the customer, with the team?

      > Another problematic area is the top management starts viewing
      > estimates [proposal estimates] as the metric and the teams which
      > exceed that metric are categorized as under performers.

      Memo to Top Management:
      Subject: Stupid Top Management Behavior(tm)
      We produce estimates for projects, not promises. We can begin to
      produce promises if you want to. (See below.)

      Estimates have the property that sometimes they are high,
      sometimes they are low. Performance is reality, estimates are
      guesses. Performance will sometimes be better than an estimate,
      sometimes worse. If performance and estimates average out equal,
      estimation is pretty good, and we might want to work on reducing
      the variance.

      But since an estimate is not a promise, it is Stupid Top
      Management Behavior(tm) to behave as if it is. If you would like
      us to give you promises instead of estimates, we can do that.
      However, be aware that in order to avoid ever going above our
      estimates, we will have to raise our estimates. This will have the
      result of reducing the competitiveness of our bids.

      We await your command.

      Your Worshipful Staff.

      > I agree completely that capturing all requirements upfront is
      > impossible. Even writing down everything you know in a manner
      > which is free from mis-interpretation is difficult if not
      > impossible. Hence, my interest in Agile. However, the market we
      > operate in is such that if we do not provide fixed price
      > estimates, we would be out. And our fixed price estimates are for
      > fairly complex projects - where one wrong or erroneous capture can
      > be quite costly.

      > Perhaps a more possibly question can be - how can we provide a
      > fixed price estimate for all the sprints/ iterations up front? Or
      > even can we?

      You certain can ... you can do the estimates the same way you would
      were you not doing Agile. I would imagine that that didn't work very
      well in the past, and that it would continue not to work very well
      in the future.

      Agile does give you an advantage if you choose to use it. Because an
      Agile project [done as they are supposed to be] delivers features
      from beginning to end, and because it can do any features in any
      order, you have the ability to do these things, which can help you
      perform to your original estimates:

      - do the most important things first, maximizing value to the

      - do the most risky things first, giving you more time to respond
      to difficulties that will arise;

      - do minimal versions of features, to deliver value early, to get
      concrete feedback, to ensure basic contract compliance;

      - fill in the frills and fancy bits on the features as time
      permits toward the later parts of the process;

      - be completely up front with the client on what is done, not
      done, being done, and allowing them to take part in steering the
      project to their best satisfaction.

      I don't know how to estimate any better than before I did Agile,
      except that I know how to estimate more quickly and simply.

      But I do know how to deliver a sequence of features better, which
      allows me to do a better job of satisfying the customer within a
      fixed and finite budget.

      > I am quite a new comer to Agile and Project Management in general,
      > but these issues look all pulling in all the directions to me. And
      > from what I have read about Agile, if something is not making
      > sense, it means that you have not followed some simple and basic
      > principles. Unfortunately for us, number of so called gurus either
      > have not been of much help.

      Wrong gurus.

      > P.S. I also agree that having a pre-sales team spending time on
      > these proposals is a bad investment especially if we do not get
      > the contracts. But that can be for some other time.

      OK ...

      Ron Jeffries
      Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
    • Adrian Howard
      ... [snip] How accurate are the estimates pulled from the database? What happens when they re wrong? Who decides that the developer has met the analysts spec?
      Message 78 of 78 , Jul 5, 2006
        On 5 Jul 2006, at 16:33, Vickydhiman wrote:

        > Hello Sammy:
        > Developers create the estimates based on specifications done by
        > Analysts. For most cases, estimates already exists and are pulled
        > from the database.

        How accurate are the estimates pulled from the database? What happens
        when they're wrong?

        Who decides that the developer has met the analysts spec?

      Your message has been successfully submitted and would be delivered to recipients shortly.