How can Scrum work when the development team is the support team as well? [closed]

Question

What happens in Scrum when the development team is the support team as well? How can this be improved using Jira?

We can't have a fire fighter because not all developers can solve both front-end and back-end issues. But the support issues make team velocity difficult to obtain.

Answer 1

Mike Cohn wrote a good article on sprint planning for teams with a lot of interruptions.

He suggests having a rolling estimate of the average time spent on interruptions. Then allow for that when you do sprint planning.

For example, say the team averages 30% of their time spent on fixing issues. When you do the planning you plan for a capacity of 70% for development work.

As you mention in your question, nominating a person to handle issue fixes is a common approach. This is beneficial as it allows the other members of the team to focus on new development work without unexpected interruptions. In your situation where developers are specialists this is more difficult to achieve. You may want to consider doing some cross-skilling so that developers can handle a broader range of issues. They may not fix some issues as well as a specialist, but the loss in efficiency is gained back by the rest of the team avoiding interruptions.

Other things worth considering:

• Triage bugs and only do the critical ones immediately. Schedule the other bug fixes as a part of your next sprint planning session. This may be easier to achieve if you have short sprints (say 1 week long) as the users will have less time to wait for a fix.
• Analyse the bugs and see if some development work could potentially prevent future issues. For example, you may find that a lot of bugs occur due to bad data. Spending time making the code more tolerant to bad data can help.
• Consider investing more time in automating your regression tests. This up-front investment of time can reduce the number of future bugs. It may seem like a lot of time and effort to do this, but making your workload more predictable can be valuable enough to offset this cost.

Production bugs have a bigger impact than the time spent fixing them due to the unpredictable way in which the work arises. That is why focusing on quality makes sense, even if it does seem like a lot of extra effort.

Answer 2

So the SCRUM is really for planned work, and if there is a lot of interruptions it may not be the best approach, maybe you should look at kanban or combination of both?