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

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

Expand Messages
  • Ken Schwaber
    Ron s right, the developers (team) commits to completing as much as they can of the product backlog, aiming as the sprint goal to which they committed. The
    Message 1 of 29 , Oct 7, 2002
    • 0 Attachment
      Ron's right, the developers (team) commits to completing as much as they can
      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 have
      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 technology
      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.
      Ken

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


      On Sunday, October 6, 2002, at 10:17:29 PM, Mike Cohn wrote:

      > 2) I don't really go into Scrum and what it's all about. I use the name
      > "Scrum" but I don't say, "we're going to make this group agile etc...".
      > 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).

      I thought that in Scrum the developers commit to completing as much as
      they can, not as much as is provided? What am I missing?

      Thanks,

      Ron Jeffries
      www.XProgramming.com
      Speculation or experimentation - which is more likely to give the correct
      answer?



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

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Ron Jeffries
      ... 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
      Message 2 of 29 , Oct 7, 2002
      • 0 Attachment
        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 can
        > 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 have
        > 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 technology
        > 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
        www.XProgramming.com
        To be on the wire is life. The rest is waiting. --Karl Wallenda
      • Mike Cohn
        Hmm, I must not have been clear. Here s how a typical Scrum project goes for me: First we work with a Product Owner to jumpstart the Product Backlog with all
        Message 3 of 29 , Oct 7, 2002
        • 0 Attachment
          Hmm, I must not have been clear. Here's how a typical Scrum project goes
          for me:

          First we work with a "Product Owner" to jumpstart the Product Backlog
          with all the "obvious" items on the list. (For the last year I've been
          capturing most of these as XP stories.) This takes a few hours and
          results in what will usually be 2-6 months of work for the team. I don't
          estimate it at that point but by the time most organizations get around
          to deciding to actually develop a product they have lots of ideas about
          what goes in it--some good, some bad.

          Based on what the Product Owner says the priorities are the team pulls
          off the top N tasks and says "This is what we can commit to finishing
          (tested, etc.) in a month." In reality it's never the exact top N tasks
          but rather it is the top M tasks plus "a few" more that are near the top
          but not the "next" items. I've never met a Product Owner who had a
          problem with this because their prioritization are approximate anyway,
          especially early on.

          The team codes. The Product Owner comes up with new items on the
          Backlog.

          So--yes, the team commits to completing as much as they can but they
          make that commitment at the start of the sprint (iteration) by pulling
          off a bundle of work. As Ken noted the real measure of their success is
          against a "sprint goal," which is a summary of what they're doing in the
          sprint, not against the exact list of tasks. I'm not sure I've had more
          than a couple of sprints deliver everything exactly in the sprint and no
          more/no less. Usually the team will pull a couple of things in and/or
          ask for permission to defer an item or two.

          Most of the Scrum teams I've worked with tend to pull in too much
          (especially at first) so I've encouraged them to pull in what they "know
          they can do". That way we know we'll finish the most important tasks and
          we can pull more in from there. I don't like situations where we pull in
          the 10 most important and then decide we're not going to finish so we
          drop the second-most important item. That's wrong for delivering value
          to our customer so I encourage it to go the other way. XP's idea of
          velocity here has been very useful in helping me assist Scrum teams by
          knowing how much they need to over or underestimate their capacity.

          --Mike



          -----Original Message-----
          From: Ron Jeffries [mailto:ronjeffries@...]
          Sent: Sunday, October 06, 2002 11:40 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Alternative to EGroups + scrum in a
          "management" org

          On Sunday, October 6, 2002, at 10:17:29 PM, Mike Cohn wrote:

          > 2) I don't really go into Scrum and what it's all about. I use the
          name
          > "Scrum" but I don't say, "we're going to make this group agile
          etc...".
          > 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).

          I thought that in Scrum the developers commit to completing as much as
          they can, not as much as is provided? What am I missing?

          Thanks,

          Ron Jeffries
          www.XProgramming.com
          Speculation or experimentation - which is more likely to give the
          correct answer?



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

          Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
        • Ron Jeffries
          ... You are that, Ken, you are that. ;- Ron Jeffries www.XProgramming.com The Great and Powerful Oz has spoken.
          Message 4 of 29 , Oct 7, 2002
          • 0 Attachment
            On Monday, October 7, 2002, at 11:19:09 AM, Ken Schwaber wrote:

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

            You are that, Ken, you are that. ;->

            Ron Jeffries
            www.XProgramming.com
            The Great and Powerful Oz has spoken.
          • Ken Schwaber
            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
            Message 5 of 29 , 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!
              Ken

              -----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
              can
              > 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
              have
              > 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
              technology
              > 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
              www.XProgramming.com
              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:
              scrumdevelopment-unsubscribe@...

              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Mike Cohn
              Yes, frequently. I usually try to sell away from that type of situation because I ve seen it go bad too frequently. If you go into something with a fixed date
              Message 6 of 29 , Oct 7, 2002
              • 0 Attachment
                Yes, frequently. I usually try to sell away from that type of situation
                because I've seen it go bad too frequently. If you go into something
                with a fixed date and a fixed feature set the only things that can
                change are the quality or the staff size (which will adversely affect
                the quality, so it's really only quality that suffers).

                If I'm presenting to a CEO, for example, to take over a project a
                typical question is "Why should I use you for this project? Company X
                will guarantee me a delivery date with a defined set of functionality."
                My answer to that is always: Anyone who guarantees a date and a set of
                features is either padding his estimate, lying, or both. I could pad my
                estimate and give you the same thing and take away some of your
                flexibility at the same time. It all depends on what you want.

                When I estimate approximately how many sprints a project will take I use
                a Theory of Constraints / Critical Chain approach (Eli Goldratt). This
                works really well--not necessarily for creating a Gantt chart I want to
                use for anything later--but for estimating overall duration. It also
                helps the team think through dependencies between tasks/stories.
                Critical Chain works well because it is so compatible with uncertainty.
                To estimate the project I work with the team to come up with a 50% and a
                90% estimate for each task. Using those I can figure out the nominal
                schedule for a project (based on late-start 50% estimates) and I can
                then add feeding and project buffers. So far, it hasn't failed me in
                coming up with estimates I can put around Scrum projects. I finished a
                project this summer where the CEO made us give him a point-estimate
                (7/13) six months in advance. We finished on time and the team commented
                how nice it was to have accomplished so much but never have felt
                inordinately under the gun as on most projects. That same CEO is no
                longer even asking for estimates--he does lay out aggressive goals for
                the team but he now has trust in the team to deliver the most they can
                the fastest they can.

                --Mike

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

                > 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
                www.XProgramming.com
              Your message has been successfully submitted and would be delivered to recipients shortly.