Kanban in Operations

Three months ago I joined the Site Operations team at realestate.com.au and I was pleased to see that the team were using a card wall for work.

Card Wall

Although the physical card wall proved to be a great place to have stand ups and manage work, it had its problems: - We have a distributed team. With operations teams in Italy (casa.it) and Luxembourg (athome.lu), people on devops rotations and working from home on occasion makes it hard for them to participate during stand up. - Data associated with cards such as creation timestamps, creators etc. is dependant on users writing it on the cards. - Limited external visibility into Site Ops work load. If any one wanted to know what we are currently working on, they would have to head up to the Site Ops area and have a look. - After a discussion with the team, we decided to trial a virtual card wall.

Scope

The trial would run for two weeks, replicating the cards on our physical card wall, with a retrospective and decision to continue at the end. The trial would not include capturing incidents or deployments and would be light as possible.

Setup

To get the trial up and running as soon as possible, we utilised our existing Jira installation with Greenhopper. The project setup and configuration was kept to a bare minimum. We created five new issue types, based on the cards on our physical wall – Service Requests, Deployment, Provisioning, Housekeeping and Faults.

A week before the trial commenced, we manually imported the cards into Jira and wrote the Jira issue number on the cards. During that week we also duplicated the any new physical cards into Jira. This allowed us to start tracking behaviour before we started the trial.

Our virtual card wall is tactile. Stand ups would now be conducted in front of a Smart Board, which allowed us to interact with Greenhopper using our fingers as the mouse.

The Trial

The trial kicked off on Friday 8th July at 0900, we had our regular stand up with the exception of the new virtual card wall.

In addition to Greenhopper, we started a trialling weekly iterations (versions) in Jira – Thursday to Thursday. Although we weren’t planning the iterations, the option is there for participants to put cards into a few iterations later if the card won’t be actioned for a few weeks.

What works and what doesn’t?

The trial of Greenhopper has been great. The trial has identified a few things that work well, and some that don’t. So what works and what doesn’t? - It’s difficult to raise new cards at stand up. It’s a change to our regular process of raising cards at stand up, as we have to create and edit cards before or after stand up. However this has minimised interruptions during stand up, allowing the team to focus on stand up. - We are able to raise cards wherever we have access to a web browser and we are not constrained to being in the office. - For a few of the stand ups we didn’t have access to the Smart Board and used a projector instead. It felt awkward. Having physical interaction with the card wall definitely enhances the experience. It feels natural for the team to huddle around the card wall, rather than a computer.

What’s next?

So what’s next for the Site Operations Greenhopper integration? - First up is to trial the system to the global operations teams with a possible change to our stand up time to a more sensible hour for our European colleagues. - Next is to increase transparency into Site Operations current work load. To achieve this we will look into publishing a read-only card wall to the wider company. - Start planning work for iterations. We didn’t plan beyond one week during the trail, but we are collecting data on how long cards are taking to cycle through our system. - Estimating card size again. Based on  the data collected we should be able to reliably estimate work and compare that to the actual durations. - Customise Jira to suit the work flow in Site Operations, including incident management and deployments. This will be an evolutionary process, with an aim to try and keep the work flow as light as possible. - The final goal is to investigate integration with other operations systems, such as ZenDesk and Nagios. This would minimise the amount of duplicated for and streamline our work flow.


Matthew Jones is an operations engineer, living in Melbourne. He is one half of Infracoders.

Follow him on Twitter or find out more about him.