The Blending Philosophies of Lean and Agile

Publish date:

Some management philosophies should not be mixed. Because the unique flavor of the ingredients will get lost in the mix. As well as the benefits. Lean is a powerful but typical mindset (see The Power of Lean Thinking). But does that automatically imply that it cannot be combined? I believe not. I believe that Agile […]

Some management philosophies should not be mixed. Because the unique flavor of the ingredients will get lost in the mix. As well as the benefits.

Lean is a powerful but typical mindset (see The Power of Lean Thinking). But does that automatically imply that it cannot be combined? I believe not. I believe that Agile thinking, principles and methods are more than just aligned with Lean. I am convinced that Lean and Agile are blending philosophies.

In general, companies and customers refer to organizational problems when expressing the desire ‘to be Lean’. And if they want ‘to be Agile’, they are probably talking about software development. Hoping for some magical, off-the-shelf implementation of thé one-and-only (silver bullet?) Agile solution to all their problems.

Responding that “Agile as such does not exist” may be a good start in explaining that Agile is a way of thinking and that a transformation beyond the borders of the software development department is required for real and lasting benefits. An entire organization will prosper from adopting the Agile mindset of empiricism and adaptiveness. Frequent Inspect & Adapt cycles will challenge every status quo and assure continuous learning while active Business Involvement optimizes Business Value in turbulent enterprise, business and market circumstances. Software development in particular is finally acknowledged as a creative and complex activity by and for People. And Agile allows to finally stop trying to predict the unpredictable, as its practices incorporate dealing with answers, solutions and competing ideas that emerge while building software.

An evolutionary approach to software development is not new. Craig Larman has extensively described the historical predecessors of Agile in his book “Agile & Iterative Development – A Manager’s Guide”. But the label ‘Agile’ itself dates from early 2001, when 17 software development leaders gathered at the Snowbird ski resort in Utah. They assembled to discuss their views on software development in times that there was a tendency to replace failing traditional (waterfall) approaches with heavy-weight RUP implementations. In times that these leaders were doing things quite differently with methods like Scrum, eXtreme Programming, Adaptive Software Development, Crystal, Feature Driven Development, DSDM, etc.

The gathering resulted in assigning the label ‘Agile’ to the common principles, beliefs and thinking of these leaders and methods. They were published as the Agile Manifesto.

Definition of Agile?

Fortunately, ‘Agile’ is more tangible than the thinking tools, the origin of the word and the Agile Manifesto suggest. I describe Agile by following key characteristics:

  • Business-People. Agile is not driven by a predictive plan, but by Business involvement and priorities. People are respected for their creativity, intelligence and self-organizing capabilities to understand and resolve a problem without tons of ceremony;
  • Facilitation. Agile Teams are facilitated by servant-leadership management with overall objectives and a context of subtle control, rather than being assigned on a daily base to executable micro-tasks in a command-and-control style;
  • Iterative-Incremental. Agile processes are defined and require high discipline to build products piece by piece (incremental), while frequently revisiting built pieces (iterative) to expand, improve and adapt them and assuring the overall integrity;
  • Success and Progress are measured upon actual Business Value of Working Software at the end of every timeboxed iteration. Not by compliancy with predictive plans, milestones, documents, hand-overs, signatures, approvals or other ceremonies;
  • Change. New or evolving opinions and priorities are at the heart of an Agile process. Such Emerging Requirements are not disruptive, and what was known as ‘change’ has been… evaporated.

Agile processes mitigate risk and deliver Value by slicing the time in timeboxed iterations with working builds of negotiated software at the end of every iteration.

Agile still requires the application of all normal IT activities (Analysis, Design, Coding and Testing). But in Agile these activities are fundamentally re-organized. They are performed in an incremental and parallel way on a daily basis. The goal of such integrated, cross-functional approach is Built-in Quality and prevention of defects, rather than attempting to establish quality in a post-process stage. Knowing that lacking quality cannot be added to a finished product. Not to speak of delays and budget increases.

Blending Philosophies

Beyond the clear similarities in Lean and Agile thinking, Agile has distinct practices that match the main Lean principles.

There are no less than 3 major approaches to Eliminate Waste:

  1. Potentially unused inventories of requirements, hard-coded plans, designs, etc. are not produced upfront. No more than the next, highest priority work is detailed appropriately. A Team will Pull in the amount of highest priority work they deem feasible for an iteration, commit to it and start delivering it using techniques for progressive learning and continuous improvement.
  2. Partially done work, another important type of waste, won’t pile up as the goal of an iteration is to produce a working increment of product. No undone work is included at the end of an iteration. The overall Kaizen thinking, and its explicit daily Inspect & Adapt implementation, mostly a stand-up meeting, prevents taking up new work while undone work remains in the iteration.
  3. Active Business Involvement prevents the production of unwanted or invaluable requirements. Because only 20% of product functions are regularly used, this represents an enormous waste of effort and budget. It is highly disrespectful that people should spend their time on it. But, as only work pulled into an iteration is expected to remain stable, Business can continuously adapt to Value expectations and make gigantic savings.

A Shared Visual Workspace facilitates fast decisions, high interaction and short communication lines, but will also contain Information Radiators. Task Board, Team definitions, agreements and process artifacts like Backlogs and Burndown graphs are made visible. Preferably even posted on the room walls. Agile Teams post this information to share it and use it to inspect and adapt. This transparency, unfortunately, can be abused. Regularly, in a situation where progress is less than expected or hoped for, commitment is forced into a contract. This undermines the foundation to being Agile. And specifically it will cause an infringement on Sustainable Pace. Thus endangering product quality.

In order to Deliver Fast every iteration is timeboxed and at the end of every iteration only usable, working software is shown, holding the promise to launch it ‘as is’ into production. The software is reviewed with all stakeholders in order to gather feedback, remarks, improvements and enhancements. On top of this product inspection, an Agile Team will hold a retrospective meeting to look for other improvements that will be introduced in the next iteration. This does however not impede a Stop the line call of each Team member during the iteration.

Agile implements Optimizing The Whole by demanding that Business prepares and prioritizes work, and takes active part in the technical build process. But it is also required that all skills are onsite available to turn ideas, options and requirements into working software in an iteration. This automatically optimizes the Value Stream because traditional waiting activities like hand-overs and external decisions are eliminated. There are no macro hand-overs typical to a sequential organization in large blocks of work packages, but also no micro hand-overs within the collectively responsible Team. And, finally, the cross-functional eco-system includes a process master/mentor who will act as a Manager-teacher, i.e. manages the process (not the people), teaches the people and facilitates the Team by removing impediments.

Related Posts


Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...


Architecting the ecosystem: Five challenges for 2020 and beyond

Date icon April 8, 2020

Being agile, both in business and technology, is rapidly becoming the standard.


Industrial and agile: How to be both?

Arnaud Balssa
Date icon February 27, 2020

Distributed Agile allows companies to benefit not only from Agile methods, but also from the...