Lean Thinking for Busy Software Developers: the definitive version, now also in print

Version 3.0 of "Lean Thinking per sviluppatori software impegnati" rewrites chapters 1 to 6 from reader feedback and carries agentic AI through the whole text, not just the chapter devoted to it. And there is now a print edition, 6x9 inches (15.24 x 22.86 cm), 316 pages. The book is written in Italian; an English edition is coming later this year.

Lean was born on a factory floor. Software is not a factory. The book started from that sentence, and it is the reason most Lean books for developers end up in a drawer: they apply manufacturing recipes to a craft whose raw material is ambiguous requirements, not standardised bolts.

Today the version I consider definitive comes out, and with it the printed edition. Paper was always part of the plan, but you send a book to the printer when it is finished, not while you are still writing it. It is finished now, so here it is on Amazon in print as well.

What I have seen in the teams I taught Lean to

The book comes from there, not from a reading list. I do consulting and training on these principles inside real companies, and the speed at which a team comes back to life once it stops fighting its own process still surprises me. People who said nothing in the first meeting stop you in the corridor two months later to tell you how the board should be changed.

Then comes the uncomfortable part. Once the flow of work is visible to everyone, it almost always turns out that the bottleneck was not the team. It was priorities rewritten every Monday, approvals sitting for days on somebody’s desk, work started three times and never finished. Very often it was management that noticed first, and admitted that the problem to fix was its own. That is when things really started moving.

Software House Nightmares

One of the analogies I use most often came from television. If you have never seen “Kitchen Nightmares”, the mechanism is always the same: a restaurant is about to close, the chef spends a few days there, watches how people actually work during service, turns the place upside down and leaves behind a kitchen that works. Nobody ever mentions production or processes, and yet almost everything the chef imposes is Lean: he cuts a menu of eighty dishes down to ten done properly, empties freezers full of stock bought months ago, puts the kitchen back in order because wasted movement is visible to the naked eye, watches the service live instead of listening to what the staff say about it, and before leaving gives a demoralised brigade its dignity back. Reduced variety, inventory, wasted motion, going to see for yourself, respect for people. Those are the same chapters.

You could shoot “Software House Nightmares” without changing a line of the method. The artifact changes: the dish becomes a release, the walk-in freezer becomes a backlog of four hundred tickets nobody will ever open, Saturday night service becomes the Friday deploy. The principles stay where they are.

That happens because they are principles and not rules, and it is a difference our trade keeps missing. A principle survives a change of context: “make stalled work visible” holds in a kitchen, on a shop floor and in a repository. A rule does not. A rule has to be rewritten every time the context changes, because it was calibrated on the previous one. And we in software are excellent at writing rules, complete with their numbers: two-week sprints, 80% coverage, a WIP limit of five, four ceremonies a week. Then the team changes, the product changes, and the rule keeps applying out of inertia while nobody remembers the principle that produced it.

That is why the book explains every principle in its original context, Toyota’s, and then re-invents it for software instead of decanting it. If you have understood the principle, when the context changes you rewrite the rule yourself, which is the only thing that really matters.

“Kitchen Nightmares” began as “Ramsay’s Kitchen Nightmares”, a format created and produced by Optomen Television for Channel 4 and distributed worldwide by All3Media International; Gordon Ramsay hosts the British and American editions. Local adaptations exist in several countries. Titles, formats and trademarks belong to their respective owners: I mention them here purely as an analogy, with no connection to the programme or its producers.

What is inside the book

Chapters 1 to 6 are rewritten from reader feedback: the reasoning is more conversational, and the scenarios come from the real working day of someone who writes software rather than from an assembly line.

The numbers are there to be redone. Little’s law in the form that actually helps, Lead Time = WIP / Throughput, and a work in progress table built on stated assumptions, a team of five and tasks of eight person-days, so you can check line by line what happens when you go from three parallel jobs to one. Every quotation goes back to the primary source, and some of them hold surprises: the word “Lean” was not coined by Womack and Jones in 1990, it belongs to John Krafcik, in a 1988 article that came out of his research at MIT.

Then there are the pages I use myself first: the closing cheat sheet, the table of the 7+1 muda with a column of concrete examples, the Lean code review checklist.

The twenty-four diagrams exist for that reason, to show in one figure what takes two pages in prose. The three pillars everything else rests on, for instance.

Agentic AI does not stay in one chapter

When I started writing, AI assistants completed lines of code. Today they open pull requests.

There is a dedicated chapter, but confining AI in there would have been convenient and false. Agents shift the balance everywhere, so the subject comes back wherever it belongs: in flow, in estimates, in WIP limits, in code review, in the way quality is judged. Where AI changes nothing I say nothing, and where it changes something I say it at the point where the reader is already wondering about it.

There is an objection I hear often: if AI writes the code for me, Lean matters less. It is exactly the opposite. When the cost of producing code collapses, everything else stays where it was: waiting for approvals, feedback loops that take weeks, the time work spends sitting in a queue. If you used to write a feature in three days and wait seven for the deploy, the imbalance was tolerable. Now that you write it in two hours, those seven days become intolerable and glaringly visible.

This is the diagram that accompanies the chapter on flow. Count the days: almost all of them are waiting, and not one of those boxes gets shorter because an agent writes the code for you.

The book describes three wastes that could not have existed in the Toyota Production System.

Vibe coding: generating code without understanding it, accepting it as long as it seems to work. It is technical cargo cult in a modern edition, adopting the outward forms (the code compiles, the functions get called) without the substance. Every line accepted without understanding it is technical debt you do not see when you sign it and pay on every maintenance.

Then there is generative overcapacity. Classic overproduction comes from a developer who decides to build something “while we are at it”; here it is the agent building while it thinks: variants nobody asked for, invented edge cases, error handling for scenarios the system never contemplates. All of it work somebody will have to maintain anyway.

The last one is verification overhead, the cost of critically reading what the agent produces. It is not zero and it appears in no estimate. The agent does not know your architectural conventions, nor the implicit business rules the team has accumulated over the years. If you do not count that time, generation speed looks like productivity and it is not.

Why paper

Because a lot of you asked for it. Some people happily read on screen, and some prefer paper for a book they consult: it stays open next to the keyboard, you annotate the margins, you find the page you need without opening anything. It is a matter of taste, and version 3.0 now covers both.

The print edition is 6x9 inches, that is 15.24 x 22.86 cm, 316 pages, cream paper. The twenty-four diagrams were redone specifically for print, so on the page they read the way they read on screen.

Who it is for, and who it is not for

If your team writes code faster than it manages to get it into production, the bottleneck is not the keyboard. This book helps you find it and remove it, with what you already have in the building: the board you look at every morning, the numbers of your own flow, Friday afternoon’s code review. It is written for senior developers, tech leads, architects and CTOs of small technical companies, that is for people who actually write code and have no time to waste on theory. The examples are in Python for readability, but the principles hold in any language.

The book is not for managers looking for motivational slides, nor for consultants looking for a framework to resell. And it is not a book about the Toyota Production System: Toyota is the historical premise, not the subject.

Where to find it

The Kindle and print editions are on Amazon: EUR 9.99 for Kindle, EUR 19.90 for the paperback. The digital version also stays on Leanpub, with updates included as always for anyone who already bought it.

One thing to be clear about: the book is written in Italian. An English edition is planned within the year. Spanish, Brazilian Portuguese and German depend on how many people ask for them, so if you want one of those, write to me at d.teti@bittime.it and say which language. Enough requests and I will get it translated.

If the book was useful to you, the most useful thing you can do is leave an honest review. For a self-published technical book those few lines count for more than any campaign.