A cat's Garden

2026-05-10

Reading notes: The Lean Tech Manifesto

Authors: Fabrice Bernhard and Benoît Charles-Lavauzell

The Agile Manifesto is focused on small teams. But how do we build an Agile organization that scale ? How the Lean Principles can Help ?

According to the authors, the four values that drives Agile teams don’t scale.

  1. Individuals and interactions over processes and tools don’t work once people can’t manage an individual connexion with everyone within the organization.
  2. Working software over comprehensive documentation don’t scale when the system is complex enough so that fast delivery will not catch rare bugs or help coordinate work between multiple team.
  3. Customer collaboration over contract negotiation might not be possible in bigger organization because “the team” is in fact multiple teams or because the customer has multiple stakeholders with multiple interest.
  4. Responding to change over following a plan works only as long as the ownership of each decision can be owned by the leadership team and have a meaningful effect.

How to we scale these values ? How do we stay Agile in bigger and more complex organization ?

Lead with Value for the Customer

Find the value for the customer and embed it in the system so it’s crystal clear for everyone !

How do we find the value for the customer ?

To find the value, regular visits on the production line are necessary. These visits (Gemba) leads to a deeper understanding of the system. Whether by knowing what value is created or by surfacing the problem affecting both the team and the customer. For these visits to be the most effective they should follow 3 steps:

Value is what makes a product or service meet and/or exceed expectation. These expectations are often unclear, even to the person using the product or service […] (p. 29)

[…] you can start with a simple value model by answering the following two questions:

Having a qualitative feedback on customer expectation (e.g. by using the Net Promoter Score) is mandatory to identify value gaps.

I am convinced that being customer centric is the way to go. I just have a hard time translating the “Go and See” visits in a Tech context. Because, at least in the companies I worked for, we didn’t build the same thing twice.

It’s more like we build each time a new vehicle but the first might be a car, the second a bicycle and the third a bulldozer. And to me it’s a slightly different way of optimizing, which is more on the process rather than on the product. Even if we can find metrics that are relevant for all vehicle it’s seems to me that it’s more indirect.

I would have liked more details about the necessary adaptations linked to this specificity.

Part of the value is not to have anti-value.

factors that won’t make the product stand out if they’re right, but could make the product fail if they’re wrong (p. 32)

To get that tidy first hygiene, the authors suggests to use the SQDCE framework:

On the quality part of the framework, there is the idea to label bugs by detection stage. From the detection during development to the detection by the end user. I like it because it can allow you to find where the defect are found in your system, and from that to think about ways to detect them earlier.

On the cost part I found the following questions particularly relevant.

Are we working on the right topics ?
Are we doing the work right ?
Do we have the right indicators to uncover problems?
(p. 37)

In my experience so much work can be thrown away when we fail to take the time to answer those questions.

An other Idea I found worth noting is that even if estimating the work ahead is hard, it can bring insight to the team. There is value to detect early misconceptions and/or misalignment. There is value to think collectively how we can find the best solution to bring the value. Whether by changing some technical decision or the product requirements.

How do we embed the value for the customer within the organization ?

Visual Management help keeping the value for the customer at hand. It help building trust, align teams, making quick decision, giving a sense of accountability and ownership. Bonus: it reduce the need of meetings !

Visual Management should start and make central the value for the customer. Then leave space for discovery phases. Finally make it as clear as possible.

Visual Management is a very effective way to communicate value for the customer to the whole organization. But it does not help teams understand how they contribute to customer value and how to track that contribution. (p. 45)

That’s an interesting quote. I don’t see why visual management could not help teams understand how they contribute. Obviously the visuals can and probably should be different for each team.

The point here seems to be that the topology of the teams plays a significant role in fact that the teams can (or can’t) easily see how they contribute. The teams should be small (so they can build trust) and customer centric.

Empower People with a Tech-Enabled Network of teams

Give people skills and autonomy !

It reminded me of the book Turn the ship around4 where the autonomy and skills are linked together. No given autonomy to skilled people is bad as is a autonomy without competence !

So…

How do we empower people ?

The Supportive Team Leader is the cornerstone at the Team level. He should be competent (know how to do), caring, and Spiky (particularly skilled on one topic and naturally inspire other)

You know who the best managers are? They are the great individual contributors who never, ever want to be a manager but decide they have to be… because no one else is going to do as good a job. Steve Jobs (p.64)

He is the one that should ensure that the team has the competences needed, the support it deserves and guide it through continuous improvement.

