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

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

Expand Messages
  • Kevin Callahan
    Oct 4, 2012
    • 0 Attachment
      Hi Cass,

      > 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?
      >

      It's certainly been discussed, though we value the stability granted through scrum's sprint/timebox structure, particularly since we are a nearly completely distributed organization. All of us are in the US, though spread out pretty good, so we miss out a lot on the benefit and gains of being able to ask a question across the room, huddle around a whiteboard, etc. Add to that a high degree of inter-team dependencies and things start to get more interesting and benefit from structured over on-demand planning, development, and inspection/adaptation. We have eliminated (masked?) a lot of pain by syncing up the teams' schedules within a day or so. Of course more than 4 or 5 teams and this latter approach breaks down, well, a lot of things break down at that scale and require a new approach. So yes, as you suggest there are some inefficiencies, though we feel that overall where we are it's more valuable to the enterprise to stick with scrum for now. We do continue to inspect and adapt this, and there are places in the org where we're implementing kanban boards to make visible WIP and bottlenecks both within and between teams.

      > 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?
      >

      Of course :) As long as our devs are also production support, there will be some degree of interrupt-driven work. Though I agree it is a smell of some deeper issues. For example some of the scalability issues we're working through is a weakness due to a sort of evolution of patches, of over and over putting a simple solution in place for a complex problem even though it's known (or suspected) to be imperfect in ways that could hurt down the road. Simplicity is good when it lowers costs and increases revenue; it gets a little tricker when the deeper costs begin to emerge and it's clear that collectively, we've let some things slide that we probably shouldn't have; hindsight is, of course, always perfect and being able to more clearly perceive what to let go and what to dig in on and fix is tough. I've started coaching to this point, and attempting to shift mindsets away from a more reactive patch approach toward designing and building more robust systems from the get go even if it takes more effort and thus expense (the Oz Principle at work, really). This is, of course, a tricky balance because we don't want to be architecting the end-all perfect system, just the one that maximizes quality and performs enough to get it out the door and generate value. It's a bit of a juggling act for sure, though at this point I think we're too far into the territory of blaming external APIs for sucking (which they absolutely do) rather than acknowledging that the engineering problems are a bit tricky to solve and seeking a higher level of innovation. Then again, it's not like we're writing software to fly space craft, airplanes, or planetary exploration robots; there are much, much more difficult problems in the software universe that have been solved...

      Additionally, we've identified some solid paths toward improvement of our releases, which historically tend to be pain points; some of these are process-related milestones counting back from the release date that will give better early warning that things are slipping. Again this is a patch, a reactive band-aid that does little to solve the problem though enables us to better detect it. More importantly though, is *why* they're slipping, which gets into much more interesting conversations about how the teams are estimating and committing to work, how production issues (often resulting from lack of alignment, poorly-planned work, etc) are pushing the schedule out, and how user stories and acceptance criteria are being too broadly written that either create pockets for unknowns and risk to hide in, or strive to decompose proposed work into the smallest independent chunks to minimize the effect of one piece hanging up grinding the whole feature development to a halt; again it's a balancing act driven by productive communication and alignment. We're investing heavily in learning about the latter (among other improvements in engineering practice and integration of test roles into the dev team), and it's really starting to pay off as all quarters of engineering step up their game; pretty exciting, really.

      Anyhow, hope that's helpful; good questions for sure!!!

      -kevin



      On Oct 3, 2012, at 8:26 PM, Cass Dalton wrote:

      >
      > 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@...
      >
      >
      >
      >
      >
      >

      Kevin Callahan, CSP
      Scrum Master
      mobile: 207-691-2997
      AIM: kevmocal
      email: kcallahan@...
    • Show all 21 messages in this topic