Just What is Lean Development?

It’s been a strange 30 years in management: methodologies and technologies have changed so much that business is almost unrecognizable. One of the largest contributors comes from the Toyota shop floor in the 60s—the Lean Manufacturing System, which has gone on to revolutionise dozens of fields from political campaigning to software development.

Today, we’re going to be breaking down what Lean is, and how it applies to software.

WHAT IS LEAN?

Eliminate waste.

Okay, it’s more than that, but that’s the guiding principle that everything else revolves around. The original lean guide (TPS, or the Toyota Production System) split waste into three types:

• Muda: time, money and resources that have been allocated or used poorly. While it’s important to eliminate muda, many managers stop here—they’re only really fulfilling ⅓ of the principles, and they are not correctly implementing lean methodology.

• Muri: inconsistency. If your staff have nothing to do for three weeks then suddenly have to scramble in the last three days to write code for the production environment, then they’re going to write worse code and it’s going to cost time and money later trying to fix it.

• Mura: overburden. Your staff should be properly-trained, well-equipped, well-rested and well-supported. This is the most commonly forgotten of the three principles, and that’s part of the reason lean gets a bad reputation in some circles—failure to eliminate mura can lead to short-term financial gains but cripples companies in the long run.

Let’s break those three down:

MUDA

There are seven wastes under muda:

• Overproduction: create only the products that are needed.

• Transportation: moving products costs money, and increases the risk of damage.

• Inventory: the cost of storing goods and resources is a silent killer financially.

• Motion: in the original context, this meant the literal movements of employees on the shop floor—creating a space where people weren’t going further than they needed to.

• Defects: Things that don’t work as well as they should.

• Over-processing: using expensive tools and equipment when simple and cheap ones would do.

• Waiting: wasting time by having products sitting around when they don’t need to be.

Which is very focussed on manufacturing, but we can use the same ideas in the context of software development:

• Overproduction = overengineering. If you’ve found yourself asking “do we really need this feature?” then you might have found some muda. Does your rideshare app really need a livestream feature that lets users chat to each other while they wait for a ride?

• Transportation = sloppy deployment. How are you getting code from the development to the production environment? How are you deploying patches and updates? With the advancement of platforms like Heroku, you can deploy an app in less than 5 minutes. If you’re spending days waiting on a dozen different platforms to line up, then you’re wasting a huge amount of time.

• Inventory = poor database scaling. If you’re running an Oracle Enterprise Edition DB for a project you could be running out of $20 cloud storage, then you’re wasting a massive amount of money for something you’re not using.

• Motion = motion. A lot of guides translate this into something else, but I’ve always felt like it worked in a very similar way: how are your staff navigating the office? Is it easy for them to get where they are to where they need to be? In the digital space, this can include things like: what sort of chat channels are they using? How is video chat configured? If you’re wasting the first five minutes of a video call making sure everybody is properly set up, then, well … you’re wasting time.

• Defects = Defects. You know what they say: “catching a bug in development costs 1c, catching it in testing costs $10 and catching it in production costs $10,000.” Proper QA is critical in any lean software pipeline.
• Over-processing = over-processing: do your developers really need that super-shiny IDE? They actually might (see muri), but it’s important to ask so you know that the right tool is being used for the right job.

• Waiting = waiting. Is somebody’s code compiling? Tell them to find something else to do. Catch up on the email backlog, take a minute to check in on a client, start planning out what you’re going to do after everything compiles.

If you work to eliminate these seven wastes, you’re going to be on-track with most of your competitors running Lean Development. However, they’re only ⅓ of the core principles. If you really want the edge as a lean developer, read on.

MURA

Mura is often harder to immediately pin down, which is why TPS places so much importance on visual tools like Kanban boards that can make abstract ideas like flow more tangible. Mura is rarely the result of making one single change and isn’t seen when looking at individual parts of the company: it requires a broader view of conception through to delivery.

Generally speaking, a good manager avoids micromanagement and mura understands this fundamentally: it’s about taking a broad eye on things. Mura involves using visual aids like graphs and kanban boards to identify bottlenecks, and to optimize product delivery times. One of the original core concepts is takt time, which is the average time between starting production of one unit and starting production on the next; we don’t talk about takts a lot in software (where we’re not producing a new discrete piece of software for each sale), but they’re useful in considering how a manager should look at mura: a macro view of processes that—when combined with other macro-views—allows us to look at our company like gears in a watch.

MURI

If you ask your teams to do things that aren’t within their capability, you create waste: you get a worse product and a frazzled developer. This means overburdening both their time and their skills: it’s the same result, and that result is waste. There are immediate financial repercussions (buggier products require more testing) and long-term morale repercussions that cycle back around to being income issues: the cost of replacing developers and the subtler effects of low morale on product quality. Muri also includes:

• Lack of support and training: if your developers don’t know what they’re doing, it’s much easier to overburden them. Making sure they’re properly-supported means their threshold for stress is higher—the work they’re doing takes less effort, which means they can do more work.

• Lack of proper tools and equipment: here, Muri and Muda come into conflict, and in my experience Muda wins too often. If an expensive tool is what your developers need for the job, then you might just have to go with that expensive tool. It’s wasteful to have an Oracle Enterprise DB for a 2mb app, but it’s also wasteful to run cheap cloud storage for a government record keeping department. The costs in time and money running around trying to make the ocean fit inside a thimble are going to outweigh any savings from just buying the right DB in the first place.

• Poor communication: even if everybody has the right skills and tools, they can still create waste if they simply don’t know what they’re meant to be doing. Developers often lack soft skills, and that can cause a huge amount of waste if not dealt with.

• Not enough staff: one of the main criticisms of Lean is that it means “not hiring enough people”. This is certainly how it has been used, though managers doing this are implementing lean incorrectly and are generating muri rather than eliminating it. You don’t want to have the least number of staff possible, you want the right number of staff for the job to get done efficiently.

Wait, what about 6 Sigma?

6 Sigma isn’t actually a core Lean principle, though they’re highly complementary and are often seen together for good reason. That’s its own topic entirely and not one we’re covering today, though I highly recommend you brush up on it to have another great tool in your management toolkit. Let’s save that one for next time.