What’s Lean-Agile, and how can it help you avoid project waste?

Lean-Agile is a set of principles and practices for working that aims to minimise waste whilst maximising value. This enables organisations to make quality a priority in their products and services.

For us, we’ve found that it helps us to interface with other businesses. It enables us to work with external organisations that have different working practices.

In this post, we’ll look at the core principles of Lean-Agile and practices that boost effectiveness while cutting waste. Plus, we’ll look at why you need to train your organisation in Lean-Agile before you and your team start using it, even if not all teams will be using it in their day-to-day work.

The not so Lean-Agile way to work a.k.a. waste, waste everywhere and not a drop to drink a.k.a. no one is empowered or learning

Imagine…

Twelve months ago, Sam and their team sat down with a group of stakeholders at Hyper-Mega-Corp Z. A new box that took input and produced output was on the cards. Like anyone engaging in a very linear, Waterfall-like process for product development, the team and stakeholders mapped out everything from the start. Timelines, requirements, design, features, testing, and so on—they predicted everything over a series of meetings, workshops and lengthy email chains.

With the plan set and the budget signed off, Sam’s team started work on software development for the box. The processor was already decided for this box, and so the team wrote code that worked with that processor. But as the weeks and then months went by, the team started to have questions about development but didn’t feel like they could feed back to Sam or their stakeholders.

The team found out the chosen processor was not the best for the task the box was going to perform. The software library they’d planned on using had been found by a group of external security researchers to have massive cybersecurity flaws. And to top it all off: their stakeholders were frustrated they weren’t working through as many features per month as they thought they should be, while taking ages to give any valuable feedback.

Sam knew they were getting behind and that the box might be in trouble but didn’t believe they could talk to their stakeholders. Sam kept drawing team members into performance management reviews to speak to them about their efficiency.

One team member, Lindsay, had tried to talk to Sam about all of this. But there was no mechanism in place for learning or continuous improvement during development. Improvements in everything would have to wait until the next box.

The outlook for Sam’s team, and the box, was grim.

If only they’d had the right principles and practices in place. If only their entire organisation understood Lean-Agile and allowed Sam’s team to work using it.

Let’s explore the principles of Lean-Agile and see how they might have helped Sam.

The three layers of Lean-Agile

It helps to think of Lean-Agile in three layers.

The top layer is Lean principles, adapted from manufacturing. That second one is Agile project management practices, adapted from software development (like Scrum or Kanban). The third is technical practices that help you implement Lean principles (Test-Driven Development, retrospectives, and so on).

Lean-Agile is a hybrid between Lean principles and Agile practices.

What are these Lean principles?

Mary and Tom Poppendieck best describe the principles of Lean in their book Lean Software Development: An Agile Toolkit. Here’s a summary:

1. Eliminate waste. What’s waste? It’s anything that doesn’t “add value to a product, value as perceived by the customer.” Waste is anything produced or sitting around that doesn’t get used. Parts on a shelf that are just gathering dust. It can be “[when] developers code more features than are immediately needed.” The time lost shifting development from one group to another? That’s waste too, say Mary and Tom Poppendieck.
2. Amplify learning. The Poppendiecks see tackling a software solution as a lot like trying to put together a new recipe for a top restaurant dish. A chef will iterate and learn from the variations produced. Software development is more complex, and teams can be big, but when you amplify learning, it makes this discovery process possible.
3. Decide as late as possible. In something like embedded software development, there can be many unknowns. Which processor is going to fit the product and users’ demands best? Should we develop in x, y or z language? Is this screen better than that screen? Functionality likely to change due to user or market feedback? There’s no value in speculating. Instead, delay decisions until you have the facts.
4. Deliver as fast as possible. “Design, implement, feedback, improve,” and repeat. “Rapid development” is entirely plausible; its speed enables you to make informed decisions with real feedback. Keeping this cycle short, amplifies learning as well as making sure “customers get what they need now, not what they needed yesterday.”
5. Empower the team. The people doing the work are the ones who understand the details the best. Want “excellence”? Make sure your technical team are involved in “the details of technical decisions”. Enable these teams to use “pull techniques” and “local signalling mechanisms” (like Kanban) to schedule and complete work whilst letting everyone know what’s coming up. So long as a leader guides the team, “they will make better technical decisions and better process decisions than anyone can make for them.”
6. Build integrity in. Here the focus is on ensuring quality. This is more than just customers being happy with the final product, its “perceived integrity”. And it’s going further than “conceptual integrity” where the whole works seamlessly together. For software, building integrity in means it can evolve smoothly over time, because it has “coherent architecture, scores high on usability and fitness for purpose, and is maintainable, adaptable, and extensible.” For the team, integrity comes “from wise leadership, relevant expertise, effective communication, and healthy discipline”.
7. See the whole. Don’t just look at one area of a project. Step back and look at all areas involved. “Quite often, the common good suffers if people attend first to their own [specialised] interests.” Instead of measuring based on people’s “[specialised] contribution”, look instead to the overall performance of the project. ¹

