Automotive Metaphors for Lean and Agile Software Development

May 8, 2013

I read a lot, and as I’ve read various books on lean and agile topics I’ve noticed some authors occasionally using automotive metaphors or examples that are useful in making their point. While these don’t cover all the nuances of lean and agile development, I thought it would be nice to compile my notes in one place – and perhaps I’ll and some visuals and weave this approach into my courses that I’m developing as well!

Delighting the Customer
Lean and agile development is all about flowing value to the customer. The first principle of the Agile Manifesto states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

How do we satisfy (or as Steve Denning says, delight) the customer? In a way that is profitable and competitive? Richard Rumelt provides this guidance in Good Strategy Bad Strategy: The Difference and Why It Matters:

“Form an image in your mind of the BMW’s driver; see her taking the curves on the winding Angeles Crest Highway. Look at her face and imagine sensing her pleasure or displeasure with the automobile.

“Now, begin to vary the design. Make the car bigger, quieter, a bit less responsive but more powerful, heavier. Now, lighter, quicker, more responsive. To do so, you have to change the chassis, the engine weight and torque, the suspension, the steering assembly, and more. It will sway less and hug the road; the steering wheel will provide more tactile feedback. Now adjust the chassis: make it stiffer to dampen longitudinal twist and soften the front suspension just a bit to reduce road shock. Varying forty or fifty parameters, you will eventually find a sweet spot, where everything works together. She will smile and like her car.

“But there is more. Her driving pleasure depends upon the price paid, so we begin to include cost in our design. We concentrate on her smile per dollar. Many more interactions must be considered to find the sweet spot that gives the largest smile per dollar.

“You cannot search the entire space of possibilities; it is too complex. But you can probably, with effort, produce a good configuration. To get more sophisticated, you should also include the pleasure the driver takes in buying a premium brand, backed up by image advertising and swank dealers. You should also consider her buying experience and the car’s expected reliability and resale value. More design elements to adjust, more interactions to consider. And then, of course, you should consider other drivers with other tastes and incomes, a huge step upward in complexity and interaction.

“Yes, we went beyond product to include manufacturing and distribution in the design, but our strategy was tuned to please the customer, not to deal with competition.

“To deal with competition, expand your vision again to include other automobile companies. Now you are looking for a competitive sweet spot. You have to adjust the design—the strategy—to put more smile per dollar on a driver’s face than she can get from competing products.”

Vision and Planning
One benefit of lean and agile development is unlocking the potential of people. A shared vision provides a means to energize people and provide direction. Peter Senge discusses the importance of a shared vision in his book The Fifth Discipline: The Art & Practice of The Learning Organization:

“A shared vision, especially one that is intrinsic, uplifts people’s aspirations. Work becomes part of pursuing a larger purpose embodied in the organizations’ products or services—accelerating learning through personal computers, bringing the world into communication through universal telephone service, or promoting freedom of movement through the personal automobile.”(Italics mine)

In addition, while small companies tend to travel down one road, they may need more options – new highways – as they begin to grow. Michael E. McGrath shares his perspective in Product Strategy for High Technology Companies:

“A rapid-growth company is more aggressive, but it doesn't travel just one highway. Instead, it invests in a broad portfolio of product development projects. It invests in some of the highways for growth identified in the proactive process, but it also continues to invest in maintaining the competitive position of its current product offerings. The increased investment in R&D pays off once the company begins growing rapidly.

“A stronger competitive position can sometimes be a highway to growth, but frequently the result is an increase in revenue. Adding improvements that make products better than those of competitors is always a good defensive strategy, and may be necessary to keep competitors from taking away market share.

“In a new, rapidly growing market, a winning and sustainable vector of differentiation will provide a highway to growth. By continually focusing on improving its products along its vector of differentiation, an integrated customer solution, SAP grew rapidly from 367 million DM in 1989 to 8.5 billion DM in 1998. The key to such growth is the ability to sustain the “competitive advantage of a successful vector of differentiation. Once this advantage is lost, then it ceases to be a growth highway even in a growing market...”

In their book Rework, Jason Fried and David Heinemeier Hansson state what is solidly recognized in lean and agile circles: “We’re all terrible estimators. We think we can guess how long something will take, when we really have no idea.”

