RallyDev.com
Mon 22 Jun 2009
Agile and Lean Software Development – an Oxymoron?
I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.
One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.
“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.” Wikipedia’s Etymology for Oxymoron
Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.
Agile as an umbrella term
First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code. It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.
My rendition of the geneology of Software Development Approaches
Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.
I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.
Lean merges with capital-A Agile
I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.
Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)
- Small batch sizes, short cycles that create rhythm
- Reduction in queues through pull
- Reduction in work in process inventory
- Design quality in
- Stop-the-line defect control
- Value streams the link to the customer
- Integrated learning through reflection
- Last responsible moment decision making
These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD. I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me.
What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?
I think that Agile and Lean are strongly related, but that they are two different ideas. Lean aims to achieve efficiency through eliminating waste and respecting people. Agility is a by-product in lean as rapid cycles are required to identify and eliminate waste. Agile software development aims to meet the evolving needs of customers through the early and continuous deployment of valuable software.
The values, principles, and practices of the two approaches are different, even though complementary. If your original position were accurate, then the behavior, activities, and focuses of a “lean consultant” would be a superset of the behavior, activities, and focuses of an “agile development consultant”. I suspect consultants billing themselves as “lean” or “agile” would act differently in general. What have others experienced?
I agree with Kent and see the varied Agile components as complementary. In my training and consulting I present the principles and practices from Lean, Scrum and XP as contributing different dimensions of a complete solution. I posted my summary definitions to achieve this at:
http://www.jconne.com/agile1whatisit/
There are a set of problems around creating software. People have solved some of these problems and wrapped the solution up into a methodologies. It’s likely that these problems have a finite set of solutions. People independently coming to the same solutions rather than representing a concern – represents a better understanding of the underlying problem…or at least a better understanding of how to deal with the underlying problem.
I’m not familiar with Lean though I have been working with Agile for a little while – even if the two were developed on separate planets – I’d say they’d probably still converge. And this point of convergence probably represents some deep truth about how to do software..
I see exactly what you are saying, but what would a Lean Practitioner say to an Agile Practitioner when the Agile practitioner states that the customer should be allowed to introduce changes late in the development process? Both practices do focus on efficiently meeting the customer’s needs, but wouldn’t the concept of welcoming change at every phase reduce leanness?
@Scott Jackson
Lean allows change late in projects just like Agile, in lean projects even more than in agile projects you work feature by feature instead of the phase by phase approach of waterfall. Changing requirements shouldn’t be a problem.
Scott, in a kanban pull process, the backlog can change upto the last moment before the work has started on an item. In that sense I would say that a lean process welcomes change in requirements even more than Scrum.
I would support Kent’s view here. The key principle in agile is acting on customer feedback, whereas lean is more about streamlining the flow. I don’t see why both cannot go hand in hand.
Thanks for the clarification. I am still working with these concepts at a theoretical level. My current work has us locked into a very ordered development process (Waterfall), which in the past has worked well for our customer and the types of products we are developing. The part that kills our current schedules is obviously change, especially in requirements. I am more familiar with the Agile/Scrum methodology then Lean. My point above stems from the fact that Lean strives to reduce waste, but couldn’t waste occur in requirement change with overproduction, extra processing, and waiting?
I definitely see how the two processes are similar and I can see how the concept of “pull” relates to the Agile principles. Not to beat a dead horse, but isn’t the Lean Practitioner’s view of pull different from the Agile Practitioner’s principle of “welcoming change” late in the development process? According to Poppendieck’s Principles of Lean Thinking – “The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.” The bottom line is that with either process, adding value according to the customer’s needs will be the focus of development. If there is a drastic change in “value” that renders previous work as waste, then there are probably bigger issues.
Ryan,
I think it depends on what problem we are trying to solve.
Are we trying to streamline the flow, eliminate waste and remove bottlenecks? Then Lean principles can help.
Are we trying to develop products in an uncertain environment, with unstable and changing requirements? Then Agile principles can help.
Are we trying to do both? Then adapt both principles.
As I see it, Lean and Agile are independent, but can both help from a software delivery standpoint depending on what you are trying to achieve.
Great post, I think Agile and Lean may not be based on the same ideas and principles but certainly on the same sentiments. I’m often amazed at how when applying lean principles to a problem I’ll come to the same conclusion as when approaching the problem in an agile way. In the few cases they lead me to different practices I usually learn something about one or both of them.
Agile is a varied field, you can approach problems looking at many different aspects, management (scrum) quality (tdd) communication (crystal) etc. Lean is a valuable tool to add to this toolbox.
You are trying to compress millions of facts and experiences into a single abstract comparison, this will most likely fail. I prefer to discuss Agile and Lean on their own merit, most people will find the overlap for themselves.
Great comments everyone, Thanks! I am really trying to understand the taxonomy and develop our own theories around these to concepts.
Maybe a multiple choice question would be better than strict advocacy on the concept of “instance?” I did not sell everyone:)
A. Agile and Lean are different/oxymoron
B. Agile is for software teams and Lean is for executives and manufacturing
C. Agile and Lean are both empirical processes, not plan driven
D. Agile is template extension of Lean without the waste elimination and with heavy emphasis on customer feedback
E. Agile is an instance of Lean for Software Development teams (Kanban is Agile and Lean)
Ryan
Great post. I am more closely aligned with Kent’s comment but I don’t think he goes far enough in drawing the distinction. I cant agree with him that one is the subset of the other as IMO they address two orthogonal environments, But let me take a stab at it.
Lean finds it roots in refining known, predictable, and measurable activities. It is easily linked to cost and consumption and has seen many incantations ranging from MTM (manual time and motion) to JIT, Dependent Demand Algorithms and Queue theory. They all work within their strengths and fail terribly when there is little or bad data to work with. They are horrible in trying to do something new.
Agile has come from Emergent Solutions, Complex Adaptive Systems and Chaos theory. In a sense it is closely aligned with exploratory research. It works best with new stuff, having the discipline to frequently review and evaluate the impact and value of the work and then to adjust not only the work but the goal being worked toward. It starts having problems when there is a lot known about the task, there is good data to compare and contrast past efforts with current situations.
It is important to keep in mind that both can work in the other’s area, but why would you consciously pick the wrong one for the what you were doing.
Ryan
F. Agile and Lean are not the same, but are more alike than they are different.
G. You can’t accurately distill complicated concepts like Agile and Lean down to simple multple choice ’soundbyte’ answers.
H. All generalizations are false.
That said, of all the great comments above, I find I agree the most with Kent’s
For those interested in further discussion of this topic, check out the discussion thread in the Agile Alliance LinkedIn group
good blog…. Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.
[...] to me. Many others do to. For example, Ryan Martens recently blogged on the topic at Agile and Lean Software Development – an Oxymoron? However, some of the experts comments he received back were not so [...]