Lean in the IT Department

Dear Gemba Coach,

My company has been doing lean for a while now, and I’ve been asked to start lean in the IT department. I’ve read the books and gone to the conferences, but most of what I see is very focused on manufacturing. I‘m unsure about where to start – would you have a few pointers?

Lean and IT: interesting topic. I understand your difficulty because it is one hard topic to tackle. First, let me encourage you to learn more about the agile and extreme programming community. Some of these guys have been applying lean techniques and giving them cool names such as scrum, sprints, sashimi, and unit tests. There’s some very good stuff in there and the agile crowd tends to be both fun and quirky. Unfortunately, such techniques seem to be hitting the same acceptance barrier in IT departments that early just-in-time efforts had in production, which is not helpful. If your company has a strong lean drive, you might want to see how you can borrow from the agile world as well as develop an approach to lean in IT.

Lean tools don’t translate immediately to the IT world for good reasons. The two worlds have significant differences. The most important distinction is that IT is project-based. While manufacturing can be seen as project-based as well, its operations are repetitive, while IT projects are not, and have time frames of at least several years. In project development, projects have different phases during their life cycles, so workers feel that no two steps are the same. Moreover, development teams are typically put together from a pool of individuals for each project, or for certain tasks within a project, which makes team-based learning is difficult to organize.

A second large difference is that in manufacturing, customer requirements are, by and large, pretty clear – once the product has come out of engineering, rightly or wrongly, that’s it. The goal of manufacturing is to produce as close to specs as possible, and to fix matters in response to customer complaints. Understanding what the product is supposed to be is quite clear. Not so in IT where, in many cases, the understanding of what the system is supposed to do remains vague to the last stages; and can be the source of many disagreements with customers and users.

A third large difference is that IT work is mostly invisible and personal. The coder is alone with her screen, and only she really knows what’s really going on in her code. In manufacturing people work together on visible things, such as components and machines. This makes seeing the flow and the quality issues (relatively) easy, if you know how to look.

Fundamentals

As you can imagine, applying all aspects of lean to IT is a topic that entire books can be written on (and have been; I highly recommend Mary Poppendieck’s work on the subject). So let’s focus first what kind of environment or program would help you to be able to do lean in IT. If you get that right, then you can move on to the more detailed work of getting each project to work in a leaner way. Let’s see how lean fundamentals can apply to a lean IT department.

First, customer satisfaction. Now, there’s a biggie! The first, difficult step here is to accept once and for all that we don’t know what we don’t know. And when it comes to what customers want from an IT system, we really don’t know what we don’t know. Worse, often they don’t know as well and will only tell you this after all the work is done, and it’s not to their liking. This is a HUGE issue, and should be tackled accordingly. It’s not new to IT, of course, and there have been many attempts at resolving that by more communication with customers. Unfortunately, it doesn’t help that much. Customers don’t come to the meetings (they’ve got better things to do than listen to a bunch of IT guys jabbering techie lingo), and whatever they tell you is highly misleading. So if talking to them more is not really an option, what can we do? The first step is accepting we’ve got a problem: not only don’t we understand what customers truly value (because they don’t know themselves) but, to add insult to injury, this misunderstanding evolves over time (the same customer will not value the same things all the time). The answer is a determination to becoming really good at understanding what customers are ready to pay for as opposed to what they say they want.

How? The hard way: by learning. The first thing to set up for lean in the IT department is a rigorous, three-day hansei or “post-mortem” session after each project has been delivered. The key questions of this event is “did we get customer requests right?” and “if not, why not?” The output of these sessions shouldn’t be about a better system – that’s come and gone – but for a stronger way to figure out what customers want. In other terms we need to learn how to understand what customers value, and how to share this with our teams. In practice, you’ll probably see that we do find out what the customer really wants, but late. So the question is how do we discover this earlier on? This will probably lead you to schedule mini hansei sessions (half-a-day) throughout the project just to check that we’re still in phase with the customer values.

Here’s an interesting question: IT is supposed to be a lever for productivity and delivery. Is it? When we deliver a new system to internal customers can we see an improvement of productivity (after and expected short initial dip corresponding to getting the system in hand)? The proof of the pudding is in the tasting. IT systems should make work easier, better faster. This is a good question to have in mind in the hansei sessions: what, exactly, is the value to final customers?

Just-in-Time for IT