They continue, talking about how we can underestimate simple things like how long a trip to the grocery store will take and pointing out just how far off we can be at times: “Plus, we’re not just a little bit wrong when we guess how long something will take—we’re a lot wrong. That means if you’re guessing six months, you might be way off: We’re not talking seven months instead of six; we’re talking one year instead of six months.

“That’s why Boston’s “Big Dig” highway project finished five years late and billions over budget…”

Capacity and Flow
As experienced lean and agile practitioners understand, planning to utilize “resources” (people) at 100% capacity is a BAD PLAN because flow will be impacted. In his book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Dean Leffingwell urges us to “Think of a highway system at rush hour.”

He states that “…when a system is loaded to capacity, it can become unstable, and the problem is compounded. In heavily loaded systems, larger batches move disproportionately slower (throughput decreases) through the system. “(Or highway in the case of the automotive metaphor.)

What we need something to deal with the variability that we inevitably encounter in software projects. Tonianne DeMaria Barry and Jim Benson cover this in their book, Personal Kanban: Mapping Work | Navigating Life:

“Consider what makes the roadway flow. Is it the cars, or the space between the cars? If there were no cars, there would be nothing to flow. If there was no space, the cars could not move. It’s that balance between cars and open space that gives us flowing traffic. That open space is called ‘slack.’ We need slack in our workflow, we need space to adjust. Without slack, we will overload.”

Oversight and Governance
Lean and agile oversight and governance is done with a light touch. We want as much self-management as possible, not constrictive control. But there are boundaries that need to be drawn. While we want to promote freedom of movement, we want to ensure safety, much like a speed limit sign does. (Provided people follow the speed limit.)

Richard Rumelt, in Good Strategy Bad Strategy: The Difference and Why It Matters, advises us to implement frameworks and policies that act “Like the guardrails on a highway, the guiding policy directs and constrains action without fully defining its content.” (Scrum is a great example of a framework that guides teams without being overly prescriptive.)

And we do need to take care about the boundaries that we draw, as Donella H. Meadows cautions us in Thinking in Systems: A Primer:

“When you draw boundaries too narrowly, the system surprises you. For example, if you try to deal with urban traffic problems without thinking about settlement patterns, you build highways, which attract housing developments along their whole length. Those households, in turn, put more cars on the highways, which then become just as clogged as before.”

Progress and Metrics
When driving a car, progress is a measure of how far down the road you have traveled, just as “Working software is the primary measure of progress,” as one of the principles of the Agile Manifesto states. The act of driving a car involves – as Tonianne DeMaria Barry and Jim Benson state in Personal Kanban: Mapping Work | Navigating Life – a combination of things:

“Situational knowledge is seeing the road, metrics are the gas gauge. Visualizing work combined with metrics provides a full understanding of the current situation.”

The point is excellent. We don’t blindly follow our gauges alone when we drive, do we? Yet we tend to rely on metrics alone to “drive” our companies. Josh Linkner points out this problem in his book, Disciplined Dreaming: A Proven System to Drive Breakthrough Creativity:

“We use complex models, historical data, and buzzwords like ‘key performance indicators’ and ‘balanced scorecards.’ Like dashboard instruments, these tools are great, but they're not the one-and-only factor in creating success. We hire team members for their judgment and creativity, but often relegate them to merely following systems mechanically.”

(I have to confess Josh’s metaphor was actually one of flying a plane, but I took a little liberty to pull this into the mix, since he makes a great point.)

Commitment and Competence
When agile software teams make an iteration or sprint commitment, teams need the desire and ability to execute and realize that commitment. James Flaherty gives us this perspective in his book, Coaching: Evoking Excellence in Others,3rd Edition:

“I think of commitment as if it were the engine of a car. It doesn’t matter how powerful the engine is, or how well tuned up it is, or how much gasoline it is getting if it is not connected to the wheels by the transmission. The transmission is a metaphor for competence. This competence takes many forms: sometimes it is skill, as in learning how to fly a plane; sometimes it’s a capacity to observe ourselves and not become defeated by negative emotions or self-assessments.”

