I’m often asked while working with teams transitioning to Agile how Agile and Scrum can be applied to groups like Infrastructure or Support that manage a continual stream of user requests. These teams find it difficult to shoehorn their work within time boxed iterations when their work has dependencies that may not be met within a defined iteration or their customers can’t wait for the end of an iteration to receive a software fix.
This is a great question, which I usually answer by pointing out that there are different flavors of Agile and that not all flavors utilize time boxed iterations. Agile, whether it is employed for software projects or your Honey Do List, is all about flow. Specifically, it is about managing the flow of work through a system to optimize efficiency and effectiveness.
Kanban is a form of Agile that does not use iterations to manage the flow of work. Instead, it focuses on visualizing work in progress within a system, limits the amount of work in progress in order to improve throughput and uses a pull system to pull new work into the system as soon as there is capacity. Kanban uses metrics such as average cycle time to measure the performance of the system in terms of speed and adherence to defined Service Level Agreements.
Implementing Kanban is less obtrusive than other forms of Agile since you can apply the principles directly to your existing process without having to change it. Start by visualizing the work in progress in your current system. Once you visualize work as it moves from state to state within your system, you can determine where bottlenecks occur and apply WIP (work in progress) limits to smooth the flow over time.
Let’s walk through an example of applying Kanban to an infrastructure environment using an approach created by David Anderson from his book Kanban: Successful Evolutionary Change for Your Technology Business.
1. Agree on the goal(s) for introducing Kanban.
Identify and get agreement on what problem(s) you are trying to solve by implementing Kanban. Then, translate each problem into S.M.A.R.T. goals so that you can measure how changes to the system are driving you towards achieving the goals. For example, many infrastructure groups want to reduce the total time it takes from a customer request to a deployed environment.
2. Map the value stream.
The next step in the process is to map your current process from end to end. The intent is to identify each of the states that a work item, such as a request, goes through from beginning to end. The challenge is to keep the process flow high level to avoid an unmanageable number of states within the flow.
3. Define the point where you want to control input.
Determine the point(s) of entry into your system so that you can control the amount of work entering your system and thus control the amount of work in progress. In the value stream example above, you would want to identify each channel in which requests are made, such as an online form, email or phone, and limit the channels to only one or a few in order to better control input.
4. Define the exit point beyond which you do not intend to control.
Determine at what point you relinquish control of the work to some downstream consumer. This allows you to limit the amount of work exiting your system so that downstream consumers can absorb it.
5. Define a set of work item types based on the types of work requests that come from upstream stakeholders.
A work item can be any service your group provides. By defining the various work items we can then determine the demand for each type and what Service Level Agreements are needed to support them. Below are examples:
- Environment Issue
- New Environment Request – Single VM
- New Environment Request – Multiple VMs
- Change to an Existing Environment – Software
- Change to an Existing Environment – Hardware
- Business Continuity Test
6. Analyze the demand for each work item type.
For each work item type, determine the demand for that work item. It could be steady, cyclical, burst or intermittent.
- Environment Issue = Burst
- New Environment Request = Steady
- New Environment Request – Multiple VMs = Steady
- Change to an Existing Environment – Software = Intermittent
- Change to an Existing Environment – Hardware = Intermittent
- Business Continuity Test = Cyclical
7. Meet with the upstream and downstream stakeholders to discuss the following:
- Policies around capacity of the piece of the value stream you want to control and get agreement on a WIP limit. For example, you may want to put in place a policy for Environment Issues that states they will be addressed within 24 hours and can exceed the WIP limit on any state within the Value Stream.
- Discuss and agree on an input-coordination mechanism with upstream partners.
- Discuss and agree on a release/delivery-coordination mechanism with downstream partners.
- Introduce the concept of classes of service, if needed.
- Agree on a lead-time target for each class of service of work items.
8. Create a card wall to track the value stream you are controlling.
Based on your value stream, create a card wall to manage your existing process. The end result should be a series of columns, one for each high level state in your process. Use queues between states to make bottlenecks visible. Set initial WIP limits for each column, including the input queue. When assigning WIP limits, start simply by limiting the WIP for each state based on the number of people that perform that function. Monitor the flow of work to determine where adjustments to WIP are needed in order to smooth the flow and reduce bottlenecks.
9. Agree with the team to have a standup meeting every day in front of the board.
Incorporate meetings that are essential for Kanban. These include the Daily Stand Up, Queue Replenishment Meetings, Release Planning and Retrospective. Identify the frequency of each meeting type and the participants.
- Daily Stand Up – The team meets daily to review the Card Wall and discuss:
- What did I accomplish yesterday?
- What will I commit to today?
- What impediments exist?
- Queue Replenishment – Serves the purpose of prioritization in Kanban. Held with a group of business representatives or product owners and conducted at regular intervals, such as weekly.
- Release Planning – Plans a downstream delivery to production.
- Retrospective – Occurs regularly where the team covers the following items in order to practice continual process improvement:
- What worked well?
- What did not work well?
- What will we improve?
10. Educate your team on the new board, WIP limits and the pull system.
As with implementing anything new, you need to communicate the reason why the change is needed and how the new system will work. A key factor for success is to get your team to buy-in to the new process and make it their own. Over time, the team will self organize to determine what states may need to change in the value stream and the proper WIP limit is for each state.