Favored development methods in numerous fields and industries, Agile and Lean are both flexible, quick and end-user-focused philosophies that help teams develop and produce high-quality products and services quickly and sustainably. Both methods have the goal of providing clients with a high-quality product rapidly, one iteration at a time. However, understanding the meaning of Agile vs Lean can cause confusion for practitioners.

Because they share common goals and principles, Agile and Lean are easily confused. Many teams practicing either Lean or Agile methods don’t have as clear an understanding as they should.

In fact, practitioners of both methods often use the terms synonymously when describing common practices. To make things even more complicated, many companies adopt a Lean framework when trying to scale Agile across the organization. Are you confused yet?

Here’s why it matters: Although any Agile or Lean influence is a good influence, these methodologies are most effective when applied holistically. Because modern Agile and Lean implementations are as philosophical as they are practical, failure to understand the principles behind them fully can lead to shallow implementations that ultimately do not lead to the kinds of outcomes Lean and Agile teams strive to achieve.

Having a clear understanding of Agile and Lean can ensure that teams adopt the principles and accompanying practices of their selected methodology fully, so that they can establish a solid foundation for a mature Agile or Lean implementation. Once this is accomplished across teams, organizations can consider a more advanced hybrid scaled Agile and Lean approach that will allow them to enjoy the practical and cultural benefits of the two methodologies. But first, let’s seek to understand the differences between them.

•

Lean and Agile Metrics: Oh, my!

Learn how you can manage WIP limits, size features, view velocity, burndown and so much more with the Planview Agile Program Management solution.

Titta på webinar • Lean- och Agile-mätvärden

Agile vs Lean: A Brief History

Understanding the differences between the histories of Agile and Lean can provide clarity about what makes each methodology unique. Here are the brief histories of how these methodologies got started in their respective industries, and how they evolved over time to become more broadly applicable as they are today.

Lean thinking

Lean principles took root in the 1950s with Toyota automobile manufacturing in Japan. Driven by a need to reduce inventory costs and improve efficiency in auto manufacturing, Taiichi Ohno developed a system known as the Toyota Production System (TPS). Inspired by the systems used to manage inventory in grocery stores, the system used visual signals to indicate inventory needs precisely when items were needed, reduce overall waste and optimize the entire system of production.

TPS took Toyota to new heights, and soon, Japanese auto manufacturers were running their Western manufacturers out of business. The Western companies had two options: Trim down or shut down. They began adopting the practices of Japanese companies (referring to the practices collectively as Lean) to improve their speed, productivity, and cost efficiency to remain competitive.

During this time, Lean thinking was boiled down to overly simplistic ideas, generally used to justify relentless cost cutting. Western implementations demonstrated a lack of understanding of the management philosophies behind TPS that had made it a sustainable and effective solution for Toyota and other Japanese companies. Although this version of Lean thinking helped Western manufacturers remain competitive, it created new problems – employee turnover and quality issues, to name two – that helped Japanese manufacturers maintain their dominance for years to follow.

In an effort to out-perform competitors, many variations of Lean methodology were born in the years following, including Total Quality Management, Just-in-Time, Six Sigma, and the Theory of Constraints. Each of these movements incorporated various practices from what the Japanese businesses were doing that differentiated them from their competition. Many of these popular “Lean” management frameworks were highly prescriptive by nature and required considerable training to adopt fully, making them difficult to implement, especially for teams outside of manufacturing.

In their books, The Machine that Changed the World and Lean Thinking, Jim Womack and Dan Jones helped us elevate our understanding of Lean thinking, allowing us to move from mimicking Toyota practices to truly understanding the principles that made the Toyota system work. Approaching Lean as a set of guiding principles, rather than a specific set of prescriptive practices, made implementation easier, more flexible, and more sustainable, and therefore better suited for application across an entire organization.

Agile

Necessity is the mother of invention – such was the case for Agile. In the 1980s and 90s, computer programmers were using traditional manufacturing methods, such as the Waterfall approach, to manage their development work. They spent months to years developing one product, releasing it when it was finished, only to find that it had already become outdated by the time it hit the market.

Their processes were not only slow, they were expensive: The software they developed was often too costly to justify their relatively short lifecycles. The rapidly-evolving needs of new software for businesses, coupled with the specialized skillsets and amount of time and effort it takes to deliver software, had driven up the cost of software development so much that the industry (and the leaders within it) had hit a breaking point: They had to find a better way to plan, develop, and release products so that they could meet the needs of their market.

Agile was designed for software development teams as a time-focused, iterative way of achieving continuous value delivery.

The seeds of Agile were planted decades ago, but many view a historic meeting of 17 developers at the Snowbird resort in Utah in 2001 as the beginning of modern Agile. The developers were looking for a way to define the new lightweight practices that were emerging to evolve away from the heavyweight, regimented, regulated practices that had plagued early software development.

It was during this meeting that the Agile Manifesto was written. The manifesto outlines 12 principles that have guided the practice of Agile throughout recent decades. Although these principles were written for software development, the ideas behind them are applicable to nearly all project-driven work.

Agile vs Lean: The Differences

Approach to speed and iteration

Agile aims to deliver working software as quickly as possible. Frequent software / product delivery (rather than delivering large batches) allows teams to quickly utilize any feedback from customers when making changes to upcoming work.

This is very similar to the Lean principle of Deliver Fast: The idea is that the quicker a team can deliver value to a customer, the sooner they can learn from their feedback. The difference is that in Lean thinking, teams increase speed by managing flow (usually by limiting work-in-process), whereas in Agile, teams emphasize small batch sizes to deliver quickly (often in sprints).

Method for putting customers first

Both Agile and Lean thinking prioritize customer satisfaction as a primary goal. Agile teams accomplish this by focusing on open communication between end-users / customers and developers.

Agile’s iterative approach encourages constant feedback and allows for changing requirements over time, even in the late stages of development.

Lean teams put customers first by focusing on building and improving processes that allow them to do just that; eliminating waste (by the Lean definition) is a key part of that. Basically, if a customer wouldn’t pay for it, it’s waste: Context-switching, too much work in progress, and manual completion of a task (when it can be automated) are all considered waste in Lean thinking. While Lean teams also aim to let the voice of the customer drive decision-making, they put equal emphasis on streamlining their processes as a way of putting their customers first.

Role of discipline

Although far less regimented than its predecessors, most Agile implementations are still much more structured than Lean practices. They rely on:

  • Defined roles
  • Structured meetings
  • Estimation techniques
  • Systematic reviews

and other disciplined project management practices to ensure that the system works. Although shared principles are important to Agile implementations, a disciplined process is what allows Agile teams to move and adapt to change quickly.

Lean thinking also relies on discipline, but in a different way. Successful Lean implementations are typically those in which Lean principles and Lean thinking have become a part of an organization’s culture. Therefore, discipline in Lean is less about upholding external expectations and rules, and more about each individual and team buying into and upholding the same Lean principles, which allow the system to operate smoothly and efficiently.

At the end of day, Lean principles are rooted in respect: Respect for the customer, respect for fellow employees, respect for the current and future state of the organization. This is what makes Lean easier to implement in theory but often far more challenging to implement in practice, especially across larger organizations.