Most product development teams own both development and support responsibilities for the products they build. Sometimes that’s done because there just aren’t enough people to staff separate teams; sometimes it’s because the best people to diagnose and fix a problem are the ones that built the product in the first place. There are good reasons for either approach. However, no matter why you do it, you’re going to be faced with a BIG problem.
How do you maximize the value your team is producing while also allowing for support-based interruptions?
To produce the best outcomes, there are a few things you must pay attention to. The most important two, focus and capability, are the keys to creating a team that can effectively handle simultaneous development and support. In this blog post, I’m going to give you a series of tips and tricks you can use to allow your teams to achieve the best outcomes: both in development and support tasks.
Tip #1: Stop Bailing and Fix the Hole in the Boat!
I want you to imagine you’re in a small boat with two other people and the boat is taking on water from the hole in the bottom. All three of you are bailing out the water as fast as you can but, as hard as you are working, you’re aren’t lowering the water level in the boat. Obviously, somebody needs to fix the hole. Bailing is good, but until the hole is fixed, you’re going to end up bailing until you tire yourself out. Game over.
The same is true for support teams. Yes you have to fix the problems, but don’t forget to address the causes too!
As a team, do the following:
- Treat every support issue as an opportunity to improve the product – most problems are caused by 1) users doing something they shouldn’t be able to do, 2) users misunderstanding what they are supposed to be doing, or 3) external factors that are very difficult to predict or control. Once a problem is fixed that took more than a few hours, put it on a list for review during the retrospective at the end of the Sprint. During the retrospective, take three or four of the most expensive issues and identify more permanent fixes for them or tools that will make them easier to diagnose and fix next time. As easy as it is to blame the user, don’t. If a user can break the product somehow, it is the team’s job to fix it, not the user’s. Think about things like coding changes to catch the error conditions, better documentation, more intuitive UIs. Add those items to the product backlog for later work. Throw the rest of the list away; don’t start building yet another uselessly long TODO list for your team. If a problem reoccurs, it’ll be back and the team can address it when it returns.
- Treat every support issue as an opportunity to improve the team – when a problem occurs, does the same person fix it again and again? Is the cause of the problem something the team seems to be doing wrong again and again? If so, we need to 1) teach other people how to deal with the problem, and 2) we may need to improve the capabilities of the team. When a problem is fixed, what can we learn from the fix about our future work? Do we need better comments? Do we need better error messages? Do we need to test for more unusual conditions before updating that database or sending that transaction? What skills can we improve that would help us in the future? Every problem is a potential gap in the team’s product development techniques.
- Treat every support issue as the last time you want to see that problem – fixing a problem once is OK. Fixing it multiple times is problematic. Where possible, write automated tests to ensure that a specific problem can’t occur anymore (or, at the very least, won’t have to be solved by your team again). In addition to test automation, better tools for your users or customer support representatives to diagnose and fix common problems can go a long way toward reducing the support load on your team.
Tip #2: Use the Sprint Goal to Your Advantage
Sprint Goals are intended to provide focus for your team. Here at Artisan, we recommend that most Sprint Goals include
- the services or functionality you want to provide or build
- the quality goals you want to achieve
- the capability goals you want to achieve
When we write Sprint Goals that ignore the obvious need to also address support issues, we create unnecessary tension for the team. By “unnecessary tension,” I mean that the team becomes conflicted (frustrated and confused) between trying to accomplish the functionality they forecast for the Sprint while, at the same time, having to deal with support issues. Once a Sprint Goal is proven to be clearly unachievable because the team has had to spend so much time on “unplanned” support work, they tend to forget about the goal – it becomes unachieved because the team decides it is unachievable.
In other words, when there is a clear dichotomy between the goal and the reality, the goal is forgotten. Once the goal is forgotten, the team loses focus and momentum. Imagine a football team knowing that they can’t score a goal because of the insane capabilities of the opposing team. At that point, why try?
Instead, I recommend you write a Sprint Goal that looks a little more like this:
“By the end of the Sprint, we will complete the customer registration capability, close all new severity 1 and 2 issues in two days or less, and have two more team members capable of repairing database out-of-sync issues.”
Let’s take it apart. The Sprint Goal above has three parts:
- the functional subgoal (“complete the customer registration capability”)
- the quality subgoal (“close new severity 1 and 2 issues in two days or less”), and
- the capability subgoal (“have two people more team members capable of repairing…”).
The functional sub-goal is about the Product Backlog Items the team forecast for this Sprint during Sprint Planning. The capability subgoal is about what the team determined at the previous retrospective they need to add to their capabilities. The important part for our purposes is the quality subgoal – to close all new severity 1 and 2 issues in two days or less.
By including the quality subgoal in the Sprint Goal, the team can now rally around their goal of attacking and closing high severity issues in two days or less. Because the reality (the team is working on development AND support issues) is now in alignment with the Sprint Goal, the team can react to support issues not as the end of their chances of accomplishing the Sprint Goal, but as an opportunity to raise the bar. Now the Sprint Goal serves the team again (as it is supposed to), instead of causing endless frustration.
Tip #3: Use History
The problem a lot of teams cause themselves is planning too much into a Sprint and not leaving time to deal with support issues. The best way to deal with this problem is to do the following:
- DO NOT size support issues that come to the team as an escalation (as in, “has to be fixed now”). Sizing these issues is a waste of time; you can’t use the size for anything.
- DO size support issues that are added as Product Backlog Items and planned into a Sprint (and if the team says they can’t size a support issue until it’s diagnosed, figure out the average size of most defects and just use that — remember, sizes don’t need to be right, they need to be consistent).
- Set your next Sprint’s capacity (that is, how much they can safely plan into the Sprint) as equal to the velocity of the previous Sprint.
A team’s velocity is defined as the sum of the sizes of the Product Backlog Items completed during the Sprint. So, if you DON’T size the escalated support issues, the team’s velocity is now defined as the sum of the sizes of the PLANNED work in the Sprint. You can use this value to properly plan the next Sprint.
Oh, but now there’s excess capacity in the Sprint!! My team can do more. Yes, they can. But there’s no benefit in planning product backlog items the team knows they won’t do because of support issues. Planning more than the team can do is not only frustrating, it’s a big waste of time.
What happens if there isn’t much support work in a Sprint and the team has excess capacity? Get the team together and plan a little more work into the Sprint — just make sure that the Sprint Goal doesn’t change as a result (that’s a BIG no-no in Scrum).
Tip #4: Put Boundaries Around Severity
All support issues are not created equal. Some are really important and need to be addressed right away. They are usually defined as “Sev-1” (critical). Some support issues represent annoying problems and are lower severities (e.g., “Sev-5”).
Get a clear definition of what differentiates a low severity issue from higher severity issues, how quickly work needs to begin, and how quickly a solution needs to (ideally) be in place. For example:
| Severity | Explanation | Time to Start | Time to Complete |
|---|---|---|---|
| 5 | minor issue; doesn’t keep the user from using the product (i.e., spelling errors, button in the wrong location, wrong color/style used) | 60 days | 90 days |
| 4 | annoying issue; can cause the user to lose a few minutes and start over (i.e., documentation errors, rare problem in functionality that occurs only at certain times. | 30 days | 60 days |
| 3 | Frustrating problem; can cause user to lose more than a few minutes and/or have to repeat work. There’s a known work around for the problem. Can sometimes require logging off and logging back on to alleviate problem | 15 days | 30 days |
| 2 | Major issue; can cause users to not be able to use the system for extended periods of time; lost of effort/work likely. Can sometimes require restarting one or more devices to correct. | 1 day | 3 days |
| 1 | Critical issue; product is non-operative. Potential loss of data; potential loss of revenue; potential legal exposure. | 1 hour | 1 day |
With these severity levels defined, we can then define which support issues can be escalated directly into the Scrum team’s sprint (bypassing planning) and which are created as support issues, added to the Product Backlog for planning into a future Sprint. If you look at my example table, you see that severity 1 and 2 issues MUST be escalated into the Sprint (because their “time to start” timeframe is well within the span of a Sprint). Severities 3, 4, and 5 MUST be opened as Product Backlog Items and planned into an appropriate Sprint based on the “time to start” timeframe.
By following a careful and consistent approach, we can avoid having issues escalated into a Sprint that do not need to be solved at the cost of interrupting a Scrum team and we give the Scrum team, especially the Scrum Master and Product Owner a means for deferring lower severity support work for higher value development work.
One Final Key
All of these tips can make a real difference for your team, both in their struggles to become truly self-managing as well as their ability to learn and improve over time. Of course, a key element in everything I’ve proposed here is the cooperation of management. Teams are built from finite resources from which infinite outcomes should not be expected. None of what I’ve proposed here will work very well if the environment in which the team works is plagued by unreasonable expectations and a demand to “get everything done now” instead of “get what you’re able done right” (remember the “sustainable pace” principle of Agile Development).
With strong leadership and the tips I’ve provided, a Scrum team can have the best of everything — clear goals, a great work environment, a high quality product, and self-regulating high standards of performance. To create an environment like this, I recommend taking a look at my latest training system, The Leadership Edge, a twenty-four week adventure during which EVERYONE will see improvements in not only their lives, but their teams’ outcomes too. Given our satisfaction guarantee, you’ve got a lot gain and little to lose by taking the challenge and joining the adventure. Click here for more information.
Leave A Comment