Many companies have heard that the concepts and methods of Lean would be of use to their organization; however, they do not see how something that sprang from manufacturing practices could apply to software development. This article presents a different way of looking at Lean Software Development – one that is independent of Lean’s manufacturing heritage. It begins by presenting Lean as a collection of a body of knowledge applying Lean principles to software development. It then shows how this creates a new paradigm of management, one that does not inevitably lead to micro-management or chaos. Finally, it concludes with a discussion about how organizations can use Lean to improve their ability to learn.

The Lean Paradigm Shift – Lean Science
Lean represents a paradigm shift from focusing on increasing productivity to focusing on shortening the time from the beginning of work to the completion of it. While Lean adopters are looking for higher productivity and lower cost, they have learned that going after these directly actually results in lower true productivity (value delivered per person) and higher costs. The reason is that productivity measures too often are geared toward how much work people are doing rather than how much true value is being delivered and cost, alone, is inadequate for deciding on process and/or product improvements. For example, measuring how much work people are doing leads to keeping people busy. Unfortunately, this leads to overworked analysts, developers and testers are incredibly busy while seemingly taking forever to deliver what the business stakeholders need. It does not translate into true added value.

Lean science could be said to be the set of testable knowledge based on the foundations of Lean thinking. To summarize, these foundations are

• Attend to the system in which development takes place; that is where the bulk of errors are;
• Respect the people doing the work;
• Attend to the time from when work starts until it is consumed by the customer (“cycle time”);
• Get to the root cause of errors when they occur.

The foundational tenet of Lean is, “focus on shortening cycle time.” Productivity will follow. In other words, Lean is based on the hypothesis that shortening cycle time raises productivity by reducing the delays that make error detection more difficult and it lowers cost because this delay in error detection increases the amount of work needing to take place.

Consider the type of work we do in software development, as illustrated in Table 1.

Table 1: Activities performed during software development

These items are not listed in any particular order; I am not implying any particular process. The activities on the left represent work that provides real value while those on the right represent work which we often must do but which don’t really add value. In the Lean world, these latter activities are called “waste.” And it is good to try to eliminate waste.

The problem with trying to eliminate the waste is it is often created by people who are not doing the work. Consider the problem of two ditch diggers. Both are working hard. One is digging away and throwing his dirt into the other guy’s hole. Stepping back, you can see the first guy is creating extra work – “waste” -  but down in the trenches, the second guy just sees still more dirt that he has to remove. Sometimes waste can’t be seen until you look at the entire picture.

It is easier to say “eliminate waste” than it is to actually eliminate it. We can’t just stop doing wasteful things; we must stop the need for doing them. Let’s consider the wasteful activities on the right-hand side of Table 1 and what is driving the need for them. It will become clear that the root cause involves delays, and that is what we want to eliminate.[1]

Re-doing requirements is a common practice in software development. It occurs because we often get requirements too early. There is a delay between when a requirement is first mentioned until the development team starts working on it. Inevitably, the requirements will have to be updated or redone; otherwise, we will have another activity, working from old requirements, which clearly causes wasted effort.

Consider “fixing” bugs. The quotes around the fixing are intentional: although most developers believe they spend a considerable amount of time fixing bugs, in reality they spend more time looking for the bugs. This is not just semantics. Imagine a developer who writes a bug but is immediately told about it. She can probably fix the problem fairly quickly. Now, consider the situation where the same error occurs, but the developer is not told about the problem for 2 weeks. It will take her considerably longer, even if nothing else changed. It is even worse if it falls on someone else to fix it. Where did this new work come from? It comes from the delay between creating and detecting. I call this “induced work” because it is caused by delay: Just like moving magnets induce electricity in wires, delays induce work in development.

A similar phenomenon happens with “integration” errors. Virtually every “integration” error I have seen  in my years of development has been caused either by communication errors between two groups or one group not doing what they said they would do. While such an error is detected at integration, it doesn’t make it an integration error.

Note how all of these “wasteful” items, including building unneeded features is exacerbated by delays in information or in people being available. Overbuilding frameworks is perhaps the only item in the right-hand column that is not caused by delays.[2]

Let’s look at the work in Table 1 again. How much time do you spend on the left hand side and how much on the right hand side? Seriously, stop and think about it a minute. In my classes, when I ask people this question, people tell me they spend between 30% and 70% of their time on the left hand side, doing useful work. This means that between 70% and 30% of the time is spent on the right hand side, doing work that is essentially useless!

