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

619RE: [scrumdevelopment] Re: Alternative to EGroups + scrum in a "management" org

Expand Messages
  • Ken Schwaber
    Oct 7, 2002
    • 0 Attachment
      Your assessment of xP and Scrum practices is correct, and collaboration is
      of course the solution. And, in both, it is the team that selects how much
      they can do. The customer says "what", the team commits to how much of
      "what" and "how" they will turn the "what" into code.

      The customer wants to commit a fixed amount of money and get a fixed amount
      of functionality on a specified date. Just like at Dunkin Donuts, where
      $2.49 buys 6 donuts right now. A bunch of answers:

      1. Lay out the functionality and estimate it, just like you were bidding on
      a fcfd (fixed cost,fixed date) contract using traditional methodologies. Of
      course you are going to have to absorb some up front cost and effort to do
      this, and you'll build that cost into the bid/estimate. And prioritize the
      functionality. Collaborate with the customer that this functionality
      delivered in this sequence will optimize his ability to get the value, to
      deliver the vision, to redo the business operation, will deliver the system,
      that he wants. Tell him that you need the functionality ordered like this
      because you do iterative development and you want him to confirm that you
      are on track every iteration. And that you will give him the ability to
      change the requirements and their priority at the end of every iteration,
      because you know that his mind will change as he sees the system emerge and
      because his business conditions will change. And tell him that, in your
      experience, he will probably get most of the value from just some of the
      functionality, but you want him in charge of what functionality first. Then
      start going and collaborate. This is what DSDM does with the premiss that
      20% of the functionality will deliver 80% of the functionality. The
      prioritized backlog or stories, projected forward with estimates, becomes
      the contract bid.

      2. Same as 1 except only lay out functionality for the first three months of
      work. Bid the first three months as needed to really get a grasp on some
      pretty complex requirements and technology. And that at the end of the three
      months the customer will have the start of their system, potentially a first
      release to implement, and know if they want to proceed with you and to build
      the system or not. A proof of concept and engagement, except with real
      working functionality. Then enter into a collaborative, iteration by
      iteration (or 3x) contract. And switch the pressure, know that they know how
      good you are and how you can satisfy their needs. Tell them that you may
      need a longer committment so you can commit the resources to them.

      3. Check with Alistair Cockburn and the DSDM people. They bid on a state of
      Utah contract that was a fcfd rfp, and by using the first approach they
      changed the way that the state people viewed bidding and contracting and -
      in the process - may have become the preferred vendor.

      4. Understand that some customers are such contractual pricks, going after
      fcfp because they are lazy and don't intend to get involved, that you should
      walk away because it's a losing proposition (yes, even in these economic
      times ... remember that grocery stores still need baggers).

      BTW, I was so pleased when I read one of your last emails and you said that
      I was a better, better man. Thanks!

      -----Original Message-----
      From: Ron Jeffries [mailto:ronjeffries@...]
      Sent: Monday, October 07, 2002 9:57 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
      "management" org

      On Monday, October 7, 2002, at 9:46:28 AM, Ken Schwaber wrote:

      > Ron's right, the developers (team) commits to completing as much as they
      > of the product backlog, aiming as the sprint goal to which they committed.
      > The goal is the overall purpose of the sprint, the backlog is what they
      > to turn into product functionality to meet the goal. They are free to add
      > and subtract (with the customers colaboration) from the backlog as long as
      > they meet the goal. If the requirements become irrelevant or the
      > untractable during the sprint so that they can't meet the goal, the sprint
      > can be abnormally terminated either by the customer or the team.

      Now, this may be exactly what Mike meant by "committing to what they
      sign up for". Let me try out some differences between Scrum and XP to
      see if I understand. These are in the form of statements, but they are
      really questions:

      In Scrum, the developers pick from an ordered list of backlog, that
      is the Backlog Owner says what the priorities are and the team does
      the top N that they feel they can commit to, based on their
      assessment of their velocity.

      In XP, based on existing estimates for stories and on the team's
      measured velocity, the customer picks stories that s/he next wants
      to see done. The team signs up for those.

      Comparing, in Scrum the team commits to the high level goals but not
      to the details, nor to the how. In XP, the team undertakes to meet
      the Customer's detailed acceptance tests, but still not to the how,
      and renegotiates when it appears that they will fall short. XP
      involves the Customer in the tradeoff decision, while by definition,
      pardon the term, Scrum does not. (I'll bet that in practice, Scrum
      teams do commonly go to the owner and offer alternatives when
      there's tradeoff to be done.)

      So there's an equivalent amount of real "commitment", I'd say. Now
      Mike said:

      > Rather, I just describe an approach--stress that you're doing the
      > project in one month increments and that during that one month the
      > developers commit to completing everything they sign up for and that you
      > want the business to commit to not changing things (that doesn't sound
      > like a problem in your case). Describe how you'll meet at the start of
      > the month to create the "sprint backlog" and how the marketing person (a
      > "product manager" or in Scrum terms the "Product Owner") completely owns
      > the prioritization but that the team will draw a line under the tasks
      > they can commit to.

      In a recent conversation on the xp group, Bill Walton who bravely came
      and talked with us after writing an op/ed piece that many XPers
      roundly trounced, made the point that in his experience, managers want
      hard answers as to how much some project will cost. He feels that they
      will not sit still for approaches like the above, because they don't
      let them decide go / nogo on a project and its budget.

      Do you feel the same pressure to come up with a complete answer? How
      do you deal with it?

      Ron Jeffries
      To be on the wire is life. The rest is waiting. --Karl Wallenda

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 29 messages in this topic