In an organization that wants to use an agile/Scrum software development process, but that also has a large production support / operations burden with an expectation for quick response times, what's the best way to ensure an adequate level of production support / operations without throwing all teams' sprints into chaos?
I currently work in a software organization which consists of several teams that (have been attempting with various degrees of success to) use what is basically an agile Scrum process. We produce a set of websites that our customers use to run their businesses, and we bill them for new development they request and for ongoing maintenance and support.
Frequently, things come up during sprints that the business would like to see addressed quickly. Examples include:
- The website is not working in production and our client is on the phone with support trying to find a resolution
- Some bug has been discovered to have caused some bad database entries that require manual correction soon
- There is some audit going on where the customer needs us to produce unusual report datasets
- A new client missed a business-critical feature request and needs it worked and pushed ASAP
- Automated or manual testing finds a regression defect after the sprint that introduce it and we need to fix it before an upcoming release
I am aware that the correct response to these kinds of things is to work them in the following sprint, get the team to modify the current sprint or cancel the sprint. But each of these has some problems we'd like to avoid:
- Work in the following sprint - management buys into agile to a degree, but our paying customers don't care that we are agile, they just want a quick response to their issues.
- Modify the current sprint - this can work from time to time, especially for missed feature requests, but for standard operations type stuff - small requests - this would bog down the team in a lot of process.
- Cancel the sprint - this too has been done but it hurts our ability to deliver consistently in the long term... obviously doing this by default means just giving up on agile/Scrum, but then what do we replace it with?
One thought that has occurred to us is that we could perhaps have a new team, which uses a different process - Kanban? Something else? - to handle all of this kind of thing, and allow the agile/Scrum teams to remain more stable.
- Is this a good idea or a bad idea?
- Is there a name for this or any literature on how to do it well?
Note: we do have a non-technical customer support team who can help with usage, configuration and basic troubleshooting and workarounds. This has more to do with issues that require technical skills to investigate or resolve - code, database, etc.