If you're part of an engineering team, you’re probably familiar with this scenario. Your morning is full of requests around improving production instances, searching for performance issues, and blocking malicious traffic that may just have hit your server. And this is just as you’re finishing your first cup of coffee.
More issues are raised throughout the day and all need your attention and a rapid solution. These fires you have to put out can range from dealing with critical customer concerns, ensuring timelines are being met and overcoming project roadblocks. However, balancing multiple priorities can be complex when all tasks have to get done, especially if delays occur or if there is a breakdown in processes.
This is what happened to my team three years ago. We were constantly firefighting, and constantly working towards a tight schedule to deliver new features. When everything is always a high priority and urgent, fixing ad-hoc requests becomes the daily norm. The consequence of this is that it actually impedes our typical delivery process and reduces the trust our support team, project managers and customers have in us.
Our director of engineering at that time, YC, was aware of the situation and approached us to understand more. He shared a youtube video with us and asked us to watch it to get a brief idea out of it. In the next few days, he guided us to implement some of the Kanban principles to help me and my team navigate through the never-ending high-priority items.
There are a few weaknesses with how the team manages priorities and expectations:
At the end of the week, we look into the control chart in our Jira to understand what are the reasons for a longer lead time. After many control chart reviews, we frequently came to the same conclusion - the longer lead time is due to firefighting. There's a saying that, "Insanity is doing the same thing over and over and expecting different results.” Clearly, the existing delivery process is no longer a fit for the team.
Based on the identified weaknesses, our goal is to be able to transparently depict the priority of WIP work items and the delivery commitment that our team currently has. The increased visibility toward WIP items shall promote more discussion and negotiation around the work itself and delivery commitment.
In order to better understand the nature of work that our team is delivering, we are guided to see ourselves as an engineering team that provides services to the Support Team and PM
As part of the engineering team, we provided the following following services:
Once there’s an understanding of the services the team provides, the classes of services are identified and defined. All work the team has done needs to meet a certain set of expectations to our Support Team, PM and customers.
In our case, the main issue is deciding which work should be prioritized. Each of our service requesters has their own expectations. Therefore, we define classes of services according to the “urgency” of work. Then our JIRA Kanban is configured to show the classes of services as swim lanes.
Now everyone has the transparency of what is being worked on by the team, and what is the delivery commitment made by the team. It can be told from Kanban whether the team is overcommitting.
The delivery commitment is much more visible now, but how do we make sure the right work gets prioritized?
Here’s another scenario. Let’s just say you have a number of high priority work items in your backlog, what are you going to work on first?
Here is where the concept called "cost of delay" comes into play. You can assess the service requests by asking “If I delay working on this, what impact does it have on ours and customers’ businesses?”
Thinking from the perspective of delaying cost starts to shift our mindset and we begin to ask better questions that could help both customers and ourselves. We start to see the business risk and impact of our work, and this helps the team gain better clarity on the urgency and importance of the work.
Most of the work items be it features, bugs or improvement are subject to discussion and negotiation in the terms of delaying cost. There are more quality discussions about our customers' real needs and we continue to work on understanding them, and finding the solutions together with the Support Team and PM to avoid issue escalation. This helps the team be able to focus better in work and reduces the number of fires.
I need to emphasize that all the changes and Kanban principles that we applied are all simply tools we use for guidance. They don’t magically solve all our problems. These guiding principles and tools promote quality discussion and help with negotiation. It is the people on the team having high value discussions, practicing quality discussion and negotiation that slowly get the team back on track. I appreciate that my team, especially my manager, Sanjev, is practicing these principles very well.