Where does Agile fit?

When comparing the above Lean principles with the principles from the Agile Manifesto, you start to see the crossover between the two. Both emphasise learning and a people-first approach while enabling sustainable projects that eliminate waste. Agile’s focus on continuous improvement also meshes well with Lean.

Prediction is wasteful

Traditional project management practices such as Waterfall try to predict all elements of a solution right at the beginning. Solutions developed like this will rarely adapt significantly in the face of new evidence and will not adapt to new learning.

Predicting leads to waste and prevents you from deciding later when you have all the facts and makes delivery slower.

In manufacturing, this could be predicting what parts you need and holding onto stocks of these, taking up space unnecessarily. These same parts could also become obsolete before use—leading to waste.

Software development has a similar issue when traditional project practices are used, with software features potentially going unused. Often this waste comes from trying to predict what features the user wants.

A 2019 report from Pendo found that in the average cloud software product, 80% of features are rarely or never used. Pendo estimates that these unused features represent $29.5 billion in Research and Development investment by publicly traded cloud companies.

At first glance, having these unused features may seem like it’s no big deal, but they become a maintenance burden. Just removing them may not be an option. It’s more waste.

Adaptation over prediction: effectiveness v efficiency

Why is adapting better than predicting? On the face of it, adapting can look like it’s less efficient than predicting and it is. To understand Lean-Agile and why it’s so successful, you need to understand the difference between efficiency and effectiveness and how it stops waste.

Efficiency focuses on time and cost, the amount of work done, while effectiveness is about building the right thing. Adapting to new knowledge as it emerges, ending up with the right solution and avoiding the waste that comes from making the wrong thing.

If you have a focus on efficiency, you won’t be able to see the advantages of being effective. You need to take an extra step back and look at the whole picture of what the team is creating.

For example, measuring how many lines of code a team writes per hour or how many features they add per week is one way of looking at a software project. Significant gains here might make you think that, due to efficiency, a team is doing well.

Lean-Agile however means potentially doing less, but because the team is being effective, they are adding the right features. There may be a small increase in cost, but there’s a significant increase in the value generated.

Technical practices that boost effectiveness in software teams

These are not all of the technical practices available to software development teams. But these are practices that home in on effectiveness over efficiency.

Be effective with Test-Driven Development

Test-Driven Development (TDD) is a way of developing software. Developers will write a “unit test” before they write code, checking that these tests fail and then write code to pass that test.

Research from Microsoft has found that TDD can lead to a 15-35% increase in initial development time (link opens PDF), but they also found that it increases the quality of code. Code written using TDD had fewer defects, according to Microsoft. The creation of unit tests also means that these assets exist for reuse later in a product’s lifecycle.

A 2018 study that looked at TDD and unit tests (link opens PDF) found the approach led to code with fewer defects as well. Looking at mutation scores (where you check tests through introducing defects to code), this study found TDD led to 87.5% detection of these defects. Conversely, a test last approach, testing code at the end of a project, typically favoured in Waterfall style development, found only 67% of defects.

Taking a TDD approach means that fixing these defects happens early on, before they can create waste.

