My discovery of the Lean Tech Manifesto: when agility meets lean
Pure coincidence in timing: I was finishing reading this book a few days ago when Fabrice Bernhard took the stage during our Jumpstart to pitch the Lean Tech Manifesto. An excellent opportunity to put some “live context” on what I had been able to read and interpret.
The Lean Tech Manifesto was born from the reflections of Fabrice Bernhard and Benoit Charles-Lavauzelle on their way of working, generating value and efficiency within their agency Theodo. Before going further in my review of this book, I must admit that I particularly embraced its spirit. I’m already a fan of agile methodologies, but I also have proximity to lean approaches, having worked in a consulting firm specialized in lean and lean six sigma.
This dual experience allowed me to approach this book with a critical but benevolent eye, and I must say that I come away convinced.
A book I recommend without hesitation
I strongly encourage you to read this book, for several very concrete reasons. First, it’s remarkably well done: I find it well written, easy to read, quick to go through. It’s very clear and quite concise, which isn’t always the case with this type of methodological work.
But what seduced me the most is the wealth of concrete examples it contains. These practical cases really allow you to project the concepts onto your own activity, which transforms reading from a simple theoretical exercise into a genuinely applicable reflection. Throughout the pages, I was able to say “hey, that’s exactly the situation we experienced last year” or “that’s what we could implement tomorrow”.
The Lean Tech Manifesto: my understanding of this evolution
The first concept to remember from this book is undoubtedly the Lean Tech Manifesto itself. This manifesto comes to overlay the Agile Manifesto that we all know in our industry. It brings concepts that are closer to lean than to traditional agile.
As a reminder, here’s the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The definition of the Lean Tech Manifesto according to the authors
The authors propose their own manifesto that enriches and complements the agile approach. This manifesto is structured around four pillars that complement existing agile values:
Value for the customer
- Over customer collaboration
- Over contract negotiation
This hierarchy places customer value at the top, which speaks to me enormously. Rather than just collaborating with the customer, it’s about truly creating value for them. It’s a higher level of requirement that fundamentally changes our approach.
A tech enabled network of team
- Over individuals and interactions
- Over processes and tools
The idea of a network of teams connected by technology rather than isolated individuals resonates with my experience. I’ve seen the difference that a truly connected team can make versus individual talents working in silos.
Right first time and just in time
- Over working software
- Over comprehensive documentation
This approach of “right first time and just in time” goes further than simply “working software”. It’s a requirement for quality and timing that truly reflects the lean spirit applied to development.
Building a learning organisation
- Over responding to change
- Over following a plan
Rather than simply reacting to change, the goal is to build a learning organization. This is probably one of the most ambitious and difficult points to implement, but also one of the most important for sustainability.
Why this evolution was necessary in my opinion
If the Agile Manifesto was created in reaction to the waterfall model, the Lean Tech Manifesto comes, in my opinion, to intelligently incorporate lean concepts into our work methodology by focusing on value and meaning.
What particularly convinced me is the authors’ explanation that the agile methodology, as it was created, cannot meet the necessary growth needs of our domain - both in volume and speed. It’s an analysis I totally share, having observed these limits in several professional contexts.
The concepts that marked me the most
My vision of leadership according to this book
In the field of leadership, the authors develop concepts with which I’m personally very aligned. Three ideas particularly resonated with my experience:
The fundamental role of the leader is to act as an arbitrator when the group encounters a crisis. This vision reminded me of several situations where I had to play this role, and I find that it’s indeed one of the most important - and most difficult - responsibilities of leadership.
The leader’s role is also to facilitate consensus. Rather than imposing their vision, it’s about creating conditions for the team to collectively find the best solution. It’s an approach I try to apply daily, even if it’s not always obvious.
Finally, making sure that self-organization takes place as much as possible. This is probably the ultimate goal: creating an environment where the team can function autonomously and efficiently.
Problem solving: the importance of timing
Several times, the authors talk about quality and problem solving. They notably develop an idea that I find absolutely fundamental: the most important thing isn’t the problem itself, but the moment at which it’s detected.
This perspective really marked me because it puts things in perspective. The problem isn’t having problems - that’s inevitable - but detecting them before they end up in production or with the client. This approach completely changes how we approach quality and testing in our projects.
Applying lean principles to digital
The authors also detail all lean principles while trying each time to apply them to the field of software development and the digital world. What impressed me is the wealth of very concrete examples they propose.
I won’t detail them all here - that would be rewriting the book - but this part allowed me to make connections between concepts I knew in manufacturing industry and our daily life in digital. It’s particularly valuable when you have, like me, experience in both worlds.
What I take away for my practice
In conclusion, I would say that this book is very interesting because it allowed me to put a certain structure and certain words on practices that we know, that we sometimes practice, or that we don’t know yet.
I also think that this book can be an excellent introduction to lean methodology. It introduces a number of important concepts from this approach that have proven themselves around the world in different types of industries and business sectors. Some may sometimes seem like common sense, but they are nevertheless very well detailed and explained.
It’s certainly a book that will stay on top of my pile of books on my bedside table, not too far away, and which I can refer to when I try to explain certain things to my team. It’s now part of my references for explaining how we can evolve our agile practices towards something more mature and adapted to current challenges.
Check it on the official website