Kanban, the first steps

Here’s the background; a little while ago I was sent on an Agile course which was pretty good, but for the most part covered Scrum which was an awkward fit at best. We don’t work in sprints, we’re just always sprinting. We don’t have fixed scopes of work, sometimes we’re quiet (rare), other times we’re so swamped we don’t know left from right. Standard project management practices (for example waterfall) were not useful as we cannot predict what will be coming our way. We have to manage ourselves so that we do not overcrowd our individual task lists, and don’t start “dropping balls” on tasks we’re working on. I don’t have time to resource plan everyone when issues come in, I need my team members to do that. This course was pretty much a non-fit until they touched on one topic; Kanban.

I work in an environment that requires high-speed maneuvering, quick reaction, and to top it off I need to be able to do this while still being able to report “almost up to the minute”. Well, not quite that extreme, but I work as a Team Lead for a development support team that is often asked “how are things”, which requires a better answer than “OK”. This means we work at resolving live world issues on a massive suite of products when first and second line have failed to resolve them.

Since my team’s job profile is pretty simple; fix issues by either developing a fix, finding someone to develop a fix, use experience to work around the issue, or resolve the issue where the first support lines have failed; it does come with a complex problem: how do I manage my team’s success in what they do when they are being bombarded with 40-120 new live issues a month (some month’s peak at 160+)? How do I let my manager know what’s important and how we’re doing? To top it off, we’re only 5 members.

Here’s the scenario; we have a source of work requests (issues, work orders) from a number of possible entry points; our Remedy System, Email, Office Communicator, Phone and good-old walk-to-our-desks-and-ask. We need to track and prioritise these, and we need to know where they are in the system. At any given point I can be asked what’s happened to a particular issue. Is it in testing? Have we even looked at it? In some cases, is it fixed and deployed already?

I won’t rehash what Kanban’s about as this info is all over the web. However, what I’ve taken to is its simplicity, ease of use, and the beauty of self-management and iterative improvement that it brings to the table. If anything, the Kanban board is easy to view and when I’m now asked “how’s issue A” I point to it on the board. I no longer feel like I’m swamped with work because I can’t remember where it originated (was it in Outlook, or was it in Remedy, or how about that post-it that was left on my desk), let alone the issue itself. I can reflect on the day ahead’s work by simply standing in front of the board and doing what’s on my list, or taking something on that isn’t. All my team members do this, and as a result it just works. I know if someone’s not busy; there’s nothing on the board with their name. I know when someone is overworked; they have all that tasks on the board with their name. When someone doesn’t have any work in progress, then they “look right” and see what bottlenecks further down the stream they can resolve. Often these tasks will not even be their own.

If anything, Kanban is a perfect fit for a support team such as mine. Other support teams in our company work differently (they release fixes in Service Packs) so I’ve had to find this information myself, and through the team’s trial and error we’ll get the board right. The fact that it’s not cast in stone means we can fix it if it isn’t quite working. Since there’s no software involved, changes are simply “new lines or removing lines on a whiteboard” and require little more than a quick discussion with the team. We started off simple. We have 4 states and special “Critical Issues” and “Development Fixes” swimlanes. Beyond that, we work as we always have, we now have a board that makes my life an absolute pleasure and keeps stakeholders happy because they can see it and ask questions.

The biggest challenge has been to just start. You can procrastinate and read all the books and articles you can find, but that won’t really help you. I purchased one book; Kanban, Successful Evolutionary Change for Your Technology Business. I read it half way through and realised I had enough to get started. The rest of the book drills down into details that won’t necessarily make sense yet. David J. Anderson knows Kanban well, and he knows you probably don’t. So he explains it well.

I started by simply taking a snap shot of everything we have right now. Everything. Work in progress. Work in testing. The backlog. All of it. It was painful, but it was worth it. I put everything on the board as it is right now. This was for 80+ items. It allowed me to see just how dire our situation is by the number of tasks we try to work on at once. We’ve put in a throughput limit of 2 tasks per member. Maybe it’s too small, maybe not, but the beauty is we’ll see how it works and adjust accordingly. I will take a snapshot of the board as it is now, and compare it to a year’s time. It will be an interesting contrast I’m sure.

That’s all for now on the first steps in our progress towards Agile and Kanban. I’ll add more articles to this as I go.