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

Re: [scrumdevelopment] Variable sprint lengths

Expand Messages
  • 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 1 of 10 , Oct 2, 2007
    • 0 Attachment
      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 2 of 10 , Oct 2, 2007
      • 0 Attachment
        (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 3 of 10 , Oct 2, 2007
        • 0 Attachment
          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 4 of 10 , Oct 2, 2007
          • 0 Attachment
            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 5 of 10 , Oct 2, 2007
            • 0 Attachment
              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 6 of 10 , Oct 2, 2007
              • 0 Attachment
                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 7 of 10 , Oct 2, 2007
                • 0 Attachment
                  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 8 of 10 , Oct 2, 2007
                  • 0 Attachment
                    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.