Tuesday, June 19, 2007

Lean NPD Summit Report

A couple of weeks ago, Rick Garber, our manager of process engineering at Corbis, and I attended the 2nd Lean New Product Development Summit in Chicago. This event is primarily a vehicle for Don Reinertsen to promote Lean ideas in design and product development. Last year I was an invited speaker and at Don’s request presented a mish mash of stuff that spanned my adventures in Lean and Agile over the previous 5 years including results from my work at Motorola and Microsoft. I tried to present too much in a short time window and the result wasn’t pretty. I didn’t publish the presentation as it mostly reworked previous longer presentations. Somehow, I still managed to get invited back again this year, despite overloading last year’s audience with too much material.

So, demonstrating my ability to learn from feedback, this year I decided we’d focus only on our Kanban System case study. The results were much better. This year we really got the conference a-buzz with discussion and both Rick and I were swamped with questions during subsequent breaks and at the cocktail reception in the evening. The following day many speakers were referring to our presentation with favorable comments and as a reference point for what was possible. I believe that we delivered a presentation that told a real story, presented real data and provided an actionable set of guidance that others could copy. The full presentation is available over on my Articles (and Home) page, A Kanban System for Sustaining Engineering.

A few more comments about the event…

I really like this conference. It is limited to just 75 participants. They generally range from senior process people (individual contributors) through several layers of managers including directors and vice presidents. I really don’t attend any other event where I can mix with so many thoughtful and pro-active managers experimenting with Lean ideas. The participants also span a range of industries including medical products, aircraft, industrial components and high technology (not just software). This is also refreshing. It’s nice to get out and mix with people from other backgrounds and be exposed to fresh ideas. I have found the event both years to be incredibly energizing and I’ve returned from it both times renewed and ready to push on with yet more ideas for management innovation.

My biggest wonder this year was why an event that had such a stellar set of speakers and included Mary Poppendieck as a keynote in addition to Don, wasn’t sold out! If you get the chance, carve out three days on your calendar next year and attend. It’s probably the best investment you’ll make in a management event all year. Technorati tag: Agile, David+Anderson, Lean, Kanban, Software+Engineering, Don+Reinertsen

A Kanban System for Sustaining Engineering

On June 6th, Rick Garber and I presented a brief overview of our Kanban system for software engineering sustaining releases adopted on my team at Corbis. I’m making a PDF of the slides available for general download. This is very much a first attempt to explain and teach what we’re doing to a wider audience. It should be read along with associated blog posts: Kanban in Action, My Approach At Corbis, Kanban Conversation , Six Month Review, April Fool With Meaning, Do you have your Sticky Buddy?.

Abstract

Given an executive directive to focus 10% of engineering resources on maintenance and upgrades through regular sustaining engineering releases of software systems, the Software Engineering Department promised it could deliver a release every 2 weeks. Initially, a traditional project management approach to define scope and schedule with a firm release date was adopted. The results were terrible – the process of gaining agreement on scope, cost estimates and release dates with management alone often took over 2 weeks and the process drained resources from other major projects.

The response was to adopt a kanban system to limit and control work-in-process, coupled with a regular release schedule and a regular prioritization meeting with business owners to introduce work to the system. This kanban implementation utilized a floating pool of resources, delivered a release every two weeks, against a service level agreement of 28 days lead time, and demonstrated 10% resource utilization. The process clearly demonstrated that software development can exhibit all the same phenomena as Lean Kanban Theory suggests. For example, greater variation causes a need for increased queue sizes, larger work-in-process and longer lead times, while expediting also causes longer lead times, lower efficiency in resource utilization, greater work-in-process and ragged flow.

This presentation details the process as adopted and uses real data to explain the results. It shows how the process has adapted over time to improve throughput, reduce lead times, decrease variability, and limit work-in-process.

Download A Kanban System for Sustaining Engineering [PDF 1.5MBytes] Technorati tag: Agile, David+Anderson, Lean, Kanban, Software+Engineering, Don+Reinertsen

Friday, June 15, 2007

Policies - You’ve Got the Power

If you are a manager reading this, then the chances are you are running a department with sub-optimal performance. Much of that performance is being constrained by policies. Those policies may have been around for years. Many of them pre-date you taking control of the team. Many of the staff have forgotten why a certain policy was introduced. They are part of the folklore of how things are done around here. Often your shop floor individual contributors will know that these policies are affecting performance but they abdicate any responsibility viewing it as a management problem.

Guess what? You are the manager!

Policies are under your control (or maybe your boss or an upline manager).

If a policy is affecting the performance of your team - change it! Show some courage. Make a change. Just do it!

For example, we had a policy that locked down our test environment for 3 days after every release. Since introducing our kanban system for sustaining work, we’ve put a release out every two weeks. A 3 day outage in testing was constraining our productivity by limiting our test capacity to only 70% efficiency. The effect was lower total throughput of change requests and delivered business value. A small cross functional team investigated the policies behind the 3 day lock down and discovered that most of the original reasons for the 3 day period no longer applied. On the recommendation of the team, I changed the policy to 1 day, giving us back 20% of our testing capacity. Since we made this change in early April we’ve seen continued growth in throughput of processed change requests delivered to production each month.

Where are your policy constrained bottlenecks?