Nikolay Sturm's Blog

Musings about Development and Operations

Kanban in Operations - the Idea

| Comments

At DevOpsDays I saw Mattias Skarin’s talk about Kanban in Operations. The points he made resonated very well with my own ideas and the problems I faced, when experimenting with Scrum and XP in my admin team. So I decided to give it a try and document my experiences here.

We are 4 admins at work, with myself as team leader and an additional one or two trainees or interns. One admin is dedicated to dealing with user requests, while the rest of us are working on infrastructure projects, each on their own one. We have some overlap though, to permit for holiday replacement.

Our current setup poses a couple of problems I hope to tackle with Kanban:

  • everyone feels like having too many things going in parallel
  • admins only know their parts of the infrastructure
  • many projects take forever to finish
  • it’s hard for me to notice problems in delegated projects, as we only do some kind of ad hoc project management
  • urgent mini-projects regularly occur, halting the affected admin’s regular projects

Kanban 1.0

In this first post, I want to document the kanban board as I came up with it. I assume that after some discussion with my colleagues and experiences in the wild, the layout will change.

Our group has two sources of work: user requests and projects. For now I want to keep the separation between helpdesk admin and project admins.

User Requests

We will only manage bigger user requests on the kanban board, that take at least an hour of work.

There are two lanes: 1st Level and 2nd Level. The 1st level lane is worked on by a dedicated admin, who will move requests to 2nd level, that need attention from one of us project admins. In the spirit of production has precedence over projects, 2nd level has higher priority than project work.

Open questions:

  • How can we limit 1st level WIP, when requests often enter a wait state?

Projects

On the left, there is a prioritized project backlog called Projects. This is where upper management can freely reshuffle and replace cards. Both, the project backlog and the number of active projects are limited.

For each project in work, the team maintains MMFs in the Backlog. The highest priority MMFs are regularly broken down into individual tasks and moved to the Ready state. From there, tasks move via WIP to Done and finaly the MMF itself is moved to Done. Ready and WIP states are limited.

In case of urgency, management has one urgent project slot. This project has higher priority than any other project being worked on, but less than 2nd level operations.

Improving Collaboration

To improve collaboration, all project admins will work together on the same project(s) and we will experiment with pairing.

Comments