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

Re: [scrumdevelopment] SCRUM with Fixed Price Contracts

Expand Messages
  • Vickydhiman
    ... Historically, we have only billed developer time to the clients. The communication/ interaction/ project management time has not been billed. Analyst team
    Message 1 of 78 , Jul 4, 2006
    • 0 Attachment
      Hello Ron and Group:

      >>If the team is spending time with the customer, surely that should be billed. If the team is spending time planning and designing, surely that should be billed. Tell us more about how you account for your time?

      Historically, we have only billed developer time to the clients. The communication/ interaction/ project management time has not been billed. Analyst team time is billed however for all the solution framework work.

      >> My favorite estimation technique is to put all the features on cards, have experienced team members estimate the cards as to how long they'd take to do in a perfect world, then multiply that number by three.

      And you provide these cards for the custom for an estimate of how much an iteration would cost the client?

      >> So it's the manager / Scrum Master who is actually jerking the project around, not the customer?

      Its basically the client. Scrum Master just follows the brief - discusses with the client and then provides the milestone for modules completion.

      >> It sounds to me as if that feedback loop, relating cost to value, is broken in your project. If that's the case, probably no estimation technique is going to help.

      I am not sure if I even understand what cost to value loop means. Probably Google around a bit. I am sure that business must generate profits and despite everything we are able to generate profits but probably not enough profits. We routinely offshoot our project estimates but probably because of other factors [low taxes, low salaries etc.] we are able to generate profits. And we all agree that there is scope for improvement.

      >> I would like to hear more about the communication loop between team, manager, customer, as regards changes and costs.

      We have switched to using BaseCamp PMS over past one year or so. All project milestones, to-do lists, messages, documents are posted there. The team and client have access to this account where all project discussions are done.

      The basic document which governs the discussion on changes and costs is the basic proposal document [specification and estimates].

      Let's revisit our sign-in page functionality:

      We drew the two text boxes and buttons and some links. Now the client says that what you showed me was obviously a basic page and what I require is an aesthetic looking web page which has a fancy faded background image [he would point out and say Graphics Design is part of the scope], some "?" Javascript pop-ups. And suppose this is the first time a client has made such a request [you had no historical data for this]. How would we handle this request?

      Thanks

      Vicki
      Ron Jeffries <ronjeffries@...> wrote:
      On Monday, July 3, 2006, at 4:41:03 AM, Vickydhiman wrote:

      >>> 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:

      > It was not working then - its not working now. In the past we used
      > to have these discussions at the end of the project making us
      > spend almost double the time on recoding. However, because the
      > project was complete - the customer generally used to be
      > reasonable [or should I say less demanding] in requests.

      OK ... I'm missing something, not sure yet what ...

      > Now - they are involved at each step and because nothing is built
      > as yet they take their flights of imagination to seventh heavens.
      > This ends up making us take longer to build but lesser to show in
      > terms of time sheets [increased communication/ interaction -
      > something which we have not historically kept track of]. But this
      > is not the main problem. We are working on optimizing our
      > interaction/ communication.

      Below, you're talking about the manager doing most of the
      communication with the real customer. So I'm not seeing what is
      taking all this unallocated time. What am I missing?

      If the team is spending time with the customer, surely that should
      be billed. If the team is spending time planning and designing,
      surely that should be billed. Tell us more about how you account for
      your time?

      > What concerns me is how to estimate correctly for a SCRUM project.
      > If I did not have any existing estimation method - what would you
      > recommend? Doing detailed CRC cards for all projects you are
      > bidding for? Is it not a waste if you dont even get the project?

      My answer would depend on what you did know. If you didn't know
      anything, I'd not be suggesting being in the fixed-price contract
      business.

      Bidding a project is always a waste if you don't get the project.
      It's necessary to decide how much to spend on a bid. The less you
      spend, the cheaper it is not to get the contract, and the riskier
      your bid is. In general, Agile thinkers recommend against fixed
      price projects. Of course, in general, everyone who does them wishes
      they didn't have to. The reasons are the same.

      I was thinking that your company, having done many projects, might
      well have enough information to estimate projects very quickly. I'll
      come back to that below.

      My favorite estimation technique is to put all the features on
      cards, have experienced team members estimate the cards as to how
      long they'd take to do in a perfect world, then multiply that number
      by three. (The number isn't entirely made up, it's based on my
      experience, and a lot of other folks' experience, that it takes
      between two and three times as long to do something in the real
      world as a programmer thinks it would if everything went perfectly.)

      BUT EVEN THEN ... you have to steer the project. That's discussed
      below as well.

      >>> 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?

      > Yes, we allot a weighted average - 75% to last one year and 25% to
      > the previous years data. Is that sufficient?

      I was asking, if you take your past projects and calculate their
      cost per screen, how similar are the numbers from one project to
      another? If those numbers vary too much, how similar are the costs
      per screen widget?

      I've had this thought that some simple calculation of number of
      screens, perhaps times a complexity per screen factor, might
      estimate project cost very well. Sounds like you might have enough
      information to look into that, so I was wondering.

      >>> 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 ...

      > Yes. He works as Scrum Master. Responsible for client
      > communication [most of it], burn down chat updates.

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

      > We do not have a Product Owner. I think the client would be the
      > Product Owner in our case. SCRUM Master is in direct contact with
      > the client from start of the project to end of the project.

      So it's the manager / Scrum Master who is actually jerking the
      project around, not the customer?

      The Product Owner role is critical in Scrum. From the Product Owner
      viewpoint, the team is a "machine" that produces features (backlog
      items, stories) at a roughly fixed rate. To complete the project on
      time and on budget, the Product Owner needs to pick the most
      important features and defer the rest. It works best if the features
      picked are made very simple at the beginning, then fancied up if
      time and money permit.

      In a situation such as yours, there would be a sketch, already
      approved, I gather, of some simple screen. There would be a cost
      associated with that screen. If the Product Owner wanted to make
      that screen more complex, she would have to "pay" for it in time and
      money, and if the budget were fixed, she'd have to give up something
      else or pony up some more money.

      It sounds to me as if that feedback loop, relating cost to value, is
      broken in your project. If that's the case, probably no estimation
      technique is going to help.

      I would like to hear more about the communication loop between team,
      manager, customer, as regards changes and costs.

      Ron Jeffries
      www.XProgramming. com
      Think! -- Aretha Franklin



      Do you Yahoo!?
      Get on board. You're invited to try the new Yahoo! Mail Beta.

    • 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
      • 0 Attachment
        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.
        [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?

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