Automotive Metaphors for Lean and Agile Software Development

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...”

Estimating
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.”