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

Re: What to do when the team is not firing on all cylinders?

Expand Messages
  • Michael
    Kevin, The out of sprint work is being done first because these requests are coming from both the director and the VP of engineering. Mike
    Message 1 of 39 , Sep 1, 2010
    • 0 Attachment
      Kevin,

      The out of sprint work is being done first because these requests are coming from both the director and the VP of engineering.

      Mike

      --- In scrumdevelopment@yahoogroups.com, Kevin Johnston <kevj121@...> wrote:
      >
      > Hi mike
      >
      > Why is the out of sprint work being done first if you have a backlog maybe it should be added to it and prioritised?
      >
      > Regards
      >
      > Kevin
      >
      >
      >
      > Sent from my iPhone
      >
      > On 1 Sep 2010, at 15:15, "Michael" <mikeabugow@...> wrote:
      >
      > > Hi All,
      > >
      > > My goal is to help this team respond to their sprint backlog effectively, and to help the P.O. say no to the out of sprint work that continually comes up. Myself and one of the other ScrumMasters in my division agree that a Kanban approach would be more appropriate for this type of development team. Unfortunately, upper-management does not feel that switching to Kanban is a worthwhile exercise.
      > >
      > > The team sees itself as getting more work done than ever before, and feels they are doing a good job when they get the little amount of actual planned work completed along with all of the planned for out of sprint work.
      > >
      > > Mike
      > >
      > > --- In scrumdevelopment@yahoogroups.com, Bachan Anand <bachans@> wrote:
      > > >
      > > > Michael ,
      > > > Great post !!
      > > >
      > > > On Tue, Aug 31, 2010 at 8:14 AM, Michael <mikeabugow@> wrote:
      > > >
      > > > >
      > > > >
      > > > > Alan,
      > > > >
      > > > > Agreed, this is a case of education and fear. I have discussed this with
      > > > > the team in multiple retrospectives, and their group opinion is they are
      > > > > doing fine because they are getting so much work accomplished. Even though,
      > > > > most of the work is out of sprint,
      > > > >
      > > >
      > > > Is your objective to stop out of Sprint work or to have a more effective way
      > > > of handling the new stories that comes up. How long are your sprints,
      > > > intention of the question is to explore whether the Sprint duration has
      > > > anything to do with out of Sprint .
      > > >
      > > > > which they set aside story points for every sprint. (My only victory thus
      > > > > far as their SM.)
      > > > >
      > > > > We started tracking out of sprint work so not only the team, but also so
      > > > > management could see how little actual planned for work is being
      > > > > accomplished during the sprint. This tracking, unfortunately become the
      > > > > accepted norm.
      > > > >
      > > > > Mike
      > > > >
      > > > >
      > > > > --- In scrumdevelopment@yahoogroups.com<scrumdevelopment%40yahoogroups.com>,
      > > > > Alan Dayley <alandd@> wrote:
      > > > > >
      > > > > > This appears to be a case of the team not knowing what they are missing.
      > > > > In
      > > > > > other words, they don't see a problem to solve so they refuse the
      > > > > solution
      > > > > > as not needed. Education is the answer and may take a while.
      > > > > >
      > > > > > Another likely issue is that they fear application of more control around
      > > > > > the interruptive work. If they choose to track the flow of the
      > > > > > interruptions that means they sometimes will have to stop accepting
      > > > > another
      > > > > > task. Maybe they fear having to work with and regulate incoming requests.
      > > > > > Again, education of the team and the people making requests is necessary.
      > > > > >
      > > > > > I find two major sources of objections to pair-programming.
      > > > > >
      > > > > > First, many individuals like to be specialists and see value in being The
      > > > > > One with the answers for specific needs. They see specialization as job
      > > > > > security. This fear has some basis in fact and has to be addressed by
      > > > > > providing confidence that their individual value is secure as possible,
      > > > > even
      > > > > > if someone else also has similar skills and knowledge.
      > > > > >
      > > > > > Second pair-programming is seen as inefficient. Two people working on one
      > > > > > task is percieved as wasteful since a second task by the second person is
      > > > > > not being worked on. Education about pair programming benefits in code
      > > > > > quality, cross-training, culture and team building is needed there.
      > > > > >
      > > > > > A quick approach to get past the education need is to couch the new idea
      > > > > as
      > > > > > an experiment. For example, if they still object to pair-programming,
      > > > > > suggest that the team try it for just one sprint. One experiment is worth
      > > > > a
      > > > > > thousand or more white papers and a million presentation slides!
      > > > > >
      > > > > > Alan
      > > > > >
      > > > > > On Mon, Aug 30, 2010 at 10:53 AM, Michael <mikeabugow@> wrote:
      > > > > >
      > > > > > >
      > > > > > >
      > > > > > > Hi All. I have relatively small Scrum team that is responsible for
      > > > > database
      > > > > > > design, and maintenance. Unfortunately, this team is treated as an
      > > > > > > operations type team, but is still expected to run as an Agile Scrum
      > > > > team.
      > > > > > > Greater than 60% of their work is out of sprint tasks. I have suggested
      > > > > that
      > > > > > > they try incorporating Kanban as part of their development cycles.
      > > > > > > Unfortunately, neither the team, nor their P.O. sees this as a viable
      > > > > > > alternative to having constant out of sprint work given to them.
      > > > > > >
      > > > > > > Also, each member of the team is considered a specialist in their
      > > > > > > day-to-day work by the other team members. I have suggested the team
      > > > > try
      > > > > > > pair-programming so that they each can pick up any task at any time.
      > > > > Again,
      > > > > > > the team has not seen the value in this.
      > > > > > >
      > > > > > > Any suggestions on how I can help this highly specialized, and
      > > > > constantly
      > > > > > > distracted team?
      > > > > > >
      > > > > > > Thanks,
      > > > > > > Mike
      > > > > > >
      > > > > > >
      > > > > > >
      > > > > >
      > > > >
      > > > >
      > > > >
      > > >
      > >
      > >
      >
    • Matheus Henrique Gorino
      Do your management knows that you are NOT doing Scrum already? When you say they do not want to leave Scrum , I d say they want to implement Scrum . And if
      Message 39 of 39 , Sep 22, 2010
      • 0 Attachment
        Do your management knows that you are NOT doing Scrum already?
        When you say "they do not want to leave Scrum", I'd say "they want to implement Scrum". And if they want to implement Scrum, they need to really buy the idea, to play the game, and stop disrupting the process.
        What I feel from what I read is that they do not want do Scrum, they just want do stick to the process you are running today, a Kanban with some Scrum practices that you can call anything but Scrum.
        In this case, my discussion with them would be something like: "We do not do Scrum today. We can't do Scrum because we can't follow some of it's basic rules. We can do Kanban and put some Scrum practices in place. And we need to understand what practices would bring value to our custom process."
        The division in Sprints, for example, seens to be waste. Doing retrospectives every two weeks or so might bring value. Prioritizing tickets might bring value. Planning the items that were in that 40% of the backlog might bring value. Daily Meetings might be waste. And so on.

        On Fri, Sep 3, 2010 at 4:15 PM, JackM <jack@...> wrote:
         

        There was very little in the way of actual advice on how to solve this problem. I think the answer to your question is ..

        1. identify the source of interruptions and track them on the burndown so everyone can see how the team is being affected.

        2. as was mentioned above. bring the interrupts into the sprint, track in it's own backlog for example and budget for the interrupts in the sprint.

        3. batch the delivery of solutions for interrupts. When i joined my current company it was natural for anyone in the company to go directly to the developer and ask them to fix something. They were delivering patch after patch after patch. Now we set a patch delivery cycle, everything get's batched and everything is managed within the sprint. It's amazing how when you share a patch schedule with your customers how accepting they are. This helps you to manage your resources more effectively and become more predictable.

        4. Find out why so many interrupts - usually this is a code quality issue. So figure out how to pay down this debt. We invested heavily in automation and unit tests. Eventually this will pay dividends.

        5. Pair program, share the knowledge then you have more flexibility to pull some folks off to deal with maintenance while the rest of the team works on the core sprint stuff. This role can be rotated assuming you have collective code ownership.

        Hope this helps
        jack
        www.agilebuddy.com


        --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
        >
        > On 9/2/10 12:39 AM, David A Barrett wrote:
        > >
        > >
        > > I think I'd take a different approach to this.
        > >
        > > If the problem is that the team is spending too much time on "out of
        > > Sprint" items, then pull those activities into the Sprints.
        >
        > ...
        >
        > > I think you'll be surprised at how little people get upset when you tell
        > > them that some big job will need to wait until it can be prioritized
        > > into a Sprint.
        >
        > Yes, I think that's a fine solution. And if people /can't/ wait, or say
        > they can't, then consider shortening your sprints. No work is
        > instantaneous, even if started right away, so the argument "I need it
        > right now" holds no water.
        >
        > - George
        >
        > --
        > ----------------------------------------------------------
        > * George Dinwiddie * http://blog.gdinwiddie.com
        > Software Development http://www.idiacomputing.com
        > Consultant and Coach http://www.agilemaryland.org
        > ----------------------------------------------------------
        >


      Your message has been successfully submitted and would be delivered to recipients shortly.