Now, we can speed things up either by doing the work on the left hand side faster or by figuring out how not to do the work on the right hand side at all. While you might be able to do the work on the left hand side faster, with the exception of automated testing, it is not likely you will realize significant improvements doing so. On the other hand, getting better (faster) feedback and having the right people work on the right tasks at the right time can virtually eliminate most of the work on the right hand side.

Shift your focus from productivity to working on the right things at the right time with the right folks. Better productivity and lower costs will come as great by-products.  How to do this in software development is exactly what Kanban focuses on. [3]

Working on the Right Things at the Right Time
So how to shorten the delays involved in our work? In large organizations I would assert that we must include the work done prior to the development teams. We can think of product development flow to have four stages. These are shown in Figure 2.

Figure 2. The stages of product development flow.

Identification and sizing of business capabilities. This is the first step. Business stakeholders (typically business executives or product managers) identify the business capabilities needed. They size these by refining them to their minimum marketable features (MMFs), sometimes called minimum viable features (MVFs).

Prioritization of these capabilities. For organizations with more than one product line, the business stakeholders and product managers that are associated with those products must decide which of these MMFs are the most important. This is product portfolio management. An organization must look across all of its products in order to determine what to work on next. Some products will return most of their value in a short period of time while others may continue to deliver large returns with each investment. It is important that teams not get locked into their products but rather switch to a product with a higher return if it makes more business sense.

Creation of stories for the teams to build these capaibilities. Once the MMFs have been prioritized, they need to be broken down further before the teams pull them to actually build the capabilities. It should be apparent that for large organizations this flow will be somewhat complex. Each business capability will likely be split out across several teams which must build different components that have both technical and business dependencies. A technical dependency between components means that one component requires another one to work. A business dependency means that although the components may work without each other, their value won’t be realized until all of them work. This is not unlike when you wait for your bags after a flight. If you have three bags, getting the first two doesn’t give you any value. It is only when that third bag arrives that you can leave.

A Short Lesson in Pull
To understand the flow in Figure 2, you need to understand a key Lean management concept: pull. Planning work is very difficult in high-variability situations – which software development certainly is. The idea of pull is that rather than planning the timing of our work, we have each step pull work from the output of the previous step. For example, in Figure 2, the development team (depicted as ‘building the capabilities’) would pull from the work area preceding it that creates the stories.[4] The people doing the work here need just enough work to ensure that when a team is ready to start a project there is enough work there for them to do so. Perhaps a little more for safety’s sake since sometimes projects are longer or shorter than expected. In other words, the development teams should be working as fast as they can, working to their capacity, and pulling work whenever ready. The upstream folks know to create another project to be ready when the developers pull one off the ready queue.[5]

By managing with pull, the organization focuses on lowering the queues between the different steps. As the queues get smaller, the work flows faster since the biggest delays in most software development is not so much the work itself as much as the time between the steps. To see this, consider how much time people are waiting for answers or approvals.

The Need for Management
It should be apparent that trying to coordinate this sequence of events with its accompanying business dependencies and technical dependencies requires a larger perspective than a team view. Not one of micro-management from the top. But one of recognizing global interactions are different than local ones.  How do we reconcile these different perspectives – the one from the top that is attempting to make a cohesive flow and the one from the bottom where the actual work takes place? Lean science provides a basis for aligning both global and local efforts because both should be looking to shorten cycle time in whatever they do.

Current management places a lot of emphasis on ensuring that people are working productively. Lean management would have management shift from trying to motivate people to providing them with the proper work environment in which to get their work done. “Work environment,” means more than simply the physical environment they work in. It includes the way they integrate with others doing development. Management’s role shifts to a larger view: helping to create an organizational structure in which the people doing the work can best function. Instead of managing by telling people what to do, managers now assist teams in getting their work done by providing the proper environment for them to do so and coaching as required.

In large organizations, managers can best assist teams by helping coordinate their work so that they are not over-burdened. Overloading teams is one of the primary causes of serious delay. The Lean manager’s role is both to focus on how work flows and in coaching teams to attend to avoid delays. Management provides the high view of the organization needed while providing assistance to work done at the team level.

In Figure 2, management’s role could be considered to be getting proper flow of work from the left to the right. This would entail having the right number of things being worked on at each step of the process. Imagine how having the right number of items hitting the team for them to pull from will help their productivity. A secondary effect will be that product owners will be more available to the teams as well. A common challenge in software development organizations is the lack of product knowledge which slows the teams down. It is ironic that the very people who can help them (e.g., product owners) are spending time creating more stories than are necessary. By limiting how much work can be upstream of the team pulling their work, the organization is also simultaneously making these people needed by the development teams more available to them.

