Operations & Agile Kanban
Here at Mind Candy we use an Agile development process called Scrum, and it suits our business needs very well. But this suits the development process and not IT operations. Because we find it hard to commit to a two week sprint, iterations don’t make too much sense. Our work is a mix of reactive & proactive maintenance, and mostly we are working on whatever is most urgent for the day/week. Yes, we do work on infrastructure projects which are more iterative, but team members aren’t dedicated to projects, so they could still get pulled off project tasks to deal with any urgent issues.
We needed a workflow that was more adaptive but complimented the Agile processes we already had in place. Welcome to the world of Kanban.
I’m not going to go into explaining Kanban in detail given that there is an excellent article already written by Henrik Kniberg and Mattias Skarin. This can be downloaded here http://www.infoq.com/minibooks/kanban-scrum-minibook.
When deciding to use Kanban, some of the key differences were really important for this to work for our team.
Timeboxed iterations are optional & tasks on the board can be event driven
Estimation of time to complete is optional
A Kanban board is persistent & not reset every sprint
We can add and remove tasks from the board as capacity or business needs change
Tasks can easily feed in from different development teams on diverse projects
We can prioritise our own work alongside other parts of the business.
If you use Scrum you will have a backlog of tasks that needs to be prioritised & fed into the next Sprint. You will need to estimate points/time for each story & break them down into smaller tasks that you can complete within one iteration. For Kanban you can have a prioritization scheme or just go with the flow. You may or may not have a backlog, but here we use Jira* and we feed the backlog for the week from this. Users can raise tickets and set importance using the defined Jira priority scheme. However, not all tasks have to be in Jira, for example frequent maintenance tasks, quick fire issues & deploys can be added to the board directly. Priorities are negotiable and I will arbitrate between teams.
*At the time of adopting KanBan we were still using Trac before moving to Jira. Greenhopper is mentioned later on.
A Kanban board doesn’t look much different to a Scrum board and in basic form has a ‘To do’, Work In Progress (WIP) & Done column and the tasks flow from left to right. I wanted to break it down into different lanes so I could focus on different types of tasks or a current project. The lanes should always be reconfigurable. For this I set the board to flow vertically rather than left to right so I could add more lanes.
The big difference from Scrum is the limits on each state. In Scrum there is no rule preventing how many tasks are ‘Work In Progress’, the limit is defined in sprint planning with a fixed scope …you can’t add more tasks part way through. ( Well you shouldn’t !) Kanban limits per workflow state, so in this case we defined a ‘To Do’ limit of 15 and a WIP limit of 6. In our first KanBan board we used different colour post-its to define difficulty/effort as well.
Green = Tasks < 1 hour
Orange = 1 Day
Yellow = 3 Days
Purple = 5 Days
Each post-it had a start and finish date written on it so I could track cycle time and efficiency. ( This was prior to using Jira and Leankit ). Also, we broke down the backlog into ‘This week’ & ‘Next Week’ so we could see upcoming date related tasks way in advance.
We added magnetic Avatars and used these to indicate the owner of the task.
( First attempt )
The Rules of the jungle …
Always take the top item from the To Do list
Take any item
Don’t take consecutive purple tasks ( let others share the bigs ones ! )
Work on one ticket at a time unless its green then go for it
If you start another task and the current one is on hold move it to the right place
No more than 6 post-its in WIP
Every week a dedicated person to deal with the deploy lane
Every week a dedicated person to deal with the Tech support lane
Daily standup at 10am
So we were relatively happy with the KanBan process but felt we could add some further improvements and tweaks.
Writing out post-its became a bore
People would forget to go to the board and move post-its
Post-its fall off. Even super sticky ones !
Anyone working remotely couldn’t see the board
It looked messy
Tracking efficiency was a pain.
Heelllllloooo Virtual Whiteboard….
I started looking around for a way to replace the board with an electronic version. I’d used Greenhopper before in Jira but at this point we hadn’t yet adopted Jira. I looked at a few software solutions as well as online ones. I re-visited Jira but found Greenhopper not configurable enough for my needs…simply put I wanted an exact replica of my whiteboard with post-its.
Welcome to Leankit http://leankit.com/
Leankit is a great tool, lots of board templates for Scrum or Kanban and can be configured very easily. I can create, remove and adjust lanes on the fly, and totally customise the format of cards. Here are some of the features which have transformed the way we use the board.
Card features such as avatars, colour coding, priority indicators, task size & date make the board easy to read and use.
Mini-boards – You can break down bigger tasks into sub-tasks with its own mini board.
After adopting KanBan we found it greatly improved our visibility on our day to day work, and gave other teams a better understanding of how we worked. The daily stand ups encouraged better team communication through task reviews, sharing issues & bouncing ideas off each other.
Having the limits on the workflow meant we never over committed our work and made it easier to negotiate with project managers regarding last minute requests. In turn it helped them to understand that something had to give in order to facilitate an expedited task.