5 Steps to LEAN-er IT

There are many good things that can come from enabling the proven practices of LEAN manufacturing within your IT organization. Many books have been written on the subject, including two of my favorites; "The Phoenix Project" and "LEAN Enterprise". The thrust of LEAN,or DevOps as it is sometimes called in IT, is to promote continuous improvement by observing IT processes, gathering data on the failures and choke points in the processes, and then instituting controlled experiments to improve the processes. This is done as rapidly as possible to test whether the improvements actually deliver value to the organization. LEAN methodology recognizes that most changes do not add value, and that discovering which improvements are valuable should be done as quickly and as cheaply as possible.

In practice, there are several steps that you can follow to start realizing the benefits of LEAN practices in your IT organization. They can and should be done in order, and with minimal investment. And best of all, you should be able to see and measure the benefits of these LEAN methods within a few weeks or months. To successfully use these steps, you will need to cooperate with and listen to everyone involved in the IT processes that you want to improve. So it is essential that your LEAN team include practitioners from every area of the identified process. These should be the people doing the work and those directly managing the work. (The role of executive management in LEAN is to support the workers in their quest to improve, not to suggest improvements) Once you have assembled enough of a team to begin, follow these steps:

Step 1: Observe

The way to start any LEAN process improvement is to first observe the current process. In LEAN manufacturing, this means going to the plant floor and watching the manufacturing process in action, interviewing workers to find their pain points and gathering quantitative data on each manufacturing step. For IT Ops, it means watching the flow of tasks that are part of a process through the work centers or departments within the IT organization. For example, one might observe the process of setting up a new server in the data center, which includes racking the hardware, loading the OS, setting up security, loading applications, etc. Each of these steps might be performed by a different team or person. The total process includes all of the steps and persons involved.

The purpose of the observations is to identify the two major causes of friction in any workflow, which are "work in process (WIP)", and "rework".

WIP is defined as tasks that are queued and waiting for someone to work on them, or tasks that have been started, but are now waiting on an external or internal sub-task to be completed. Reducing WIP is the number one way to improve process flow. One way to make WIP visible for observation in IT is to use a Kanban board in each work center. This is merely a corkboard divided into three sections; to-do, in-work, and done. New tasks are put into the to-do column using index cards, and pulled into the in-work column by a worker who is free to perform the task. When the work is complete, it is moved to the done column. Tasks in the in-work column of the Kanban board can be marked with special characters when they are blocked by external or internal sub-tasks. By observing and gathering data on the flow of work across the Kanban boards of each work center that is involved in an IT process, the LEAN team can identify choke points in the process.  This is most easily done by daily counts of each column in the Kanban board, and by noting the cause of each piece of work in WIP. Choke points should be considered opportunities for process improvement.

Rework seems self-explanatory. Anytime a task has to be done again because something went wrong, it is rework. For instance, if a server OS is configured, but later it is discovered that the configuration is incorrect for the application, then the configuration step must be done again, at least in part. Rework can also be identified using a Kanban board. When a task is done, but then comes back to the work center for any reason, the original card for it should be marked with a special character and put back in the to-do column. A root cause analysis should be performed on every to-do item that is identified as rework. Every root cause should then be looked at to see if it can be eliminated by a process improvement. 

Step 2: Brainstorm

Once you have gathered some data about the possible choke points and frequent areas of rework within a process, the next step is to brainstorm with the team about possible solutions. One of the most important aspects of LEAN methods is the involvement of the actual workers in brainstorming solutions. Ideas for improvements should be solicited in an open, non-threatening environment. All ideas should be captured, no matter how wacky. Then the team should decide which ideas seem to have the best chance of success.

While all ideas have merit, the best LEAN ideas have some common attributes that the team should look for:

- They can be tested with a small initial investment

- They can be measured against the current process to see if they worked or not

- They can be scaled to the organization if they are successful

With these attributes in mind, the team can decide in what order, and how best to test each idea that the team feels might be beneficial to the process.

Step 3: Test

Now that the team has one or more ideas for improvements to the process, it is time to experiment. LEAN experiments focus on proving that our ideas work by investing the minimal time and resources necessary to prove that the idea is worthwhile. To do this, the idea should be tested either in place of, or side by side with, the existing process. The experiment should have a defined start and end point, and measurements should  be taken during the test to see if the idea is working. The measurements might be as simple as comparing the number of tasks in the Kanban board columns to see if WIP and rework are reduced. Or we might need to use additional measurements, such as number of customer complaints, or downstream lead times. If the team needs additional measurements, be sure to establish a baseline for the measurements prior to running the test.

During the experiment, if the test is not going well, it is important to stop it as soon as possible. Then the team should evaluate what they think is going wrong, and either adjust the experiment, or begin a new experiment that addresses the problems with the test. Remember that our goal is to learn quickly, and to get to a process improvement that works as quickly, and as cheaply, as possible. The team should be careful not to get pulled into trying to save experiments that are not going well. In particular, the team should be mindful that sunk cost and sunk time are not good reasons to keep pursuing a test that is not showing any gains for the process. The team must recognize that 9 out 10 process changes do not improve productivity or quality. The focus of LEAN is to find the 10th change.

Step 4: Adopt

When a test is concluded successfully and shows a measurable gain in productivity or reduced rework, a plan should be made to adopt the change permanently into the organization. It is important to keep in mind that the experiment performed may not scale to the organization. So adoption of the new process steps should be done incrementally if possible, and care must be taken to properly communicate, train, and roll out the new process. Measurements should be taken during and after the roll out to ensure that the change is having the intended effect.

This is why it is so important to keep the changes small and to get the enterprise comfortable with the idea of frequent process improvements. The LEAN team plays a crucial role in this communication. Members of the LEAN team should communicate frequently with their peers and other workers about the experiments that are going on, and about coming process changes. Feedback, whether positive or negative, is the most important learning tool in the LEAN cycle. All feedback should be captured and discussed by the LEAN team as soon as possible.

Step 5: Repeat

Finally, it is most important to remember that LEAN is a continuous process, not a project. Improvements are never done, and no process is ever perfect. So the LEAN team should be a permanent part of the organization, and should be implementing experiments and rolling out changes one after the other. The members of the LEAN team should also change over time. This will allow for new ideas to come into the team, and will also spread the LEAN methodology across the organization. Hopefully, the ideas of frequent experimentation and continuous improvement, of small investments and quick failures, will become an intrinsic part of the IT organization.