How lean production control keeps our engineers on engineering

Typing is no longer the scarce resource. Attention that can still do engineering is. Extra hands, human or machine, do not raise output by themselves. Without a production system they move the bottleneck onto review, onto integration, and onto the person who still holds the project in their head. Quality rarely falls on the day the first extra session is opened. It falls later, when two versions of the truth have already entered the product.

We did not start from that observation with a slogan about agents. We started from a factory problem that lean engineering has been describing for decades: how to let more work happen in parallel without letting the system lie, collide or drift. AGELAIOS is built under that constraint. This article explains the production system we use so that our engineers spend their time on engineering, and so that extra capacity multiplies finished work rather than unfinished inventory.

From the factory floor to project work

Lean did not begin as a software method. It began as Toyota’s answer to a physical factory that could not afford waste, piles of half-finished parts, or defects discovered at the end of the line. Taiichi Ohno’s production system is built on a small set of stubborn ideas: produce only what the next step can actually take, stop the line when a defect appears, make the state of the work visible, and refuse to hide a problem inside inventory [1]. James Womack, Daniel Jones and Daniel Roos later gave the West a name for that system, lean, and showed that it was a production logic rather than a national trait [2].

Project work is not a car plant. Design is full of uncertainty. A schedule drawn too early fills the gaps with guesses. Glenn Ballard took the same production logic into that world with the Last Planner System. The unit of control is no longer a task on a Gantt chart. It is a promise that someone actually accepted, taken only when the work is ready, measured by the share of promises kept, and studied through the reasons why a promise broke [3][4]. Lean product development added two further ideas that matter in a software factory: keep several design alternatives alive until evidence eliminates them, and put the project on a wall that is a projection of facts, not a theatre of status [5].

Those are the values. The rest of this article is how they are implemented, mechanically, in the system that builds AGELAIOS. The house tool around that system is a production-control register. It is not a chat log and it is not a board that someone paints green on Friday.

Waste is unready work, not idle people

Ohno’s first enemy is waste. In a software factory the most expensive waste is not a developer who paused to think. It is work started before its conditions exist: an ambiguous requirement, a missing predecessor, an arbitration that nobody has given, a document that no longer matches the spec. Launching more sessions on that pile does not create throughput. It creates rework, token burn, and a review queue that nobody can honestly clear.

The countermeasure is make-ready, then pull. An engagement enters the frontier of the graph only when its predecessors have been kept and its readiness conditions are true. Three kinds of precedence keep that graph honest.

1. Finish to start: B does not begin until A has been kept.
2. Interface: B may start on A’s frozen contract, but a change to that contract invalidates B.
3. Information: B must see the result of A, without being blocked by it.

Nobody pushes six sessions onto a heap of topics. The coordinator pulls the next ready engagement, and only that. The people doing the work never see the whole graph. Their context contains the written rules of the repository, the promised scope, and the contracts of their predecessors. The operator sees the whole graph. That split is deliberate. A person who must reconstruct the project from memory is not doing engineering. They are acting as the company’s DNS.

This is also why extra capacity can multiply action without multiplying chaos. Parallel sessions are allowed on the frontier. They are refused on work that is not ready. Speed comes from flow, not from the number of windows open.

A promise has to be accepted

A task can be assigned to you without anyone asking whether you can hold it. A promise cannot. At Penrose the unit of work is a commitment: a request, a promise, a delivery, an acceptance. The person or session able to produce the result examines the request, checks that the expected outcome is understood, and decides whether it can reasonably be promised. Then they deliver. The person waiting accepts, or says what is missing.

That rule is the same for a commercial proposal and for a scoped implementation session. Sales carries the customer’s request. It does not take the delivery promise in someone else’s name. An agent session carries a bounded engagement. It does not carry the product. The culture chapter Promises rather than tasks states this for the company. The production system enforces it for the factory.

Five things are explicit on every engagement: who promises, to whom, which verifiable deliverable, by when, under which readiness conditions. A deadline is not slid in silence. If it cannot be kept, the engagement is marked broken, with a typed reason: ambiguous specification, dependency, estimation, abandonment, technical, no response. A new engagement is proposed if the work is still owed. Breaking and restarting keeps the measure honest. Quietly moving the date falsifies it.

Ballard called the measure Percent Plan Complete: kept promises over promised promises [3][4]. We use it as a reliability signal for the system, not as a score for a person. That distinction is not cosmetic. A metric that decides a career will be gamed, and the culture chapter Progressing without playing employee of the month exists for that reason. We do not publish a PPC figure here. It is an internal instrument, regenerated from the register. Publishing it as a commercial claim, without a way for the reader to replay it, would turn a measurement into a boast. What we can state, because it is a rule rather than a result, is that every broken promise carries its reason, and that reason is used to improve the system rather than to shame whoever could not hold it.

Human obligations live in the same register. Answering an arbitration, accepting a specification change, reviewing a delivery: these are response commitments, with the same deadline and the same measure. If agents are waiting on a person, that wait is a fact on the board, with everything it freezes downstream. The bottleneck becomes visible. It stops being a corridor anecdote.

Concurrency without collision, competition without theatre

Two kinds of collision destroy parallel work. The first is a file collision: two writers on the same tree. Isolated workspaces remove that. The second is an intention collision: two engagements that believe they own the same requirement module. Isolated directories do not see that. A reservation register does. Scope is claimed atomically. The first reservation to land wins. The second takes the next ready item on the frontier. There is no meeting to decide who spoke first. A lost race is not an insult. It is production control.

