The evils of inventory

 When I worked for Boeing in the early 1990s, the company was utterly dominant in the commercial airplane industry—record profits, orders, and market share. However, Airbus was a growing concern, and Boeing leadership was keenly aware of how U.S. companies used to dominate the auto industry, but now that dominance was shifting overseas. At the core of that shift were higher quality and greater agility, which in turn drove more advanced features and larger margins. So, soon after I started at Boeing, my co-workers and I all got training in reducing inventory.

What does reducing inventory have to do with quality and agility? Everything. Inventory is the product, product components, and product work that you’ve begun but haven’t delivered—your work in progress. Why haven’t you delivered it? Because it’s either broken or unfinished. Living with high inventory means living with low quality and slow delivery rates. But you can’t just tell people to deliver higher quality and be more agile. You must be more concrete. When you ask people to reduce inventory, yet still deliver committed work, people quickly find no alternative but to increase quality at every step and deliver pieces faster. Drive down inventory and you drive up quality and agility.

What does reducing inventory have to do with you and Microsoft? Everything. True, Microsoft doesn’t manufacture planes or cars, but it does have quality and agility problems. We are bursting with inventory—unfinished features, open bugs, unintegrated and undelivered code, and even unread email. If we’re going to be agile and deliver high-quality products, we need to start by reducing that inventory by orders of magnitude. Fortunately, that’s something every individual can do—helping ourselves and our company at the same time.

Eric Aside

You must always have some inventory—work that’s started but not finished. Otherwise, you’d never work on anything. The key is to drive inventory down to as low as it can safely be.

As for Boeing, the training helped, and Boeing manufacturing did improve substantially, but Airbus still managed to gain market share. Like competition, improvement is a continuous struggle.

Things have changed

Microsoft has been around for forty years. Many of the practices we used to make us successful when we were young no longer make us successful today. As fond as I was of the creative ways we shipped on floppy disks and CDs (swapping disks and weight-balancing labels), that’s just not how it’s done anymore. Now we ship online multiple times a day, yet many of us still act like we’re winners if we ship a few times a year (an improvement, but not the goal).

Some of the changes necessary to ship multiple times a day require entire divisions to alter how they organize and operate. Individual engineers can embrace and enable such change, but they don’t directly control it. However, individual engineers can directly reduce their inventory. Doing so will accelerate the reduction of overall inventory and lead to higher quality and agility for our teams, our groups, our organizations, and our products. It’s not that hard to do once you realize how evil inventory is and commit yourself and your team to subduing the savage inventory beast.

Finish what you started

Our primary collection of evil inventory that individual teams can reduce is our collection of unfinished features and open bugs. Teams can choose to spec, implement, and validate only one or two features at a time (minimizing the number of active features the way feature crews do) and prioritize closing bugs quickly (using bug jail if needed).

Even if your team refuses to reduce inventory, you still can reduce it individually by working on only one or two features at a time and keeping your individual bug count down to only a few young bugs. You can compare your inventory to that of your peers by counting their respective active work items (including bugs). You can compare how long that inventory has been festering by calculating the average age of those work items. Warning: the results may be alarming.

Many Agile methods also reduce inventory. Test-driven development (TDD) drives excellent implementation design and thorough unit testing. Pair programming ensures peer review of code and promotes robust design. Scrum, Lean, and Kanban all directly reduce the number of active features in progress. Try these methods on your team. Some can be used in combination, like two my favorites: TDD and Kanban. All will improve quality and agility.

Eric Aside

I talk about TDD, pair programming, and Scrum in The Agile bullet and Lean: More than good pastrami. I give you a quick primer of Kanban in Too much of a good thing? Enter Kanban and fully break it down in Agile Project Management with Kanban.

Get moving

Another collection of inventory is our unintegrated and undelivered code. Even if that code contains completed features with all bugs closed, it stays inventory for your team until it’s integrated into the main codebase, and it stays inventory for Microsoft until it’s delivered to customers.

Continuous integration used to be common practice at Microsoft—build, validate, and integrate your code at least once a day. It still is for many teams, but some teams don’t integrate their code for weeks at a time. Those weeks of built-up inventory not only reduce agility, but also accumulate merge conflicts and quality issues. The longer your code stays isolated from the main codebase, the more issues accumulate and the longer it takes to resolve them. It’s not linear growth—one month of churn produces more issues than four individual weeks do. That’s due to all the second-order effects that arise as codebases diverge. In other words, integrate early and often.

Continuous deployment and delivery are already the standard across the commercial software industry—deploy your code to at least a subset of customers every build and/or every day. Many Microsoft teams, like Bing and Xbox, already do this. Others are quickly ramping up their cadence. It’s not just online services. Xbox sends platform and app updates to preview audiences constantly. Continuous delivery not only reduces inventory and increases agility, it also speeds customer feedback, so you always have both quantitative and qualitative measures of your product. You can tune your product to your customers in days instead of months or years. Don’t be left wondering what your customers will think—deliver your inventory and know.

Eric Aside

I discuss continuous delivery and its benefits in There’s no place like production, Quality is in the eye of the customer, and Data-driven decisions.

Buried alive

A more subtle yet evident collection of inventory is your unread email. An overflowing inbox makes you less responsive and less informed, diminishing the quality of your decisions and your overall effectiveness—that’s the result of allowing inventory to accumulate. Inventory is evil.

You don’t have to read and respond to every email—that’s not feasible. Instead, you need to separate the signal from the noise (using inbox rules), and then quickly handle the signal (using folders, quick responses as needed, and liberal use of the delete button).

Your inbox rules can (and should) filter any email not sent directly to you into folders broken down by category (discussion aliases, build and check-in mail, and team mail). The only email that reaches your inbox should have you on the to- or cc-line. I describe how to quickly manage those mails in Your World. Easier. You can scan your team mail and other folders separately (and less urgently).

Eric Aside

Here’s a stretch goal for you: Hit zero items in your inbox at least once every day—not necessarily for every folder, but at least for your inbox. I’ve been doing that for over a decade.

Be the change

We can’t be competitive as a company or as individuals in today’s fast-moving world when we have an anchor of inventory around our necks. Inventory hides information and quality issues, slows feedback, and hobbles agility. If we can’t contain inventory, we can’t compete.

Fortunately, every one of us can reduce inventory. Ensure you and your team only work on one or two features at a time, from start to finish. Keep quality high and bug counts low. Strive to integrate and deliver code every day, every week, and every month. And keep your inbox clean and yourself well-informed, so that you’re always ready to make good decisions.

Microsoft isn’t some abstract entity. It’s each and every one of us. When we all do our part to deliver high quality and remain agile, Microsoft does the same. We enabled the world to move at warp speed with a computer on every desk and in every home. With your help, Microsoft will compete and win in the world we helped create.