How Lean and Agile Relate and How You Can Win by Using Both

Lean Principles

The lean movement has roots in the manufacturing world. Many of us have heard about the Toyota Production System (TPS), credited to Taiichi Ohno. This method started off with the baseline of what Ford Motor Company was doing with their production line. However, Toyota’s focus on continuous improvement pushed their company ahead in terms of quality and value. They also incorporated the idea of “just in time” manufacturing, where products were delivered right when and where they were needed in order to reduce waste and inventory.

These principles were later adapted for software development. Let’s compare the principles that started at Toyota with how they look now.

Lean Manufacturing Principles

The original lean principles, identified back in the 1940s, looked like this:

1. Value. It’s important to provide value from a customer’s perspective, not just checking items off of a list. This principle conveys the core focus of lean.

2. Value stream. This means the end-to-end list of actions required in order to build a product that the customer values.

3. Flow. We should ensure that the value stream continuously delivers value

4. Pull. This means producing on-demand, only when needed.

5. Perfection. We want to be continuously improving value streams and products in order to achieve zero defects.

With this original set of principles, Toyota became one of the most popular automotive companies in the world.

Lean Software Principles

There were many changes and additions to the original lean concepts when we started adding the principles to software development. Notably, the book Lean Software Development: An Agile Toolkit, written by Mary and Tom Poppendieck, came out in 2003. This book provided a new way of looking at software development.

We often wonder how this works with agile. Thankfully, the authors added the word agile to the title, so we knew we were in good hands.

The principles vary based on the author- or methodology-du-jour. You may have even seen this Plutora post where we discussed the following set of principles:

1. Eliminate waste

2. Build quality in

3. Create knowledge

4. Defer commitment

5. Deliver quickly

6. Respect people

7. Optimize the whole

I found it interesting to see that the original list focuses much more on providing value to the customer. Based on the changes I’ve seen happening in companies that I’ve worked with, we’re returning to the original list and focusing in on customer value. This has come about in part due to books like The Lean Startup by Eric Riess, where maximizing customer value is the most important piece.

If you’re wondering what happens to waste and quality when we focus in on the customer, don’t worry. Those benefits, like eliminating waste and delivering quickly, can also come about from making it the most important principle to deliver value to the customer. Customers want value, and they want it quickly. So if we provide that in a lean and agile way, we’re on the right path. And as a bonus, it fits nicely with the agile principles we use today.

Lean Startup Principles

I’d like to bring in a bonus set of principles from The Lean Startup. As mentioned earlier, methodologies like those of The Lean Startup drive the focus back to the customer. With this approach, we follow a pattern of build, measure, and learn.

This benefits our lean and agile adoption because it answers the question “What if you’re building something that no one wants?” Here, we enable our teams to validate their assumptions, learnings, and hypotheses about our product. With validated learning, we can make sure we’re not only writing software in an efficient and quality-focused way but we’re also creating a product that customers will use.

Now, let’s move onto our next section, which will deal with agile principles.

Agile Principles

The agile methodology focuses on building a product correctly. But it doesn’t focus as much on the value of the product. With agile, we’re happy when the customer is happy. However, the customer might be happy with a product that he never uses.

Another focus of agile involves shortening the feedback loop between the proposed requirement and the development team writing the functionality. It helps the product evolve toward fulfilling requirements. On the other hand, lean focuses on making sure the requirements match user need and provide actual value.

Here are the original twelve agile development principles:

1. Encourage customer satisfaction by early and continuous delivery of valuable software.

2. Welcome changing requirements, even in late development.

3. Deliver working software frequently (weeks rather than months).

4. Prioritize close, daily cooperation between business people and developers.

5. Build projects around motivated individuals, who should be trusted.

6. Consider face-to-face conversation the best form of communication (co-location).

7. Use working software as the primary measure of progress.

8. Assure sustainable development that allows you to maintain a constant pace.

9. Give continuous attention to technical excellence and good design.

10. Consider simplicity—the art of maximizing the amount of work not done—essential.

11. Understand that the best architectures, requirements, and designs emerge from self-organizing teams.

12. Reflect regularly with your team on how to become more effective and adjust accordingly.

Overall, these principles focus on making software development more flexible and efficient. They’re a ground-up attempt to change the way that software engineers do their jobs so the focus can be on building quality software through fast iterations and feedback.

Combine Lean and Agile

When combining lean and agile, we’re really combining two key concepts: (1) build the right thing using lean, and (2) build the thing right using agile. But we don’t always combine these two methodologies in a healthy way.

The Wrong Way

Some teams make the mistake of creating different phases of the lifecycle of the project for lean and then agile.

This makes the whole process more like waterfall, with two drastically different areas for learning/discovery and the actual implementation. This treats experimentation and validation as a separate activity from what we ship to the customer. To combine lean and agile, we should instead work to have the circles overlap. And we should use practices from both to make our product decisions.

The Right Way

So now we know that we should use practices from both lean and agile together, and not as distinct parts of the software lifecycle. What practices can we specifically target for this cross over?

Adding Lean Practices

If you’re living in an agile team, but want to add lean practices, here are a few places you can get started.

Include Value Stream Management