And what if a software team isn’t meeting the needs of the business? There are a lot of drivers here, covered at a high level in the Agile Manifesto. Sometimes the easy answer isn’t always the right answer, as Dean Leffingwell points out in Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise:

“And although it’s true that we want to absolutely need to create product flow, where input does match output, we can’t simply achieve flow by just ‘backing off the accelerator,’ or fewer cars will do down the freeway than it has capacity for. Yes, it’s flowing, but it’s too slow. Rather, we want to accelerate to the point of most efficient productivity, the point just below which congestion (in this case as witnessed by a combination of overloaded, multiplexed teams and badly matched expectations) occurs.

So, it could be that you need more capacity (another team), but teams also owe the business to be as finely tuned and efficient as possible, hence the reason for a couple of other principles in the Agile Manifesto:
  • “Continuous attention to technical excellence and good design enhances agility.”
  • “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
In effect, we are regularly tuning the engine while driving. But that is where effective – and real – learning takes place, as James Flaherty tells us in Coaching: Evoking Excellence in Others,3rd Edition:

“No one can learn to drive a car simply by learning the language of automobiles and traffic laws. After learning that language we must get behind the wheel, spending many hours practicing driving. It’s only by this continual, focused, intentional practice that we become competent drivers.”

Adaptability and Flexibility
The final word comes from Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, advising management to move “from ‘our way or the highway’ to flexibility.”


That highway metaphor reminds me of the concept of hysteresis. It means a system's state depends on its history. If you push a system beyond its limits, it will take some time to recover.

This is likely something that applies for software teams as well. If you push a team beyond its limits, even momentarily, it will yield a reduced output till it has recovered. Kind of reminds me of your post about crunch time and its effects. :)

May 9, 2013 at 2:14 AM
Dave Moran said...


Yes, as you note pushing a system beyond its limits (such as working overtime for too long or forgoing vacations) will require recovery time. In addition to the "crunch time" post, I provided a similar perspective last August in a post, Take a Rest and Boost Your Productivity

May 12, 2013 at 9:01 AM
Mitchelle Garry said...

Thanks for a this great post. Software Development seems so complicated to me before but when I started working for the company where I am in now, I was forced to learn and blogs like yours helped me widen my understanding a lot.

May 17, 2013 at 5:11 AM
Dave Moran said...


Thanks for compliment! And keep reading!

-- Dave

May 21, 2013 at 8:24 PM

Awe-inspiring bequest! Your blog is attention-grabbing. I feel affection for it.

July 4, 2013 at 2:55 AM
Dave Moran said...

@MAC Address Software, Thank you very much!

July 17, 2013 at 1:10 PM
Barb Dwyere said...
This comment has been removed by a blog administrator. July 20, 2013 at 2:51 AM
Keith S said...

Lean and agile both are good and different method. There is many difference between book reading and real time experience. Book reading can only give you Information about agile and lean, Experience can learn you about programing.

February 4, 2014 at 2:20 AM
hozy cat said...

You just have so many guts to go ahead and tell it like it is. A very nice informational blog. Keep on making such important blog post. That’s nice and useful blog site for all thanks.
Software development

February 8, 2014 at 7:14 AM
Dave Moran said...

@Keith S -- Lean and agile are different, but related. Agile is built on a foundation of lean. Both support continuous improvement, which means we need to continually learn and apply that learning along with reflecting on what is working and not working in our unique circumstances. The same with programming.

@Hozy cat -- Thanks!

February 16, 2014 at 6:01 PM
Nancy Carter said...

Thanks for this post. It is informative article post. you can get software development services from

March 10, 2014 at 3:34 AM
sanam arzoo said...

I really love reading and following your post as I find them extremely informative and interesting. This post is equally informative as well as interesting . Thank you for information you been putting on making your site such an interesting. I gave something for my information. Software Development Company

April 8, 2014 at 4:07 AM
Howard Henry said...

Thanks for this wonderful sharing i found this blog very informative and interesting. It today's world agile system development very famous among big organizations. These teams are more productive than teams using traditional methods throughout the development cycle. It provides numerous benefits to organizations, project teams, and products.

April 14, 2014 at 4:45 AM

Post a Comment