Conventional lean tools include timing a process and tagging each action as value added or waste. That may work in a factory, but not in software development; or can it?

The same precision and clarity is not possible in a knowledge industry. You cannot apply a stop watch to mental problem solving. Sometimes getting away from the keyboard for an hour is the most valuable thing you can do. Few (if any) six sigma black belts will put that in the value added column, but maybe they should.

There are a few problems with this technique, but they stem from confusing a lean tool with the purpose of lean.

Client Value

In lean, being able to categorize tasks as value added or not relies on a value stream. We know what the end client wants, so we can see if each second along the way is contributing to that want. The purpose is to make sure we’re only investing energy into what is adding value. The stopwatches are just a tool to support that goal.

At a basic level, this “knowing what is valuable” is what software teams are establishing when they start with why. Once they know that, they can evaluate each deliverable (or task) as helping that cause or not (adding value or not). Again, this is to ensure that the energy they’re investing is delivering value.

That may seem much fuzzier than lean manufacturing, but it’s actually the same. The difference is what you’re not seeing in lean and what is ignored by many software delivery teams.

The Why of Lean

In lean manufacturing, we see and talk about assembly lines, plants, and other artifacts as being what lean is. We see the lean experts and plant tours as representing lean.

True, lean principles are made quite visible there, but this is not where lean starts. The best lean organizations aren’t just lean for lean’s sake. They have a purpose that transcends what they do. They have a why.

Take the example of Toyota North America’s purpose:

1. As an American company, contribute to the economic growth of the community and the United States.

2. As an independent company, contribute to the stability and well-being of team members.

3. As a Toyota group company, contribute to the overall growth of Toyota by adding value to our customers.

Notice that it says nothing about designing, making, or selling cars. Cars are somewhat irrelevant for fulfilling Toyota’s purpose. Cars are a great way to support the Anerican economy, communities, team members, and the parent company. Toyota has a purpose that has nothing to do with “what” they do.

Now being lean in manufacturing is less about saving money, it’s about making sure that the purpose is fulfilled and not wasting time waiting and not wasting money on inventory is a good way to better fulfill that purpose.

With that clarity, all of the decisions and activities that precede and support the plants are also improved. It is this part of a wholly lean operation that is oft ignored. Clarity of purpose helps ensure decisions are aligned to supporting the cause

• Should we lay people off and save money? That would be harmful to community, and destabilize team members (even those retained). Unless absolutely necessary to survive, no, we won’t lay them off.
• Should we open this plant? Maybe. It would help that community and America. It could offer new opportunities for team members. Primarily, we just need to make sure it will add the most value to our customers of all investments we could make.

It is at this level of strategic investment that software delivery teams, even very small ones, exist. Software delivery is a creative process. They must make sure their investments are aligned to a greater purpose. Every deliverable a team begins is a strategic investment. The team must make sure that the deliverable is the most value added thing they could do with those minutes if the team wants to be truly lean. This is just like Toyota deciding whether the best investment it can make to fulfill it’s purpose is a new plant.

The Lean of Software Delivery

When software folk talk about lean operations in software delivery, they often talk about how the work is non-repetitive, cannot be scripted, is very creative, etc., and so this “lean” stuff doesn’t apply. There are a few problems with that.

The first, is that the lean stuff certainly applies and in a hundred ways. There are repetitive aspects to software delivery that deserve standards and structure. But, the idea of timing software engineers like line workers is ridiculous. Or is it?

If our delivery teams are deciding the investments and making strategic decisions like the lean leadership at Toyota, then who are the laborers we could time in our system like factory workers in lean?

The users of the software.

They clearly have a structured and semi-repetitive job. If not, software wouldn’t work. Some things they do add value to their client and some don’t. The software may help with this, but the principle remains. If you want to apply all of the lean six sigma skills employed at a factory, apply them to the users of software.

If you want to help a software delivery team, give them the output of that client analysis, but when prioritizing actions to improve the client process, remember to prioritize based on why.