Advocates of Lean production and Agile development both want the same thing. What’s different is Agile’s much higher end-user collaboration — which great software requires.
Making software is not like making cars. When you make software you have the opportunity to ask end users for feedback on working pieces of the product as it is still being created — so the software will likely match what customers actually want. But when you make a car you have to wait until the car is finished before you can get user feedback on the actual car, not just on images or descriptions. Yes, it’s possible for customers to go on the automaker’s website or dealer and specify various options — colors, features, and design alternatives. But those options are already listed for you. That’s different than when users give software developers feedback on how to tweak the product while it’s still being worked on.
That’s what Agile’s advocates say software companies should do: leverage customer feedback during development to avoid the waste of making something customers don’t like. Manufacturers (carmakers included) obviously have the same goal; they would just have an issue adopting a method like Agile that requires frequent user feedback during production. Instead, they have adopted Lean, a methodology that optimizes production workflow. But if manufacturers can’t adopt Agile, some software developers have adopted Lean. What they’ve found is that Lean and Agile work much better together.
Two Paths Toward a Common Goal
Given that Lean manufacturing concepts originated in a car company, Toyota, and in the 1940s, it makes sense why Lean did not incorporate the Agile principles that the software industry introduced in the 1990s. Both methodologies were responses to the different needs of their respective industries and eras: one a better way to make things, the other a better way to make software. Yet, both defined success the same way — customers getting what they want with the least amount of waste in the process. Lean optimizes the workflow to achieve a happier customer faster. Agile optimizes the product by asking customers what they want early and often — thus also avoiding misdirection and waste. But because making cars is not like making software — Lean has traditionally left out the “ask customers early and often” part.
But just because Agile may not be practical for Lean car making (or other manufac¬turing), that doesn’t mean it isn’t practical when it comes to Lean software development. (That’s if you already think Lean is a good way to make better software in the first place.) In fact, you can make a case that Lean development really isn’t very Lean without Agile.
How Lean Makes Better Software
One global IT strategy consulting company that proves the case for Lean software development is Capgemini in its iSAP practice. iSAP stands for industrialized SAP. Capgemini is making the logical connection between the industrialized making of things (like cars) and the industrialized application of software, where SAP certainly qualifies. Capgemini’s insight is that for too long the focus of SAP implementations has been on configuring SAP modules — in other words, in creating a “happy” module, rather than a happy customer. With Lean, iSAP is focused on the customer and so has redefined project deliverables in terms of the customer value they bring — “order to cash” or “procure to pay,” for example — rather than as traditionally defined SAP modules, like FI (financial accounting) or GL (general ledger).
iSAP also makes heavy reuse of existing content (e.g., blueprints, configured modules, test scripts) so that it can focus on those relatively few “difference makers” — or the “acceptions” as Capgemini calls them. This is a play on “design by exception,” another key Lean concept. An acception is something that delivers on the customer’s key value proposition, rather than merely provide vanilla SAP functionality.
How Lean Gets Agile
So, if it’s clear how Lean might benefit software development — by making it more about the customer and less about the module — then the connection to Agile should also be clear. Agile answers the question, “How do you focus on the customer?” Agile assumes that customer requirements change as customers see the product develop — which means they need to see the product as it develops. It’s a simple idea: the best way to know what the customer wants is to ask the customer. And the best way for customers to really know what they want is to show them a working product (or at least a working piece of the product). That way, there’s no guessing. Without that collaboration, a lot of waste can happen — exactly what Lean advocates are looking to eliminate.
But Lean also benefits Agile. Take content reuse — a key Lean principle. The more content developers reuse, the less code there is to implement from scratch. That means sprints (coding/review iterations) can be shorter and encompass more of the end product — so users get an even better idea of what the end product will look like. Design by acception is another way Lean makes Agile more Agile. That’s because sprints are more likely to be developing something the customer actually cares about — thereby increasing customer satisfaction faster than if developers were just sprinting along making commodity code.
So not only are Lean and Agile better together, but they work especially well together in an industrial software environment like SAP, which is something of a poster child for long, costly, and highly regimented software projects. Maybe you can’t make cars this way; but SAP proves that you definitely can (and should) make software this way.