Re: What to do when the team is not firing on all cylinders?
- 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. Create some simple rules (I'd suggest based on the amount of effort required to complete one of these "out of Sprint" activities and its urgency) to decide when an activity is appropriate to being handled in an ad hoc manner, and when it needs to be added to a PB and prioritized. And then make sure the Team lives by those rules.
Create a PB for maintenance items. When you do your Sprint planning, consider the Maintenance PB alongside your development project PB and decide which is the most important to the organization.
The big thing here is that you're currently letting virtually anyone in the company highjack the Development Team who, probably, don't have the knowledge or authority to decide what should be done right now, and what shouldn't. So by giving them some clear guidelines to push back on ad hoc jobs that smell big and non-urgent, it goes back to the PO and the management of the departments requesting the ad hoc tasks to decide what needs to be done first.
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. The other thing that you'll find is that people will started adding stuff to the maintenance PB all by themselves (and then following up with their department management to make sure that it gets a high priority) or that they'll start coming to the Team and asking, "This is big and not too urgent. Do I need to put it on the PB". Finally, they'll figure out that they need to plan in order to get stuff done and they'll actually start putting the stuff into the Maintenance PB as soon as they know about instead of waiting until the last minute.
The big win is transparency. The fact is, the guys in Marketing know that they're planning a big mailing in October, and they've known it for 6 months. And when they come to you on September 28th, 1 week into your 4 week Sprint, because they need you to add 2 new servers to the web server farm to handle the increased traffic that it will generate, and they also need some "rush" programming done to track the visits in some special way then that's going to take 6 man days to complete, then you tell them, "To do that, we'll need to terminate the current Sprint and re-plan". And, of course, the PO needs to do that. And the PO might tell the Marketing guys to pound sand. Or not, but the Marketing guys may look like a bunch of twits because they sat on this info for months. But the Team is NEVER pulled in two directions on this.
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please delete it and advise me (by return e-mail or otherwise) immediately.
Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez le supprimer et m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
- 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
--- In email@example.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