Second lean principle to we want to apply is just-in-time. How can we possibly work in pull when we’re not delivering one product regularly, but a string of activities that build up one integrated system: nothing is twice the same? That’s true, but one of the core ideas behind JIT is takt: leveling the work so that we have the production capacity to flow smoothly through the chain. In IT this is relevant for two reasons. In the first place, and this is explained by queuing theory, if you saturate your resource beyond 80%, everything just stops: nothing gets out of the pipe. Secondly, management usually finds it very difficult to prioritize projects (everything has to be done now, regardless of resource). Leveling rules, such as a number of deliveries per week or per month (dividing the usual yearly amount of projects per month or week) will force deeper discussions about priorities and work content.

All projects are not equivalent – some are greedier in resources than others, or have greater scope. So why would we treat them the same and schedule them regularly? First, because no matter how large the project is, customers typically can’t absorb more than a project at a time, evenly spaced. So what really matters is the pace at which the developments come on line for customers to learn to use. Secondly, a regular scheduling of delivery will force a real discussion in terms of priorities (which one do we do next) and staffing (how many man-hours are needed to do this piece of work). Although JIT within a project might be difficult at first, establishing a takt of delivery is the key first step of this thousand mile journey.

Building in Quality

Third lean principle: Jidoka. How do we spot mistakes early and react quickly? Extreme programming and other development approaches have techniques to test code on an ongoing basis. This involves either automating tests after each block of code, or continuous integration, such as compiling daily to see whether the system crashes and so on. The key thing from a lean point of view is to have a way to spot coding or design errors right after they were created, and a managerial system set up to react immediately and not let the work proceed until the impact of the problem has been understood and countermeasures outlined.

Extreme agilists have also imagined some rather far out techniques such as pair programming. Two programmers work at one station: one types in the code, the other checks each line of code as it is written. Every half-hour (or less), the keyboard changes hands and roles are reversed. This sounds odd, but in this case, bugs are spotted right where they appear. Is it worth the extra labor? Aficionados claim that the result of pair programming is shorter programs, better designed and fewer bugs. One study reports that pair programmers are 15% slower than individual programmers, but error free code moves up from 70% to 85%. The added advantage is that programmers in the team learn to familiarize themselves with each other’s code. It sounds weird, but, in effect, this is like creating micro-cells with quality control in each cell rather than isolated operators (coders) and quality control (debugging) in the final product.

Lastly, I’m not aware of any specific agile or extreme techniques focusing on standardized work and kaizen. As John Shook pointed out, there are elements of work standards, such as tests and checklists, but these are not necessarily standardized work (set steps sequenced in a given time), and projects are reviewed for learning points and refactoring at the end, but this isn’t much like kaizen. In any case, to start with, having regular hansei session during any project’s development is bound to be a good start.

The last difference between IT work and production is the visibility of the process. This is a matter of being creative and finding ways of making the process visible (board, indicator tracking, etc.) Many IT guys have learned to create specific visualizations to represent their own processes. The trick is to keep the basics of visual management in mind:

• Visualize the process: find clever ways of doing so (are we ahead or late?)
• To reveal problems and react quickly (to protect the customer)
• And solve them one by one
• So that we improve our management policies

If you keep the core principles of lean in mind – by which I mean having a continuous process to discover what customers value, planning a smooth takt of deliveries, having tools to spot non-quality as it is developed and to react quickly, and standardizing and doing kaizen on your operations – then you’re already doing lean.

Purpose, Process, People

Whether by serendipity or design, lean is more advanced in IT than in other areas because many of the tools have already been developed. Merging the two together is mainly a question of sharing the same vocabulary (by no means an easy challenge) and keeping the principles of lean in mind – just as with manufacturing, programmers tend to get carried away with the tools and forget the reasons for the tools (as Mr. Ohba once phrased it: to build the Buddha image without putting the spirit into it). So if there is one word of caution this is it: always go back to what customers want. Ultimately IT is about making its customers more effective, and this can be tested. Also the immediate customer might not be the final customer, and it’s the final customer that really matters. Before making IT projects and development more efficient, it’s well worth spending some time figuring out why we want to do this development in the first place.

To answer your question, the place to start is by asking Jim Womack’s fundamental question of each proposed development: before we get people to improve the process, do we understand the purpose of what we’re asked to do? Good luck, and please let me know how it goes!