Lean Agile – Bringing Them Together To 5x Your Delivery

If you’ve been working in and around digital products for any length of time, Agile and Lean are two words that you would have heard being bandied around.

“We need to be more agile”

“We work using lean principles”

The words have become so ubiquitous in the tech, product and business world that they’ve developed their own frameworks, philosophies and movements. Read around and you’ll get conflicting opinions on what agile and lean truly are.

Frameworks like Scrum, Kanban and SAFe cause heated debates amongst consultants on Twitter, and sometimes it can feel more like a collection of religious sects rather than a set of principles to build better software

But it’s not that complicated. At their core, lean and agile are both a set of principles to follow, as opposed to a set of ceremonies that must be devoutly committed to.

This article will explain how the two philosophies started, what they are and outline how they can be applied together as what has come to be known as lean agile.

What is lean?

Although these days ‘lean’ is a term that is commonplace in the software industry, the concept has its roots in 20th century manufacturing. Toyota (yep, the car company) invented it with the following aims for its production line:

Produce the highest quality, at the lowest cost, with the shortest lead time.

To achieve this, it focused on one thing: eliminating waste.

Concepts that are essential to the everyday running of modern day production lines like Just In Time Delivery (JIT) and Kaizen (continuous improvement) were developed by the car company back in the the 70s.

And it worked; Toyota quickly became famous for high quality at a low price point and is now one of the major players in the global car market.

But what does this have to do with software? Well, not a lot until 2003 – the year that the book Lean Software Development: An Agile Toolkit was published. This book, written by Mary and Tom Poppendieck, took Toyota’s lean principles and showed how they could be applied to the software development process.

The idea of producing a high quality product for a lower cost by eliminating waste was something that didn’t just apply to car factories. Software production had similar types of wastes, and could be treated using similar techniques.

Lean Software’s 7 Wastes

In their book, the Poppendiecks assert that waste is lean’s big enemy and it comes in many forms, the 7 wastes:

• Extra features – ship features and find that nobody uses them? That’s waste. This is likely one of the biggest and most common forms of waste in software production and comes about when our vision for the product doesn’t align with what customers need. Lean’s emphasis on delivering quickly means that we quickly find out what customers value and what we should double-down on.

• Extra processes – creating lengthy documentation that nobody reads, or bottlenecks in the process that rely on people to approve work. Whilst processes do have their uses, lean insists on killing any that don’t add value or cause delays out of the production line.

• Partially done work – waste created by building too many features simultaneously, leading to none of them to be delivered quickly. It can lead to blocks in delivery and our feedback loop taking too long. Lean encourages us to limit work in progress to avoid waste.

• Task switching – when teams and team members are working on more than one thing at the same time, you get waste. Flicking from one task to another, and not being able to apply their full attention to either means that teams effort is not applied efficiently.

• Handoffs – siloed teams that need to have handoffs with one another generate waste. Lengthy documentation, extended meetings and miscommunications all lead to time being wasted. Lean recommends multi discipline teams working closely together.

• Waiting/Delays – things like sign-offs, hand-off bottlenecks and quality assurance blockers all cause delays and therefore waste. Again, lean’s cure comes in the form of close-knit multi discipline teams, empowering these teams to make decisions for themselves (and not waiting for a boss to sign-off).

• Defects (bugs) – defects, if not caught during the production process, are a big waste generator. If caught in a final quality assurance phase, they must go back to the developer to fix, and then back to the QA expert to retest. If they make it into the production codebase, they make it harder for the customer to extract value from the product, or even negatively affect the task they are wanting to do. Lean insists quality should be something that all team members are responsible for and considering during the development process, not only the responsibility of a specific QA team.

What is agile?

Ask any modern software team and they’ll tell you that they use agile. But if you stick around and watch what they do, you’ll likely see wildly different ways of working.

Nowadays there are multiple different ways of applying agile through frameworks such as Scrum, Extreme Programming (XP), Scaled Agile Framework (SAFe). Because of this, It can be difficult to work out what agile actually is.

So let’s go back to where it all began. 17 software developers gathered in Utah in 2001, in a bid to try to uncover better ways of developing software. They came up with The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile really is as simple as that. Forget ‘Sprints’, ‘Velocity’ and Jira – if a team is following the above principles when they work, they can be considered agile. If they aren’t working to the above principles, they aren’t agile.

