I was on the phone recently with Stacy, a dev team manager. During our conversation, I shared the concept of using relative card positioning, or stack ranking, to show the priority of items of a queue on a kanban board. Personally, I have used this tactic very successfully in the past as it provides visual cues to both the doers that need to know what’s next, as well as to the requestors of work who want to know when we’ll get to their item. When I finished explaining, Stacy said, “Yes, we’ve tried that in the past but we don’t do it anymore. The problem was that requestors got upset that their item was number five in our queue.”
What Stacy looked at as a problem, I looked at as a big win. One of the biggest benefits of a visual system like kanban is that it shows the ugly picture of reality and thus provokes needed conversations. Changing your kanban to avoid the conversation is like turning off failing tests instead of fixing them – completely contrary to the point. Taiichi Ohno said that the goal of kanban is to make problems rise to the surface. This means that we have to be ready to tackle some of the problems of our reality instead of keeping people in the dark. It also means that being skilled in the art of crucial conversations and conflict management is key. Not being ready for these conversations is one of the reasons that people don’t get the value out of their kanban implementations that they are hoping for.
Part of teaching people about visual systems is teaching them that they need to become comfortable with seeing issues and solving problems. So, if you’re catching yourself turning off the proverbial test, that is to say, rolling back aspects of your visualization because they cause uncomfortable conversations, ask yourself if you’re really helping or hurting yourself in the long run. Stacy would really get value from having stakeholders understand their actual priority in her queue. The stakeholders would really benefit from understanding why things are prioritized the way they are. Obfuscating the priority creates a lot of uncertainty that drives more work for all involved… can anyone say increased status reporting? In addition, there is still frustration, its just packaged differently. The stakeholder frustration is more nebulous and focused on the team. It becomes “Why is this team so slow?” I would take the frustrated question “Why is my item number five on the list?” over “Why is your team so slow?” any day!
For this particular issue on priority, if you can find a way to involve your stakeholders together in prioritization and make them part of the decision, then you are no longer forcing a priority on them. They also begin to learn about the quantity and quality of the decisions being made during the prioritization process. No matter what issues arise for you in your Kanban implementation, try not to push them away. You might defer some in order to tackle the biggest need, but don’t sweep things under the rug long-term. People learn from the behaviors of those around them and if we can teach bravery and skill in addressing and solving problems, then your organization will be well on its way to success.
Thanks for reading this post. I discuss this story briefly in my recent talk at DevOps Days Seattle called “Taming the Chaos: Beyond the Quick Wins.” The slides are posted and I’ll update the page when the video is released. Please consider subscribing to my blog by entering your email address in the form on the right. 🙂