By Les Viszlai
Development teams have been using Agile software methodologies since the late 80’s and 90’s, and incremental software development methods can be traced back to the late 50’s.
A question that I am asked a lot is, “Why not run Scrum in IT Operations?” In my experience, operations teams are trying to solve a different problem. The nature of demand is different for software development vs the operations side of the IT house.
Basically, Software Development Teams can:
- Focus their time
- Share work easily
- Have work flows that are continuous in nature
- Generally answer to themselves
While Operations Teams are:
- Constantly interrupted (virus outbreaks, systems break)
- Dealing with specialized issues (one off problems)
- Handling work demands that are not constant (SOX/PCI, patching)
- Highly interdependent with other groups
In addition; operational problems cross skills boundaries.
What is Kanban?
Kanban is less restrictive than Scrum and has two main rules.
- Limit work in progress (WIP)
- Visualize the workflow (Value Stream Mapping)
With only two rules, Kanban is an open and flexible methodology that can be easily adapted to any environment. As a result, IT operations projects, routine operations/ production-support work and operational processes activities are ideally suited to using a Kanban approach.
Kanban (literally signboard or billboard in Japanese) is a scheduling system for lean and just-in-time (JIT) production. Kanban was originally developed for production manufacturing by Taiichi Ohno, an industrial engineer at Toyota. One of the main benefits of Kanban for IT Operations is that it will establish an upper limit to the work in progress at any given process point in a system. Understanding the upper limits of work loads helps avoid the overloading of certain skill sets or subsets of an IT operations team. As a result, Kanban takes into account the deferent capabilities of IT operations teams
Key Terms:
Bottlenecks
Let’s look at our simple example below; IT operations is broken up into the various teams that each have specific skills sets and capabilities (not unlike a number of IT shops today). Each IT ops team is capable of performing a certain amount of work in a given timeframe (u/hr). Ops Team 4, in our example below, is the department bottleneck and we can use Kanban methodology to solve this work flow problem, improve overall efficiencies and complete end-user requests sooner.
As we said earlier, the advantage of adopting a Kanban methodology is that it is less structured than Scrum and is easier for operations teams to adopt. Kanban principles can be applied to any process your IT operations team is already running. The key focus is to keep tasks moving along the value stream.
Flow
Flow, a key term used in Kanban, is the progressive achievement of tasks along the value stream with no stoppages, scrap, or backflows.
- It’s continuous… any stop or reverse is considered waste.
- It reduces cycle time – higher quality, better delivery, lower cost
Break Out the Whiteboard
Kanban uses a board (electronic or traditional whiteboard) to organize work being done by IT operations.
A key component to this approach is breaking down Work (tasks) in our process flow into Work Item types. These Work Items can be software related like new features, modifications or fixes to critical bugs (introduced into production). Work Items can also be IT services related like; employee on-boarding, equipment upgrades/replacements etc.
The Kanban approach is intended to optimize existing processes already in place. The basic Kanban board moves from the left to the right. In our example, “New Work” items are tracked as “Stories” and placed in the “Ready” column. Resources on the team (that have the responsibility or skill set) move the work item into the first stage (column) and begin work. Once completed the work item is moved into the next column labeled “Done”. In the example above a different resource was in place as an approver before the work item could move to the next category, repeating for each subsequent column until the Work Item is in production or handed off to an end-user. The Kanban board also has a fast lane along the bottom. We call this the “silver bullet lane” and use it for Work Items of the highest priority.
How to Succeed with Kanban
In my previous experience as a CIO, the biggest challenge in adopting Kanban in IT operations was cultural. A key factor in success is the 15 min daily meeting commitment by all teams involved. In addition, pet projects and low priority items quickly surface and some operations team members are resistant to the sudden spotlight. (The Kanban board is visible to everyone
Agreement on goals is critical for a successful rollout of Kanban for operations. I initially established the following goals;
- Business goals
- Improve lead time predictability
- Optimize existing processes
- Improve time to market
- Control costs
- Management goals
- Provide transparency
- Enable emergence of high maturity
- Deliver higher quality
- Simplify prioritization
- Organizational goals
- Improve employee satisfaction (remember ops team 4)
- Provide slack to enable improvement
In addition, we established SLA’s in order to set expectations on delivery times and defined different levels of work priority for the various teams. This helped ensure that the team was working on the appropriate tasks.
In this example, we defined the priority of work efforts under 5 defined areas; Silver Bullet, Expedite, Fixed Date, Standard and Intangible.
Production issues have the highest priority and are tagged under the Silver Bullet work stream. High priority or business benefit activities fell under Expedite. Fixed Date described activities had an external dependency such as Telco install dates. And, repeatable activities like VM builds or Laptop set-ups would be defined as Standard. Any other request that had too many variables and undefined activities was tagged as Intangible (a lot of projects fell into this category).
I personally believe that you can’t fix what you can’t measure, but the key to adopting any new measurement process is to start simple. We initially focused on 4 areas of measurement:
- Cycle Time: This measurement is used to track the total days/hours that a work item took to move through the board. This was the time it took to move through the board once a Work Item moved out of the Ready column.
- Due Date Performance: Simply measures the number of Work Items that completed on or before the due date out of the total work items completed
- Blocked Time: This measurement was used to capture the amount of days/hours that work items are stalled in any column
- Queue Time: This measurement was used to track how long work items sat in the Ready column.
These measurements let us know how the Operations team performed in 4 areas:
- How long items sit before they are started by Operations.
- Which area/resource within IT is causing blockage for things being done.
- How good is the team at hitting due dates and
- The overall time it takes things to move through the system under each Work stream.
Can we use Kanban with DevOps?
The focus on Work In Progress (WIP) and Value Stream Mapping makes Kanban a great option to extend into DevOps. Deploying Work Items becomes just another step in the Kanban process, and with its emphasis on optimizing the whole delivery rather than just the development process, Kanban and DevOps seem like a natural match.
As we saw, workflow is different in Kanban than in Scrum. In a Scrum model, new features and changes are defined for the next sprint. The sprint is then locked down and the work is done over the sprint duration (usually 2 weeks). Locking down the requirements in next sprint ensures that the team has the necessary time to work without being interrupted with other “urgent” requirements. And the feedback sessions at the end of the sprints ensure stakeholders approve the delivered work and continue to steer the project as the business changes.
With Kanban, there are no time constraints and the focus is on making sure the work keeps flowing, with no known defects, to the next step. In addition, limits are placed on WIP as we demonstrated earlier. This ensures that a maximum number of features or issues can be worked on at a given time. This should allow teams to focus and deliver with higher quality. In addition, the added benefit of workflow visibility drives urgency, keeps things moving along and highlights areas of improvement. Remember, Kanban has its origins in manufacturing, and its key focus is on productivity and efficiency of the existing system. With this in mind, Kanban by design, can be extended to incorporate basic aspects of software development and deployment.
In the end, organizations that are adopting DevOps models are looking to increase efficiencies, deploy code faster and respond quicker to business demands. Both the Kanban and Scrum methodologies address different areas of DevOps to greater and lesser degrees.
The advantages of the Kanban system for IT operations is in its ability to create accountability in a very visible system. The visibility of activities, via the Kanban board and its represented Work Items, aid in improving production flow and responsiveness to customer demand. It also helps shift the teams focus to quality improvement and teamwork through empowerment and self-monitoring activities.
=========
Les Viszlai is a principal strategist with VMware Advisory Services based in Atlanta, GA.
