Lean Agile Center of Excellence
POSTS
How Transformations Get Built
The craft behind the diagnosis: the concrete artifacts and methods that make transformation actually work.
Why Transformations Stall
A field guide to the governance, data, and culture problems no framework solves, and where AI takes them next.
Reconciling Many Business Units Into One Process Model
Reconciling Many Business Units Into One Process Model
Ask several business units how they do the "same" thing and you get several different answers: different steps, different names, different definitions of the same words. Getting them onto one process model is one of the most foundational things a transformation does, and it is a negotiation disguised as a diagramming exercise.
In any enterprise made of multiple business units, the same activity: selling, quoting, onboarding a customer...
The Overlay Pattern: Adding Capability Without Ripping Out the CRM
The Overlay Pattern: Adding Capability Without Ripping Out the CRM
When an enterprise's systems are fragmented, the reflex is to replace them all with one. That is the slowest, most expensive, and most politically explosive path there is. The overlay pattern is the pragmatic alternative enterprises rarely write up: add the missing capability as a thin layer above the systems you already have, and leave them running.
An enterprise wakes up to the cost of fragmentation: many separate systems...
Agile in Name, Waterfall in Practice
Agile in Name, Waterfall in Practice
An organization can decide to adopt a framework overnight. It cannot decide to change how it actually thinks about building software. The gap between the two gets paid, quietly and personally, by whoever is standing in the middle.
Why Transformations Stall
At some point a leadership team decides the organization is "going agile": adopting a scaled framework, standing up trains, running planning events, renaming the roles. The decision is real, the in...
The Living Backlog: Making Your Artifacts Something Stakeholders Actually Open
Most transformation artifacts are produced, filed, and never opened again. All the rigor underneath them — the traceability, the prioritization, the structure — is wasted the moment no one will navigate it. A living backlog is the opposite: a current, navigable view of the work that stakeholders open on their own, because it answers their question in seconds.
There is a particular kind of waste that transformations rarely notice, because it looks like completion. An enormous amount of effort ...
Standing Up a Portfolio From Nothing
Standing Up a Portfolio From Nothing
Plenty of organizations have a great deal of activity and no portfolio — no coherent layer that says what initiatives exist, how they connect, who owns them, what's at risk, and when they land. Assembling that layer where none existed is quiet, unglamorous work, and it is what turns scattered motion into something an organization can actually steer.
Walk into a large program mid-flight and you will usually find no shortage of work. Teams are busy, initi...
The Runway Problem: Why You Can’t Prioritize a Backlog You Can’t Yet Build
A backlog tells you what the business wants. It says nothing about what can actually be built next, or what has to exist first. That missing information — the architectural runway — is why "what should we invest in?" so often has no honest answer, and why teams end up fed by hand.
You can produce a beautifully structured backlog — epics, features, user stories, all prioritized by business value — and still be unable to answer the one question leadership actually asks: what should we invest in...
Mapping Both Value Streams as One Picture
Two value streams run underneath every transformation: how the business delivers value to customers, and how the organization builds the systems that make that possible. They are almost always mapped separately, by different people, in different languages — which is exactly why the business and the technology drift apart. Putting both on one picture is the artifact that keeps them aligned.
Ask the business how it works and you get a story about process: how an order becomes a delivery, how a ...
WSJF Without the Theater
Weighted Shortest Job First is a genuinely good way to prioritize — and one of the easiest to turn into theater. The arithmetic is the trivial part. The honesty of the inputs is the whole game, and it is exactly the part organizations skip.
Prioritization is where most programs quietly go to war. Everyone's feature is the most important; every deadline is the hardest; every team believes its work should be first. Into that fight walks Weighted Shortest Job First — WSJF — with a promise that s...
The Shared Data Contract: Why Master Data Is Epic Zero
Every cross-unit ambition an enterprise has — a unified customer view, coordinated selling, trustworthy reporting, anything with "AI" attached — rests on one agreement that usually does not exist: agreement on who the customer actually is. That agreement is the real first deliverable, and almost no one funds it first.
Ask a large, multi-division enterprise a deceptively simple question — how many customers do you have? — and watch the answer fall apart. The same account turns up again and aga...
Reverse-Engineering Requirements From a Prototype
A prototype is the best tool there is for discovering what people need — and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan.
An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react t...
Epics as Hypotheses, Not Projects, and the Review That Makes It Real
Framing a big initiative as a hypothesis instead of a project is a genuine advance. But a hypothesis is a contract that requires a counterparty: someone to read the evidence and decide. Write rigorous hypotheses into an organization with no review gate, and you have produced the paperwork of agility with the behaviour of waterfall.
There is a real and valuable shift in how mature organizations frame large investments. Instead of defining a big initiative as a project, "we will build X, by dat...
The Traceability Chain: From Interview to User Story Without a Broken Link
Most backlogs cannot answer the two questions that matter most: why does this item exist, and if the business need behind it changes, what do we have to rebuild? A traceability chain answers both.
Pick any story in a large product backlog and ask the team a simple question: why does this exist? In most organizations the honest answer is a shrug, or a name — "someone asked for it," "it came out of a workshop," "it's been in there since the last planning cycle." The provenance is gone. The item...
When Building Is Cheap: Why AI Turns Delivery Teams Into Discovery Teams
Artificial intelligence does not remove the hard part of enterprise work. It removes the easy part — building — and leaves an organization face to face with everything it was using the difficulty of building to avoid.
Every article in this series has circled the same quiet truth from a different direction: in large enterprise change, building the software was rarely the real problem. The real problems were knowing what was worth building, trusting the data underneath it, deciding who owned th...
The Prototype Is the Requirement: Why Interviews Alone Stopped Being Enough
The old model asked people what they wanted and wrote it down. The new one shows them something and watches what they do. The difference is the difference between stated needs and real ones.
For most of the history of enterprise software, gathering requirements meant the same sequence of moves. An analyst or product owner interviewed stakeholders, ran workshops, and asked people what they needed. The answers were captured in a document — a requirements specification, a set of user stories, a ...
You Can’t Transform on Data No One Trusts
Agile frameworks are built to ship visible value in cadence. The data foundation everything rests on is invisible — which is exactly why it gets starved.
There is a moment in a lot of transformation programs worth learning to watch for. A leader is shown a number — year-to-date orders, pipeline coverage, the size of an account — and instead of using it to make a decision, they visibly set it aside. Sometimes they say it out loud — they no longer trust a number they are handed until they have ...
The Ownership Vacuum: Why Transformations Stall When No One Owns the Outcome
Frameworks like SAFe give you the org chart of accountability. They cannot give you the accountability itself — and knowing the difference is most of the job.
From a distance, most stalled transformations look like delivery problems. The teams are busy. The roadmaps are detailed. The status reports are green more often than they have any right to be. And yet, quarter after quarter, the thing the business actually wanted — a unified view of its customers, a faster quote, a pipeline number a le...
The Business–Digital Divide: How Transformations Lose the People They’re Meant to Help
The ceremonies of a scaling framework are a trust-manufacturing machine. Run them as theater, and they manufacture only the appearance of trust while the real thing drains away.
The most quietly devastating moment in a transformation program is rarely about budget or architecture or scope. It is a senior business leader concluding, without drama, that engaging with the transformation is no longer a good use of their time — and simply stopping. Not being difficult. Being honest. Deciding to re...
agile transformation AI and product business case change management data strategy discovery enterprise architecture governance lean UX MDM portfolio management prioritization process mapping product management product ownership prototyping requirements SAFe traceability value stream mapping