Lean Learning
Development systems are very complex. Cause and effect are very difficult to determine. Many events are unpredictable. And since people are involved, events can even be irrational at times. This means we have to learn quickly and challenge our assumptions. Lean’s underlying systems thinking approach enables a three step approach for learning.[6] The first is to see where you are. Then, look to see where you want to be. Finally, take steps to get there. This learning approach specifies to take very small steps. If your steps are too large, many things will happen from when you start until you see results. This will make it difficult to see the results of your actions. Kanban methods follow this by using explicit policies (e.g., limitations on work in progress at each step of your process). You can readily see the results of these actions if you have your work reflected in a value stream map or Kanban board.[7]

Putting it Together
Becoming Lean is truly a journey and not a destination. It involves creating visibility where you are so you can see what you need to do to get to where you want to go. You strive to improve your work by removing delays between the steps of the work. One method of doing this is setting work in progress (WIP) limits so you do not exceed the capacity of your organization at any step. By eliminating delays, you lower induced work which raises true productivity and quality, while lowering cost. Because we are taking a scientific process here, all the roles of the organization can see if our actions are helping or hurting. Overall cycle time is our measure of efficiency of the organization. Local changes can be made with confidence of overall improvement if they lower our overall time. The goal is continuous improvement by improving how we work to get better products for our customers. We learn in small steps so we can understand the results of our actions. Visibility is not just limited to how our work is flowing but includes the rules we use for making decisions. This enables managers to assist development teams since they can work to have the proper organizational structure they need as well as coach the teams when they need it.

Lean Software Development is a combination of Lean science, Lean management and Lean learning. It provides an overall approach that helps different roles in the organization to see how progress is being made, both in the products being built and in the way they are being built By creating visibility and a common language they help create a better, more productive team.

[1] I’ll be making several assertions in the article. An assertion is a statement where I am promising to provide evidence to validate it. Except in this case, I’m suggesting you should provide the evidence by looking into your own experience. The impacts of delay in software development are somewhat universal – I do believe if you look closely you’ll find evidence for what I am saying. If not, please ping me on the leanagile Yahoo user group.

[2] Overbuilding frameworks is typically caused by lack of knowledge of how to do proper emergent design. The interested reader is referred to Scott Bain’s Jolt Award winning book, Emergent Design: The Evolutionary Nature of Professional Software Development.

[3] The term MMF (minimal marketable feature) was coined in Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. It is essentially the smallest piece of value that can be delivered that is worth the transaction cost borne by both the development company and the customer.

[4] Please don’t interpret this diagram as depicted a phase-gated approach. The reality is developers are represented early in the cycle as well and there is no intention that story definition is completed in the third box. Rather we mean just enough to get started building the software.

[5] This coordination is not usually done in real-time but rather by checking on a regular basis (e.g., weekly) to see if new work needs to be prepared. The regularity of this checking is called the cadence of the step.

[6] I highly recommend Mike Roth’s Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results. While based on Toyota (and therefore manufacturing) the learning process equally applies to knowledge work.

[7] Scrum boards can accomplish this but typically don’t as most Scrum teams do not explicitly state how they move work that takes place within a Sprint. Rather they limit their explicit policies to be how stories get on (Sprint ready) and off (done) the board.

Trackback(0)

TrackBack URI for this entry

Comments (8)

...
written by Mark Hart, September 13, 2011

In my experience, the labels in Table 1 should be changed.

"Activities that provide real value" should be changed to "Activities the may provide..."
"Activities that we do that provide no value" should be changed to "Activities that we do that typically provide minimal value"

Examples:
1. If there is a change in the market, the project can suddenly not be viable. The project will stop or pivot. Much of the work done in the column on the left will have little value. The same is true if a key assumption in the 'requirements' is wrong.

2. Just because someone works on items in the left column (getting requirements, planning, design,...documentation), it doesn't guarantee that they are valuable. The effort may be worthless if it is not valuable to customers at the time in the future when they deploy it in their evolving context.

3. The items in the right-column have some value. They may contribute to learning.

Most of the items in Table 1 are internal-centric. They may produce a solution that stakeholders accept and consider valuable. Knowing the percentage of projects that fail, the effort may not 'provide real value' to stakeholders.

Otherwise, there are many great points in the article.

• 
• +0
• 
• 

...
written by Jeffrey Morrow, January 01, 2011