Reservations expire. Nothing is reserved forever. An abandoned claim returns the work to the frontier with a variance reason, so the next session can resume the branch or start from the main line. Integration itself is serialised. Two deliveries do not merge onto the main branch in parallel. Each is checked against an up-to-date state. That looks slow. It is what prevents two incompatible truths from entering the product on the same morning.

Competition, in this system, is not a contest between people. It is a contest between designs. Lean product development calls it set-based concurrent engineering: several alternatives stay alive, with explicit elimination criteria, until evidence removes them, as late as the decision can still be reversed [5]. A specification-change proposal may carry more than one option. Agents can prototype those options in parallel, each in its own workspace. The option that violates a measured criterion is eliminated, and the elimination is written down. Status does not win. The alternative proposed by the most senior person is not retained because it came from the most senior person. Experience helps to form better hypotheses. It does not turn a hypothesis into a fact. The culture chapter Writing what must survive, deciding without theatre is the same rule for humans.

When a product question appears, the session stops. It does not invent a more convenient specification. An ambiguity of wording becomes a change proposal. A genuine design choice becomes an arbitration request: one page, addressed to a named human, on the A3 pattern of context, closed question, costed options, downstream impact, recommendation, and a fallback if the decision-maker is silent [6]. The person who asks does the preparation. The person who decides only has to judge. An open question is not publishable. An option without a measured consequence is not an option. It is a preference.

We do not pretend the fence around a session is a security boundary. A reminder can stop a mistake. It cannot stop intent. The real control is the convention of the engagement, plus verification after the fact. Saying so is the same posture we take on the public product: limits are stated with the same precision as capabilities.

One fact, several projections

A project dies in two ways that look opposite. Either the knowledge lives in someone’s head, and the company is that person’s calendar. Or everything is written somewhere, and somewhere is a six-month message thread that nobody can replay. Lean visual management is the refusal of both. The obeya, the big room of Toyota product development, is supposed to make the state of the work obvious from facts [5]. A board filled in by hand starts lying within two weeks. Ours is generated from versioned files. It cannot stay green out of politeness.

The same rule governs the product artefacts.

The specification is the only source of what the product must do. Tests are named against that source. A criterion without an automated test is treated as unmet. User-facing documentation is derived from the specification. It is not a second novel, maintained by goodwill. After a delivery is integrated, the documentation that depends on the touched requirements is regenerated. If a reviewer rejects the generated text, the correction is not typed into the manual. It is written back into the specification, then the manual is generated again. Hand-editing the derived document would recreate the drift that the system exists to prevent. Client documentation also stays a client document: it does not expose the internal machinery of the requirements dossier.

Traceability is therefore not a slide assembled before an audit. It is a matrix generated from the same files that the work already uses: requirement, implementation, test, document. The dashboard, the matrix and the manual are three projections of one state. When they disagree, the disagreement is a defect of the source, not a communications task.

Reports follow the same discipline. A figure published in a delivery record is produced by a versioned instrument, and the record names the command that produced it. A figure copied from memory ages in silence. We learned that the expensive way, more than once, when a narrative summary and its own generated report disagreed. The narrative is not the evidence. The instrument is.

Engineers can leave for a week without becoming the index of the project. Someone joining a subject they do not yet know can read why a choice was made, which alternatives were eliminated, and which promise currently owns a given module. That is what Writing what must survive, deciding without theatre asked of conversations. The production system makes it the default, not an act of virtue.

Where the engineer actually spends time

The point of extra capacity is not to retire judgement. It is to stop spending judgement on coordination that a system can hold.

An engineer at Penrose still does the work that does not compress: framing the requirement, choosing among costed options, reading a delivery against its definition of done, and stopping a line that should not continue. The culture chapter Being able to say stop before it is too late is that last duty, written for humans as well as for sessions.

What the production system takes off that person is the rest. Ready work is already identified. Collisions of intent are already reserved. The document will not silently diverge from the spec. A broken date has a face. A product question has a named decision-maker. Several implementation sessions can then run in parallel on the frontier, each in a bounded workspace, each against a promise that someone accepted.

We do not claim that this replaces a team. We claim that a team without production control cannot absorb extra hands without lowering the bar, because the extra speed has nowhere honest to go. The house system exists so that multiplied action still meets the same definition of done: tests, a report, a scope, a regenerated document, an integration against current main. On the product, that bar is already public: about 930 automated tests, 9 continuous-integration chains, a bit-for-bit reproducible image factory. On the factory, the bar has the same shape. A promise is not kept because the work felt finished. It is kept when its definition of done is true.

Organisations that want to see this discipline applied to an instance, a module or an architecture workshop can write to us. The proofs of the platform remain in the public repository. The factory is not in that repository. The product is, and the factory exists so that speed does not get to rewrite it.

Sources

1. Taiichi Ohno, « Toyota Production System: Beyond Large-Scale Production », Productivity Press, 1988
2. James P. Womack, Daniel T. Jones, Daniel Roos, « The Machine That Changed the World », Rawson Associates, 1990
3. Glenn Ballard, « The Last Planner System of Production Control », PhD thesis, University of Birmingham, 2000, https://etheses.bham.ac.uk/id/eprint/4789/
4. Glenn Ballard, « Improving Work Flow Reliability », Proceedings of the 7th Annual Conference of the International Group for Lean Construction, 1999, https://leanconstruction.org.uk/wp-content/uploads/2018/09/Ballard.pdf
5. James M. Morgan, Jeffrey K. Liker, « The Toyota Product Development System: Integrating People, Process, and Technology », Productivity Press, 2006
6. Durward K. Sobek II, Art Smalley, « Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System », Productivity Press, 2008