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

55919Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?

Expand Messages
  • Cass Dalton
    Oct 5, 2012

      I believe you are arguing semantics.  The use of the word maintenance comes.from the fact that the work appears after the main development is done, not from any wear and tear on the software.  The reason that such work is relevant to the discussion is that this work often comes in unexpectedly and is high priority because it is a defect that is preventing a downstream consumer of the software (customer, integration team, etc.) from working effectively.  Whereas normal development has a flow that lends itself well to scrum's fixed length iterations of immutable work (I.e. not changing work/scope/priorities for work assigned to a Sprint), this so called "maintenance" work can throw a wrench in the process.  The organization is faces with the choice between sticking to the ideals of scrum or responding to their downstream customers.  Customers usually win.  In this discussion thread, it appears that is the case for the OP.  While this is not a catastrophic problem, it detracts from some of the value you get from following the scrum process the way it was intended.  The team focus is degraded and the information radiators may be affected.

      > Every change to a piece of software is made to accomplish some *new* feature.

      Really?? You've never made a code change for the sole purpose of fixing an existing feature?  I want to give you the benefit of the doubt, but that statement makes it sound like you've never written code in a production environment.
      On Oct 5, 2012 10:08 AM, "woynam" <woyna@...> wrote:
       


      That's funny. I take the complete opposite viewpoint: There is *no* such thing as software maintenance. The term was obviously coined by someone in the Accounting Department who didn't understand software, and was trying to figure out how to depreciate the costs associated with it.

      Unlike a building's roof, a furnace, or an automobile, software does not wear out. It has *no* moving parts. Given a piece of software and a piece of hardware, it will continue to function as built indefinitely.

      Every change to a piece of software is made to accomplish some *new* feature.

      Do you want you software to run under Windows 7, when it was not designed for it? Well, that's a *new* feature. It's not "maintenance".

      Mark

      --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
      >
      > I'm partial to the Pragmatic Programmers definition. All development is
      > maintenance. It's particularly true if you are aggressive about
      > refactoring.
      >
      > On Thu, Oct 4, 2012 at 7:36 AM, Charles Bradley - Scrum Coach CSP CSM PSM I
      > <chuck-lists2@...> wrote:
      >
      > > **
      > >
      > >
      > > Cass,
      > >
      > > How do you define "maintenance type stories"?
      > >
      > > My guess is if I asked 10 different developers at 10 different orgs, I'd
      > > get wildly different answers.
      > >
      > > So, how do you define that?
      > >
      > >
      > > -------
      > > Charles Bradley
      > > http://www.ScrumCrazy.com <http://www.scrumcrazy.com/>
      > >
      > >
      > > ------------------------------
      > > *From:* Cass Dalton <cassdalton73@...>
      > > *To:* scrumdevelopment@yahoogroups.com
      > > *Sent:* Wednesday, October 3, 2012 6:26 PM
      > >
      > > *Subject:* Re: [scrumdevelopment] Re: Does anyone have experience in
      > > adopting Scrum in Software Maintenance?
      > >
      > >
      > >
      > > Kevin,
      > > With your backlog consisting of a significant percentage of maintenance
      > > type stories, is there any reason that your organization wouldn't also move
      > > to Kanban? Or do you feel that the maintenance type work is resulting from
      > > systemic issues in your org/process that you'd like to understand and
      > > address before making that type of change?
      > > On Oct 3, 2012 7:51 PM, "Kevin Callahan" <kcallahan@...> wrote:
      > >
      > > **
      > >
      > > Hi Xiaozhou,
      > >
      > > Here's what the team I work with is doing these days; I would say we're an
      > > intermediate-level adoption and constantly striving to improve. We have
      > > several scrum teams working toward a web oriented architecture, meaning
      > > that teams write features required by other teams and then expose that
      > > functionality via external API calls. One of the pain points is the
      > > conflict between planned feature development and unplanned emergent work, a
      > > nice way to say production issues; all of these are tracked in the same
      > > backlog on a per-team basis. We used to call all production issues bugs,
      > > though over time it's become more and more clear that this is not the case.
      > > Yes, some of these are due to defects in the software, though more often
      > > they are due to unforeseen use contexts, changes to behavior of external
      > > data APIs (the app is a sort of middleware), or volume that is outside of
      > > the design parameters.
      > >
      > > Because of these latter points, we now treat production issues as research
      > > spikes, and they are added to the current sprint as for us, responding to
      > > production trumps all other work, and you may start to see why so many
      > > folks have suggested Kanban for maintenance, because technically in Scrum,
      > > we can't just mess with the committed sprint backlog. Customers who want
      > > their apps to work as expected though tend not to care a whole lot how
      > > technically correct our Scrum implementation is :) Anyhow, so after the
      > > devs have dug into the issue a bit they can give an overview of what's
      > > going on. With that information we can decide if this is truly a bug or an
      > > emergent feature, what it's relative size is, and the PO can use this to
      > > decide the priority of fixing it now or adding a new item into the product
      > > backlog for future attention.
      > >
      > > Obviously, this situation requires a renegotiation of the sprint backlog,
      > > with previously-committed items falling out of the sprint. While this is a
      > > scrum anti-pattern of itself, to me the more important thing is the
      > > communication within our organization, that information is flowing into and
      > > out of the team, that there is alignment and agreement on priorities and
      > > current dev actions, and that we are maintaining a sustainable pace of
      > > development, and of course, that we are continuously improving the quality
      > > of our software and the value it delivers to our customers.
      > >
      > > Anyhow, I hope that helps a bit; I don't think I can give you much more
      > > info on our internals for a use case though you're welcome to contact me
      > > off-list if you'd like more specifics…
      > >
      > > Thanks,
      > >
      > > -kevin
      > >
      > >
      > > On Sep 28, 2012, at 8:16 PM, lixiaozhou wrote:
      > >
      > >
      > > Hi, Steve
      > >
      > > Thank you for your time replying. I kind of screwed myself up by choosing
      > > this topic when i have no actual experience in a real-life scrum project.
      > > Anyway,long story :D
      > >
      > > And concerning what you've brought up, that's the thing i'm interested in.
      > > And what i would also like to know is that how a PO prioritize the sprint
      > > backlog and maintenance backlog simultaneously.Are there any models to
      > > follow or universal guidelines? And what are the factors that might
      > > influence the priority of maintenance stories compared to original user
      > > stories? That would be the spot i could write something about. And do you
      > > by any chance know some projects that I might use as a case?
      > >
      > > Many Thanks for your time. And sorry for my lack of knowledge.
      > >
      > > Best wishes.
      > >
      > > --- In scrumdevelopment@yahoogroups.com, "Steve" <steve@> wrote:
      > > >
      > > > Hi
      > > >
      > > > My first question is how come you are doing a masters in 'advanced'
      > > Scrum when you are still a rookie! But that's acedemia for you!
      > > >
      > > > The way I have implemented it has always been with developers that are
      > > also maintainers.
      > > >
      > > > They work 3 week Sprints on developement during which time maintenance
      > > requests come in and are added to a Maintenance Backlog (I even managed to
      > > get the users to write requests in User Story format for one
      > > implementation!).
      > > >
      > > > On the Monday of the fourth week all the relevant people gather for a
      > > maintenance Sprint planning workshop where the requests are prioritised,
      > > estimated and planned.
      > > >
      > > > The team work their way through the plan for the rest of the week and
      > > have a demo on the pm of the Friday; then they go back to development on
      > > the next Monday.
      > > >
      > > > This has had the effect that some low priority maintenance requests
      > > never get done; some increase in priority as time goes on.
      > > >
      > > > Of course 'showstopper' maintenance requests are dealt with immediately;
      > > the team allow for such possibilities in their development sprint planning
      > > but it happens very rarely.
      > > >
      > > > So that's one way. I have never seen a dedicated maintenance team.
      > > >
      > > > --- In scrumdevelopment@yahoogroups.com, "lixiaozhou" <lixiaozhou725@>
      > > wrote:
      > > > >
      > > > > Greetings
      > > > >
      > > > > My name is Xiaozhou Li, a student in University of Tampere in Finland.
      > > And i'm a total rookie in scrum development area. Recently, i've been
      > > working on my master thesis concerning adopting Scrum in software
      > > maintenance and relevant issues. And so far i have some general questions
      > > including:
      > > > >
      > > > > How do you feel about using scrum in software maintenance compared
      > > with traditional software maintenance process (personally)?
      > > > >
      > > > > In which way do you think it's more efficient and profitable (if you
      > > indeed think it's efficient and profitable)?
      > > > >
      > > > > Are there any drawbacks that bothering you if any?
      > > > >
      > > > > What are the best practices you think would be concerning scrum in
      > > software maintenance?
      > > > >
      > > > > ......
      > > > >
      > > > > I would bring up more specific questions about it later on as i'm a
      > > bit stuck so far. Thanks a lot for your kind responses including all
      > > constructive advices and criticism. THANKS. MERCI. GRACIAS. KIITOS ...
      > > > >
      > > > > ps. feel free to contact me with any sort of ideas
      > > > > email: lixiaozhou725@
      > > > >
      > > >
      > >
      > >
      > > Kevin Callahan, CSP
      > > Scrum Master
      > > mobile: 207-691-2997
      > > AIM: kevmocal
      > > email: kcallahan@...
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      >

    • Show all 21 messages in this topic