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

RE: [scrumdevelopment] Variable sprint lengths

Expand Messages
  • Wolfgang Schulze Zachau
    This is a wonderful example of how Scrum exposes weaknesses in an organization, which now has a chance to reconsider various options and the importance of
    Message 1 of 10 , Oct 2, 2007
      This is a wonderful example of how Scrum exposes weaknesses in an organization, which now has a chance to reconsider various options and the importance of Scrum.
      The very simply answer is: Don't. Do not vary the length of your sprints. It plays havoc with all sorts of things. Your velocity is never really quite clear, people have trouble with committment, your customers cannot rely on a regular cycle of delivery, and the list doesn't stop here. We did it, and our troubles only stopped when we stopped modifying sprint length (and some other things). It's one of those rules that cannot be bent or broken without braking the whole thing.
      The underlying problem is that your PO is not committed. If (s)he was, (s)he would make sure to be there when needed. If someone has a responsibility, but cannot or won't fulfil it, it shows a lack of accountability and committment (or authority, but I don't think that's the case here). So now the question is: why? Is (s)he working fulltime as a PO? Or is this just one of a list of activites for her/him? If yes, why? Does the top brass believe in Scrum? Do they understand how it works? Are they pulling the PO in different directions? Or is it the PO herself/himself?
      (and there are more questions to ask).
      And yes, you are right: there is absolutely no point in closing a sprint without the PO.
       

      Regards,

      Wolfgang

       


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emiliano Heyns
      Sent: 02 October 2007 10:38
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Variable sprint lengths

      Hi,

      I'm wondering what to do about the variability of our sprint lengths. It makes it a bit harder to monitor our velocity, but our PO has very limited availability and way too much leave time, so we've had to slightly lengthen or shorten our sprint lengths so far in order to have the PO present at the review session. How much of an issue is this?

      We're managing so far, but that may be because we're just getting ramped up on scrum, so we may not be noticing how much we're missing. I can't really force the PO to be present, however, and closing the sprint without him would be pointless.

      Emile

    • Emiliano Heyns
      Hi Wolfgang, ... No, unfortunately. He works part-time, and only about half of the time he s available to the organization is allotted to us. Effectively, that
      Message 2 of 10 , Oct 2, 2007
        Hi Wolfgang,

        On 10/2/07, Wolfgang Schulze Zachau <wolfgang@...> wrote:
        The underlying problem is that your PO is not committed. If (s)he was, (s)he would make sure to be there when needed. If someone has a responsibility, but cannot or won't fulfil it, it shows a lack of accountability and committment (or authority, but I don't think that's the case here). So now the question is: why? Is (s)he working fulltime as a PO?

        No, unfortunately. He works part-time, and only about half of the time he's available to the organization is allotted to us. Effectively, that means 1-2 days a week. He goes off on holidays quite frequently. I can hardly begrudge him that, but it is inconvenient for our team.

        Or is this just one of a list of activites for her/him?

        Yes.

        If yes, why?

        He has always had many responsibilities. He's not a product manager in the traditional sense, he works in the finance departments and has not been freed from many of his existing responsibilities.

        Does the top brass believe in Scrum?

        The top brass is not explicitly involved in Scrum. Our project group was asked for the current project, and we've started using scrum for most of our projects recently. Since we're using scrum, we have asked for the steering group to provide a product owner.

        Do they understand how it works? Are they pulling the PO in different directions?

        I suppose that could be said. The long and short of it is simply that he's not exclusively ours.

        And yes, you are right: there is absolutely no point in closing a sprint without the PO.

        Which brings us to the simple problem: we've only started scrum since early this year, and the holidays of this PO have been long scheduled. So that pretty much leaves us 4 choices:
        1. Request a different PO. Not likely to be granted, and we wouldn't really want it anyway. The PO himself has been fine so far.
        2. Allow variability in the sprint length
        3. Finish without the PO present (as said, pointless)
        4. Start the sprint later so the 3-week mark falls at a date the PO is available
        We've actually done 4 once -- all the team members are, unfortunately, also only assigned part-time to this project, so the time between sprints could be used to go full-time on the other projects, and when the sprint did start we had two full weeks of full-time on this project, which was absolutely fab for focus and productivity.

        We know our setup is very far from ideal. It's still an unbelievably big step forward in manageability and productivity, so we're sticking with it and aim for improvement where possible.

        Part of the problem is that this place doesn't really have strong background in doing projects. It's mostly an office-type setup, with our project-targeted group the exception rather than the rule.

        Emile
      • paul_oldfield_ams
        (responding to Emile) ... One thing I ve had succeed on a RUP project might work for you? We assigned someone from our team to act as Product Owner proxy and
        Message 3 of 10 , Oct 2, 2007
          (responding to Emile)

          > No, unfortunately. He works part-time, and only about half
          > of the time he's available to the organization is allotted
          > to us. Effectively, that means 1-2 days a week. He goes
          > off on holidays quite frequently. I can hardly begrudge
          > him that, but it is inconvenient for our team.

          One thing I've had succeed on a RUP project might work for
          you?

          We assigned someone from our team to act as "Product Owner"
          proxy and spend all the time available with the true PO
          to capture as much as possible of the relevant information.
          The rest of the time this proxy PO was acting as a PO for
          the rest of the team. Thie proxy had good Business Analyst
          skills, so could use his time effectively when with the
          true PO.

          We did something similar when there were multiple stakeholders
          whose needs we had to fold into one coherent view of a
          compromise product.

          Sure, it takes a couple of cycles to iron out most of the
          misunderstandings between true PO and proxy, so be
          prepared for the proxy to "change his mind" a bit more once
          the true PO sees the product. OTOH, we found that a good
          BA could on occasion spot and resolve problems as the
          requirements were captured, that would otherwise not be
          spotted until the working code was demonstrated. (Don't
          rely on that happening - Waterfall does, but it goes wrong
          too often!).

          Paul Oldfield
          Capgemini
        • Wolfgang Schulze Zachau
          Well, I suppose the fundamental question really is how important is this project to the company? If it is really important, then surely they can be made to
          Message 4 of 10 , Oct 2, 2007
            Well, I suppose the fundamental question really is how important is this project to the company? If it is really important, then surely they can be made to understand that a fully committed Product Owner is essential for the success of it.
            Our own PO also has other duties, but there is no doubt in anybody's mind that his PO duties come first.
            We sometimes vary the length of sprints by single days, but then we have been doing Scrum for 2 years now, with a fixed team.
            Option 4 sounds like a good choice, expecially if you do have other work to do. In the long run I would try and move towards option 1. The current PO can still be an influential stakeholder and provide input to the PO, but a fulltime PO is always better than a part-timer. Same goes for the team. Here I would raise the question whether it is worth while to put all your work into ONE big product backlog (seeing that you have ONE pool of resources) and the work off that.
            I presume you are currently the Scrum Master? How about training somebody else for that role and becoming PO yourself?
             
            The problem with a part-time PO is that Scrum is based on lots of communication going on between the PO and the team. Without this, there will be misunderstandings and lack of knowledge/information and subsequently the solutions implemented by the team will be off target (Even XP asks for a customer on site full-time, for the very same reason). It's almost always better to have a fulltime PO with less domain knowledge compared to a part-time PO with full domain knowledge. The domain knowledge can be built, time cannot.
             

            Regards,

            Wolfgang

             


            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emiliano Heyns
            Sent: 02 October 2007 11:52
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Variable sprint lengths

            Hi Wolfgang,

            On 10/2/07, Wolfgang Schulze Zachau <wolfgang@mobilefun. co.uk> wrote:

            The underlying problem is that your PO is not committed. If (s)he was, (s)he would make sure to be there when needed. If someone has a responsibility, but cannot or won't fulfil it, it shows a lack of accountability and committment (or authority, but I don't think that's the case here). So now the question is: why? Is (s)he working fulltime as a PO?

            No, unfortunately. He works part-time, and only about half of the time he's available to the organization is allotted to us. Effectively, that means 1-2 days a week. He goes off on holidays quite frequently. I can hardly begrudge him that, but it is inconvenient for our team.

            Or is this just one of a list of activites for her/him?

            Yes.

            If yes, why?

            He has always had many responsibilities. He's not a product manager in the traditional sense, he works in the finance departments and has not been freed from many of his existing responsibilities.

            Does the top brass believe in Scrum?

            The top brass is not explicitly involved in Scrum. Our project group was asked for the current project, and we've started using scrum for most of our projects recently. Since we're using scrum, we have asked for the steering group to provide a product owner.

            Do they understand how it works? Are they pulling the PO in different directions?

            I suppose that could be said. The long and short of it is simply that he's not exclusively ours.

            And yes, you are right: there is absolutely no point in closing a sprint without the PO.

            Which brings us to the simple problem: we've only started scrum since early this year, and the holidays of this PO have been long scheduled. So that pretty much leaves us 4 choices:
            1. Request a different PO. Not likely to be granted, and we wouldn't really want it anyway. The PO himself has been fine so far.
            2. Allow variability in the sprint length
            3. Finish without the PO present (as said, pointless)
            4. Start the sprint later so the 3-week mark falls at a date the PO is available
            We've actually done 4 once -- all the team members are, unfortunately, also only assigned part-time to this project, so the time between sprints could be used to go full-time on the other projects, and when the sprint did start we had two full weeks of full-time on this project, which was absolutely fab for focus and productivity.

            We know our setup is very far from ideal. It's still an unbelievably big step forward in manageability and productivity, so we're sticking with it and aim for improvement where possible.

            Part of the problem is that this place doesn't really have strong background in doing projects. It's mostly an office-type setup, with our project-targeted group the exception rather than the rule.

            Emile

          • Emiliano Heyns
            ... I like that. In our case, however, the person closest to having something that could be labeled BA skills without the rest of the group sniggering would be
            Message 5 of 10 , Oct 2, 2007
              On 10/2/07, paul_oldfield_ams <Paul.Oldfield@...> wrote:
              (responding to Emile)

              > No, unfortunately. He works part-time, and only about half
              > of the time he's available to the organization is allotted
              > to us. Effectively, that means 1-2 days a week. He goes
              > off on holidays quite frequently. I can hardly begrudge
              > him that, but it is inconvenient for our team.

              One thing I've had succeed on a RUP project might work for
              you?

              We assigned someone from our team to act as "Product Owner"
              proxy and spend all the time available with the true PO
              to capture as much as possible of the relevant information.
              The rest of the time this proxy PO was acting as a PO for
              the rest of the team.  The proxy had good Business Analyst
              skills, so could use his time effectively when with the
              true PO.

              I like that. In our case, however, the person closest to having something that could be labeled BA skills without the rest of the group sniggering would be me -- and I don't think PO and SM should be the same person.

              Emile
            • Emiliano Heyns
              ... That is a very good question indeed. Our project was started to automate the calculation of KPIs (Scorecarding) for units within our organization. These
              Message 6 of 10 , Oct 2, 2007
                On 10/2/07, Wolfgang Schulze Zachau <wolfgang@...> wrote:
                Well, I suppose the fundamental question really is how important is this project to the company? If it is really important, then surely they can be made to understand that a fully committed Product Owner is essential for the success of it.

                That is a very good question indeed. Our project was started to automate the calculation of KPIs (Scorecarding) for units within our organization. These KPIs have so far been done by hand, which we've already established was error prone and not even consistently wrong when the numbers indeed were off. But the bottom line is that the KPIs can be done by hand -- the pain and cost involved might not be visible enough.

                Our own PO also has other duties, but there is no doubt in anybody's mind that his PO duties come first.
                We sometimes vary the length of sprints by single days, but then we have been doing Scrum for 2 years now, with a fixed team.

                We're talking full-week deviations on 3-week sprints. We've only been doing this since May or so.

                Option 4 sounds like a good choice, expecially if you do have other work to do.

                We do.

                In the long run I would try and move towards option 1. The current PO can still be an influential stakeholder and provide input to the PO, but a fulltime PO is always better than a part-timer. Same goes for the team. Here I would raise the question whether it is worth while to put all your work into ONE big product backlog (seeing that you have ONE pool of resources) and the work off that.

                We sorta-kinda do in the team to keep an eye out to make sure each project mostly gets their allotted time. But the projects have no real common ground, and the people involved are not necessarily the same persons.

                I presume you are currently the Scrum Master?

                You presume correctly ;)

                How about training somebody else for that role and becoming PO yourself?

                A 2nd SM is going in for training in December, so it's worth consideration. I must say I'm enjoying being SM immensely.

                The problem with a part-time PO is that Scrum is based on lots of communication going on between the PO and the team. Without this, there will be misunderstandings and lack of knowledge/information and subsequently the solutions implemented by the team will be off target (Even XP asks for a customer on site full-time, for the very same reason). It's almost always better to have a fulltime PO with less domain knowledge compared to a part-time PO with full domain knowledge. The domain knowledge can be built, time cannot.

                Good point. What is clear to me is that this is indeed going to be the cause of inefficiency, so I'll raise it at the next retrospective.

                Emile
              • Petri Heiramo
                Hi, ... limited ... lengthen ... at the ... I consider these things as one of those just have to manage with situations. You should keep trying to set up a
                Message 7 of 10 , Oct 2, 2007
                  Hi,


                  > I'm wondering what to do about the variability of our sprint lengths. It
                  > makes it a bit harder to monitor our velocity, but our PO has very
                  limited
                  > availability and way too much leave time, so we've had to slightly
                  lengthen
                  > or shorten our sprint lengths so far in order to have the PO present
                  at the
                  > review session. How much of an issue is this?

                  I consider these things as one of those "just have to manage with"
                  situations. You should keep trying to set up a regular cycle, but
                  until that day happens (if it ever does), you'll have to try to set up
                  each sprint as a timeboxed iteration with a predefined end date
                  _at_the_start_ of the sprint. So even if each sprint is slightly of
                  different length, they are all of predefined length. Try to get the PO
                  committed to each sprint review session well in advance. Changing end
                  date _during_ the sprint should be avoided. Then again, if you can't
                  avoid that, then just replan a little based on new end date.

                  I know that's not a book example but reality never is. Remember the
                  purpose of iterations, never lose sight of that (i.e. clear checkpoint
                  to see where the project is, a replanning and communications session
                  with the product owner, and an opportunity to meet stakeholders for
                  feedback). You should be fine.


                  Petri Heiramo
                  Senior Process Improvement Manager
                  SYSOPENDIGIA Plc., Finland
                • Petri Heiramo
                  Wolfgang has a very good list of why you should try to get to the regular release cycle. :) I agree with all that. Bring it to the attention of the PO. See if
                  Message 8 of 10 , Oct 2, 2007
                    Wolfgang has a very good list of why you should try to get to the
                    regular release cycle. :)

                    I agree with all that. Bring it to the attention of the PO. See if
                    he/she can sort the participation. But I don't think you can just say
                    "I refuse to co-operate until you agree to a fixed schedule".
                    Communicate with patience and try to work out a solution.


                    Petri Heiramo
                    Senior Process Improvement Manager
                    SYSOPENDIGIA Plc., Finland


                    --- In scrumdevelopment@yahoogroups.com, "Wolfgang Schulze Zachau"
                    <wolfgang@...> wrote:
                    >
                    > This is a wonderful example of how Scrum exposes weaknesses in an
                    > organization, which now has a chance to reconsider various options
                    and the
                    > importance of Scrum.
                    > The very simply answer is: Don't. Do not vary the length of your
                    sprints. It
                    > plays havoc with all sorts of things. Your velocity is never really
                    quite
                    > clear, people have trouble with committment, your customers cannot
                    rely on a
                    > regular cycle of delivery, and the list doesn't stop here. We did
                    it, and
                    > our troubles only stopped when we stopped modifying sprint length
                    (and some
                    > other things). It's one of those rules that cannot be bent or broken
                    without
                    > braking the whole thing.
                    > The underlying problem is that your PO is not committed. If (s)he
                    was, (s)he
                    > would make sure to be there when needed. If someone has a
                    responsibility,
                    > but cannot or won't fulfil it, it shows a lack of accountability and
                    > committment (or authority, but I don't think that's the case here).
                    So now
                    > the question is: why? Is (s)he working fulltime as a PO? Or is this
                    just one
                    > of a list of activites for her/him? If yes, why? Does the top brass
                    believe
                    > in Scrum? Do they understand how it works? Are they pulling the PO in
                    > different directions? Or is it the PO herself/himself?
                    > (and there are more questions to ask).
                    > And yes, you are right: there is absolutely no point in closing a sprint
                    > without the PO.
                    >
                    >
                    > Regards,
                    >
                    > Wolfgang
                    >
                    >
                    >
                    >
                    > _____
                    >
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emiliano Heyns
                    > Sent: 02 October 2007 10:38
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: [scrumdevelopment] Variable sprint lengths
                    >
                    >
                    >
                    > Hi,
                    >
                    > I'm wondering what to do about the variability of our sprint lengths. It
                    > makes it a bit harder to monitor our velocity, but our PO has very
                    limited
                    > availability and way too much leave time, so we've had to slightly
                    lengthen
                    > or shorten our sprint lengths so far in order to have the PO present
                    at the
                    > review session. How much of an issue is this?
                    >
                    > We're managing so far, but that may be because we're just getting
                    ramped up
                    > on scrum, so we may not be noticing how much we're missing. I can't
                    really
                    > force the PO to be present, however, and closing the sprint without him
                    > would be pointless.
                    >
                    > Emile
                    >
                  • David Milner
                    Having a proxy PO is a good idea. Also an option would be to make a business analyst of some sort who works in the same area as the PO the official PO, and
                    Message 9 of 10 , Oct 2, 2007
                      Having a proxy PO is a good idea.  Also an option would be to make a business analyst of some sort who works in the same area as the PO the "official" PO, and move the part-time PO just to a stakeholder type of position just based upon availability.  If the current PO has great business sense, experience, and is valuable that's a good way to keep them in the loop while not sacrificing Scrum principles.
                       
                      Dave


                      Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
                    Your message has been successfully submitted and would be delivered to recipients shortly.