In my last post, I shared some high level information about the way that my team is currently using the Kanban system for work management. In the nine months that we’ve been using this method, we’ve made a fair number of adaptations to make it work for us. In this post, I’ll cover the most significant tweaks we’ve made.
One of our biggest challenges is working in an environment where we are responsible for operations and support work, which by its very nature is unplanned, and project work. Our team has an on-call support rotation and many of the team members are called upon to perform support work outside of this cycle due to system access or product knowledge not shared by the entire team. As you might imagine, this can create conflicts between what we planned to do and what we actually have to do to keep the lights on.
The Kanban system offers a mechanic that helps us to identify these conflicts: the block. Whenever planned work cannot move forward, it is placed into a blocked state. This can occur for a number of reasons. We may be called away to deal with a system outage, we could be waiting on a vendor partner to provide information or another internal team to deliver a piece of the work or we could simply be waiting for an available change control window to promote the work to production. The reason for the block is ultimately less important than the process we implement to resolve these issues when they occur.
In my last post, I talked about the role of the board owner as the arbiter of priority and work sequencing. Another critical role that person plays on the board is the “icebreaker”. As mentioned in the last post, once a resource moves a work card from “to do” into “doing” they are accepting the accountability for completing that work, ideally in the estimated time frame. As such, they are initially responsible for resolving conflicts that are causing blocks. The expectation on our team is that resources will work to resolve these items until the team’s next daily stand-up meeting. If the issue cannot be resolved, then the board owner takes over the resolution of this conflict.
Structurally, we’ve modified our board to include lanes to accommodate our most frequent delays. Early on, we realized that we needed to account for our internal change control process which often adds 3-7 days from the time that something is completed and ready for promotion to production until it is actually released. To account for this we added a sub-lane under “doing” called “waiting for release”. Work cards can move here after being submitted to our change board and a date is added to the card indicating when this will move into production. Once approved and released, this card is moved to “done”. This way, we don’t tie up the WIP limits for our team with cards that aren’t really being worked on.
We also end up with items that are waiting on other internal teams or vendor partners. We decided that if these items are going to cause work to be blocked for more than one day, we needed a place to store them until these issues were resolved. We created another sub-lane under “doing” called “waiting on others” and now move cards to this lane if we reach an impasse or anticipate a significant delay with work completion. We make a point of reviewing these items every morning to keep ourselves disciplined and focused on our commitment to completing this work. Once items move to this lane, the ownership for escalation and issue resolution lies with the board owner. Once those conflicts are resolved, these cards will move back into an active state before any new work is pulled from the “ready” lane.
One thing that we reinforce is that simply because an individual resource’s WIP limit is two items doesn’t mean that he or she needs to have two work cards active at all times. We know that there are daily admin activities, email, support work and numerous other small issues that crop up throughout the day. We’ve set a guideline that any support work or other activities that won’t consume two hours of dedicated time are outside the scope of the board entirely as the administrative overhead of managing cards for these items just doesn’t make sense. On days where a resource is on-call or stuck in meetings all day it is not uncommon to see no cards in that individual’s lane and that’s OK. This is simply another data point that the board owner can use to estimate the real cycle time for work items.
Whew! Hopefully all of that makes sense. In next week’s post I’ll recap a great discussion I just had with a small business owner asking how to get started in designing a board that works for a particular situation and how to start using it.
Dan Marbes 