Make decisions as late as possible by developing solutions in parallel

Another example of efficiency v effectiveness is to look at how making decisions as late as possible may be perceived as less efficient but is more effective. Specifically, the process of developing solutions in parallel.

How does this work? Say that you have a technical problem, like deciding which processor would be the right one for an embedded system.

In Waterfall, the processor would be picked early on, based on predictions around its performance. But if you have chosen the wrong processor, you won’t know this until you’ve got significantly through the development process. At this point, changes to the code to accommodate a different processor would set back a project, creating waste.

The Lean-Agile approach would be to shortlist the best possible processors and develop in parallel for all of them. Developing in parallel, you start to see which options are not working out and sooner. You’ll be able to benchmark the processors against the user tasks you need them to do. You’ll adapt based on real knowledge.

To pick one processor from the start is efficient, but it’s not necessarily effective.

Use Mob Programming to work through tough problems as a team

Mob Programming (or mobbing) is where a team sits around a computer and works on code together. One person at a time is typing the solution (driver) while the people around them navigate the problem and communicates a solution (navigators). At set intervals, the roles rotate through the team. You’ve got everybody’s intelligence applied at the same time to make sure that you’re doing the right thing, with the added benefit of constant, informal code reviews

Having more than one person work on a task at a time may seem ridiculous when dealing with industries where talent is scarce. But mobbing is another practice where it appears to be less efficient, but it is more effective.

Woody Zuill, who has done much to champion Mob Programming, found that with it, task completion happens in a shorter time frame than having a single person working on it.

It’s a productive way to work. But there are many benefits to mobbing that help Mob Programming be effective:

• It offers a continuous learning environment.
• It lowers the fear of failure.
• Mob Programming enables shared understanding, shared knowledge and shared ownership.
• It reduces handover times, increases understanding and communication.
• It improves code quality as mistakes can be spotted and corrected early.

For a deeper understanding of Mob Programming, Woody Zuill’s talk on the practice is a good start:

Lean-Agile is nothing without training and awareness

One thing we’ve found at Bluefruit is that for Lean-Agile to be a success, we’ve had to train our whole team in it. Engineering and non-engineering. But we haven’t always trained everyone, and because of this, we saw friction between our engineers and leadership, finance, HR and admin team, as well as sales and marketing.

These indirect parts of our business use a few of the practices we’ve described, but they understand the principles at the core of how we work.

With our clients, we also ensure that they know where we’re coming from. We coach them through Lean-Agile principles when a sales conversation starts.

But how can you empower people with core principles without being top-down?

Gaining acceptance of Lean-Agile is best done through coaching. Instead of dictating the principles, training should enable your team to discover them and how it can work for them and others. You then keep this training up, helping people to make it part of their behaviour and not something they have to think about.

Coaching rather than dictating

People are more receptive to concepts when they reach the same logical conclusions by themselves.

An example might be introducing formal coding practices into an organisation. Developers often learn about programming from different sources and take on personal quirks and styles in how they code.

For software development, this presents a problem as it can be difficult for anyone, other the original developer, to understand the code and maintain it in future. It can be difficult to read and navigate, to review, or to make changes, risking the quality of future work.

Rather than hand out a rule book to follow, you can encourage the developers to find a consensus about which coding styles to use. This is how coaching comes in. Coaching often involves getting people into a team workshop, presenting them with a problem, having them go away and work on it and then come back to review the exercise and each other’s solutions.

The review process helps everyone assess the benefits of different approaches and, with the coach nudging, to select the best bits. Then they go away to solve another puzzle, come back, and review again. Repeating coaching sessions like this over time helps developers adopt the same style of coding.

Be effective, be Lean-Agile

We hope that by this point you’re interested enough in Lean-Agile to start thinking about how you could bring it to your organisation.

To read more about Lean-Agile practices, check out the posts below.

¹ Mary Poppendieck, Tom Poppendieck, Lean Software Development: An Agile Toolkit (Crawfordsville, Indiana: Addison Wesley, 2003), pp. xxv-xxviii.