The best way to learn problem solving is still through the daily support of the team leader. This means team leaders need to master problem solving, lead by example, and create accountability. (p.63)

This part was fairly interesting to me as it resonate highly with my experience. The importance of supporting Team Leader that lead by example and the fact that people highly care about their team (more than their company)

A few tools are discussed to help, mainly the Plan, Do, Check, Act (PDCA) and Problem, Impact, Standard, Causes, Action, Result (PISCAR). The first one is a way to use a scientific method to drive problem solving. The second helps to define a good plan.

I was not totally convinced by the example given. The majority of the potential causes identified seems linked to fairly easy to measure properties (e.g. row count in database, how full is a disk or the number of database request). So in my mind looking at those numbers would still be interesting to determine which causes is the more probable and which plan to elaborate. The 5S methodology is also cited to help maintaining the development environment.

Finally, the technology should help the people. For instance, high quality API in every modules allow small teams to be technically autonomous and reduce the need for communication. Before trying to communicate better, do we really have to communicate ? The less communication is needed the less friction will arise.

Produce Higher Quality with Right-First-Time

Detect defect early and learn from them !

How do we detect defect ?

The earlier we detect a misconception or a defect the less it has an effect.

We need to find ways to automatically detect defects as early as possible (p. 90)

Defect can be detected at different stages, from the moment the code is produced to the moment the customer uses the product.

How do we learn from them and create an environment that prevent mistake ?

Once we have detected a defect, we have to learn from it.

I found this part really interesting has it share some similarities with methods we tried to get working at some company I worked for. The Andon chain of help reminded me of the “2h rule” stating that nobody should be stuck without calling for help for more than 2 hours. Then the defect analysis was really close to the 8D method, which is probably to be expected as it comes from Ford Motor Company.

The main take-away is that we have to understand the root cause. We have to understand what caused the defect and eventually, why it was not detected earlier. Otherwise we might only correct a symptom and get another one surfacing later.

Finally the last part is about creating mistake-preventing environment. I didn’t know the term poka-yoke before and I found the example of the electrical plug a very good explanation. It’s impossible to plug an electrical plug in a harming way.

From a software perspective we have to choose languages, framework and more generally tools (like linters) and best practices (TDD) that create an safer environment to work with.

Deliver Continuously with Just-In-Time

Get the minimum needed, when needed !

How do we get the customer the value it needs now ?

By reducing the Lead Time ! The concept of Lead Time (from customer order, to the customer benefit) and Cycle Time (the time to make the product) are useful metrics to evaluate how fast value can be delivered.

A shorter lead time mean more value bring to the customer, more value opportunities by increasing the number of feedback loops. It also bring architectural challenges (reusable modules, best-practices, documentation…) that leads to better performing teams.

How do we reduce the lead time ?

Using a pull system (Kanban), working on one topic at a time and getting it done.

A common problem encountered during go and sees is that teams are not prioritizing customer value. They are focused on doing a good job in their area of responsibility. (p. 119)

This quote had me thinking a lot. I think we are totally there in my current future ex-company. We have bottlenecks here and there (functional specification, design reco…) but we are doing thing. Sometimes things that have lower priority because “We have to do something !”

And then:

It may be counter intuitive that the best way to improve value flow is to ask some people to stop working. (p. 120)

At first I was bewildered. But from the system’s point of view it make sense to make the problems visible.

To work a Kanban need to diplay:

At work we have columns representing steps, no Inventory specific column and no lead time. Well lead time would probably be pretty bad anyway as our backlog in some kind of gigantic bottomless horror.

Anyway the interesting question in my mind right now is more: if the columns should represent teams. How to we follow the work within a team ? How do I make visible that I have a code-review bottleneck for instance ? I get that, if we are focused on a team, we might follow a local priority while missing the global one.

How do we avoid flow problem within Teams ?

Limit the Work In Progress (WIP).

In a factory a team working with batch optimize it’s own production but it probably has side-effects on the whole line leading to under-performance.

In software engineering, there is an equivalent to batching: a team working on multiple features at the same time. (p. 126)

In other words, one feature done is better than two almost done.

The system should lean toward, small increments merged quickly (even if it means merging unfinished work with feature flags). These increments should be linked to a minimum of different features (ideally one).

I like that the book state the main complain: “but it will save time !” which I heard a fair bit without having the right answer in mind. And while that’s probably true within the team, that’s probably isn’t at the company level. And we are back again to the idea that the system needs the problems to surface and not be hidden even if it means that people have to stop working.

