Ative at Work

Agile software development

Ative at Work

Lean Software Development

Today the lean meme is in every business newspaper. It has been a long time coming. Some companies like Toyota have lived these principles since the 1950s when their lack of capital forced them to improve their production processes radically. In the West it appeared on the radar with the books by Womack & Jones published from 1990 and onwards. Now, the ideas have gained mainstream mindshare and are being applied in many fields. Applied to software development “lean” provides a great toolbox of agile methods to help radically improve development efficiency.

Deliver High Customer Value Quickly at Low Cost

The lean starting point is to optimize the production from a customer-centric perspective. The goal is to provide the customer with maximum value quickly and at a low cost. Therefore the first step is to define the value of the product (or features) from the customer’s perspective. Translated to Scrum this is the job of the Product Owner.

Eliminate Waste

The central point of lean is to eliminate "muda", or waste. Muda is defined as all the activities and steps in a production process that add no value to the customer. In software, examples are work-in-progress, defects, features that are not necessary, the bureaucratic hindrances in traditional software development organizations and all the stuff and over-generalizations that developers love to do (“we might need it later”) even when a much simpler solution will suffice.

Since there is so much waste a typical lean transition begins by mapping the value stream for the complete production process from the customer's perspective. Then we reduce it to only the steps that add value to the customer. This is usually a very small subset.

Introduce Single-Piece Flow

Once we know the steps we organize the remaining steps into the best sequence and introducing “single-piece flow”: completing the production of a whole but small product in one continuous sequence with no delays.

Use Pull Scheduling

At the integration points between the single-piece flow “cells” the lean method of scheduling is using “pull”. When a downstream consumer is ready for processing a new part it requests it from its upstream supplier. This makes scheduling very simple. There is no inventory to keep or partially made items to track. The synchronization mechanism is simply to keep everyone working in the same “takt time”, producing new stuff at just the rate it is needed. Therefore no waiting occurs. This is a simple way to optimize the throughput without complex planning systems.

Improve The Process Continuously
After the initial radical reengineering of the production process we continuously focus on improving the process as we learn and innovate, so that the effort and time do the work keeps falling. This produces a virtuous cycle. In the words of Womack & Jones lean is a method to do more and more with less and less.

Stop-the-Line Root Cause Problem Fixing

A lean process stops when there is a problem and it does not restart until the root cause of the problem has been fixed.

One of the legendary lean examples of this is when Toyota took control of the NUMMI car factory in the USA. The US tradition was to let defects slip and fix them in QA later. Instead, Toyota simply it told the workers to do good work and stop the assembly line when they could do their work properly.

It took about month to produce the first vehicle.

Since then, however their quality and productivity has been outstanding and they have earned an impressive number of awards.

To teach people the stop-the-line culture Taiichi Ohno of Toyota used the principle of “five whys”. When we encounter a problem we ask why five times to unveil the true root cause of the problem rather than just treating the symptoms. In software you see that very good operations people have a natural tendency to do this, while most developers faced with the same problem tend to just advice to “restart the server” or some other fix that does not unveil the nature of the problem or prevent it from reoccurring. The stop-the-line practice improves quality - while the other just accepts low quality without fixing it. One of the central lessons of lean is that you have to improve quality to go faster so by continuously removing the root causes of problems we also improve the efficiency of the entire production system. In fact, from a customer perspective testing to find defects is a “muda” whereas testing to prevent defects from occurring is not. In software terms this makes the case for test-driven development and identifies test-later as an expensive, wasteful practice.

In the coming months we will explore lean and its applications to software development in this blog. Until then - Happy New Year and keep the comments coming. We really appreciate your participation.

