Our business is managed hosting, so keeping our web operations work in flow is essential. In this article series, I’m sharing what we’ve learned in that regard.

• Part 1: How we got ourselves into trouble
• Part 2: How we learned to keep work in flow
• Part 3: How we learned to make quick decisions
• Part 4: How we learned to manage interruptions
• Part 5: How we’re doing today

In part 1, I described how a lack of control over the flow of our work brought about an emergency for our web operations team and, in consequence, for the business. Luckily, my favorite DevOps book showed me a way out of this mess.

Making work visible

One of our problems was that first, we didn’t have clear visibility of the work that was going on (or not), and in consequence, we had no means of limiting the number of balls people were juggling. The protagonist in “The Phoenix Project, a Novel About IT, DevOps, and Helping Your Business Win” solves these problems by introducing an organizational method that — and it’s hard to admit this — we already knew. In fact, I had even given talks about it. I’m referring to the Kanban method that uses cards arranged on a board with columns and lanes to represent projects or tasks. Regardless if the board is physical or virtual, it gives you instant visibility of all work in progress (WIP). Additionally, by imposing a limit to the number of cards in particular sections of the board, you can constrain the amount of work the team may take up at a time.

Before we introduced the Kanban board, our WIP was scattered across many projects in Asana, which made keeping track of everything almost impossible. Now that WIP is visible in a central place, it is much easier for us to spot who’s working on what and who is stuck with an issue.

Moving things along

For the Kanban method to work, there needs to be a process that defines when and how cards get moved from one stage to the next. Cards always start out in the leftmost column; in our case, it’s labeled “Backlog”. As the CTO, it is up to me to fill the backlog with the work items that create the most value for our customers at any given time. Every team member can suggest additional work items by tagging Asana tasks with “wip”.

Now that the tasks ahead are clear, we have to distribute them. We do this in our weekly WIP planning round. Every Tuesday, the whole ops team goes on a Slack video call to pick the backlog cards we’re going to tackle. Each of these cards goes into the “This Week” column and is assigned to a team member who’s going to be responsible for getting it done. This column has a formal upper limit for the number of cards in it, but we think that having a vivid discussion of the right choice of cards for each week is more effective. Over time, we’re developing a realistic sense of what we can achieve during any coming week, taking into account holidays, time off or other special circumstances.

The central area of our Kanban board are two stacked lanes labeled “Active” and “Waiting”. When a team member starts working on a card, they pull it from “This week” into “Active”. Ideally, every card spends most of its lifetime in this lane.

If a card requires input from outside the team (most often a customer), we put it into the “Waiting” lane until we get a response. This way, the “Active” lane can have a WIP limit without getting clogged by tasks we can’t advance by ourselves. Due to our DevOps approach to customer relationships, some cards switch between “Active” and “Waiting” multiple times.

However, if a card is stuck because its owner needs help from the team, they mark it as “blocked”, accompanied by a comment that explains the issue. This way, we can resolve it much more quickly than before when these blockages often did not surface until the next planning round.

In the end, every card reaches the “Completed” column where it stays until it gets taken off the board at the next planning round. Before we talk about new tasks, card owners are encouraged to share short comments on their finished work. We also discuss tasks that took longer than expected to get done.

So why is the Kanban method working for us this time around when it didn’t before? After all, each time we tried it in the past, we eventually felt that the additional management effort just didn’t pay off. In hindsight, I found multiple reasons for these failures.

Making sense of WIP

One of those reasons is that back then, we used very simple board layouts consisting of only a few columns like “To do”, “Doing” and “Done”. This is the way many applications (Trello and Asana, for example) display their board layouts.

This time around, we decided to spend a bit of money on a Leankit subscription. Its flexibility in creating more sophisticated board layouts does make a big difference for us. We can assign card types with different colors to distinguish different types of work (product features, support requests, customer orders, etc.) Some types even get their own “swim lanes”. For example, a major part of our planned work is infrastructure coding, which we manage in a small development pipeline with the stages Design, Development, Review, Testing and Release.

With this more complex board layout, we can see at a glance what’s going on.

Size matters

Another reason that Kanban didn’t work well for us in the past was that we did not have normalized work item sizes. One card stood for a routine task, another represented a whole project.

For Kanban to work, it’s important to answer the question “Which amount of work should a single card represent?”. Consistently small card sizes not only level the flow of work, you also gain the satisfaction of moving things into the “Completed” lane much more frequently. We did a few experiments and in the end, we found that by aiming at a task size of “Finished until tomorrow evening” is ideal for us.

Speaking of movement — we don’t yet measure performance metrics like “cycle time” (the time we spend actively working on a card) and “lead time” (the time a card spent waiting in “This week”). We intend to start this kind of analysis at a later time.

Making choices

We started our journey into lean web operations because we didn’t seem to be able to get any project done. By applying the Kanban method, we now keep our projects in constant motion until they’re finished. Which projects, though? After all, I have to decide what new cards I put into the”Backlog” column each week. And there is always an enormous number of projects ahead.

Back in the bad old times, all these projects seemed equally important. Picking one felt like choosing a favorite child! In consequence, we often took on too many at a time. But now that we finally had a working Kanban board, we needed to find a way to keep us from flooding it. In the next part of this series, I’m going to tell you the solution we found.