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

Re: [scrumdevelopment] Re: Dealing With Overcommitment

Expand Messages
  • Ron Jeffries
    Hello, Jeff. On Friday, December 1, 2006, at 1:28:25 PM, you ... Someone should help them see that failure is not as good as success. I would have thought
    Message 1 of 28 , Dec 1, 2006
      Hello, Jeff. On Friday, December 1, 2006, at 1:28:25 PM, you
      wrote:

      > What's happening is that we have fixed deadline and the team is very
      > motivated to try and meet it. This is leading them to keep trying to get
      > more done than they are currently capable of, which has lead to an
      > atmosphere were failing a sprint is not seen as a bad thing.

      Someone should help them see that failure is not as good as success.
      I would have thought that everyone knew that, so I'm not sure how to
      help beyond that simple suggestion.

      > The result
      > is that they don't really understand what it means to be successful.

      I would think it would be relatively simple, at the end of the
      Sprint, to point out that we drew the line here, and only got done
      to here.

      Then in planning, when they draw the line (do they draw the line, or
      does someone else tell them where the line is???), ask them if
      they're really going to get that much really done.

      Raise the line until they say yes. Rinse, repeat.

      It's not about success or failure, really. It's about correctly
      predicting what's going to happen.

      This next is heresy and will surely get me burned at the stake: a
      shorter Sprint will help with this.

      > In
      > my experience, teams achieve the highest level of productivity when they
      > build on a history of success. A team that enters a sprint, knowing that
      > there's no way they can achieve everything they've taken on, isn't
      > really committed. They aren't self-organizing to achieve goals, but
      > rather scrambling to pack as much in as they can.

      Your problem isn't productivity, in my opinion. It is
      predictability.

      Ron Jeffries
      www.XProgramming.com
      That's my opinion and I agree with it. -- Julio Santos
    • Nicholas Cancelliere
      I agree with Ron. I think it s a pitfall many fall into - misidentifying productivity vs. predictability issues. In my past experience I have had a team who
      Message 2 of 28 , Dec 1, 2006
        I agree with Ron.  I think it's a pitfall many fall into - misidentifying productivity vs. predictability issues.

        In my past experience I have had a team who was deemed "unproductive," because they never met their sprint commitments and had as a result a very low velocity.  The upper management would take the number of folks on a project, calculate how many hours they should be working, look at the estimates, and then scratch their heads as to why it wasn't working out.  

        The team was clocking over 380 hours (although they only got 140 hrs of velocity).  Looking at the causes, interruptions and firedrills in the sprint, the upper management are then faced with the reality that a lot of effort is expended on non-sprint related work.  The reality presents itself -- the team could really be humming if left alone.  Was the team unproductive?  Not at all.

        Can we predict what stories get done - yes by using the velocity of 140, not 380.  The difference between 140 and 380 represents the "uncertain" element that you can't plan because if history repeats itself (and usually it does, without conscious change) that time will be eaten up again with non-sprint work.



        On Dec 1, 2006, at 1:11 PM, Ron Jeffries wrote:

        Your problem isn't productivity, in my opinion. It is
        predictability.

      • Ken Schwaber
        Teams overcommitting after the third sprint is a smell that they are not managing themselves. I ll bet they don t have an accurate sprint backlog that they are
        Message 3 of 28 , Dec 1, 2006

          Teams overcommitting after the third sprint is a smell that they are not managing themselves. I’ll bet they don’t have an accurate sprint backlog that they are updating, and I’ll bet that you don’t hear a group of people figuring out how they are going to meet their sprint goal every daily scrum.

          Ken

           


          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
          Sent: Friday, December 01, 2006 1:09 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Dealing With Overcommitment

           

          Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
          you wrote:

          > My recommendation to the Scrum Master in such a situation is to
          > strictly limit the amount of work accepted to the team's
          > empirically- proven velocity. I think that once there is some
          stability
          > in delivery, velocity will increase naturally over time.

          Unless I am mistaken, which is quite possible, the way Scrum works
          as described in Scrum 101 is that the TEAM decides how much of the
          backlog they can consume, and they commit to getting that much fully
          done. They adjust until they're good at it.

          That's not happening where you are ... what is happening instead?

          Ron Jeffries
          www.XProgramming. com
          Accroche toi a ton reve. --ELO

        • Ken Schwaber
          Teams overcommitting after the third sprint is a smell that they are not managing themselves. I ll bet they don t have an accurate sprint backlog that they are
          Message 4 of 28 , Dec 1, 2006
            Teams overcommitting after the third sprint is a smell that they are
            not managing themselves. I'll bet they don't have an accurate sprint
            backlog that they are updating, and I'll bet that you don't hear a
            group of people figuring out how they are going to meet their sprint
            goal every daily scrum.

            Ken


            --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
            <ronjeffries@...> wrote:
            >
            > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
            > you wrote:
            >
            > > My recommendation to the Scrum Master in such a situation is to
            > > strictly limit the amount of work accepted to the team's
            > > empirically-proven velocity. I think that once there is some stability
            > > in delivery, velocity will increase naturally over time.
            >
            > Unless I am mistaken, which is quite possible, the way Scrum works
            > as described in Scrum 101 is that the TEAM decides how much of the
            > backlog they can consume, and they commit to getting that much fully
            > done. They adjust until they're good at it.
            >
            > That's not happening where you are ... what is happening instead?
            >
            > Ron Jeffries
            > www.XProgramming.com
            > Accroche toi a ton reve. --ELO
            >
          • Clinton Keith
            From: Ron Jeffries ... We re seeing a great deal of turnover and addition to the tasks to fulfill stories during the sprint. Much of this is attributed to the
            Message 5 of 28 , Dec 1, 2006
              From: Ron Jeffries

              > Dropping stories does not mean you met your commitment,
              > it means you failed to meet your commitment.

              > What is causing the team not to estimate in such a way
              > as to have to drop no stories? Why do they not value
              > making their commitments?

              We're seeing a great deal of turnover and addition to the tasks to
              fulfill stories during the sprint. Much of this is attributed to the
              nature of our product which is video games. Value is "fun".

              We first attempted to create very narrowly focused stories that could be
              broken down and estimated, we often don't see fun. The team would see
              that it wasn't going to be fun during the Sprint, but their story
              commitment didn't allow change.

              We then shifted to creating less stringent stories that allow the team
              to vary the task in the Sprint to a great degree to achieve their goals.
              This does require someone on the team to be a product owner. This
              created more "fun" per Sprint. It also created more reasons to drop
              lower priority stories; sometimes too easily.

              So I don't think that saying the team has "failed" is reasonable. On
              the other hand, casually dropping stories can often work at odds with
              having the highest sustainable level of intensity throughout the entire
              project.

              Clint
            • mpkirby
              ... The interesting question is what do you do about it. Does one manage a team into managing itself? Mike
              Message 6 of 28 , Dec 1, 2006

                Teams overcommitting after the third sprint is a smell that they are not managing themselves. I’ll bet they don’t have an accurate sprint backlog that they are updating, and I’ll bet that you don’t hear a group of people figuring out how they are going to meet their sprint goal every daily scrum.

                Ken

                The interesting question is what do you do about it.  Does one "manage a team into managing itself?"

                Mike


              • Ron Jeffries
                Hello, mpkirby. On Friday, December 1, 2006, at 7:16:29 PM, you ... I would remind them of the need to meet their commitments, and when they sign up, remind
                Message 7 of 28 , Dec 1, 2006
                  Hello, mpkirby. On Friday, December 1, 2006, at 7:16:29 PM, you
                  wrote:

                  > The interesting question is what do you do about it. Does one "manage a
                  > team into managing itself?"

                  I would remind them of the need to meet their commitments, and when
                  they sign up, remind them again, and every day ask them to look at
                  how they're doing, and about a million other little things.

                  Ron Jeffries
                  www.XProgramming.com
                  Some things are impossible. And some things people say are
                  impossible -- because they don't know how to do them. -- Ron Loyd
                • Ron Jeffries
                  Hello, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you ... Are these technical tasks that should have been foreseen at planning time, or new things
                  Message 8 of 28 , Dec 1, 2006
                    Hello, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you
                    wrote:

                    > We're seeing a great deal of turnover and addition to the tasks to
                    > fulfill stories during the sprint. Much of this is attributed to the
                    > nature of our product which is video games.

                    Are these technical tasks that "should" have been foreseen at
                    planning time, or new things that the PO or someone is adding to the
                    mix.

                    If the latter: that's a no-no.

                    > Value is "fun".

                    Do you mean business value, or some other kind of value?

                    > We first attempted to create very narrowly focused stories that could be
                    > broken down and estimated, we often don't see fun. The team would see
                    > that it wasn't going to be fun during the Sprint, but their story
                    > commitment didn't allow change.

                    Why's that? Why is knowing what you're going to do "not fun"?

                    > We then shifted to creating less stringent stories that allow the team
                    > to vary the task in the Sprint to a great degree to achieve their goals.
                    > This does require someone on the team to be a product owner. This
                    > created more "fun" per Sprint. It also created more reasons to drop
                    > lower priority stories; sometimes too easily.

                    I don't understand this. Is it you and your team's view that you are
                    doing Scrum?

                    > So I don't think that saying the team has "failed" is reasonable. On
                    > the other hand, casually dropping stories can often work at odds with
                    > having the highest sustainable level of intensity throughout the entire
                    > project.

                    Intensity is not, as far as I know, a desirable element.
                    Predictability and transparency, on the other hand, are.

                    Ron Jeffries
                    www.XProgramming.com
                    The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                  • clintonnkeith
                    ... Neither. These are art/design/technical tasks that arise from the aesthic and emotional reponse to the prior attempt. For example, the team won t know if
                    Message 9 of 28 , Dec 1, 2006
                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                      <ronjeffries@...> wrote:
                      >
                      > Hello, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you
                      > wrote:
                      >
                      > > We're seeing a great deal of turnover and addition to the tasks to
                      > > fulfill stories during the sprint. Much of this is attributed to the
                      > > nature of our product which is video games.
                      >
                      > Are these technical tasks that "should" have been foreseen at
                      > planning time, or new things that the PO or someone is adding to the
                      > mix.
                      >
                      > If the latter: that's a no-no.
                      >

                      Neither. These are art/design/technical tasks that arise from the
                      aesthic and emotional reponse to the prior attempt. For example, the
                      team won't know if a character jump with one or four animations will
                      look right under all circumstance, nor can they at planning.

                      > > Value is "fun".
                      >
                      > Do you mean business value, or some other kind of value?
                      >
                      Business. Fun games sell copies.

                      > > We first attempted to create very narrowly focused stories that
                      could be
                      > > broken down and estimated, we often don't see fun. The team would see
                      > > that it wasn't going to be fun during the Sprint, but their story
                      > > commitment didn't allow change.
                      >
                      > Why's that? Why is knowing what you're going to do "not fun"?
                      >

                      You can know if a story is resulting in a fun mechanic or not half-way
                      through the sprint. What the team does as a result of that knowledge
                      is the question here.

                      > > We then shifted to creating less stringent stories that allow the team
                      > > to vary the task in the Sprint to a great degree to achieve their
                      goals.
                      > > This does require someone on the team to be a product owner. This
                      > > created more "fun" per Sprint. It also created more reasons to drop
                      > > lower priority stories; sometimes too easily.
                      >
                      > I don't understand this. Is it you and your team's view that you are
                      > doing Scrum?
                      >

                      We are doing Scrum, unless Mike Cohn (our coach) says we're not. The
                      "PO as pig" may be debatable but it has improved business value velocity.

                      > > So I don't think that saying the team has "failed" is reasonable. On
                      > > the other hand, casually dropping stories can often work at odds with
                      > > having the highest sustainable level of intensity throughout the
                      entire
                      > > project.
                      >
                      > Intensity is not, as far as I know, a desirable element.
                      > Predictability and transparency, on the other hand, are.
                      >

                      So what reason is there for the team to commit to half of what they
                      are capable of doing every Sprint? It would be more predictable and
                      transparent....
                    • Ron Jeffries
                      Hello, Keith. On Friday, December 1, 2006, at 8:11:57 PM, ... I don t understand the question. And I may have missed something ... are you happy with the way
                      Message 10 of 28 , Dec 1, 2006
                        Hello, Keith. On Friday, December 1, 2006, at 8:11:57 PM,
                        you wrote:

                        > So what reason is there for the team to commit to half of what they
                        > are capable of doing every Sprint? It would be more predictable and
                        > transparent....

                        I don't understand the question.

                        And I may have missed something ... are you happy with the way
                        things are going now?

                        Ron Jeffries
                        www.XProgramming.com
                        Thousands of years ago, the first man discovered how to make fire.
                        He was probably burned at the stake he had taught his brothers to
                        light - Howard Roark (The Fountainhead, Ayn Rand)
                      • mpkirby
                        ... The Jiminy Cricket approach to being a scrum master. Yes. I d arrived at the same conclusion. Isn t it sad that the way to move forward is to be really
                        Message 11 of 28 , Dec 1, 2006
                          > > The interesting question is what do you do about it. Does one "manage a
                          > > team into managing itself?"
                          >
                          > I would remind them of the need to meet their commitments, and when
                          > they sign up, remind them again, and every day ask them to look at
                          > how they're doing, and about a million other little things.

                          The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                          at the same conclusion. Isn't it sad that the way to move forward is to
                          be really irritating to those around you :-)

                          Mike
                        • Ron Jeffries
                          Hello, mpkirby. On Friday, December 1, 2006, at 10:18:24 PM, you ... Well ... and this will be hard to believe, yet it s true ... I try not to be irritating,
                          Message 12 of 28 , Dec 2, 2006
                            Hello, mpkirby. On Friday, December 1, 2006, at 10:18:24 PM, you
                            wrote:

                            > The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                            > at the same conclusion. Isn't it sad that the way to move forward is to
                            > be really irritating to those around you :-)

                            Well ... and this will be hard to believe, yet it's true ...

                            I try not to be irritating, though I do sometimes fall short of that
                            high aspiration.

                            Ron Jeffries
                            www.XProgramming.com
                            The greatest mistake we make is living in constant fear that we will make one.
                            -- John Maxwell
                          • dnicolet99
                            ... manage a ... is to ... What they re talking about here is called coaching , and it isn t a question of being irritating. It s a question of helping the
                            Message 13 of 28 , Dec 2, 2006
                              --- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
                              >
                              > > > The interesting question is what do you do about it. Does one
                              "manage a
                              > > > team into managing itself?"
                              > >
                              > > I would remind them of the need to meet their commitments, and when
                              > > they sign up, remind them again, and every day ask them to look at
                              > > how they're doing, and about a million other little things.
                              >
                              > The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                              > at the same conclusion. Isn't it sad that the way to move forward
                              is to
                              > be really irritating to those around you :-)
                              >
                              > Mike
                              >

                              What they're talking about here is called "coaching", and it isn't a
                              question of being irritating. It's a question of helping the team
                              discover how to manage itself effectively, as opposed to jumping in
                              and trying to do it for them.
                            • dnicolet99
                              A smell? Yeah, but in this case it s just one scent in a mixed bouquet. There are a lot of red flags lurking between the lines of Ryan s description of the
                              Message 14 of 28 , Dec 2, 2006
                                A smell? Yeah, but in this case it's just one scent in a mixed
                                bouquet. There are a lot of red flags lurking between the lines of
                                Ryan's description of the situation. It sounds like a very challenging
                                situation for the ScrumMaster, with issues to address at multiple
                                levels - team, customer, management, organization. Could be fun!



                                --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                                <ken.schwaber@...> wrote:
                                >
                                > Teams overcommitting after the third sprint is a smell that they are
                                > not managing themselves. I'll bet they don't have an accurate sprint
                                > backlog that they are updating, and I'll bet that you don't hear a
                                > group of people figuring out how they are going to meet their sprint
                                > goal every daily scrum.
                                >
                                > Ken
                                >
                                >
                                > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                > <ronjeffries@> wrote:
                                > >
                                > > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                > > you wrote:
                                > >
                                > > > My recommendation to the Scrum Master in such a situation is to
                                > > > strictly limit the amount of work accepted to the team's
                                > > > empirically-proven velocity. I think that once there is some
                                stability
                                > > > in delivery, velocity will increase naturally over time.
                                > >
                                > > Unless I am mistaken, which is quite possible, the way Scrum works
                                > > as described in Scrum 101 is that the TEAM decides how much of the
                                > > backlog they can consume, and they commit to getting that much fully
                                > > done. They adjust until they're good at it.
                                > >
                                > > That's not happening where you are ... what is happening instead?
                                > >
                                > > Ron Jeffries
                                > > www.XProgramming.com
                                > > Accroche toi a ton reve. --ELO
                                > >
                                >
                              • ryanpcooper
                                To dnicolet99: You re quite right. We have a rather dysfunctional implementation of Scrum currently. In fact, some would probably not be happy with us calling
                                Message 15 of 28 , Dec 3, 2006
                                  To dnicolet99: You're quite right. We have a rather dysfunctional
                                  implementation of Scrum currently. In fact, some would probably not be
                                  happy with us calling it Scrum at all. ;)

                                  To Ron: You're not mistaken, that is how Scrum works. Unfortunately,
                                  it's not what we've been doing, and as a result our "Scrum" hasn't
                                  been working. Our "velocity" was mandated from outside the team. This
                                  was caused by some political pressures and a lack of understanding and
                                  acceptance of Scrum in the organization as a whole. This has been a
                                  (huge) roadblock for the team, one our Scrum Master is working to remove.

                                  Cheers,
                                  Ryan

                                  --- In scrumdevelopment@yahoogroups.com, "dnicolet99" <dnicolet@...>
                                  wrote:
                                  >
                                  > A smell? Yeah, but in this case it's just one scent in a mixed
                                  > bouquet. There are a lot of red flags lurking between the lines of
                                  > Ryan's description of the situation. It sounds like a very challenging
                                  > situation for the ScrumMaster, with issues to address at multiple
                                  > levels - team, customer, management, organization. Could be fun!
                                  >
                                  >
                                  >
                                  > --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                                  > <ken.schwaber@> wrote:
                                  > >
                                  > > Teams overcommitting after the third sprint is a smell that they are
                                  > > not managing themselves. I'll bet they don't have an accurate sprint
                                  > > backlog that they are updating, and I'll bet that you don't hear a
                                  > > group of people figuring out how they are going to meet their sprint
                                  > > goal every daily scrum.
                                  > >
                                  > > Ken
                                  > >
                                  > >
                                  > > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                  > > <ronjeffries@> wrote:
                                  > > >
                                  > > > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                  > > > you wrote:
                                  > > >
                                  > > > > My recommendation to the Scrum Master in such a situation is to
                                  > > > > strictly limit the amount of work accepted to the team's
                                  > > > > empirically-proven velocity. I think that once there is some
                                  > stability
                                  > > > > in delivery, velocity will increase naturally over time.
                                  > > >
                                  > > > Unless I am mistaken, which is quite possible, the way Scrum works
                                  > > > as described in Scrum 101 is that the TEAM decides how much of the
                                  > > > backlog they can consume, and they commit to getting that much fully
                                  > > > done. They adjust until they're good at it.
                                  > > >
                                  > > > That's not happening where you are ... what is happening instead?
                                  > > >
                                  > > > Ron Jeffries
                                  > > > www.XProgramming.com
                                  > > > Accroche toi a ton reve. --ELO
                                  > > >
                                  > >
                                  >
                                Your message has been successfully submitted and would be delivered to recipients shortly.