Further Reading

  • Taiichi Ohno - one of the greatest industrial innovators of the 20th century, the father of the Toyota Production System. After spending his career relentlessly optimizing manufacturing at Toyota he wrote the book Toyota Production System: Beyond Large-scale Production that describes his work.
  • Womack & Jones - Their books are great and it is well worth to read them all to see a lot of the principles and case studies for lean thinking. Also, it is quite interesting to see that software development is now rediscovering some of the things that manufacturing learned much earlier - in the case of Toyota as early as in the 1950s and 1960s. Begin your studies with The Machine That Changed the World, a five-year study of the global auto industry from MIT and go on with the Lean Thinking and Lean Solutions. They give a fascinating perspective on manufacturing and plenty of examples of the lean principles and they applications. 
  • Mary and Tom Poppendieck - with a background in manufacturing and software they have translated the concepts of lean to software development. They have written two great books and Implementing Lean Software Development and Lean Software Development - an Agile Toolkit. Both books are well worth reading a present a both the principles and lot of cases in a friendly, colloquial manner. Mary Poppendieck is a frequent conference speaker. We saw her giving some very impressive lectures at Agile 2006 ( and there is plenty of opportunity to see her on the conference circuit. Highly recommended!

Updated January 11, 2007: fixed grammar and typos.

Published jan 08 2007, 09:06 by Martin Jul
Filed under: ,



Mark Seemann said:

This post, like many of your other agile posts, made me wonder about a thing: How would you apply these organisational changes when the software project deals with a fixed price project in response to a large public tender?

In all my career, this has been the most common form of software project, and for large-scale projects, I predict that this will be the case for many more years.

The challenge arises from what I perceive as a contradiction between this project model and the agile/lean methodology of putting customer value in focus. It seems that all the points you make in this article hinges on mindset of adressing customer value first and foremost. It also presupposes that value can somehow be ranked, so that you can prioritize most valuable features highest.

If you ask a customer behind a public tender about value, you will quickly discover that features have a binary value: If it's part of the tender's requirements, its value is positive infinity (the project delivery cannot be accepted without this feature). If it's not a requirement, in terms of this kind of project, its value is zero. (I'm simplifying a bit here, but you I hope you get the point.)

The typical response I get from other agilists is that the customer needs to be re-educated, but that is a bit of an arrogant attitude, and even if it's right (which it may be), it's not very realistic, if nothing else, then for legal reasons.

Now, you don't have to convince ME that agile methods may be better, and it's not even that I can't convince development organizations that agile principles may be beneficial - it's just that it's so darn hard to apply these principles when you have a completely unyielding customer at the other end of the table.

BTW: On a completely different matter, can you please turn on full postings in your feed again? A couple of posts ago, your feed changed to contain only excerpts, which forces me to go to your site every time I need to read the full article. It kind of defeats the purpose of syndication...

januar 8, 2007 10:56

Jan Daniel Andersen said:

- > Mark: I'm pretty sure you agree with me, but I just felt like claryfying.

In my oppinion, value (requirements) most certainly CAN be ranked. Imagine that you're building a car for your customer:

1. Requirement: Brakes.

2. Requirement: Must have top speed at 200mph.

Now I would argue that req. 1 has a higher value than req. 2. It would be intolerably dangerous to have a car going 200mph, without brakes. The opposite is not as much so. In a way you can say that to implement req 2 you need to have req 1 in place, which is some kind of ranking. The car would work safely without req. 2, but would never be allowed to hit the streets without req. 1.

This might not be the best of examples, but I hope you get the idea. I'm not saying that it's easy to convince a customer about prioritizing requirements in a real world situation, I'm just saying that it's a very good practice.

I really don't believe in the old ideas of "Every requirement should be in place, in time and at the exact right quality". Oh well .. maybe if you only have 2 simple requirements, it would probably be possible :-). We SHOULD use the knowledge gained throughout the development process to adjust what it is we're doing, therefore it's is VERY practical to prioritize.

BTW: Excelent post, I haven't gotten around to reading those books yet, but they most certainly are on my To-Read list!

januar 10, 2007 12:28

Mark Seemann said:

Hi Jan

In fact, I find your example quite reasonable as a metaphor, and I do agree that requirements often CAN be ranked. However, that doesn't mean that the customer is willing to do so.

This may not even stem from bad will. Large, fixed-price projects are often a result of specification by committee, and concensus about ranking can be virtually impossible to achieve (even reaching a concensus about the requirements in the first place is often a difficult process).

You could argue that the whole concept of large fixed-price projects is flawed, and that customers should adopt an agile mindset as well, but that's probably not going to happen overnight.

It seems to me that if a development organization wants to be agile under such circumstances, it must abandon the idea of the customer as an active, cooperating participant. Since customer value is still an indispensable component of the agile mindset, one or more persons in the development organization must assume the role of the customer's advocate internally in the organization. Interestingly enough, this corresponds very closesly to MSF's Product Manager role.

