Use SCRUM when team members juggle different roles?

Question

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

How can we use SCRUM sprint to help us deal with product development and support issues?

Answer 1

You might want to take a look at kanban or combat. I'm not a fan, but it may work better for your scenario where distractions and interruptions can be inevitable. Immerse yourself in the sprint, but keep the priority lag. Instead of tracking and measuring spring speeds, measure the delay in each phase.

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

I would recommend taking a step back. If you want to be an effective flexible team, you need to buy back management ... why does the development team make first level support? Do you have a strong lunatic who can isolate a team from distracting internal clients? I don’t know what your amount of support is, but I play with the turn through your team members to an obstacle situation, where they take on support / internal client flack for a week at a time, allowing other participants to focus. In any case, take a madman ... rotate team members through this position until you find the right person for the job.

Answer 2

Hello, I think it’s easy to say and a little difficult from the very beginning.

It causes each member of your team to become familiar with the roles that exist in your team, for example, in my company we use about 1 month for iteration, then we make a turn.

I also think that you should mix SCRUM and other software engineering techniques.

The sultan

Answer 3

Before addressing the issue of sprint, I think it’s important to know if your team is organized around Scrum roles.

• Product Owner - prioritizes products backlog items
• ScumMaster - holds daily meetings, helps to keep the team informed, removes obstacles ...
• Team - a group of people committed to delivering filled gap elements

The product owner and ScrumMaster must be two different people. Are these roles defined in your unit? If not, I would recommend considering who should fill out these slots.

In any case, I think it’s better to start small, choose some projects and pilot the process. Learn from your mistakes. See what works and what doesn't.

Because you know that other work may take precedence over planned activities. Try to complete sprints in 4-week intervals for several months. Iterate, reflect, and adjust when you go.

Finally, attract your customers, invite them to your sprint reviews. You will get excellent feedback and your product will be faster.

Answer 4

Promise less . When you plan sprints, specify the minimum probable speed. You can always pull items out of backlog if your availability increases.

If your available resource has changed a lot in all sprints, consider switching to Kanban, as others have suggested.

Answer 5

My team is also in this situation. We have many ongoing developments, but also support. And we support production services, so if there is a problem, we may need to drop everything and fix it.

We decided, so far, to continue to use the scrum, as before, but saving some time each sprint for current tickets and other works that were not known in advance. Every day there is a special person to handle incoming tickets, Nagios notifications, etc. If necessary, this person can always consult or transfer things to another engineer, but we try to avoid this. This reduces interference in the flow of other engineers.

Scheduling reserved time can seem very complicated: support loading tends to change. However, our experience is that most of the time our reserved time is in the right range. Obviously, there are exceptions where we lose a few man-days, but in the worst case, we throw items from the sprint. I can’t remember the last time this happened.

To summarize: most of the time, load support is quite predictable. Reserve time in the sprint for this, and it should work. But the most important piece of advice I can give is: try something, even if you are not sure about it, and look back in your retrospective. You only know for sure as soon as you try, and you thought.

Answer 6

I agree with Trey. You might consider Kanban or Skrumban. But what do you do when you are a true Team post production developer and can't follow Kanban for some strange organizational reason?

I was a Scrum Team master who was in a similar situation, like you. Now let me understand, when you say “1st line”, will users directly contact your product owner or your team? If so, I just think there should be another Scrum team that could handle this.

We had a Scrum Operations Support team that usually did this. Note that this command can also perform release and deployment operations. You also have another member of the Development Scrum team, a member of the Scrum Operations support group, each Sprint for support.

The important point is that after Sprint started working with the Scrum Team development team, it is not recommended to start adding production release lags during the current Sprint. This can take away the value of the current Sprint and demoralize Team members. Responsibility for the contents of Sprite does not matter, and she may have to fight the business for this from time to time. SM must, of course, do what it takes to protect the team from external influences and help the software ensure the stable operation of Sprint Backlog.

Currently, the flip side of this is sometimes management, you may need to cancel Sprint if the Sprint target is out of date. This can happen if a company changes direction or changes in market or technological conditions or if there are too many production problems. In general, Sprint should be discontinued if that makes no sense given the circumstances. However, due to the short duration of Sprints, this rarely makes sense.

So, we summarize:

• Create a Scrum team to support operations and let them be the first line support to work with Backlogs Support Support.
• Turn the tide so that developers join the Scrum Team Operations Support Sprint team to help work with production support backlogs.
• If the Sprint target becomes obsolete for Scrum Team PO, you can cancel Sprint and start a new one with new Sprint shipments.

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

Answer 7

You cannot get around both. Use Scrum or support your customers.

I would suggest using Scrum if you can create a team of at least five developers who will not be overloaded during Sprint. Typically, even if support is required, customers can wait for Sprint to complete. On the other hand, you may have one substitute developer whose task is to support customers.

The team will then be able to complete their work by developing more valuable products so that your customer support requirements are reduced. Then your organization, in my opinion, will benefit from your Scrum experience.

Answer 8

I have a team that supports two tools - including development, bug fixing, maintenance, work. Therefore, our situation is not too different. Perhaps our solution may work for you too ...

We recently started using Scrum with a two-week iteration. How we do this, we have a Service Level Agreement, which is accepted by all our customers; requests that are not covered by SLAs are accepted only during sprint planning, while those that can be processed immediately.

Then we have a General Support user story in each sprint that simply requires us to comply with the SLA. In this case, we set the task for "unknown queries", which are evaluated in the so-called hours; when new legitimate tasks appear, we subtract the new estimate of the problem from unknowns, which leads to a lack of a net increase in work. If you properly evaluate the amount of support work, this will not result in a net loss of development time. And, of course, if you underestimate what is likely to happen the first or two times, this is what you can learn from the next sprint.

With the support already included in the plan, you can better assess what you can achieve with development in one sprint. Inbound support requests may still randomize your team, but if you can focus on one task at a time, this effect is not very serious.

(We also just started using Rational Team Concert to track everything, but we didn't use it long enough so I could tell how useful it is in this situation).