Have you ever been asked “the question”? The question that implies you may be a dinosaur working in the backwaters of technology, practicing… dare I even say it... waterfall (pardon my foul language!)?

It’s the question we’ve all heard at some point or another in our professional lives...

“Are you Agile?”

Here at Hexawise, the answer to this question is surprisingly, “No.” We aren’t Agile. We don’t have sprints, we don’t have a SCRUM master, we don’t burndown, we don’t XP, and we don’t have Agile Manifesto posters on the walls.

“Really? You aren’t Agile?”

Yes, really. We aren’t Agile… we’re Lean!

“Oh… OK. Uh... isn’t that the same thing?”

I’m glad I pretended you asked, because no, no it’s not.

 

Agile and Lean

Agile and Lean are siblings, but they aren’t identical twins. Lean is the older sister of the two, a Factory Manager at John Deere. Agile is the younger sister, she’s a Scrum Master at Spotify. Both Lean and Agile were raised properly as systems thinkers, and Agile learned a lot from her older sister, but they are not the same.

Agile software development - image source

Let’s start with Agile, the method you’re likely more familiar with. Agile software development is about iteratively building the right software. Software is developed with the customer in small iterations (called sprints) that result in a working, shippable release. An emphasis is put on having short iterations, customer (or customer surrogate) participation during each iteration, early and regular hands-on feedback from working software, and team reflection and improvement after each iteration. The main risk managed by Agile software development is spending too much time building the wrong thing.

Lean software development - image source

Lean software development is about continuously delivering value to the customer as quickly as possible. Work that’s stuck in the system is not yet delivering value so an emphasis is put on continual improvement to minimize waste, inefficiency, and time that work spends in-progress. Lean is not about keeping everyone on the team maximally busy, but instead optimizing the team for the valuable output of the entire system. The main risk managed by Lean software development is the time and cost of delivering value.

Agile and Lean Differences - A Deeper Dive

One of the key differences we just mentioned is iterative (Agile) versus continuous (Lean).

To help further tease apart Agile from Lean, let’s consider a canonical focusing question of each, and how it’s typically answered.

Canonical Questions

A canonical Agile question is, “Could we ship the results of this sprint if we have to?,” and it’s answered via the results of Continuous Integration (CI) and feedback from the customer representative using working software.

A canonical Lean question is, “Are users getting value from this yet?,” and it’s answered via the results of Continuous Deployment (CD) and shipped software.

Agile and Lean software processes will both have CI/CD pipelines, but the focus is different due to the structured iterations of Agile. Agile is focused on ensuring the result of each sprint iteration is shippable, while Lean is focused on shipping as quickly as possible after pulling new work, and only pulling new work when existing work has shipped.

Another way to understand the differences between Agile and Lean is to consider the most important tools, methods, and techniques used to implement each.

Tools

The key tools of Agile software development are fixed-time iterations and continuous integration to build shippable software for rapid feedback from a customer or customer surrogate on the team. Between iterations requirements evolve and processes improve based on retrospective analysis. These are the bare minimum tools needed to practice Agile software development, but best practices have evolved over time that include a product backlog, sprint planning, a sprint backlog, stories, story points, burndown charts, Scrum, and XP, among others.

The key tool of Lean software is a Kanban pull system used to visualize and restrict the amount of work-in-progress. Existing work-in-progress is shipped as soon as possible, and new work is pulled only when prior work has shipped. The entire team rallies to ensure any work-in-progress gets shipped before taking on new work. The other key tool of Lean development is the simple question, “Are users getting value yet?”, and this is best managed through a continuous delivery pipeline.

Agile and Lean fit different needs that are best understood by looking at each of their strengths.

Strengths

Agile is strongest when there is substantial risk in knowing what should be built. The emphasis on customer involvement, and continuous learning about the problem/solution domain shapes the software by interaction with the real world in a way the waterfall software development is incapable of. New companies, new products, and new projects are all well-served by Agile.

Lean is strongest when there is less uncertainty but a need to deliver more value sooner. Having a clear (and often endless) backlog of value to be delivered but limited time and resources to deliver it signals that Lean is a strong approach. Lean’s strength is in recognizing that one useful feature benefitting real users now is more valuable than twenty useful features in various unshipped stages of development. Teams that have developed substantial domain expertise with mature products and projects that have product/market fit are well-served by Lean development.

The last way we’ll consider Agile and Lean is by looking at some of their weaknesses.

Weaknesses

Agile can be more susceptible to cargo culting than other processes. There’s a lot of virtue signaling going on right now in the world of Agile, and I’ve experienced teams that are entirely waterfall but wrap themselves up in the tools, terms, and techniques of Agile without achieving any agility.

Are you practicing Agile without a customer representative on the team? Are you practicing Agile with fixed requirements, scope, and delivery dates? Are you practicing Agile but building the same thing you thought you were going to build 9 months ago? If so, you probably want to strip back some of the Agile theater and refocus on building shippable software in very small iterations, and continually learning and changing from the resulting feedback.

At the other end of the spectrum, there’s a danger in Agile practiced as a religion. I’ve seen teams with more time and people spent on managing their Agile process than on building software. How much total time are you spending on the overhead of backlog pruning, point estimating, sprint planning, Scrum meetings, burn down charting, and retrospectives? Ensure your Agile process is well-sized for your needs, and that each part of the process is delivering outsized value compared to the time invested.

Lean's key weakness is that it’s less often applied in software development than in other domains. Many teams have no prior experience with Lean, and some of the best practices can seem counterintuitive so there may be pushback from team members or management. Someone will have to stick their neck out to champion Lean before it can be proven to work in the organization.

Two Good Approaches, Not One

Agile and Lean share a common lineage and many common traits. There are Lean teams that are more Agile than others, and there are Agile teams that are more Lean than others, but Agile software development has stolen most of the attention, and not many teams understand the alternative approach of Lean software development. If you haven’t been aware of Lean, I hope this post explained how it differs from Agile, and why it’s a better choice for some teams.

In part 2 of this series, I’ll be diving into why Lean was the right choice for Hexawise and how Lean works for us in practice.

Blog cover photo by Daiga Ellaby