This is a guest post by Robert Dempsey, CEO & Founder of Atlantic Dominion Solutions. He helps clients with agile training and builds products like scrum’d.
I wish I had known about Kanban when I was a network administrator. It would have helped me immensely in terms of prioritization of work and making everything we were doing in the IT department more visible, helping people understand the pressures we were under.
There are two big concepts I could have used – work item types and classes of service. Let’s look at each below.
Work Item Types
First thing I would have used are work item types, which are exactly as they sound – the types of work we are doing. Some examples of work item types are:
- Requirement
- Feature
- User Story
- Change Request
- Production Defect
While most of the above are specific for software development, we can easily create a few work item types for purely IT work. Some of these might be:
- Maintenance – such as patching servers or workstations
- Implementation – installing new servers or software
- Desktop Support – for desktop-specific tasks
- Server Support – for server-specific tasks
Whatever work item types you choose, be sure they reflect the type of work that you do.
Classes of Service
Classes of service are used for the prioritization of our work item types. It is at this level that service level agreements (SLAs) are applied. Typically classes of service are defined based on the impact to the business. So, some examples are:
- Expedite
- Fixed Delivery Date
- Standard Class
- Intangible Class
The policies that are applied to classes of service are determined by the business, and help us to prioritize our work. In this way, it takes the burden off of us to determine what should be worked on, and places it instead on the system. Thus, changing the policies for classes of services will change the system.
Much More to Kanban
There is much more to Kanban than work item types and classes of service, however these two concepts are helping a variety of teams to make their work more visible, and take the burden off of themselves to prioritize their work. In looking at how to implement Kanban, start here.
Agile Web Operations 
Also nice to read another insightful post Matthias. It sparked two questions:
– Do you also use it for project work? I found it hard to keep an overview when a project spans multiple packages. Any suggestions here?
– Also splitting up a change in multiple small working changes is not that easy: f.i. network, firewall, storage, … all for one server. Especially if you’re not working with developers. Examples of this would be great. Or maybe for another post 😉
LikeLike
Hi Patrick,
As for using Kanban for project work, you can definitely do that. If you have a multi-package project, then you could create a column on your main kanban board for the other package, and have two stated – in progress and done. Then you can have a separate kanban board for the second package.
For your second question, that is complex. You have a single change that spans multiple pieces of hardware. Depending on how your IT group is set up, you could either create a kanban board for these types of situations (going from hardware to hardware as your columns), or you could “bundle” the hardware portions into a single column. I’d try it one way and if that works stick to it.
The main idea is to come up with the process in a collaborative fashion. Talk with your team for solutions too.
LikeLike
There is a great movie like presentation about how to use a kanban board showing Work Item Types and Classes Of Service amongst others: http://www.slideshare.net/marcusoftnet/kanbanboards
LikeLike
Robert, Matthias, thanks for the sound advice. For the second piece: I didn’t actually mean a multipackage system. It’s more trying to find a way to visualize the overall projects as opposed to all the different changes one by one. Similar to the story mapping overview. I’ve seen some approaches by having a top lane which denotes the projects level and see how they progress.
LikeLike