I became the scrum master of a newly established team, that is responsible for creating a software AND maintaining other deployed application. So basically each team member has development & operations tasks.

I have been observing how they work the past couple of weeks and I noticed that team is having troubles in coordinating these tasks. when a developer is concentrating on coding he get interrupted to fix an issue raised in production, and it's hard for him to focus again on previous task.

I have tried allocating % of developer time for operations work but apparently this isn't resolving the issue. I'm interested in hearing from scrum masters who came across this situation before, how did you manage it and what are your recommendations?

  • 1
    Prioritize and resolve the critical production bug first and then resume normal development. Both at the same time is asking for a mistake to be made. – Mark Rogers Dec 2 '16 at 16:05

This problem is as old as scrum. There is a solution, but you won't like it.

  • Put new tasks on the backlog.
  • Don't interrupt developers.
  • Wait for the next sprint.

Putting your devs in more than one scrum, having two separate backlogs or assigning only a percentage of their time to the sprint all work against what scrum is trying to achieve, i.e. a consistent flow of completed tasks.

If you try those type of things you basically go back to 'chaos' or 'JFDI' development methodologies with all its attendant problems e.g.

  • Developer has ten tasks on the go at any one time. No-one knows what they are working on or when it will be finished.
  • Unknown time to finish project, because it depends on what other projects are happening at the same time.
  • No consistent view of project priority. Other managers divert developers to their pet projects.

Of course the usual response to this advice is "But I can't do that! The business needs those production bugs to be fixed ASAP!"

But that is not really true.

If you really have that many actual bugs that are affecting the business to this extent then you need to get professional and improve your testing. Just work on bugs and automated tests until you have fixed them all. Hire a QA team and test the hell out of all new releases.

What is more likely though is one of the following:

  • The bugs are operational problems, running out of disk space, no DR, no Backups, no failover etc. Get an OPS team.

  • The bugs are users not understanding how the system should work "This happened! is it a bug?". Get a helpdesk and train your users, write documentation.

  • Fear of rollback. You launched a new feature and it broke something, don't try to rush out a fix. Roll back to the previous version and put the bugs on the backlog.

  • 5
    how long is your sprint? I would go down to a single week – Ewan Dec 2 '16 at 10:05
  • 3
    You can get away with not doing the review and retro, maybe do them once a month. Design (UI design?) as a separate team/sprint is a good idea i think. Hopefully most of the time the design is done before the dev starts and doesn't change too much – Ewan Dec 2 '16 at 10:37
  • 3
    The product owner wants developers to drop everything and work on production bugs, stop the current sprint, fix the bug and start another sprint when it's done. There are consequences to these decisions and this will make the product owner realize the impact on the immediate bug fixes. They'll have to use more discretion when things are considered an emergency. Or you could wait and address them during the next stand up. This way you can see who has any extra bandwidth and you don't interrupt the dev's flow. – JeffO Dec 2 '16 at 12:57
  • 5
    If you skip the review and retro and do design in a separate sprint, there's not really any Scrum left... – Erik Dec 2 '16 at 13:27
  • 6
    Your solution is "gain top authority in the company, then spend a lot of money by creating three whole new teams"? – Lightness Races in Orbit Dec 2 '16 at 14:29

Just trying to think outside the box here.

As it might not be possible to get the product owner see things your way. There still might be critical errors that simply can't wait, meeting with clients where developer assistance is needed etc. where you need to take one developer out of the sprint for a while.

Why not try to anticipate this and use it for your advantage?

You'll need a team of 5+ for it to be realistic perhaps.

But why not take one developer out every sprint (rotating between the developers, each gets their turn).

As there most likely aren't enough errors to use a full developer for corrections there are other issues or tasks that can be done.

  • Running tests to identify performance bottlenecks or scalability issues
  • Maintaining the build system
  • Meetings with clients
  • Researching new frameworks/libraries
  • Exploring language features you'd like to use
  • Reading up on security issues
  • Database maintenance
  • Server maintenance

The team velocity might go up, stress might go down, conflicts with management might go down, you actually get time to improve your knowledge.

  • 3
    I was thinking the same -- rotate one developer to do the "chores" (production issues) and because he isn't going to get a lot of real work done, let him do research / exploration / other irregular thing as well. And do a good root cause analysis of each production issue so the number of them goes down. – RemcoGerlich Dec 2 '16 at 12:16
  • 1
    That's actually a very good idea! I'm going to need to hire one or two more developers but I believe it's worth it. Many thanks! – Shadin Dec 2 '16 at 13:00
  • 1
    On our project, we have formalized that position to some extent. We have a senior dev on each team who is designated Tech Lead for the scrum team. The TL does a number of things (mentor junior developers, do "4+1 plans" before production, solve problems for other devs as they come up, etc) but one thing that comes with being TL is dealing with hot potato production issues and high priority defects. Obviously, a LOT depends on your production system/philosophy but the TL can intervene to "shield" the rest of the team and let them focus on user stories. – JBiggs Dec 2 '16 at 18:10

An effective solution for managing developer effort for truly essential production issues that I've used is the "Batman approach".

The expensive aspect of production support responsibility while developing new functionality is context switching, so you should aim to limit that.

With the team's buy in, create a list of the team members and cycle through it, so that each day, a new person is declared "Batman" at the stand up meeting and will respond to essential production issues on that day. The remainder of the team can stay focused on development without having to context switch and everyone has a fair share of the pain of support. With a team of 5, that's one day a week where a developer may be interrupted and 4 days of uninterrupted, predictable development time.

This has the benefit of knowledge/experience being shared among the team, so you don't have one person responsible for fixing particular issues and becoming a single point of failure and fair division of support issues.

  • A very interesting approach and I believe it's applicable in our situation now! Many thanks! – Shadin Dec 3 '16 at 7:43

protected by maple_shaft Dec 2 '16 at 17:20


Would you like to answer one of these unanswered questions instead?
