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

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

Expand Messages
  • Charles Bradley - Scrum Coach CSP CSM PSM
    Oct 3, 2012
    • 0 Attachment
      Correction:
      > Whether it is true to Scrum or not, I'll leave that judgement to others.
      Should read
      > Whether it is true to Scrum or not, I'll leave that judgement to others, but I reserve the right to discuss/debate the judgement by others.  :-)
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: Charles Bradley - Scrum Coach CSP CSM PSM I <chuck-lists2@...>
      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      Sent: Wednesday, October 3, 2012 5:59 PM
      Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



      Good post, Kevin.

      What you described is a very similar to the approach the one I've used several times myself for production support and bugs.  Whether it is true to Scrum or not, I'll leave that judgement to others.

      http://www.scrumcrazy.com/bugs
       
      -------
      Charles Bradley
      http://www.ScrumCrazy.com




      From: Kevin Callahan <kcallahan@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Monday, October 1, 2012 8:42 AM
      Subject: Re: [scrumdevelopment] Re: Does anyone have experience in adopting Scrum in Software Maintenance?



      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










    • Show all 21 messages in this topic