How to coordinate developers time between two different projects in Scrum?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.