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

Re: [scrumdevelopment] Re: On Committment

Expand Messages
  • Ron Jeffries
    Thanks, Jeff ... this makes very much sense to me and is consistent with what I teach. I like item 2, outsourcing ... that s not one that I often consider. Of
    Message 1 of 11 , Feb 27, 2006
      Thanks, Jeff ... this makes very much sense to me and is consistent
      with what I teach. I like item 2, outsourcing ... that's not one
      that I often consider. Of course "everyone is as busy as we are",
      but on the other hand, not everyone is on the same deadline. Could
      be some quid pro quo.

      I would put 4, abort and start a new full-length Sprint, as a very
      distant fourth, and expect that almost always 1 through 3 are
      possible, unless the team has really blown it and wants to back up
      the code base.

      With overlapping Sprints like you do, these ideas could work even
      better I'd imagine. Must learn more about that ...

      Thanks,

      Ron Jeffries
      www.XProgramming.com
      I could be wrong. I frequently am.

      On Monday, February 27, 2006, at 5:43:28 AM, Jeff Sutherland wrote:

      > Here is what I am telling people:

      > 1. The best solution when it appears you cannot get all features in a
      > Sprint is be like Toyota. Approach it differently to get it all done
      > on time. (First place to look is overengineering. It is always there
      > and they are violating a basic XP principle.)

      > 2. Second best is outsource - give things to someone outside the group
      > - and make sure it is done.

      > 3. Third best is cut low priority features - this is usually possible
      > without significant hardship.

      > 4. If all else fails abort the Sprint. Replan a new 30 day Sprint and
      > execute it properly. (Many companies are running two week or three
      > week Sprints, same idea applies.)

      > The point is - never fail a Sprint. If needed, abort early, do a root
      > cause analysis, fine tune the process, and restart. Act like Toyota.
    • Thierry Thelliez
      What about the situation where the technical tasks involve a lot of unknowns? In our case we had to port our product to Windows 2003. The Windows 2003 security
      Message 2 of 11 , Feb 27, 2006
        What about the situation where the technical tasks involve a lot of
        unknowns?

        In our case we had to port our product to Windows 2003. The Windows 2003
        security variations between hardware, patches,... and undocumented Windows
        features made our planning extremely difficult and many Sprints ended up
        'unfinished'. We discovered unplanned issues like the 'Data Execution
        Prevention' that killed some of our processes without leaving a trace... it
        took days to find out what the issue was.

        Maybe we should have outsourced to some people more aware of the Windows
        server new 'features' but we also wanted to retain some knowledge in-house.


        Suggestions?


        Thanks,
        Thierry Thelliez

        -----Original Message-----
        From: scrumdevelopment@yahoogroups.com
        [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jeff Sutherland
        Sent: Monday, February 27, 2006 6:43 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: On Committment

        Here is what I am telling people:

        1. The best solution when it appears you cannot get all features in a
        Sprint is be like Toyota. Approach it differently to get it all done
        on time. (First place to look is overengineering. It is always there
        and they are violating a basic XP principle.)

        2. Second best is outsource - give things to someone outside the group
        - and make sure it is done.

        3. Third best is cut low priority features - this is usually possible
        without significant hardship.

        4. If all else fails abort the Sprint. Replan a new 30 day Sprint and
        execute it properly. (Many companies are running two week or three
        week Sprints, same idea applies.)

        The point is - never fail a Sprint. If needed, abort early, do a root
        cause analysis, fine tune the process, and restart. Act like Toyota.

        Jeff Sutherland

        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
        <ronjeffries@...> wrote:
        >
        > On Sunday, February 26, 2006, at 5:38:09 AM, Jeff Sutherland wrote:
        >
        > > Never be a loser. If you are two weeks into the Sprint and the
        > > consensus is that you will not make it, stop the line, replan, and
        > > then execute a successful Sprint. Always win at the end of the Sprint.
        > > Abort any hand that is a loser. Most people are smart enough to do
        > > that when they play poker. Why not when we play planning poker?
        >
        > Jeff ... interesting and thought-provoking advice. With 30-day
        > Sprints, would you stop half-way thru and then plan a full 30 days
        > from there? Or would you plan the remaining days?
        >
        > I've generally favored a more incremental adjustment of the plan in
        > the iteration, replanning as needed. Generally there are only a
        > couple of items at risk, so it has seemed mostly harmless to me. I'm
        > interested in hearing more about your approach.
        >
        > Thanks,
        >
        > Ron Jeffries
        > www.XProgramming.com
        > I have tried in my way to be free. -- Leonard Cohen
        >






        To Post a message, send it to: scrumdevelopment@...
        To Unsubscribe, send a blank message to:
        scrumdevelopment-unsubscribe@...
        Yahoo! Groups Links
      • Jeff
        Imo, the nice thing about backlog items is that they themselves are self classifying , and self failing . Let me explain. E.g. I ve found unclear backlog
        Message 3 of 11 , Feb 27, 2006
          Imo, the nice thing about backlog items is that they themselves are "self classifying", and "self failing".  Let me explain.
           
          E.g. I've found unclear backlog items going into our sprints.
           
          When the team goes to commit, if an unclear backlog item is commited to, then risk is high, and failure on the backlog item is possible.
           
          So, one thing we're trying is to _make_sure_ backlog items are well defined before they are "eligible" for the sprint.
          Some backlog items are obvious, some are not.
          Usually, this is just a matter of the architect team sitting down with the product owner, and scrummaster, and sorting out what the product owner is really looking for.
           
          Sometimes, the product owner simply doesnt know, and the item requires further investigation.
           
          In this case, its pretty simple to the "label" the backlog item as such.
           
          Now, for these items, what we try to do is get that clarity before the sprint, but if cant happen, then "getting the clarity" becomes the backlog item.
           
          The nice thing about this, is that since the backlog item is prevented from reaching the team, there is now a sense of urgency by the product owner.
           
          Make sense?  Is this a good practice?
           
          A related question: Is it the scrummaster responsibility to make sure that all backlog items have sufficent clarity before the team is asked to commit to them?


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Thierry Thelliez
          Sent: Monday, February 27, 2006 9:35 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: RE: [scrumdevelopment] Re: On Committment


          What about the situation where the technical tasks involve a lot of
          unknowns?

          In our case we had to port our product to Windows 2003. The Windows 2003
          security variations between hardware, patches,... and undocumented Windows
          features made our planning extremely difficult and many Sprints ended up
          'unfinished'. We discovered unplanned issues like the 'Data Execution
          Prevention' that killed some of our processes without leaving a trace... it
          took days to find out what the issue was.

          Maybe we should have outsourced to some people more aware of the Windows
          server new 'features' but we also wanted to retain some knowledge in-house.


          Suggestions?


          Thanks,
          Thierry Thelliez

          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com
          [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Jeff Sutherland
          Sent: Monday, February 27, 2006 6:43 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] Re: On Committment

          Here is what I am telling people:

          1. The best solution when it appears you cannot get all features in a
          Sprint is be like Toyota. Approach it differently to get it all done
          on time. (First place to look is overengineering. It is always there
          and they are violating a basic XP principle.)

          2. Second best is outsource - give things to someone outside the group
          - and make sure it is done.

          3. Third best is cut low priority features - this is usually possible
          without significant hardship.

          4. If all else fails abort the Sprint. Replan a new 30 day Sprint and
          execute it properly. (Many companies are running two week or three
          week Sprints, same idea applies.)

          The point is - never fail a Sprint. If needed, abort early, do a root
          cause analysis, fine tune the process, and restart. Act like Toyota.

          Jeff Sutherland

          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
          <ronjeffries@...> wrote:
          >
          > On Sunday, February 26, 2006, at 5:38:09 AM, Jeff Sutherland wrote:
          >
          > > Never be a loser. If you are two weeks into the Sprint and the
          > > consensus is that you will not make it, stop the line, replan, and
          > > then execute a successful Sprint. Always win at the end of the Sprint.
          > > Abort any hand that is a loser. Most people are smart enough to do
          > > that when they play poker. Why not when we play planning poker?
          >
          > Jeff ... interesting and thought-provoking advice. With 30-day
          > Sprints, would you stop half-way thru and then plan a full 30 days
          > from there? Or would you plan the remaining days?
          >
          > I've generally favored a more incremental adjustment of the plan in
          > the iteration, replanning as needed. Generally there are only a
          > couple of items at risk, so it has seemed mostly harmless to me. I'm
          > interested in hearing more about your approach.
          >
          > Thanks,
          >
          > Ron Jeffries
          > www.XProgramming.com
          > I have tried in my way to be free.  -- Leonard Cohen
          >






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








        • Steven Gordon
          There is another kind of unclear backlog item - the story is completely clear, but how to implement it is not clear enough to commit to any estimate. In such
          Message 4 of 11 , Feb 27, 2006
            There is another kind of unclear backlog item - the story is completely clear, but how to implement it is not clear enough to commit to any estimate. 
             
            In such cases, a "spike" is a good approach - the sprint item is for the development team to perform a time-boxed investigation into various ways to try to implement the story and what the complexity and technical risks are for each alternative.  This facilitates a reasonable estimate for implementing a story in a future sprint.
             
            I think this also fits your pattern.
             
            Nevertheless, sometime a team will not discover an implementation issue until they try to implement a story (such as an unexpected bug in a 3rd party API).  It sounds like Jeff Sutherland would recommend cancelling the sprint and replanning when this happens.  Perhaps, it would make more sense to first ask the customer whether they would prefer cancelling and replanning or just turning the one problematic story into a spike and continuing with the rest of the sprint.
             
            Steven Gordon

             
            On 2/27/06, Jeff <ne14mx@...> wrote:
            Imo, the nice thing about backlog items is that they themselves are "self classifying", and "self failing".  Let me explain.
             
            E.g. I've found unclear backlog items going into our sprints.
             
            When the team goes to commit, if an unclear backlog item is commited to, then risk is high, and failure on the backlog item is possible.
             
            So, one thing we're trying is to _make_sure_ backlog items are well defined before they are "eligible" for the sprint.
            Some backlog items are obvious, some are not.
            Usually, this is just a matter of the architect team sitting down with the product owner, and scrummaster, and sorting out what the product owner is really looking for.
             
            Sometimes, the product owner simply doesnt know, and the item requires further investigation.
             
            In this case, its pretty simple to the "label" the backlog item as such.
             
            Now, for these items, what we try to do is get that clarity before the sprint, but if cant happen, then "getting the clarity" becomes the backlog item.
             
            The nice thing about this, is that since the backlog item is prevented from reaching the team, there is now a sense of urgency by the product owner.
             
            Make sense?  Is this a good practice?
             
            A related question: Is it the scrummaster responsibility to make sure that all backlog items have sufficent clarity before the team is asked to commit to them?
          • Jeff
            Yes. However, the cancelling the sprint is a worrisome absolute for me. Yes, its up to the team to decide, however, in our case there is typically a few
            Message 5 of 11 , Feb 27, 2006
              Yes.
               
              However, the 'cancelling the sprint' is a worrisome absolute for me.
               
              Yes, its up to the team to decide, however, in our case there is typically a few unrelated things going on in the sprint.
              E.g. three people might be working together to implement Feature A, while another three might be working on Feature B, where A and B are unrelated and stand by themselves.
              All members of the team are working on the same release and feature set.
               
              So, if feature B is busted (ill defined), then B can be dropped, and A proceed as a goal.
               
              But I agree that the owner must be in agreement, etc. 
              Typically, the team and SM will have a good idea of whats acceptable. 
              (If they dont know, then there probably isnt good communication.)


              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Steven Gordon
              Sent: Monday, February 27, 2006 10:45 AM
              To: scrumdevelopment@yahoogroups.com
              Subject: Re: [scrumdevelopment] Re: On Committment

              There is another kind of unclear backlog item - the story is completely clear, but how to implement it is not clear enough to commit to any estimate. 
               
              In such cases, a "spike" is a good approach - the sprint item is for the development team to perform a time-boxed investigation into various ways to try to implement the story and what the complexity and technical risks are for each alternative.  This facilitates a reasonable estimate for implementing a story in a future sprint.
               
              I think this also fits your pattern.
               
              Nevertheless, sometime a team will not discover an implementation issue until they try to implement a story (such as an unexpected bug in a 3rd party API).  It sounds like Jeff Sutherland would recommend cancelling the sprint and replanning when this happens.  Perhaps, it would make more sense to first ask the customer whether they would prefer cancelling and replanning or just turning the one problematic story into a spike and continuing with the rest of the sprint.
               
              Steven Gordon

               
              On 2/27/06, Jeff <ne14mx@...> wrote:
              Imo, the nice thing about backlog items is that they themselves are "self classifying", and "self failing".  Let me explain.
               
              E.g. I've found unclear backlog items going into our sprints.
               
              When the team goes to commit, if an unclear backlog item is commited to, then risk is high, and failure on the backlog item is possible.
               
              So, one thing we're trying is to _make_sure_ backlog items are well defined before they are "eligible" for the sprint.
              Some backlog items are obvious, some are not.
              Usually, this is just a matter of the architect team sitting down with the product owner, and scrummaster, and sorting out what the product owner is really looking for.
               
              Sometimes, the product owner simply doesnt know, and the item requires further investigation.
               
              In this case, its pretty simple to the "label" the backlog item as such.
               
              Now, for these items, what we try to do is get that clarity before the sprint, but if cant happen, then "getting the clarity" becomes the backlog item.
               
              The nice thing about this, is that since the backlog item is prevented from reaching the team, there is now a sense of urgency by the product owner.
               
              Make sense?  Is this a good practice?
               
              A related question: Is it the scrummaster responsibility to make sure that all backlog items have sufficent clarity before the team is asked to commit to them?
            • Thierry Thelliez
              Steven, ... until they try to implement a story (such as an unexpected bug in a 3rd ... sprint and replanning when this happens.  This is the scenario we are
              Message 6 of 11 , Feb 27, 2006
                Steven,

                >Nevertheless, sometime a team will not discover an implementation issue
                until they try to implement a story (such as an unexpected bug in a 3rd
                >party API).  It sounds like Jeff Sutherland would recommend cancelling the
                sprint and replanning when this happens. 

                This is the scenario we are encountering here, amplified by the fact that
                the 3rd Party component is Windows Server 2003 ;-)

                So while the product backlog story is well understood, the implementation
                details are not. And the issues are not going to be known until the
                technical task is done.

                This is a very different scenario from when the team is comfortable with the
                technology and can make a fairly confident estimate.

                We tried to have sprints tasks where we goal was only to look at the
                feasibility. This works for some tasks but not all. In some cases you just
                do not know what issues are going to be next. For example we just discovered
                that under Windows 2003 .bat cannot be executed from Batch accounts anymore.


                With some much uncertainty how do you plan a Sprint?


                Thierry Thelliez
              • Hubert Smits
                I would spend time with (part of) the team preparing for the planning meeting. In XP one can use a spike to work on a story until it is well enough understood
                Message 7 of 11 , Feb 27, 2006
                  I would spend time with (part of) the team preparing for the planning
                  meeting. In XP one can use a spike to work on a story until it is well
                  enough understood to be estimated, I would apply the same principle in
                  Scrum. This can be an incident - one story on the product backlog is
                  unclear, or it can be structural - the problem domain is new to the
                  team and one needs a continuous effort to prepare for the next sprint
                  planning. Participants would typically be delivery team people,
                  architects and product owners. The ScrumMaster would facilitate the
                  process, ensuring that this does not become a Big Design Up Front.

                  --Hubert

                  On 2/27/06, Thierry Thelliez <thierry@...> wrote:
                  > Steven,
                  >
                  > >Nevertheless, sometime a team will not discover an implementation issue
                  > until they try to implement a story (such as an unexpectedbug in a 3rd
                  > >party API). It sounds like Jeff Sutherland would recommend cancelling the
                  > sprint and replanning when this happens.
                  >
                  > This is the scenario we are encountering here, amplified by the fact that
                  > the 3rd Party component is Windows Server 2003 ;-)
                  >
                  > So while the product backlog story is well understood, the implementation
                  > details are not. And the issues are not going to be known until the
                  > technical task is done.
                  >
                  > This is a very different scenario from when the team is comfortable with the
                  > technology and can make a fairly confident estimate.
                  >
                  > We tried to have sprints tasks where we goal was only to look at the
                  > feasibility. This works for some tasks but not all. In some cases you just
                  > do not know what issues are going to be next. For example we just discovered
                  > that under Windows 2003 .bat cannot be executed from Batch accounts anymore.
                  >
                  >
                  > With some much uncertainty how do you plan a Sprint?
                  >
                  >
                  > Thierry Thelliez
                  >
                  >
                  >
                  >
                  >
                  > To Post a message, send it to: scrumdevelopment@...
                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                  >
                  >


                  --

                  All opinions in this message are my own, and are not necessarily
                  shared by my employer.
                • David A Barrett
                  When I attended the CSM course a few years back, I asked Ken about this stuff. At the time, I remember that I had the impression that commitment meant a
                  Message 8 of 11 , Feb 28, 2006
                    When I attended the CSM course a few years back, I asked Ken about this
                    stuff. At the time, I remember that I had the impression that "commitment"
                    meant a firm contract to complete the work. Ken clearly did not agree with
                    that, although he didn't really give me what I considered an adequate
                    explanation of why at the time.

                    But it did stick with me, and I pondered it for quite a while afterwards.
                    My boss especially holds the view that, "a commitment is a commitment is a
                    commitment", so I've got to somehow reconcile that with a "Sprint
                    Commitment".

                    Here's what I've come up with:

                    1. Stuff happens.
                    2. Some commitments are firm, and missing them is a serious problem with
                    the Sprint.
                    3. Some commitments are loosely defined, and therefore subject to
                    reduction of scope without penalty.
                    4. User testing is never part of a commitment.
                    5. You start a Sprint with ***estimates*** for the sizes of tasks. These
                    are sometimes wrong. "Commitments" need to be viewed in this context.
                    6. Missed commitments need to be publicized, leftovers go into the PB and
                    the users can decide if the uncompleted work goes in the next Sprint.
                    7. The team needs to win, whenever possible. Accept #1 above, and without
                    covering up, split a backlog item into 2 or more items and complete
                    something. Then use #6.

                    In other words, the worst thing you can possibly do is end a Sprint with a
                    bunch of tasks 90% done. Better to drop one and complete all the others.
                    Better to scale them all back in scope, if possible and complete them all.
                    Best not to lose sleep over it.

                    A lot of our new projects are exploratory in nature. We've managed to get
                    our users to embrace the Scrum approach, and not get too tied up in tying
                    down details of the big picture at the very start. Consequently, we've had
                    occasions when we've quickly found that something is way more difficult and
                    involved than we suspected at first. In those cases we've gone back to the
                    users and told them that. Then we concentrate on getting something into
                    their hands that will best convey to them the essence of the approach that
                    we are taking. That way they can go beyond trying to visualize what we are
                    talking about (which all users are extremely bad at doing), get some hands
                    on experience with the software and give us real feedback on our approach.
                    Then, in the next Sprint and with more knowledge, we set realistic goals to
                    move forward.

                    Also, you do need to pay attention to how often commitments are missed from
                    Sprint to Sprint. Ask why? Is the team taking on too much each Sprint?
                    Personally, I eyeball the total hours we estimate for each Sprint at the
                    beginning and I try to make sure that it fits my impression of what a
                    "reasonable" workload for the team would be. If I have concerns, I let the
                    team know about it and they can decide if there is a problem -- on day one
                    of the Sprint.



                    Dave Barrett,
                    Lawyers' Professional Indemnity Company
                  Your message has been successfully submitted and would be delivered to recipients shortly.