Many teams find themselves in the middle of a crossfire at some point. Especially when you are part of a reference team with a lot of experienced members, others will come to you with demands for help or assistance and it will feel like hell. Bug fixes, technical advice, a guide on where to start on the mess that we call architecture or even a shoulder to cry on. Even when you are willing to do it, this kind of situation can challenge the ability of the team to keep focused on the most important things, respecting the priority of your backlog and not failing to remain productive. Let’s check the risks of this kind of situation and how to deal with it.
The damage to avoid
Everytime we need to stop doing what we are working on right now, and we switch to a different project, our productivity decreases. If we work on more than one project at a time, the productivity rates clashes, as we can see in the picture below:
That time losses derive from that context switch, since we need to move from one idea to another.
Moreover, when we are in a process of context switching, we tend to lose track of the priorities, since we are more focused on solving things than actually assessing urgency and importance of each issue.
How to measure the impact of intangible demands
One idea is to create a simple board or document where you will “tick” each time someone gets interrupted. We will see in a week or two, how much it happens daily. You can also assign different colors for the amount of time it took. ie:
1 hour: green tick
half a day: yellow tick
whole day: red tick
From there, you can get a grasp on how much time the team is putting on those kind of demands and what are the main reasons for that. This will bring a notion of how much it costs and if it’s actually going into the right direction. Are we putting all of this effort into the most important options?
You could also try to do some experiments inside of the team to understand this behavior, something like a A/B test where you give two tasks of similar complexity and size to two different team members but one of them will be protected from the outside world during a period of time and the other won’t. Check them, after that time, what happened to the cycle time of that task in both cases.
What can we do about it
So here are some ideas on how to deal with this kind of situation and try to diminish the impact on your team and your results starting from a local perspective and going into a more systemic approach to the issue. Remember that, no matter what is the solution.
Pomodoro
From a very personal starting point, the Pomodoro technique is a time management tool created by Francesco Cirillo back in the 80s, and the idea is quite simple. You use a timer to break down work into several intervals, usually, 25 minutes timeboxes, separated by short breaks. Each of those intervals are known as “a Pomodoro” (tomato in Italian, recalling the kitchen timers resembling a tomato). Here the invitation is to respect that time to focus on a specific task and try to avoid interruptions, so the flow of work arises and your productivity increases.
Pareto Principle
Make explicit arrangements within the team on how much time we want to spend weekly or monthly on these outside distractions and let each and every person to manage their own time accordingly. The suggestion here is to start from Pareto’s proportion (80% of the time on our own backlog and 20% of the time on outside demands) and gradually evolve. Make sure to check on this agreement at the end of the team’s cycles, to check if we are being respectful to that. This kind of agreement can be hard to keep and measure since it will take a lot discipline from every member of the team to handle their own time and maybe don’t get too involved with the issues.
Automation
Here it’s quite a simple idea: let’s automate whatever we can so that it enables others to make decisions without us needing to be directly involved. Maybe the reason we are being interrupted is because they need us to run some routines or process, maybe it’s a matter of permissions that only our team has, maybe there’s a bug that only our team knows about or maybe it’s just lack of information on some aspects of the code or products that we can make available somewhere. This can all be automated for good. The cost of this decision is that it will take longer and cost more to solve the issues, but it will pay off on the scale.
“The Firefighter”
This idea starts with a simple initiative: to designate a “firefighter” in the team for dealing with the most urgent issues that are taking us away from our focus in order to help other teams. For doing so, the suggestion is to check which person in our team is the least busy at that particular moment or iteration, and choose him/her in that role, so we can protect the bottlenecks of our operations while giving enough reaction to the system. Another important fact to remember is that the role of “firefighter” is a rotating one, and depending on the actual capacity of each member, the role should be assigned by consensus to one of the members in the team. During the time in which someone is taking on the Firefighter role, remember that it will be a tough experience for that person and he/she won’t feel so connected to the rest of the team or to the work and results that they are achieving, so there needs to be a lot of understanding and communication within the team to deal with those issues.
“The Gatekeeper”
Similar to the last suggestion here we will create an explicit role for someone to make decisions on whether or not the team will take that demand to work on. This person will receive all demands and analyze them based on the business priority, level of complexity, risk potential, and how much that will hurt our current backlog. This person should be someone with a clear understanding of priority for the organization and someone who knows the backlog of the team and also someone with good communication skills since there will be a lot of “no’s” to say in this process. What is especially good in this solution is that we are trying to increase here the systemic approach to the issue and make better decisions for the company, not only for the team.
Knowledge sharing
In the end, all of this is probably happening because your team has something that lacks on the organization. Either it’s about skills, behaviors, or some kind of knowledge that others could benefit from. So what can your team do to share it with others and diminish the dependency and enable others to deliver as much value as you do? One idea is to run workshops, training, or Dojos (practice from XP “Extreme Programming”) in order to share what you know about a particular subject in a very practical way. There is a lot of benefits from teaching while doing, so don’t make it into a cold email if you can do it together, based on real-life situations. In a smaller scale, you can also take some time to work in pairs with the people who need help (also a practice from XP called Pair Programming). If you want to go even further on that, you could build something to help decide and prioritize which subjects you will be teaching and learning together, using this tool called Competency Matrix from Management 3.0. You can check details on how to run it here: Using Team Competency Matrix to improve manager’s skills.
Let us know if any of those were helpful to you and remember to keep measuring the impact of your work, constantly. ?
Join us on our Certified ScrumMaster and Certified Scrum Product Owner upcoming training. Register now!