januar 10, 2007 1:53

Martin Jul said:


"agile under fixed-price contracts" is a great subject for a bigger post. Thanks. Maybe we will get back to that.

Anyway, for now, there is a useful technique called "exchange requests" that allows the customer to be somewhat agile inside a fixed-price contract, namely by developing the application iteratively and allowing the customer to exchange backlog items for new backlog items of the same size. This way, the customer gets the benefit to change priorities about stuff that has not been implemented yet - even put in completelyu new features to replace all the low-priority stuff at the bottom of the pile.

You will find an article about it here:

januar 11, 2007 12:51

Jan Daniel Andersen said:

I agree with you Mark. The customer might not be willing to work in an agile way and he might also be adamant on doing a fixed price project.

BUT, I doubt that we can deny the "fact" that requirements DO change and also that requirement SHOULD change. I think that it is our job, as Software Professionals to tell our customers this. If we can agree with our customers, that these are indeed facts, then we can begin to talk about how to handle them. Agile methods are all about handling these two facts.

If the customer won't agree, then at least we told him that the project in danger, long before that problems start appearing. But come on, who, in their right mind, would say that they know EXACTLY (every requirements) what their buisness needs for the next couple of years ? Agile methods will, if applied correctly, give the client exactly what they need, but without the upfront knowledge.

I think that the agilists have a good case, when trying to convince customers not to do the big upfront requirements analysis. In most cases, some compromise, can be found.

I really do think that the idea of "fixed price projects" is indeed flawed, because you need devine insight, to be able to get everything right upfront. And you cannot calculate the price of an unknown amount of work. "Price-ranged" projects however, are very compatible with agile methods. In my experience, it's not that hard to convince the customer to go with a price estimate instead of a fixed price, expecially, when they have the option to stop the project, whenever he want and still get real value for his money.

The "fact" that requirements do and should change over time are as fundamental to me as Newtons 3rd. :-)

januar 11, 2007 11:45

Mark Seemann said:

This has been quite an interesting discussion, which has prompted me to think a bit about these things, as well as reaching some interim conclusions:

1. Large, fixed price projects are not going to go away any time soon, particularly from public customers in the EU, since it's the LAW that even moderately sized projects must invite tenders.

2. The whole agile principle about actively involving the customer suddenly strikes me as constraining the development process model to enterprise development only. ISVs have no (direct) customer with whom they can interact about the next product milestone. Again, the most apparent solution is to include a customer advocate, such as the Product Manager role from MSF.

januar 11, 2007 1:48

Frederic Gos said:

I once attented a seminar about agile development held by Craig Larmann. He said something that really sounded good to me. Instead og trying to get the customer to rank the features, ask them to put a business value on the features. What is feature X worth for the customer in terms of money? I haven't tried it but it might make more sense to the custiomer and maybe even give them some insight in how hard it is to estimate anything. So, when the customer asks? 'How long would it take to build X'? Throw it back at them and start by asking, 'What is the business value for you company'?

januar 12, 2007 10:35

Jan Daniel Andersen said:

There are well documented method for doing fixed-price-projects in an agile way. I cannot find the refference right now, but it shouldn't be hard to find. The Scrum method suggests that we calculate the totalt cost of all deliveries (weekly, monthly or whatever is agreed upon), and give that as the price quote on fixed price projects.

But it also says that the project can be terminated prematurely, when the client deems that he has what he needs. this is ofcourse possible due to the agile dictum of "Deliver working software often", which means that each deliverable is a fully functional subset of all the defined features for the project.

Therefore i think it IS very possible to do agile pitches on big projects.

With regards ISV going agile, and the customer role, this is also well defined within the Agile world. Jim Coplien has written a exellent book called "Organizational Patterns of Agile Software Development", which has a pattern called "Customer Proxy", which deals with this situation. I'm guessing it is kind of the same thing af the Product Manager of the MSF.

I will agree, that it requires some amount of work and dialog to get this to work, but I'm confident, that it is possible to do agile projects with most (if not all) kinds of customers.

januar 15, 2007 11:23

Jan Daniel Andersen said:

Here's a good article, that addresses, some of the issues, pressented in this discussion.

januar 15, 2007 12:03

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS