Use SCRUM when team members juggle different roles? [closed]

Question

Our roles are not purely product development. We also provide '1st-line support' for internal & external customers, and any of these tasks, by their very nature, will always override any product development priorities.

How can we use SCRUM's sprints to help us manage product-development and support issues?

Answer 1

You might want to take a look at kanban or scrum-ban. I'm not a fan but it may work better for your scenario where distractions and interruptions may be unavoidable. Ditch the sprint but still keep a prioritized backlog. Rather than tracking and measuring spring velocity, measure latency in every phase.

http://leansoftwareengineering.com/ksse/scrum-ban/

I would recommend taking a step back though. If you want to be an effective agile team you need management buy off... why is the development team doing first level support? Do you have a strong scrummaster that is able to insulate the team from distracting internal customers? I don't know what your support volume is but I'd play with rotating through your team members into an impediment magnent position where they take all support/internal customer flack for a week at a time, allowing the other members to focus. In any case, pick a scrummaster... rotate team members through that position until you find the right person for the job.

Answer 2

Hello I guess it is easy to say and a bit complicated at the beginning.

Causes the each member of your team must to become familiar with the roles which exist in your team, for example in my company we use about 1 month period for iteration then we make a rotation.

Also I think you should mix SCRUM and other software development technics.

Sultan

Answer 3

Before addressing the question of sprints, I think it's important to know if your team has organized around the Scrum roles.

• Product Owner - prioritizes product backlog items
• ScumMaster - conducts daily meetings, helps keep the team on track, eliminates obstacles...
• Team - the group of folks committed to delivering the completed backlog items

The Product Owner and ScrumMaster should be two different people. Have these roles been defined in your unit? If not, I'd recommend considering who should fill these slots.

Anyway, I think it's better to start small, pick some projects and pilot the process. Learn from your mistakes. See what works and what doesn't.

Since you know that other work may take precedence over planned activities. Try completing sprints in 4-week time intervals for a few months. Iterate, reflect and adjust as you go.

Lastly, get your customers involved, invite them to your sprint reviews. You'll get great feedback and your product will get better faster.

Answer 4

Promise less. When you plan sprints, specify a minimum likely velocity. You can always pull items in from the backlog if your availability increases.

If your resource available is highly variable across sprints, consider moving to Kanban, as others have suggested.

Answer 5

My team is in this situation as well. We have a lot of continuing development work, but also some support. And, we support production services, so if there is an issue, we may need to drop everything and fix it.

We opted, so far, to keep using scrum as before, but reserving some time every sprint for ongoing tickets and other work not known in advance. Every day, there is a dedicated person for handling incoming tickets, Nagios notifications, etc. In case of need, that person can always consult or hand over things to another engineer - but we try to avoid this. This reduces the disturbance in the flow of other engineers.

Planning the reserved time may seem very difficult: the load of support tends to vary. However, our experience is that most of the time, our reserved time is in the right range. There are obviously exceptions, where we lose several man-days extra, but in the worst case we drop items from the sprint. I cannot recall the last time this happened though.

To summarise: most of the time, support load is quite predictable. Reserve time in the sprint for this, and it should work out. But, the most important advice I can give is: try something, even if you're not so sure it's the right thing, and look back on it in your retrospective. You only know for sure once you've tried, and reflected.

Answer 6

I agree with Trey. You could consider Kanban or Scrumban. But what do you do when you are a true development Team post production and cannot follow Kanban for some strange organisational reason?

I was a Scrum Master of a Team which was in a similar situation as you. Now let me get this clear, when you say "1st line" do the users directly contact your Product owner or your Team? If yes, I just think there needs to be a different Scrum Team which could handle this.

We had a Operations Support Scrum Team which usually did this. Note this Team may also do release and deployment activities. Also have a different Development Scrum Team member join the Operations Support Scrum Team every Sprint for support activities.

An important point is that a once a Sprint has started for a Development Scrum Team it is not recommended to start adding Production Issues Backlogs during the current Sprint. It may take away the value of the current Sprint and demoralize the Team members. It is the POs responsibility to keep the Sprint Backlog List stable, and she may have to fight the battle against the business for doing this at times. The SM should certainly do what it takes to protect the Team from outside influences and help the PO in ensuring the Sprint Backlog is stable.

Now the flip side to this is sometimes Management may need to cancel a Sprint if the Sprint Goal becomes obsolete. This could occur if the company changes direction or if market or technology conditions change or if there are too many production issues cropping up. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. However, because of the short duration of Sprints, it rarely makes sense to do so.

So to summarize:

1. Form an Operations Support Scrum Team and let them be the first line support who would work on Production Support Backlogs.
2. Rotate turns for developers to join the Operations Support Scrum Team each Sprint to help work on Production Support Backlogs.
3. If the Sprint goal becomes obsolete for a Scrum Team PO could cancel the Sprint and start a new one with new Sprint Backlogs.

References: Scrum Guide - Ken Schwaber and Jeff Sutherland (Creators of Scrum)

Answer 7

You can't do both. Either use Scrum, or support your customers.

I would suggest using Scrum if you can build up a Team of at least five developers who won't get interupted during the Sprint. Generally, even though support is required, customers can wait for the Sprint to end. On the other hand, you might have one spare developer whose job is to fulfill customers support.

The Team will then be able to fulfill its job by develiring higher value products so that your customer support requirements will decrease. Then your organization will benefit, in my opinion, of your Scrum experience.

Answer 8

I have a team that supports two tools - including development, bug fixing, maintenance, the works. So our situation is not too different. Maybe our solution could work for you as well...

We recently started using Scrum with a two-week iteration. The way we do it, we have a Service Level Agreement that is accepted by all our customers; requests that aren't covered by the SLA are only taken in during sprint planning, whereas those that are can be worked on immediately.

We then have a user story of "General Support" in each sprint that simply requires us to follow the SLA. Under that, we put in a task for "unknown requests" that's evaluated in so-and-so hours; when new legit tasks come in, we subtract the new task's evaluation from the unknowns, resulting in no net gain of work. IF you estimate appropriately the amount of support work, then this results in no net loss of development time. And of course, if you do underestimate, which will probably happen the first one or two times, that's something you can learn from next sprint.

With support already accounted for in the plan, you can better evaluate what you can achieve development-wise in one sprint. Incoming support requests can still randomize your team somewhat, but if you can focus on one task at a time this effect is not very serious.

(We've also just started using Rational Team Concert for tracking everything, but we haven't used this long enough for me to say just how useful it is in this situation).