At its heart, agile is an approach to building software that emphasizes building working software and getting it into users’ hands as quickly as possible in order to react to how they use it. Future development is then planned based on that feedback, and software is built incrementally, constantly adapting to our users’ usage of the product.

The alternative to agile is waterfall. Waterfall is a traditional project management method that is much more linear. Customer requirements are gathered upfront, they are written into a specification document to describe how the software should work, designs are created, the code is written and finally, after months or years, the product is released.

Whilst waterfall still has its place in some parts of the project world, agile has gradually taken the software development world by storm in the past 20 years. Companies using agile development practices can get a competitive advantage by understanding what their customers need quickly and regularly, enabling them to deliver value software at a higher rate. Nowadays, even companies like Space X, where lives are in the hands of software developers, are using agile.

One important part of agile that is often misunderstood are the ceremonies. Check out our guide on agile ceremonies here.

Lean + agile. Picking the best of both worlds

Lean and agile have a lot of similarities. They both focus on rapid, iterative development in order to deliver value to customers faster and avoid wasted development time by producing unnecessary features.

• Lean emphasizes low waste by only producing what is needed
• Agile emphasizes delivering software quickly and collaborating with customers

You can see how these principles can fit together quite neatly. Lean agile combines them with the aim to deliver high quality, valuable software quickly.

Let’s take a look at how lean and agile can be knitted together. Here I’ve taken the seven Lean Principles, combined them with agile principles and shown how lean agile teams can combine the two.

Applying lean agile to your projects

Whilst the above sounds reasonable in theory, it can be difficult to understand how to apply it in practice. Sure, we want to start delivering working software quickly and give teams the power to make their own decisions. But, what practical steps can we take to achieve this?

Luckily there are lots of frameworks that can help us apply these principles in the real world. The most popular frameworks include:

• Extreme Programming (XP)
• Kanban
• Scrum

These agile frameworks all include a toolset that lends itself to lean’s central ethos: minimizing waste.

They all have their differences, and I encourage you to investigate them individually, but you’ll find some of the following similarities amongst them:

• Iterative development whereby working software is released in small timeframes (weeks, not months). These are called “sprints” in Scrum.
• Practices like mobbing and pair programming (in XP) to build quality into the development process
• Chunking up specs into user stories and limiting the number that are worked on at any one time (Kanban is very strict about limiting work in progress)
• An emphasis on customer feedback at the end of an iteration/sprint and incorporating what we learn into future iterations Frameworks are sometimes described as a gateway into agile and lean practices. For an inexperienced team, they are a great way to apply agile practices to real world projects with a blueprint that is easy to follow.

In time, teams can start to adjust how they work depending on what works for them, and throw out parts that aren’t providing value. In the spirit of lean agile, we can apply the principles of continuous improvement to the process itself.

Beware of pseudo agile

Even if you opt for a framework to start things off, you should alway be asking: “does our approach follow the foundational lean agile principles?”.

An all too common malaise of the modern software team is to practice what has come to be known as pseudo agile.

These teams will conduct agile ceremonies such as two-week sprints and retrospective sessions, but the founding agile lean principles such as empowered teams, customer collaboration and continuous delivery are not followed.

Instead, these teams work on requirements specced long in advance by upper management, take months to release working software and reject change requests as “out of scope”. That doesn’t sound very lean agile to me. Don’t let the sprints fool you.

The benefits of a lean-agile mentality

To round up, let’s recap the benefits of a lean agile approach.

• Because we are delivering and getting customer feedback faster, we can be more sure that our software is truly delivering value
• Baking quality into the build process, rather than saving quality checks to the end of a long project means that we can build higher quality software with fewer defects
• Since teams are empowered and not reduced to ticket-takers, we can build autonomous, motivated teams that design solutions to problems that a top-down approach might overlook
• Budget is used more efficiently since there is less time wasted building features that nobody wants and retrospectively fixing defects in code that was written a long time ago
• A culture of continuous improvement and working in short iterations help the team to adapt their ways of working on a continuous basis So there you have it, incorporating a blend of lean and agile principles into your development process can help you produce better quality software that you can be sure is valuable for your customers.

If you’re looking at implementing lean agile for the first time, take a look at some of the frameworks referenced above. If you’re already using agile ceremonies, take another look and check if your process reflects the core lean and agile principles as they were laid out all those years ago.