Would be interested to read the ACM piece - Mike was my masters thesis co-adviser and is a formidable scholar - is it available for free somewhere? (Gotta link?) Does the article refer to any of his work in understanding 1980s-era Japanese "software factories?"
Bear in mind that Mike's in-depth attention to Toyota (in-depth for him means utter immersion: as mentioned, he's a serious scholar) probably ended in the early 1990s when he supervised Kentaro Nobeoka's dissertation research and they produced _Thinking_Beyond_Lean_ as a popularization of the dissertation. Much more is known now about the details of Toyota product/production system design and, of course, the ways Toyota does those things have evolved substantially as well.
A few comments by way of clarification attempts:
"Big company disease" may have caused complacency and arrogance from which e.g., insufficient effort flowed into assuring supplier quality in the case of the minuscule number of accelerator pedals that didn't actually jam but also did not operate smoothly. That is, Toyota's deviation from its ideals (the Toyota Way) affected Toyota's production system *instance* of those ideals in the middle of the decade (past? or is that 2011? Never can keep that straight).
In this meaning we include all of the activity required to manufacture cars, which includes designing the cars and designing the manufacturing systems and supply webs to make them as well as actual manufacturing and assembly. Of course, some instances of the Toyota Way in design differ from instances in manufacturing but at a suitably high level of abstraction application is completely congruent between both cases.
Don't know enough about modern SW Dev to comment specifically on bug fixing but if there's a useful analogy between engineering change orders (ECOs) and bug fixing I can note that from a TW perspective we're generally more interested in having fewer ECOs than in processing ECOs more rapidly - we do want to process them more rapidly, of course, but avoiding blunders that create the need to change designs helps even more.
HTH,
Jeff

• 
• +0
• 
• 

...
written by Alan Shalloway, January 01, 2011

Tom:
Thanks. This is a well thought out comment. A few points. First, Toyota's recent experience demonstrates that merely following Lean-Science blindly can have some problems. Too many companies do this - they look at what you "do" in lean instead of realizing that lean is more about how you "are." I personally believe their problems have resulted from their decision to become the largest automobile maker instead of the drive towards adding more value (quality, price, ...). This resulted in them growing faster than their management system could support. Lean, as a whole, is a combination of lean-science, lean-management and lean-learning. Overly focusing on the science can result in errors, as you've aptly described.

Becoming lean is no panacea. It does not guarantee success. Any method has the potential for error. Falling into the trap of thinking that lean is fool-proof is missing the point of it, yet is more common than not. Lean is about learning. It's about finding the rules that exist you must follow (lean-science). It's about assisting teams to follow these rules across the organization in a cohesive way (lean-management).

Your comments point out why I like to think of Lean as separate from Toyota. The fact that they were some of the first to put it together, and definitely have done the learning better than anyone, does not make them gods of the domain.

• 
• +0
• 
• 

...
written by Tom Anderson, January 01, 2011

Alan, you wrote that "Lean science could be said to be the set of testable knowledge based on the foundations of Lean thinking." The first of these foundations is to: "Attend to the system in which development takes place; that is where the bulk of errors are."

This advice might be seen in contrast with the recent article by Michael A. Cusumano of the MIT Sloan School, who wrote (in Reflections on the Toyota debacle, Communications of the ACM, Jan. 2011)

"[Toyota] began perfecting its famous Just-in-Time or 'Lean' production system in 1948.... the recent quality problems expose the limits of Toyota's production system. Making components or receiving supplier deliveries 'just-in-time' as the assembly lines need the components minimizes inventory and operating costs, and exposes quality problems visible to assembly workers. But it does not detect design flaws that surface during usage of a product."

Cusumano wrote this article for a computing journal because software development is a veritable hotbed for uptake of lean processes. The numbers of computing devices and the lines of computer code are increasing exponentially. Certainly becoming lean is a business practice that can contribute a great deal to software development, but as Cusumano argues, any manager needs to understand how those practices are limited through maintaining focus and attending to detail. Cusamano concludes his article: "The Toyota way used to be that one defect was too many," and implies that this practice should return as the ideal.

Thus, if we apply this thinking to software development, the amount of work that is saved through lean are wasted if software defects are the result. Wasting time in unguided searching for bugs is by self-sealing argument a time-waster, but testing and debugging through comprehensive code coverage should augment lean. If 30-50% of developers' time is spent looking for bugs, then there are surely some observations that managers can make to improve that to become more fruitful in fixing bugs--but surely a great deal of time should be still spent fixing (and catching) bugs. Furthermore, it suggests that testing, including user testing, should be conducted as soon as possible, so that it is testers are looking for bugs and the developers fixing them, instead of developers wasting time trying to look for bugs when user behaviors are unpredictable at the least and malicious at worst.

