I'm part of a development organization which has traditionally been using Scrum principles. We have 3-week sprints, at the end of which we produce a software artefact which our customers install on premise, and at their own discretion. Most customers have chosen to skip every odd sprint, and thus only install every 6 weeks.
Now we have a new, large customer, with several branches which will - or already are - use our software. Each branch has slightly different requirements, and a tight schedule to production.
What we're seeing since a few months:
- Our development team spends less than 50% on backlog tasks
- Daily business is heavily influenced by ad-hoc support tickets (which can concern defects, database cleanups, training the users, or simple cause analysis)
- Every week we build service packs for already delivered releases. Thus a defect is committed to master, but then cherry picked to one or several older branches.
- The time required for above support tickets and service packs will increase in the next 2 years, after which it hopefully will decline again
- Our customers tend to not give us quick feedback, we have a feedback loop lag of sometimes several months
-- Edit reg. branches --
We do develop on origin/master. But say we're currently developing release 5.0.12, and have a bug fix or feature which the customer urgently wants on 5.0.10. In this case we cherry pick the patches to 188.8.131.52 and 184.108.40.206. There are no customer-specific branches, everyone gets the same software.
-- End of edit --
I'm pretty sure Scrum is not a good fit anymore for this kind of work. I'm not proficient with DevOps, but my understanding is that it is heavily built upon rapid and frequent deployment. If my understanding is correct, that also wouldn't fit.
Are there any best practices how to deal with this? Should we:
- Split support and development, and keep Scrum for development? (a dedicated support team is planned)
- Switch to Kanban (but keep ad-hoc support and development mixed)?