Agile and Lean, two empty words?

If you're involved in startups or working in an innovation department, you'll have noticed two words popping up: Agile and Lean.

We can no longer do anything that isn't Agile or Lean. Or we'll have to face the consequences of not being fashionable. When it comes down to it, the two terms are used interchangeably, mixed up, and confused with each other. And their popularity hasn't helped matters. A multitude of companies offer us Agile products, services, and training with promises of increasing our productivity.

And we've reached a point where both terms have become empty, mere crutches that support what we've been doing for many years.

Personally I think it's a loss so...

Let's go back to the basics

The Lean method emerged in the 1970s from the Toyota Method. You've probably heard the words kaizen, which means constantly introducing small improvements, and muda, which means eliminating waste (anything that doesn't add up).

Years later, a bunch of developers tired of working for large companies invented Agile. The approach is very similar to Lean; in fact, it shares some of its learning values.

A curious note: many of us believe that XP and Scrum are born from Agile, when in fact, it's quite the opposite. Agile is a distillation of the essence that characterizes both ways of working.

So why the confusion?

Agile and Lean have something in common, which is learning.

We could say that Agile is more daring, inviting you to begin and then reflect. Lean, on the other hand, takes a more traditional approach, formulating a hypothesis. But the difference is purely intellectual; nothing prevents you from formulating a hypothesis.

Both will focus on an important step: learning or retrospective. A phase in which we put less effort than it deserves compared to the other phases.

Over the years, the terms have been refined. Perhaps one of my favorite definitions is Johnny Scheider's in Understanding Design Thinking, Lean, and Agile.

• Lean: Build the Right Thing

• Agile: Build the thing right

  Interesting developments

  Google Ventures made Design Sprints famous. This methodology of experimentation and discovery is rooted in Lean by attacking its most costly point. What is its most costly point?

  In the Lean cycle, the most demanding part is the construction phase. As my friend Carlos Sánchez often points out, "A mistake on a plan can be removed with an eraser; on the construction site, it can be removed with a hammer." And this is the question that Design Sprint poses: of all the hypotheses you can pose, which would have the greatest impact and how can you validate it as quickly as possible? And if you can cheat, even better.

  Let's understand the pitfalls of reducing prototype construction to its bare bones. We've seen this a lot in Tetuan Valley; if you need to gauge interest, invest in ads; if you need to capture leads, create a landing page. Examples include Zappos claiming to have a huge shoe catalog, but in reality, if you went to the store in person, there weren't many.

  What's the problem?

  One of the main problems we have when applying its benefits is that they remain intellectual concepts. You can't be Agile no matter how much you think; you have to act.

  As a result of this problem, we try to achieve these goals through methodologies, frameworks, or, God forbid, tools.

  We're going back to the golden hammer problem. Now we code with Scrum, we launch with Lean Startup, and everything else doesn't matter. We've reached Agile nirvana. Interestingly, like the spiritual connotations of Nirvana, Agile is the path, not the destination.

  Call to Action

  In short, agile and lean are two empty words; we must contribute our intelligence (and the effort it entails) to complete them.