How Intelligent Manufacturing Planning Reduces Supply Chain Disruptions

Welcome to the June Edition of LMNAs Chronos

A Note to Our Community

Hi from the LMNAs team,

Before anything else — June has been the month we've been quietly building toward for a long time, and we can barely contain it. Something big is almost ready to come out from behind the curtain, and July's edition is going to look a little different from the rest because of it. Keep reading — we're saving the reveal for the end of this issue, and it's worth the wait.

Now, onto what's been on our minds this month.

This month, we kept coming back to a question every delivery leader has asked at least once, usually right after a sprint retro:

If the team is strong and the plan was solid, why does delivery still slip?

Across IT delivery, the answer doesn't live in any one team's performance. It lives in the space between planning and execution — where a plan stops reflecting reality long before anyone notices.

This edition follows that gap from where it starts to where it gets closed.

Before You Read On

Picture this.

Two teams ran the exact same sprint length, with the exact same number of stories, and roughly the same team size.

One delivered on time, with capacity to spare. The other missed the sprint, blamed "unplanned work," and started the next sprint already behind.

Same length. Same stories. Same size. Wildly different outcomes.

Hold that image in mind. By the end of this edition, the reason will be clear.

IT Planning Deserves the Same Discipline as Manufacturing Planning

Manufacturing figured this out decades ago.

Before a factory makes one unit, planners already know the demand, the capacity, the materials, the bottlenecks.

IT teams forecast the same way — just work instead of units.

Requirements → Capacity → Resources → Technical Readiness → Delivery → Release → Continuous Improvement.

Miss a dependency, and delivery slips. Misjudge an estimate, and the team overloads. PMI research backs this up — shifting priorities are the single biggest driver of project failure.

The best-performing organizations aren't the ones with the best developers. They're the ones with the best planning discipline.

So where does that discipline actually break down?

Are you planning or just reacting to workload?

Five stages exist in every delivery org — Forecast, Demand, Resourcing, Execution, Delivery. Each one quietly disconnects from the others:

Forecasts built on outdated assumptions
Commitments made without checking capacity
Resources confirmed on paper, delayed in practice
Execution inheriting broken assumptions, absorbing unplanned work
Monitoring catching the failure only after it's too late to fix

A plan looks realistic on day one. By day ninety, it often looks like fiction.

Not because teams failed — because they spent the sprint protecting a plan instead of adapting it.

That's the disconnection at 30,000 feet. Here's what it feels like at standup.

The Sprint Management Gap Most Teams Don't Know They Have

No real-time view of sprint status. No dashboard for velocity, burn-down, or time-to-go. No planned leave factored in before commitments are made.

Not a discipline problem. A tooling problem.

Spreadsheets, email, tribal knowledge — and nobody can say with confidence what's actually committed, in flight, or at risk.

When it works, it looks simple: live dashboards, leave accounted for upfront, workload distributed by real capacity, sprint health monitored continuously.

Three posts in, the problem is clear at every altitude. Now — what actually fixes it?

Capacity Planning Shapes Delivery Stability — Day by Day

Monday's sprint plan looks solid. By Wednesday, it's not.

A bug Tuesday. Back-to-back meetings Wednesday. A production issue Thursday. The story slips Friday.

Why? Capacity gets planned once a sprint — not once a day.

Daily planning changes the math:

See exactly who's available, every day
Allocate reviews against real availability
Account for leave before it becomes a surprise
Adjust tomorrow's plan as today's constraints emerge

Teams planning this way stop over committing and start delivering consistently.

That's the fix at the sprint level. The next two posts carry it through testing and development.

Manual Testing Was Killing the Release Cycle

A full year behind on Frappe/ERPNext upgrades. Not from lack of will — from the sheer weight of manual testing across reports, transactions, workflows, APIs, and emails.

LATP (LENS AI Test Pilot) automated all of it.

Upgrade frequency: quarterly → weekly (4x faster)
Time to test 10 sites: 2–3 weeks → 2 days (95% faster)
QA headcount needed: 8–10 people → 2 (75% reduction)
Version lag: 1 year → 3 months (9 months recovered)

A team of two now tests what used to take eight to ten.

Testing stopped being the bottleneck. The next gap was everything before it.

Planning Was Solid. Testing Was Automated. Development Was a Black Box.

Releases planned. Testing automated. Releases still failed.

The gap was development itself — siloed workflows, scattered documentation, change impact discovered by QA instead of caught before it.

Chordium closed it — embedded in the IDE, tracking every change, flagging impact early, turning history into documentation automatically.

Quality slips: 5–10% → 1–2%
Release cycles: 2–3 weeks → weekly
One standardized workflow, zero silos

LENS IPS for planning. Chordium for development. LATP for testing. Three stages, one connected pipeline.

