Re: [scrumdevelopment] Re: What to do when the team is not firing on all cylinders?
- Op 1-9-2010 20:13, barrettdab schreef:
But this is reality for many, many developers. In many companies, the programmers that built something become the SME's when support issues come up. Not just bug fixes, but ad hoc reporting, performance management, data fixes, consulting and training, and God knows what else. And if all the experts are working on new development? Tough. Business has to keep on going day to day.
Things like reporting, appraisels, drinking a cup of hot chocolate, getting trained, going to the toilet, having meetings are a fact of (business) life, and necessary. It is not overhead and if it doesn't get out of hand there is nothing wrong with it and I won't be claiming that a developer should be coding for 100% of his available type.
I didn't list support, for a good reason. "Support" is a rather big area to address. If the company doesn't have a kind of customer support I would strongly advise to try to get a separate customer support. I've seen a separate customer support role in even the smallest companies. And if not then the PO or SM could take up the role. As a ScrumMaster I've done that, filtering out many requests that would otherwise had to be handled by the developers directly. The cool thing about doing this is that you get a rather good idea where the team is lacking some practices.
Defects always seem to be urgent, especially if people have learned that the only way to get their complaints fixed is by being a nuisance. Therefore you need good triage. You can develop some simple guidelines for classification, but even then the hard part is to stick with it.
Now there will be some defects of the type 'urgent & important'. This kind of defects can't be put on the backlog for next sprint and must be handled now. It is a valid reason for a sprint termination. And the most important thing is then looking at why you ever released a product with this kind of defect and what will be changed to avoid it next time.
If the large part of the defects that is flowing in is of this type you should either take a good look at your triage or accept the fact that what you've done in the past wasn't good enough and stop developing new stuff until you have fixed the quality issues. You can't build on a flaky foundation.
I don't think "Scrum" is suitable for all contexts, especially if you are not willing to live up to some basic rules. I think that you might miss out on some benifits that you can get if you would, but that doesn't mean that you can't do effective software development. You should do Scrum if you think the benifits outweigh the costs, if not find something that better suits you.
Personally, I think it would be a real shame if we said to everyone working in those circumstances (which I strongly suspect is a large majority of programmers out there in the real world), "Sorry, unless you're in a team totally dedicated to single, multi-iteration project doing greenfield development without any maintenance responsibilities, you can't do Scrum". Mostly, because it's not true.
- 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