God bless, I never had a lot of deal with maintenance. But I am curious, is it possible to customize Scrum for maintenance?
If yes, how to guarantee SLA (if developers have a fixed Sprints), for example? Or what Product owner should do? Gather bug reports or something else?
I would have a look at Scrumban, it combines best of both worlds Kanban and Scrum.
Kanban gives you a more just-in-time way of planning where you can tackle issues that are incoming as soon as possible. Combining this with the Scrum roles and meetings leads to something that feels very good for maintenance teams.
Product owners should develop the long-term vision and the short-term priority list, just like normal. But instead of set fixed date planning meetings. Do just-in-time planning sessions with the Product owner and make a top-list of items, repeat this when-ever the short-term backlog is nearly dried up.
There is one good question, when to release? Release when ever the work you need to release is finished or release everything that is finished on a set date. Focus on getting stuff really done and make sure you have a branch that is always in a releasable state.
Also read the free e-book: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
Maybe also check this question, where possible ways of handling adhoc work during a sprint are explained.
While it may be possible to use Scrum, queue-based frameworks are generally a better fit for support processes. Queues should be designed around response times rather than solution lead times for best results.
Capacity and work-in-progress (WIP) limits should also be clearly articulated. You should also have a clear plan of how to handle situations where capacity or WIP limits are insufficient to meet your defined Service Leval Agreements (SLAs).
You can certainly adopt agile practices for maintenance, but SLA guarantees per se are (by definition) not iterative and not agile. Agile frameworks are about improving estimates and continuous process improvement; they are not designed to guarantee fixed lead times.
With that said, while Scrum is a project management framework, an agile framework like Scrum or Kanban can certainly be used for support with a large number of caveats. Scrum in particular is largely focused on estimating capacity based on time-boxed iterations, which isn't particularly conducive to dealing with high-priority issues that arise mid-Sprint. Handling support while a product is being developed is certainly part of Scrum, but I wouldn't recommend it for a support-only process.
Kanban is somewhat of a better fit for support processes, insofar as it's queue-based. As maintenance issues are found, they are enqueued. With Kanban, you have the flexibility to design queues that map to your service level agreements, but again with some caveats. In particular, Kanban is optimized for queues with predictable variability in story size. Support and maintenance tickets would therefore need to be aggressively managed and decomposed into bite-sized pieces in order to maintain flow.
In my personal experience, an SLA should guarantee response time rather than promising a fixed time-box for results. With Kanban, that could be accomplished by adding a few queues such as "Triage" and "Respond to Customer", and ejecting or pausing work-in-progress (WIP) items from other queues when your high-speed queues are full.
It's important to understand that there's no free lunch. Regardless of your methodology, your team needs to have sufficient capacity to manage the maximum WIP you are expected to handle within your SLA. If you exceed those WIP limits, then you must have a defined process for managing your WIP limits. This may be via transparent communications with your internal or external customer, or (in some environments) may be handled as business risk with attendant costs such as customer refunds. No matter how you handle it, or what your planned capacity is, it is always possible to exceed your queue size or WIP limits, so you must decide ahead of time how to handle that.
Scrum is not suitable for software maintenance. Kanban is.
Kanban was developed at Toyota in Japan to improve the auto assembly line.
David Anderson literally wrote the book on the use of Kanban in Information Technology (IT).
Kanban has only a few principles:
Visualize the workflow: You cannot improve what you cannot see. Knowledge work needs a way to visually show the status of each task. Kanban boards are one way to display this progress.
Limit Work In Progress (WIP): Minimizing WIP improves throughput.
Measure the lead time: Cumulative flow charts are very useful for this purpose. And look for ways to make continuous improvements in small increments.
Although I'm posting a response a year after the question is asked, but this seems to be a common question and hope my experience would help some people in taking the right decision for their respective organizations.
According to me, here is a mix that works best for maintenance projects:
1). Define a sprint cycle - week or 2-week cycle depending on the volume of work, time it takes to fix/test/release, the number of resources you have in your team and the client's perspective/expectations.
2). Plan and re-plan sprints as often as possible to be on top of the estimates v/s current status. You'll also arrive at velocity or capacity to deliver in a few weeks time, which will further help you in planning.
3). I would not recommend use of Story points for maintenance, as hourly estimate works better in this case, since you exactly know what needs to be fixed and how much efforts are required, rather than going for relative-estimation techniques.
4). Use Kanban Board to keep a track of progress of tickets/incidents.
5). Daily stand-up meetings would help to resolve smaller or urgent bottle-necks while the Retrospective analysis would help to gradually improve the process.
6). Too much focus on process may also lead to bottleneck at times since you tend to lose the flexibility and agility. I recommend to be flexible enough to accommodate changes to sprint as long as nobody(other than process) is getting hurt.
In a nutshell, lots of wonderful tools, techniques & processes are available, you would want to choose only the ones that would really help you and your business.
Best, Nitesh
