Hey there, my name is Sonya Siderova and I help managers deliver on their commitments consistently, all while managing happy, engaged and motivated teams! Today, we’ll dig deeper into the concept of commitment in Kanban and I’ll walk you through a scenario that revealed great opportunities for improvement. Enjoy!
Things are not always what they seem.
One of my clients recently came to me with the following: “The problem is that there was a bug and now a third party is involved,” she explained. “And it’s taking forever for them to get back to us.”
I decided to dig a little deeper.
After a short talk back and forth, it became apparent that the third-party dependency was actually a red herring.
The real reason for the blockage was that her team had committed to fixing an issue without having a clear understanding of what was actually causing it.
Making a commitment to delivering something that’s outside of your control is a risky move.
What if the team actually spent the time to troubleshoot and reveal the problem before it was pushed to the development workflow? Would the situation look different for them? It would have, from multiple perspectives.
First, they wouldn’t have committed to delivering anything. It would have been clear from the very beginning that solving that problem was outside of their control.
Remember, the moment you pull a work item into the delivery workflow it crosses your commitment point. You make a commitment on the behalf of your team that you’ll do everything in your power to finish it. Which in that case was not possible.
Furthermore, they would’ve managed realistic expectations for their client. “Yeah, we’ll sort this out right away”, and then “Ahhm, actually we can’t sort it out because the problem is not on our side” is not really a formula for credibility.
I’m happy that my client brought up that conversation because it revealed a great opportunity for improvement. An opportunity to flex the system so that they don’t end up in more situations like this in the future.
Let’s take a closer look at what I mean by this.
The Real Reason This Work Item Got Stuck
The conversation actually started as we were going through their Aging Chart.
The Aging Chart is an important tool in keeping your finger on the pulse of the work – it lets you see any impediments, blockers or anything else that’s slowing you down while your work is still in progress.
The big red dot you see on the chart indicates an item that is currently blocked. This is work that is prevented from moving forward due to unforeseen circumstances.
When I asked my client what the blocked reason was for that ticket, she explained that once they started troubleshooting the issue, it turned out to be a problem that couldn’t be resolved by them.
Now, the ultimate goal of blocking your work, assigning it with blocked reasons and analyzing it later on using approaches like blocker clustering analysis is to identify opportunities for improvement.
Once I told her this, something clicked.
She immediately saw what was going on. The reason for that blockage wasn’t a third-party dependency. It was unclear requirements.
They didn’t know what had to be done until now. So, what if they knew, what if they had that information before they crossed their commitment point?
The Key Is in Improving the System
The key is in adjusting your management practices to make this work.
Start the conversation early and gather the information you need in order to be able to decide whether or not you can commit (and deliver).
Remember, you have no obligation to commit to a work item up until the point it goes to your downstream process. But once you do commit, you have a responsibility to deliver.
Always ask yourself, “Do we have the information we need to commit to this work item? Are we ready to initiate it?”
Once the team switched their blocked reason from “third-party dependency” to “unclear requirements,” it opened up the opportunity to improve their system.
They can now put explicit process policies in place to verify that they understand the work clearly, including whether any of the work items have issues that are beyond their control.
Something simple as a check box that requires you to sign off before pulling the item into the delivery workflow, for example, helps to keep you aware and accountable before reaching that commitment point.
Not only does this empower you to take control over your work – it shifts the focus and the responsibility from people to the system. When things go wrong or need improvement, you ultimately don’t want the blame to fall on people, you want it to fall on the system.
Isn’t that the whole point after all? To continually improve our processes so we don’t find ourselves in the same situations over and over again?
Here’s what I want you to remember, at the end of the day: Don’t commit to delivering a ticket without having enough information to initiate it. Once you commit, the ball is in your court. By having process policies in place, you and your team will be able to move forward with clarity and confidence.
If you’re interested in building a delivery system that enables you to deliver on your commitments consistently, I’d be thrilled to welcome you to our Sustainable Predictability program.
I hope this article helped shed some much-need light on committing to work items – and how to make sure your system is set up for success.
If you know someone who could really use this insight, please share this article on your favorite social media channel. My mission is to help managers like you free up your time and energy, so it makes my day to know that I’ve made a difference for someone else.
Have a wonderful day and stay tuned for more managerial goodness next week, same time, same place!
