You Can’t be Lean Unless You’re Agile

I see so much talk and confusion over what’s Lean and what’s Agile. The two terms can get used interchangeably, so much so that in some places they’re blended into one term, simply Lean-Agile (thanks again, SAFe 🙄).

However in order to do our jobs effectively we need to be able to separate these two.  We need to know when we’re making efforts to be Lean, efforts to be Agile, or if we’re falling down in either area.

The ability to measure and improve our Agile and Lean practices, in turn, allows us to achieve better business outcomes. But figuring out where to start can be tricky, and there are a number of traps that you might fall into along the way. Before you start, it’s important to realise how these two terms are connected. Being Agile doesn’t necessarily mean you’re Lean, but you can’t be Lean unless you’ve cracked Agile.

The Success of Agile

Agile took the world by storm. It rewrote the books on how software was built. Everyone could see the results: if you built in an Agile way, the numbers followed. All the tech giants – and the ecosystems built around them – were built using largely Agile methods. But is it really what led to their success? It wasn’t necessarily that these companies were ‘Agile’, which led them to grow and succeed, although they were undoubtedly agile in how they worked. And this is the part that was most outwardly visible and most easily replicable. Almost overnight, every other company in the world turned ‘Agile’.

You see it in teams who have daily standups, bi-weekly sprints, ceremonial scrum masters, story points and burn down charts… and who yet aren’t actually breaking down work into valuable increments, and iterating in short cycles. It’s not uncommon to see teams who plan their work out for two, three, sometimes half a dozen or more sprints ahead, as in define what increment they’ll tackle in each two-week block. That’s not Agile. That’s just a series of small waterfall projects dressed up to look Agile. They are performing the actions of Agile, while not embracing an Agile mindset at all. All they are doing is copying the actions they see that led to the success of the tech giants around them – everyone else does standups and two-week cycles, therefore they must too. Mimicking Agile actions won’t get you anything more than a semblance of organization and it won’t give you any real progress towards outcomes.

The magic of Agile is what it enables: it allows a team to work in short bursts, with high levels of communication throughout. In order to reap the benefits of Agile, you need to take advantage of these aspects. Agile allows your team to iterate quickly. At the end of each cycle, the increment of work should be tested and measured, and learned from. And that is the essence of Lean: Building, Measuring, Learning.

We all get caught up in the build part of the cycle. We’ve got a million ways to be Agile, all with their own rituals, and yet it’s the measuring and learning that truly activates the value in the cycle. After all, if we’re constantly just building and building and building, and never measuring or learning, how will we ever know we’re on the right track? This is the path to a feature-filled pile of junk for a product. So while you try to get to the point of being both Agile and Lean, make sure you’re not just going through the motions of “doing Agile”, but that you are Agile and ready to iterate.

Continuous Delivery is a Product Problem

Part of being Agile is being able to deliver fast.

A lot of people see continuous deployment as a pinnacle of achievement in tech terms, but superfluous for the business. After all, who really cares that your deployment process is smooth and fast. Does it really make a difference to the bottom line? In fact, it does. Continuous deployment means you can continuously iterate. And what is continuous iteration, if not the core of being Agile – the ability to iterate easily when needed. If you have to wait weeks between iterations, that’s not very Agile. And at the core of Lean is the concept of continuous learning. That continuous learning is enabled by continuous iteration.

You can’t be Lean unless you’re Agile, and you’re not Agile if you don’t iterate quickly.

So at its core, continuous deployment helps companies move towards agility and more Lean practices, which is better for the bottom line.

This is where we product people come in. We sit in the intersection of technology and the business, and it’s often up to us to advocate for investment in infrastructure and processes that help the business as a whole become more Agile and therefore Lean, even if it’s not directly tied to our division or team. Often, the tech team struggles to articulate and get buy-in for investment in deployment management upgrades, but it can make a difference if the product team helps to make the case. As product people, we should advocate for continuous delivery as part of better business practices.

Having trouble making the case? This isn’t the only reason continuous delivery helps your business. Let’s talk about release cadence and the process behind releases. If each release is a pain in the neck, they take up your team’s time and mental energy, and force the team to avoid missing releases. Their thinking is that they’ve got to “get this into next week’s release or else I hold it up and it doesn’t go out for another two weeks”. 💀

This kind of thinking leads to rushed work that is squeezed into releases (this is where your tech debt comes from), or releases that are pushed back to accommodate late submissions (this is why everything goes so slowly). It’s not good for business. This is why I’m a fan of continuous deployment, or at least a release train: releases that constantly go out with minimal fuss or effort from the team, and which scoop up whatever’s ready to go live.

Is your work not ready yet? Don’t sweat it. It’ll be in the next release. As your releases are hours or days apart, not weeks or months apart, missing a release is fine. The result is quality work, less mental overhead on managing releases, and constant opportunity for iteration. If you’re a product person, help your tech team to advocate for better release processes. It takes time and effort, but it pays off.

Continuous integration and deployment aren’t just techie things to brag about, they are game-changers for companies who want to be Agile and Lean. You can’t just do the actions of Agile, you need to invest in the process, and follow up with measuring and learning – take advantage of the fast iteration you’re unlocking for your company!

What about you? Do you release fast or slow? How does it impact your company’s ability to react and solve problems? What have you done to speed up delivery? Get your tips and stories in the comments 👇