Ideally it make visible the inflexible environment, how long it takes to deploy ? To set up the development environment ?

The authors advocate about using the Takt time to synchronise the flow of work between Teams. In theory if we can specify feature with the same size, and split it in chunk that are less than a day then we will be able to have some kind of heat beat of the production.

In practice, I find it very difficult some feature may require more time from the design, while being trivial for the product owner and the dev team. And maybe the next one will be a no-brainer for the design team but require substantial work for the dev team. If by feature we mean a chunk of work that bring some value to the customer then I think it’s kind hard to have feature with the same size.

And do we really want that ? Is it really an issue if feature A takes 4 days and feature B takes 10 ? The question may be is at which point do we have to stop and ask ourselves if feature B could not be split in two ? But if we drive with customer value in mind and if the value could not be delivered in less than 10 days it that a problem ? In less than 20 days ? 30 days ? Well now we probably have a problem. But how to we assert that ?

I think we also have a problem of moving targets in software engineering. At first you have to build a tractor. You set up the project the architecture is fine. Slowly but surely, listening to what’s needed we have to make it faster because it would be cool if we could go on city roads with it. And one day you find yourself debugging your tractor on the highway wondering how did you get there ! It’s really hard to stop delivering features to refactor.

Continue Innovating by Building a Learning Culture

How do we keep learning ?

Create a Problem-Solving Culture by rewarding the people that surface them. And obviously do not punish them ! The intent should always be on what we can learn from the problem.

Having no problems is the biggest problem of all. (p. 150) attributed to Taiichi Ohno

We can learn from the customer: what are his frustrations ? What can we do about it ? What is the job to be done by this customer ?

Experimenting should be seen as some sort of problem solving but instead of looking to solve an issue, experimentation looks for variation to improve the product. These experimentations should be easy to do and evaluated against the metric it was suppose to improve.

We can learn from the teams themselves.

The most direct way to retain knowledge is to keep teams stable for as long as possible. (p. 163)

Stable teams (should) lead to trust among its members and thus with trust the ability to challenge one another.

Writing down the best way to do the work: Standards

A standard has two distinct parts. The first describes what “good” looks like and the second describes the job breakdown currently known to yield a good result. (p. 166)

I like this idea to split the (stable) definition of good on one side and the (current) way of achieving it. Because the one problem with written documentation, is how to keep it up to date.

When you want to have a leaning culture, you want to know what good is to now where you should improve[3]. But how to keep improving ? Kaizen workshop are a way to keep improving. They have a six steps

  1. Discover the improvement potential.
  2. Analyze the current method.
  3. Generate original ideas and choose one.
  4. Develop a test plan.
  5. Implement the plan.
  6. Evaluate the new method. (p. 174)

I find that those six steps share a lot with the 8D method. Step one can be compared to “D2 describe the problem”. Step three need creativity and “D4 determine and verify Root Causes” use tools like Ishikawa diagrams to help think about the larger picture. Then Steps 4, 5 and 6 seems to me really close to the PDCA framework which we also used to drive the corrective and preventive actions using 8D.

Conclusions

Very interesting read. I think the ah-ha moment that this book brings me it the idea that optimizing one team is not optimizing for the customer value and hence for the company. Thinking back at previous read I think I encounter this idea before but I had not grasp it properly so far.

This book makes me want to read Nine Lies About Work cited multiple times.

I would have liked a bit more concrete examples particularly on the Right-First-Time part because I find it really hard in my current job. But I guess that can be a whole book by itself.

I really liked the Obeya/Situation Room concept. I think it would be worth thinking a bit on all the functions associated with it. And how, if possible, we bring them in digital tooling to have an up to date and yet readable situation room. When I work on a somewhat hard issue, I tend to get my pen and paper and draw the system I try to understand… I sort of recreate a mini Obeya for the problem at hand.

Reading this book made me think a lot about my current future ex-company. Even if we tried to get some of these ideas described in the book working, we can’t seems to reach this kind of organization. I think that as soon as a part of the organization does not follow this principles it’s hard get all the benefits. If we can’t agree what’s an MVP we can iterate on (and end up being way to big…) well then it’s hard to get fast delivery/feedback.

I would definitely recommend reading this book.

References

From the book

  1. Nine Lies About Work, Marcus Buckingham and Ashley Goodall
  2. Tyrion: a tool (from Theodo to add debt comment in code to monitor quality
  3. Maximizing Developer Effectiveness: A blog article that provides some metrics on what’s an highly effective Environment

Others