In the initial list of principles for lean, we mentioned the value stream. To identify our value stream, we can perform a value stream mapping exercise. This results in a visual representation of the processes and activities needed to get code to production and in the customer’s hands.

This process helps identify inefficiencies in your value stream. It can also put hard numbers on how long it takes to get from an idea or requirement all the way to pushing that code to production. This view of the timeline often opens executives’ eyes as to how company policies and silos are slowing down the system and keeping us from continuous delivery.

Optimize the Whole

Value stream management provides one other lean benefit: it lets us see the software system as a whole. This goes back to the lean software principle of “optimize the whole.” Without having a view of our whole system, we won’t know what to optimize. We’ll instead focus on optimizations that might not improve our process. They may even make things worse. Why is that?

The efficiency paradox states that optimizing each piece of your value supply chain will not, and cannot, optimize the whole. You need to assess the big picture in order to optimize efficiently and correctly.

A real-world example of this involves General Stanley McChrystal during the Iraq war. The general noticed that although his teams were victorious and efficient in individual battles, they were ultimately losing the war. The teams had removed waste in the form of intelligence officers and analysts that could review and share information between troops. And because of that lack of communication and analysis, the teams weren’t able to get ahead of their enemy.

In order to win the war, McChrystal had to change tactics and add inefficiencies to the individual teams by adding additional officers. Those micro-inefficiencies created an overall macro-efficiency that improved performance as a whole.

The Kanban Board

The origins of the kanban board came from the TPS system. They used cards to announce when necessary inputs were needed in a process. This reduced waste, inventory, and productivity. Even if your team isn’t using a physical board, take advantage of low waste by keeping work in flight low—essentially keeping your incomplete software “inventory” at a low level.

Customer Discovery and Validation

Typically with agile, we get requirements from our product owner or business analyst. We assume that these requirements provide value to the customer and have been vetted. However, oftentimes, they haven’t been.

In order to add lean value thinking into your software process, you can add activities, processes, and automation that validate your software meets the customer’s needs.

Here are a few ways to do that:

1. When starting out with new products or adding large features to existing products, start by identifying assumptions and risks that exist around the new feature offering. Find the most critical assumptions your team is making, and determine how you can validate the assumption.

2. Build new features with a customer hypothesis in mind. Instead of taking requirements and implementing them blindly, consider how the requirement can be validated to prove its value. This may involve writing software to implement the feature, but it also could include writing MVP functionality or manual processes that measure customer feedback.

3. Track key performance indicators (KPIs) that measure the effectiveness of your software product. If you use hard data to see how customers use your product, and if you look at changes to KPIs after the launch of new features, you’ll get critical data. You may have customers that tell you they want feature X or they really like feature Y, but if they’re not actually using those features in production, we want to know quickly.

Adding Agile Practices

Here are a few practices from the agile world you should incorporate.

Continuous Integration and Delivery

Begin building in some DevOps processes that improve quality and speed for getting features out. Make processes easy for developers and management alike by automating repeated tasks.

Test-Driven Development

A common practice on many agile teams involves test-driven development. Tests ensure that we’re building our product correctly and that it matches the known requirements. Because tests provide such a critical component to the product, they’re written first, before the actual implementation of the code.

Additionally, make sure all tests run in an automated fashion. Therefore, we’ll know what changes break existing functionality before we ship bad code to the customer.

Include Agile Ceremonies

Agile ceremonies provide more value than meets the eye. In fact, many of the ceremonies provide additional benefits that can drive value and innovation.

1. Iteration planning/sprint grooming. Provide a way for your developers to be involved in planning upcoming work. This lets them work on solutions with the greatest understanding of the problem that they’re solving.

2. Daily stand-ups. Each day should have a quick five-to-ten minute meeting to get everyone on the same page and remove blockers. Don’t make this a status meeting. Rather, look to your developers to make this meeting help their needs of getting things done.

3. Sprint demos. After each sprint or iteration, let your team celebrate functioning software by showing it to the customers and stakeholders. This provides a sense of confidence for the business, as they’re seeing the product being built before their eyes. Plus, it also puts a bow on the work that was done, helping instill a feeling of accomplishment among the development team.

Push for Co-location

Bring business people in to sit near your development team. Make the product owners easily accessible and approachable so that your devs can get the information they need quickly and in person.

Adding Lean-Agile Practices

Some practices go well with both practices. If your team’s not doing the following things, consider adding them.

Improve Continuously

Both lean and agile methodologies focus on continuous improvement. In addition to retrospectives, make sure your teams have the resources they need to improve their skills. Support their efforts to reduce technical debt and improve automation. Consider always having an automation or technical debt story in play to keep your application health moving in the right direction.

Break Down Silos

With both agile and lean, the product development team requires autonomy to do their jobs. Work to automate processes and get the people you need on the team so that your product isn’t left waiting in someone else’s backlog. With autonomous, self-sufficient teams, business value ships faster and more continuously than if multiple disparate teams have to prioritize work between themselves.

Conclusion

Combining both lean and agile methodologies provides more consistent value to your customers. Take a look at what you’re doing today and what you can learn from other methodologies. Most teams have some core problems or opportunities for improvement. Decide what methodologies can help with the problems you’re facing, add solutions from the suggestions above, and consider Plutora’s value stream management offering. And then move on to the next opportunity.