Lean IT Operations : Opsban
October 21, 2010 2 Comments
Agile methods has been accepted for a while now, many companies and organizations are on their way to implement “lean” agile systems and creating their continously improving Scrum system, which is also called Scrumban. It is basically a evolution of Scrum using the concepts of the Japanese lean Kanban methods. There are enourmous amount of resources and discussions about Scrumban and I won’t be adding much to that. (yet 🙂 ) I am writing today actually about lean operations with Kanban , i.e. Opsban!!!
It makes so much more sense to start applying lean and “fixed work being worked on” principles in IT operations. You might have a classical ops team or a new modern devops structure or your devs are somehow managing ops in your organisation. It does not matter at all, ops is the area where bad prioritisation of workflows kills productivity and speed of services delivery, ops is the place where you need an effective PULL mechanism the most. Just in time management ? : No ops would be/should be setting up an infrastructure module or delivering a service until it becomes necessary and requested. Inventory issues need to be handled and it is not less critical than the inventory management of Toyota for a company depending on its online or offline IT services.
At the end of the day, Work In Progress has to be controlled and should not exceed the limits. This work includes the incidents, meaning your service downtimes, crashing services , SLA violations etc. Speaking of Scrum, I really doubt that IT ops team can commit to 1-4 week sprints. Many issues need to be resolved immediately , some work takes months and cannot be splitted well into subtasks, you have no choice but change your priorities and start working on something else if the situation calls for it, you gotta keep the show going. Yes, I know, ops is and must be more than keeping the lights on and I agree with that too. And do keep your devops folks and engage them in scrum(ban) of your development teams. I just think it won’t be enough to reach the optimum of software and IT services value chain.
Kanban is a signalling system . It includes a physical or a digital Kanban board where the whole team can visuall see what work is in the system and should be handled (WIP) and get a perfect overview of the production environement. The demand and conditions pull the deliverables out of IT operations. And you have capacity limit of the work in progress, which keeps your pipeline clean, managable and fast! This is the cure of ticket blindness in many organisations : tickets are created one after the other, ops engineers get more tickets than they can process and lose the whole picture of their business. Such a system is called a push environement. The work is “pushed” into the members , who get overloded usually with the same type of work. These people get bored and cause trouble when they are sick or on holiday.Some stuff gets forgotten, pending or suspended for ages. And seriously, how do you create a team feeling in that environement????
Recently I came accross with a blog which describes how Kanban can work for services and Scrum developement. And this is the visual presentation of what I was trying to put into words for days :
So I’d recommend you to go and read Jaibeer’s blog if you are interested.
The main question for me about this appreach is who should be making the assignements to the backlog and decide what work gets done with what priority. It must be partly automated or managed by certain processes (like capacity management, monitoring ….). The interruptions with incidents and SLA requirements are still not adressed well enough. And you know, you should not limit what an IT professional is doing with a board with a set of cards, there must be at least some freedom and autohority given to them to decide what they are working on and assess the priority of the situation themselves. If your servers are crashing, do not expect ops people to create red cards and paste into the “urgent” section of your Kanban board. After the situation is sorted out you can go ahead and reflect on it and yeah maybe create a card. There must be trust within the team where everybody is sure that the members are doing their best to meet the requirements of the operational environement. And the Kanban “guidelines” are to be followed when firefighting or exceptions are not on your way.
Second question is innovation. How do I get my people’s crazy ideas tested out on my Kanban board? Where is the time and incentive to forget about “effectiveness” and look for new ways and have fun? Why not risk wasting a bit of time or resources, if the members would learn from it? I can imagine giving people a 10-20% buffer to strech themselves and go out if the box, where they dont need to care about the Kanban board or whatever place the “real” work is shown. A team utilized constantly more than 80-85% for “usual”ops work is not my ideal and no lean methodology is going to change that.