Connected Delivery in Numbers

4x faster upgrade frequency
95% less time spent testing across sites
75% fewer QA resources needed
9 months of version lag recovered in 3 months
Quality slips down from 5–10% to 1–2%
Release cycles down from 2–3 weeks to weekly

Not marginal gains. The difference between defending a broken plan and knowing exactly what you can deliver.

The Answer!

Two teams. Same sprint length, same stories, same size. One delivered with room to spare. The other missed the sprint and blamed "unplanned work."

The reason was never the work — or the people.

One team planned capacity once a sprint, against a snapshot. The other planned it every day, against reality.

The daily team saw Tuesday's bug and Wednesday's meetings coming, and adjusted before they became Friday's missed story. The weekly team only saw them after the sprint had already broken.

Same plan on paper. A completely different relationship to reality.

What Caught Our Eye

Plandek's 2026 Engineering Productivity Benchmarks, drawn from delivery data across more than 2,000 software engineering teams, put a number on the exact gap this edition has been circling.

High-performing teams spend over 41% of their engineering time on roadmap delivery. Lower-performing teams spend less than 21% — the rest eaten by bugs, incidents, and unplanned work. The predictability gap is just as stark: top teams complete more than two-thirds of what they plan each sprint, while the bottom quartile finishes less than half.

The report's most interesting finding, though, is about AI. Teams are shipping code faster than ever, but for teams with unstable planning or slow review cycles, that speed doesn't translate into faster or more predictable delivery — it just exposes the bottleneck instead of removing it. Faster typing doesn't fix a broken plan.

That's the same story we've been telling all month, just backed by a different data set.

Future Updates

July: The Beginning of an AI-Native Enterprise Platform

July marks a defining milestone for LMNAs.
After months of engineering, countless architectural decisions, and a clear vision for the future of enterprise software,

We are introducing LensCloud.

Not as another hosting platform.
Not as another deployment service.
But as the foundation for the next generation of enterprise applications.

We believe infrastructure should disappear into the background. Developers should focus on building business capabilities — not managing Kubernetes clusters, certificates, backups, or deployments. Businesses should innovate faster without being constrained by operational complexity.

That philosophy is what shaped LensCloud.
Built on a Kubernetes-native architecture and designed specifically for the Frappe ecosystem, LensCloud enables organizations to deploy, operate, and scale ERPNext with enterprise-grade reliability while preparing for what comes next: AI-native business applications.
And this is only the beginning.

LensCloud is the platform that will power the entire LENS Experience Suite—from LENS ERP and CRM to CPQ, LENSIPS, and the intelligent services that will connect them.
Because we don't believe AI should be an add-on.
We believe AI should be part of the platform itself.

Coming This July...

future updates

Throughout July, we'll take you behind the scenes and share the engineering, ideas, and philosophy behind LensCloud:

LensCloud Launch— Meet the AI-native platform purpose-built for the Frappe ecosystem.
From Zero to ERP in Minutes— Experience how quickly enterprise infrastructure can disappear behind a seamless deployment experience.
Engineering LensCloud— Explore the architectural decisions, Kubernetes-native foundation, and platform engineering principles behind the product.
Beyond Hosting— Why we believe enterprise platforms must evolve from infrastructure management to intelligent capability platforms.
Inside the Platform— Follow the complete customer journey, from provisioning to day-to-day operations.
Building for Enterprise Scale— Reliability, security, automation, and the engineering practices that prepare businesses for growth.

Whether you're planning your ERPNext journey, modernizing your infrastructure, or exploring the future of AI-enabled enterprise software, July's edition will provide an inside look at the philosophy, architecture, and technology driving the next chapter of the LENS Experience Suite.
This isn't just the launch of a platform.
It's the beginning of our vision for how enterprise software should be built—and how it should evolve in the age of AI.

Subscribe here — you won't want to miss this one.

Thank you for reading — and for the trust you place in us each month.

Team LMNAs

Reader's Corner

IT Planning Deserves the Same Discipline as Manufacturing Planning "The best organizations aren't the ones with the best developers — they're the ones with the best planning discipline."

Are you planning or just reacting to workload? "What started as executing the plan gradually became protecting the plan."

The Sprint Management Gap Most Teams Don't Know They Have "It's not that teams don't want to plan better. It's that they lack a single connected system."

Capacity Planning Shapes Delivery Stability — Day by Day "Daily visibility reveals what sprint-level planning hides."

Manual Testing Was Killing the Release Cycle A team of two now tests what once required eight to ten people.

Planning Was Solid. Testing Was Automated. Development Was a Black Box."A planning system that people avoid using is not a planning system. It is an expensive gap."

Feedback and Suggestions

If something in this edition resonated — or if there's a planning challenge you're facing that we haven't addressed — we would genuinely like to hear it.