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

48202RE: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?

Expand Messages
  • Roy Morien
    Aug 31, 2010
      Indeed, I agree with you entirely. But, on the other hand (as the economists would always say), if the many unplanned requests are naturally and normally arising from daily usage, that does not necessarilly imply management neglect, command and control, too many bosses etc.
       
      But what it may call forth is the question of Why are there so many unplanned requests? (yes, your same question, but viewed from a different angle). Is it because the software in use has many bugs, or does not really meet user requirements, and is being enhanced 'on the fly' to overcome this gross deficiency. It is perfectly reasonable for change requests to arise from the learning experience of using the software, but if that constitutes 60% of development work, then that can indicate a problem right from the start of the development process; ie: buggy software is being delivered, and software that has not been developed in close accord with user requirements initially is being delivered.
       
      At this point, maybe a big swing back to Scrum style development is indicated to address the problems at their source.
       
      But overall there is the notion of 'horses for courses' ... Scrum cannot be seen as appropriate for ALL situations ... although I have always held that the iterative style of development is pretty well appropriate for all situations, and the statement that 'Oh, there are some projects that can't be done that way, and need a more structured approach' is just being mealy-mouthed.
       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: alandd@...
      Date: Tue, 31 Aug 2010 22:03:19 -0700
      Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?

       
      The other side is also in question.  Why is "the company" making so many unplanned requests?  Bugs?  Management neglecting strategic plans?  Hyper-command and control?  Too many bosses?  All needs are "top" priority?

      Some teams do better with kanban and need flow of incoming work.  Even kanban enforces some control of the flow.

      But, some need to use Scrum (iteration rhythm) to help the company stop thrashing.

      Alan

      On Tue, Aug 31, 2010 at 9:25 PM, Roy Morien <roymorien@...> wrote:
       

      An interesting point, though. Scrum, and sprint planning, surely must depend on having a reasonably stable, albeit short-term, Product Backlog, that can be held at arms length away from the developers during a sprint. It seems to me that if there is a reasonably continuous stream of new requests, the 'out of sprint' stuff', then a development approach that is much more pull driven is more appropriate; take it as it comes, join the queue, we're working steadily and will do your job when it arrives at the head of the queue (excepting the situation where it does have a higher priority than existing queue items).
       
      Of course, the question of how efficient and effective the developers are does arise. And how can we measure that efficiency and effectiveness. And how can we evaluate it, for the purpose of improvement.
       
      Maybe these are questions that can be addressed to the Kanban-ers :) ... they are serious questions.


       
      Regards,
      Roy Morien
       

      To: scrumdevelopment@yahoogroups.com
      From: alandd@...
      Date: Tue, 31 Aug 2010 21:17:41 -0700

      Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?

       
      Good question.  Scrum might be appropriate, depending on the reasons why most of the work is "out of sprint."  And if that "out-of-sprint-ness" is something that hurts business purposes.

      Alan

      On Tue, Aug 31, 2010 at 9:14 PM, Roy Morien <roymorien@...> wrote:
       
      Going back to basics; if a substantial majority of the team's work is 'out of sprint' work, then is Scrum an appropriate development framework to be following?
       
      Regards,
      Roy Morien
       



      To: scrumdevelopment@yahoogroups.com
      From: bachans@...
      Date: Tue, 31 Aug 2010 09:40:55 -0700
      Subject: Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?


       
      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, 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
      > >
      > >
      > >
      >










    • Show all 39 messages in this topic