All in all, I think that Alan's article has some great advice for managers, but that the argument should be clarified with respect to Toyota's troubles of the past decade. Particularly, the failings of Toyota to find defects shows the benefits of not exporting products until they undergo extensive road testing. Thus, lean cannot stand on its own. Lean may be about learning from your own experience, but it cannot succeed without learning a great deal about your own weaknesses through the experiences of users.

• 
• +2
• 
• 

...
written by Alan Shalloway, December 29, 2010

First, a quick note to Jeff. I think you meant we needed to attend to the difference between the Toyota Production System (TPS) where they build the cars and the Toyota Product Development System (TPDS) where they design the cars. Software development _is_ more like TPDS. But the brake failure is, in my mind, a TPDS problem.

Now to Tom:
Three points. First, I do not believe the cause of Toyota's problems came from being Lean. In fact, it was their going beyond their capability as Jeff suggested that caused the problem. In other words, they could not maintain their Lean learning methods because they expanded so fast. This was likely due to their vision change from providing the best value to being the biggest. In other words, it was their deviation a few years ago from a lean vision to a size vision that set off the events that caused this. I seriously doubt those that have attributed Toyota's failure to lean truly understand what lean is. Can you name a couple?

It is a common misunderstanding that lean is about going fast. It actually isn't. Unfortunately, there is no word for removing delays to achieve overall speed. Lean, from a doing point of view, is about going from true start (idea) to true end (customer value being utilized) as quickly as possible while reducing delays while attending to achieving quality.

Finally, I am afraid you've missed the whole point of the article by bringing up Toyota. Lean in software should stand on its own. You shouldn't do anything because Toyota does it or doesn't do it. You should look at your own experience and go from there. Lean is about learning, continuously. About what works for you and your organization. Looking to others for a short-cut is actually, very unlean. Lean suggests following principles that work in your context - which will be different from any other company.

Ultimately, Lean is about learning. How to eliminate delays is a large part of it - not ho

• 
• +1
• 
• 

...
written by Tom Anderson, December 17, 2010

Jeffrey, I think you're not understanding my point, which is that there may be some danger in lean practices. It is not necessarily true that Toyota’s recalls were entirely because it is a big company. Part of the problem could be because of cutting corners and greenlighting. And I'm worried that it's exactly that route that Alan Shalloway, the author of this article, seems to be suggesting.

The advice to "shorten cycle time in whatever they do" seems to neglect the very real fact that bugs in software are potential game-losers. Nowadays, we see that Mozilla is paying $3000 rewards for finding a single serious bug in its software. In fact, finding bugs is a very important part of software development. I suggest that more time (and more efficient use of that time) should be spent on the this in the pursuit of higher quality. The Apple slogan "It Just Works" is so appealing because people understand that refactoring, putting in many great features and fixing bugs was a significant part of the drive to make products that look great, perform better than other products, and contribute to the Cult of Mac.

• 
• -2
• 
• 

...
written by Jeffrey Morrow, December 16, 2010

Toyota has had a string of very large and entirely voluntary recalls in the last year or so. The real roots of these problems - as distinct from the media spectacle of their apparent magnitude - arise in over-reaching during the past fifteen years, during which Toyota grew too fast to maintain sufficient proximity to its own ideals. (We do not want to confuse Toyota's production system with the Toyota Production System; the former is never more than a temporal instance of the latter, which is a set of ideals.)

In one sense we can see this as an experiment they tried that had outcomes (bad) that had been predicted by some insiders as far back as the early 1990s. These outcomes are manifestations of deeper problems. The good news for Toyota in this, paradoxically, is that it will likely focus the world's premier problem solving company back to its roots in problem solving i.e, result in Toyota more successfully combating what's known inside the firm as "Big Company Disease" - no one can pooh-pooh the risk of that after the last two years.

• 
• +2
• 
• 

...
written by Tom Anderson, December 15, 2010

As we all know, Toyota has had to recall a number of their vehicles recently. Brakes are failing, corrosion is forming on spare tire cables, cars are experiencing sudden acceleration. Toyota has been praised for quickly attending to these problems and safety is still their number one concern, but why did these recalls have to happen?

Some people attribute Toyota's problems to lean practices. In some ways, lean just looks like cutting a few corners to make the process faster. Trying to eliminate useless work might actually eliminate useful work that seems useless.

For example, the time spent "fixing bugs" seems useless, but perhaps it gives the programmers more time to fully understand their own code base. Cutting this practice might lead to bugs that are difficult for others to find, bugs that unit tests and constant iterations don't pick up because they are corner cases that only occur in extreme conditions--and it is those conditions that some customers are likely to experience. Although it may be said that lean practices can contribute to quality, what can we do to ensure that we are not causing problems and are indeed making software development better?

• 
• -1
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview