RE: [scrumdevelopment] Re: Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac
- View Source
I’ll jump in regarding maint etc.
We have a program which consists of multiple projects.
Some projects are under major development efforts. There are goals to be met and release plans consisting of multiple sprints. We use scrum and have a team that is “mostly” consistent.
Other projects are in O&M. By contract they have so many “patches” that are released per year.
For the most part the DR/bugs are not urgent. The releases for these can be very ad hoc regarding release dates, number of bugs fixed, and how consistent team works that effort vs. others. The team (of 1 or 2) is less consistent. So a sprint plan seems overkill (to many on the team) as many will work on the larger efforts and the patch is not as pressing. A patch release could go out with 5 or 10 DRs and usually that is ok. Or it could go out with 10 DRs this month or next month.
Hope that makes some amount of sense.
Michael et. al,
I concur with David on this.
In Ken Schwaber's blog post:
He talks of 4 different types of problem spaces(From Process control theory or some such study):
What you describe sounds somewhat chaotic.
What Dave described, IMO, is an attempt to go from chaotic to complex, and Scrum can work well for complex problem spaces.
In a different forum, Ken also makes the point that Kanban might work well for "complicated" problem spaces, where work is more known than unknown, like IT support tickets (not software bugs, mind you). For instance, an IT support team that will: install/fix your office phone, install/fix your computer, maintain A/V equipment, etc. Their requests are often repeated (build pc for person A, build PC for person B, upgrade person C's machine). Now, each ticket will not be exactly the same, but many of the tickets will have a lot in common and thus there are more knowns than unknowns.
To me, a software maintenance team that is doing bug fixes for defect reports is not "complicated" work, it is "complex" work, and as such Scrum can work just fine.
You know what doesn't work well? People getting pulled off of bug fixing efforts all of the time. It kinds of smacks of the idea that bug fixes are really not that important or urgent, as Dave says. What it smacks of is someone is trying to keep developers "busy" instead of "producing the most value."
I will say that one might be able to use a Kanban board for a Scrum team to help highlight the fact that people are being pulled elsewhere. But, do you really need a different board to figure that out? Do you not talk about these issues in the retrospective? What is is that your team thinks it will get from Kanban that it won't get from Scrum?
I can understand your trepidation about using Scrum in a maint scenario like you described, but tell us where you think you might have difficulty implementing Scrum in that scenario and maybe we can help out. I've coached several teams that do both maintenance and new features all at the same time. Typically, it's a single team doing both, so none of this "getting pulled away" business.
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: David A Barrett <dave.barrett@...>
Sent: Thursday, October 27, 2011 2:53 PM
Subject: [scrumdevelopment] Re: Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac
Two thoughts on this:
First the situation described, which seems to be an endless procession of bug fixes handled in an ad hoc manner, doesn't fit any reasonable definition of "project". A project is supposed to be a journey, with at least a theoretical end point and some kind of achievable goal. The only goal in this situation seems to be "keep the software running for another day".
So I wouldn't call it a project, and I'm not sure that project management processes, Scrum or otherwise, are appropriate to manage it.
Secondly, the idea that "...operatibility is a key: meaning that any "unexpected situation" would have to be fixed very fast", doesn't ring true with me. Show me a system where operability isn't a key....you can't. Just because something doesn't work the way you thought it should doesn't mean that changing it is automatically a top priority.
OK, so I don't really think that any of this stuff is that important with the situation described, because I don't think this situation really is a "project" in the sense that most of us would think of one. But this idea that maintenance work somehow presents some insurmountable barrier to Scrum seems to come up over and over, and it just isn't true.
A bug is simply work that someone wants you to do. It's not instantly more important than any other work that they want you to do. If the system is in production, the nature of the bug *might* make it super important, but that's something that you need to decide when it's reported to you. It's not unestimate-able. You need to have a system to decide how to triage bugs when they are reported. Determine if it's something you can clear up in a few minutes, and them maybe you just fix it right away. If not, you have to evaluate the actual urgency and the importance of the bug. Bugs which aren't important can wait. Bugs which aren't urgent - surprise - can wait.
How do you schedule them? Personally, I'd just toss them into the PB with all the other work someone wants. Let the PO figure out what he wants done first. Others take unction with that, claiming that it screws up their metrics, and velocity and earned value with rework. So have a different list if it makes you feel better.
Here's the key thing, once you've got a way to get the trivial, non-urgent, or non-important unscheduled out of the day to day interruptions, you then get a feel for how much time the truly non-trivial urgent and important stuff sucks out of your Sprint. Then plan your Sprints taking this into account.
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.