About a year ago, after several years of leading top notch technical resources, I took a step back to think about what my team was doing and how effective it really was. Even though we consistently busy and felt that we were providing a lot of value for our business partners, I got a distinct sense that there were some real challenges preventing us from delivering our best. Specifically, the culture that we lived and worked in, combined with our team alignment, made for a chaotic work day. As I analyzed the issue I found several common themes:
1) Work took a lot longer to get done than it probably should have
2) Many projects and tasks got started but never seemed to reach the finish line
3) As a resource manager, I didn’t really have a clear idea what my team was working on
4) There was friction within the team tied to a lack of understanding around who was doing what
5) Team members were frustrated that they were often in the middle of conflicts about what work needed to be done “now”
In short, while we got a lot of “stuff” done, we didn’t have a good system for organizing and managing that work. We took in work from multiple systems including our incident/problem management system, our project management system, our own list of items we wanted to do as well as walk-up requests (truly everyone’s favorite). We were operating in a “squeaky wheel gets the grease” mode and it just wasn’t efficient. Our level of engagement was declining and work kept pouring in.
If you work in or manage in a traditional IT shop, this probably sounds familiar. This is where we were in the second quarter of 2014 and I feared that our team was nearing implosion.
Thankfully, one of my peers had been exploring the Kanban system of work management and I decided to run a short-term trial to see how it would work for us. It ended up helping us turn the tide and in the nine months we’ve been using it, I feel it has revolutionized our practice.
Kanban is a a product of the Toyota lean movement originally (http://en.wikipedia.org/wiki/Kanban) and was developed to increase production line efficiency. It was subsequently adopted for development work (http://en.wikipedia.org/wiki/Kanban_(development)) and also for overall workflow management in knowledge work.
At its core, there are several key concepts. The two most important ones are:
1) Visualize the work
2) Limit work in progress (WIP)
All work in a Kanban system is listed on story cards which can be something as simple as an index card or a sticky note. One of the first things we needed to do as we got ready to make this transition was to centralize our project tasks, big support items and all of the information in people’s heads and on personal whiteboards, notebooks and stuck in desk drawers. Once done, it was all out in the open and that alone was a huge step forward. We then looked at every item and classified it by size, in our case how many working days it would take to complete. We decided that our maximum card size would be five days and that anything requiring more time to complete would need to be broken down into smaller tasks.
This was tough in some cases but the logic is that we want to reduce work to the small, manageable tasks that we know can be delivered in a finite time window. We don’t want things to drag on for weeks and weeks delaying any sense of accomplishment or progress. It also helped us eliminate waste in our process. Rather than saying “I’m working on this project for 40 hours this week” which is directionless statement that we have two tasks that require 3 working days to complete.
During the two weeks we took to get everything recorded, I stressed that priority did not matter. Whether the task on the card was part of a mission critical project or something that was a nice-to-have improvement, they were treated the same.
Once we had all the cards, we placed them onto a board. Again this can be something as simple as a wall. This board is divided into lanes which indicate what stage the work is currently in. A very simple model would include four lanes from left to right: “Backlog”, “To Do”, “Doing” and “Done”. For this example, I’ll use this design with one addition specific to a team environment, within the “doing” lane each resource has their own sub-lane.
Some quick definitions:
Backlog: Work that has been requested but not prioritized/sequenced or approved to start.
To Do: Work that is approved to start and has been reviewed to make sure that it is actually ready to start, is well defined and has the appropriate size recorded.
Doing: Work that is in progress.
Done: Work that has been completed according to the specifications in the card.
Once all of the work was written down and placed into the backlog on the board, it was time to start getting it done. Here’s where we implemented a change to resolve on of our major pain points. In a Kanban system, all of the work sequencing (or prioritization if you prefer that term) is done by the board manager. In our case, this is my role as the team lead. When resources are ready to start work, they simply grab the top item in the “To Do” lane and move it into their “Doing” lane. Any conflicts in priority among tasks is handled between the stakeholders and me without involving the resources. We want our technical experts focused on doing work, not stuck in meetings and battling politics and planning issues.
Here’s where the magic starts to happen.
We enforce a strict WIP (work in progress) limit on each resource which is generally two items. This means a resource cannot be working on more than two items at once. Why? Because multi-tasking is horribly inefficient and plenty of studies have shown that the time it takes to switch between tasks and get back on track is significant. Also, once a resource has moved cards into their “doing” lane up to their WIP limit, they are committed to finishing those cards before grabbing more. I’m sure we all know someone who has started five or more “projects” around the house but completed none so the bathroom doesn’t have tile and the bedroom needs paint and so on. By committing to a smaller number of items, we actually turn out a better product faster. Our decision to limit card size to five working days also helps ensure that work is constantly moving through the system. This helps drive a real sense of accomplishment when resources move those cards to “done”. I feel the ability to feel productive is really at the core of engagement,and I’ve witnessed a cycle of productivity driving engagement driving productivity.
Over the next few weeks, I’ll detail more about we implemented the system, the tool we used, the process for dealing with unexpected/unplanned/rush work, how this allowed us to get rid of our regular weekly team meeting and how we continue to evolve this to meet our needs. Additionally, we’re just beginning to explore how this model works in a multi-team deployment so I’ll share those experiences as they happen.
Dan Marbes 