Separating new development and support work ensures that new development teams can focus on continuing to bring innovative solutions to customers at a faster rate than if the team frequently switches between the two types of work.
A scrum team doing new development can plan and develop new working functionality within a one- to two-week sprint, but it’s difficult to plan when operational or maintenance issues will arise. Maintenance work usually requires shorter timeboxed iterations, typically no more than one day, which is usually the longest the organization can go without changing priorities with any issues in production.
Try a model that separates new development and maintenance work.
Operational support scrum team model.For a scrum team of nine developers, for instance, you can divide the development team into two teams, one with six developers, and the other with three. (These numbers are flexible.) The team of six does new development project work from the product backlog in one-week to two-week sprints. The work that the team commits to during the sprint planning meeting will be the only work they do.
The team of three are our firefighters and do maintenance and support work in one-day sprints or by using kanban. Single-day sprints allow the scrum team to triage all incoming requests from the previous day, plan the highest-priority items, implement those items as a team, and review the results at the end of the day (or even earlier) for go or no-go approval before pushing the changes to production. For continuity, the product owner and scrum master are the same for each team.
Although the newly modified project development team is smaller than before, there are still enough developers to keep new development efforts moving forward, uninterrupted by maintenance work. By the time you begin releasing functionality to the market, your scrum team will be working well together and the developers will have increased their versatility by being able to complete more types of tasks than when the project first started.
The project development team will have periodic releases to production, such as once every 90 days. At each release, one developer will rotate to the maintenance team, armed with first-hand knowledge of the functionality being deployed to production. At the same time, one developer from the maintenance team will be rotated into the project development team, equipped with first-hand knowledge of what it’s like to support the product in the real world. This rotation continues at each release.Development Operations (DevOps) is the collaboration and integration between software developers and IT operations (which includes functions such as systems administration and server maintenance). Taking a DevOps approach enables developers and operations to work together to tighten cycle times of deployment.
This DevOps model ensures that everyone gets to do new product development as well as maintenance work, and that product knowledge is continually shared effectively between the two development teams. This approach improves DevOps and facilitates cross-functional team members. It also minimizes any disruption the teams may experience from changing team members because the rotations happen only at each release rather than daily or weekly.When preparing for release, establishing expectations upfront of how the functionality will be supported in production allows the scrum team to develop the product in a way that enables the team to effectively support the product after it is deployed. It increases ownership across the scrum team and heightens the team’s awareness and dedication to long-term success.