11.6 Value stream mapping and cost of delay

Overview and motivation

Ask ten people on a delivery team where the time goes between an idea and a result in production, and you will get ten different guesses. Most of them will be wrong, and most will be optimistic. The reason is that everyone sees their own step clearly and the waiting between steps not at all. A developer knows a feature took two days to code. Nobody tracks the eleven days it then sat in a review queue, a test environment booking, a change-approval board, and a release window. The work is done in hours and lost in queues. This chapter gives you two lenses to see that whole picture and to act on it: value stream mapping, which makes the flow from idea to value visible, and cost of delay, which puts an economic price on the waiting so you can prioritise with money instead of opinions.

These two lenses complement the rest of Part 11. Chapter 11.1 describes the discovery pipeline that decides what to build, and chapter 11.2 describes the delivery pipeline that ships it. Value stream mapping stretches across both, treating the entire path from first thought to measured outcome as one system to be seen and improved. Chapter 11.3 gives you the mathematics of queues; this chapter gives you the practice of finding where those queues actually form in your organisation and what they cost. Where 11.4 (OKRs) and 11.5 (KPIs) tell you what good looks like, cost of delay tells you the sequence in which to pursue it.

For large teams, the payoff is enormous. Coordination across dozens of teams multiplies handoffs, and every handoff is a place where work waits. In enterprise settings, a feature can cross a product team, a platform team, a security review, and a release-management function before it reaches a customer, and the wait between those groups usually dwarfs the work inside them. In government, multi-year programmes commit public money against legislated deadlines, and an unmapped value stream hides both waste and risk from the people accountable for the spend. Making flow visible and pricing delay honestly is how large organisations stop arguing from anecdote and start deciding from evidence.

Key principles

See the whole flow from idea to value, not just the step you own.
Separate process time (real work) from wait time (pure delay); the gap is your opportunity.
Measure flow efficiency, and expect it to be shockingly low before you improve it.
Find the one bottleneck that governs throughput, and stop optimising everywhere else.
Price delay in money so priority becomes an economic decision, not a volume contest.
Sequence work by cost of delay divided by duration, not by who argues loudest.
Treat value stream management as an ongoing practice, not a one-time workshop.

Recommendations

Map the value stream from idea to value

A value stream is the full sequence of steps your organisation performs to turn a request into delivered value. Mapping it means walking that sequence and writing down each step, who does it, and, for each one, two numbers: process time (the time work is actively being done) and lead time (the total elapsed time from when the step could start to when it hands off, including all waiting). Do this for a representative work item, from the moment the idea is accepted to the moment its effect is measured in production. Include the discovery steps from chapter 11.1 and the delivery steps from chapter 11.2. The result is a single diagram of your real system, not the one on the org chart.

Resist the urge to map the idealised process. Map what actually happened to three or four recent items, using timestamps from your tools rather than memory. You are looking for the truth, and the truth lives in the gaps between steps. The first time a team does this honestly, someone always says a version of “I had no idea it sat there for a week.” That reaction is the point. You cannot improve a flow you have never seen whole.

Separate process time from wait time, and compute flow efficiency

Once you have the numbers, add them up. Flow efficiency is the ratio of value-add time to total lead time: the sum of process time divided by the total elapsed time from start to finish. If a feature takes 40 hours of actual work but 20 business days to travel the stream, its flow efficiency is roughly 40 divided by 160, or 25 percent, and that would be unusually good. Many real streams land between 5 and 15 percent. The rest is pure waiting: work sitting in a queue, blocked on a dependency, or parked in someone’s inbox.

This number reframes every improvement conversation. When flow efficiency is 15 percent, making the work itself 20 percent faster improves the total by only three points, while removing half the waiting nearly doubles your speed. Teams instinctively try to code faster, review faster, test faster. The map tells you that the leverage is almost never in the working steps and almost always in the waiting between them. Chase the whitespace, not the boxes.

Name the handoffs and rework loops

Two structures on the map deserve special attention. Handoffs are the points where work passes from one person or team to another, and each one is a queue where an item waits for the next party to have capacity. Every handoff also loses context, so the receiver spends time reconstructing what the sender already knew. Rework loops are the arrows that go backward: a failed test that returns code to the developer, a rejected change that goes back to a review board, a clarification that sends a story back to product. Rework loops are expensive twice over, because they consume capacity and because the reworked item rejoins a queue at the back of the line.

Count both. A stream with nine handoffs and three rework loops will have terrible flow efficiency no matter how skilled the people are, because the structure itself manufactures waiting. Reducing handoffs (by giving a team end-to-end ownership) and eliminating the causes of rework (by moving quality checks earlier, per chapter 11.2) usually beats any effort to speed up individual steps.

Find the bottleneck and respect the theory of constraints

Every value stream has exactly one step that limits its throughput, the way the narrowest point in a pipe limits flow. The theory of constraints, from Eliyahu Goldratt, gives you a discipline for it: identify the constraint, exploit it (make sure it is never idle and never working on the wrong thing), subordinate everything else to it (do not feed it faster than it can absorb), elevate it (add capacity), and then repeat, because the constraint will have moved. The crucial and counterintuitive rule is that improving any step other than the constraint improves nothing. Speeding up a non-bottleneck step just piles inventory in front of the bottleneck faster.

Find your constraint on the map: it is the step with the longest and most persistent queue in front of it. In software it is frequently a shared, specialised resource such as a single security-review function, a lone database expert, or a scarce test environment. Once you know it, protect it. Do not let it sit idle waiting for input, do not make it do work a cheaper step could do, and think hard before you optimise anything downstream or upstream of it. The whole system moves at the pace of that one step.

Use cost of delay to prioritise with economics

Cost of delay is the money you lose, or fail to gain, for each unit of time a piece of work is not yet delivered. It is the economic weight of “later.” A feature that would earn 100,000 dollars a month, delayed by two months, costs 200,000 dollars whether or not that number ever appears in a budget. Making this explicit is the single most powerful antidote to the “everything is priority one” pathology that plagues large backlogs. When every stakeholder insists their item is urgent, you cannot resolve it with volume; you resolve it by asking each one, “What does a month of delay cost us?” and putting the answers side by side.

Estimating cost of delay does not require precision. A rough figure, agreed by the people who understand the value, beats a false consensus that everything matters equally. Consider three components: the value itself (revenue, cost savings, risk reduction), the time sensitivity (does the value decay if we wait?), and any hard deadline (a regulation, a contract, a seasonal window). This connects directly to the estimation and forecasting discipline of chapter 10.15: you are forecasting value at risk, not just effort. The number does not need to be right to the dollar. It needs to be right enough to change the order in which you work.

Sequence with CD3 and weighted shortest job first

Cost of delay tells you what is expensive to delay, but it does not by itself tell you what to do first, because a hugely valuable item that takes six months may be a worse first pick than a moderately valuable one you can finish this week. The rule that resolves this is cost of delay divided by duration, written CD3. You compute cost of delay per item, divide by how long the item takes, and do the highest ratio first. This is a software application of weighted shortest job first (WSJF), a scheduling result which proves that dividing delay cost by job length minimises the total economic cost across a whole queue of work.

The insight WSJF encodes is that short, valuable jobs should jump the line, because finishing them quickly frees the queue and starts their value sooner while barely delaying anything else. A long job, however valuable, holds up everything behind it. In practice you estimate cost of delay and duration on simple relative scales, compute the ratio, and let it order your backlog. The framework used by many scaled organisations expresses WSJF as cost of delay (built from business value, time criticality, and risk-or-opportunity enablement) divided by job size, which is the same idea with named components.

Read the urgency profile of each item

Not all delay costs behave the same over time, and the shape matters as much as the size. An urgency profile describes how the cost of delay changes as you wait. Some value is roughly linear: you lose about the same amount each week indefinitely. Some has a fixed date, a step function, where delay costs nothing until a deadline and then a great deal all at once (a regulatory cutover, a contractual go-live). Some decays: a market window or a competitive first-mover advantage that is worth a fortune now and little in six months. And some is nearly flat, worth the same whenever you ship it.

Knowing the profile changes your sequencing. A steep decaying-value item should go now, before the value erodes. A fixed-date item can wait until just enough lead time remains, then must not slip. Plotting the urgency profile for your major initiatives, even roughly, tells you not just how much delay costs but when the cost lands, which is exactly what you need to schedule under contention.

Connect flow metrics to DORA and to Little’s Law

Value stream mapping produces four ongoing flow metrics worth tracking continuously: lead time (elapsed time from start to done), cycle time (elapsed time for a specific stage, often the active delivery portion), work in progress (WIP, the count of items in flight), and throughput (items completed per unit time). These are bound together by Little’s Law from chapter 11.3: average lead time equals average WIP divided by average throughput. That equation is your most practical lever, because it says that if you cannot easily raise throughput, you can shorten lead time immediately by lowering WIP. Starting less finishes more.

These flow metrics also connect upward to the DORA metrics (from the DevOps Research and Assessment programme): deployment frequency, lead time for changes, change-failure rate, and time to restore service. Lead time for changes is a slice of your value stream, and the mapping shows you which steps to attack to improve it. Treat DORA as the outcome scoreboard and the value stream map as the diagnostic that explains the score, tying both into the engineering-effectiveness view of chapter 1.10.

Manage queues, batch size, and WIP deliberately

The queues you found on the map are where lead time is born, and chapter 11.3 explains why they explode as utilisation climbs toward 100 percent. Two levers tame them. The first is WIP limits: cap the number of items allowed in each stage so work is pulled only when there is capacity, which directly shortens lead time via Little’s Law and exposes the bottleneck instead of hiding it under a mountain of started-but-unfinished work. The second is batch size: large batches (a quarterly release, a giant pull request, a big requirements document) create long queues, delay feedback, and raise the cost and risk of every handoff.

Smaller batches flow faster and more predictably, which is one of the deepest reasons the delivery pipeline of chapter 11.2 favours small, frequent, reversible changes. Reducing batch size and capping WIP are the two most reliable, lowest-cost interventions you can make, because they attack the waiting directly rather than trying to make the work itself faster.

Trade-offs: pros and cons

Practice	Pros	Cons
Value stream mapping	Reveals hidden waiting; aligns teams on one picture	Snapshot can go stale; effort wasted if no action follows
Flow efficiency metric	Redirects effort to the waiting, where the leverage is	Can be gamed by redefining what counts as active work
Theory of constraints focus	Concentrates effort where it actually moves throughput	Hard politically to leave non-bottleneck teams alone
Cost of delay	Turns priority into economics; deflates “all urgent”	Estimates are uncertain and can be argued or inflated
CD3 / WSJF sequencing	Minimises total economic delay; favours quick wins	Needs two estimates per item; false precision risk
WIP limits	Shortens lead time immediately; exposes bottlenecks	Feels like enforced idleness; resisted culturally
Small batch size	Faster feedback, lower risk per change	Higher per-item overhead if automation is weak

The central tension is between the effort of measurement and the honesty it forces. A value stream map and a cost-of-delay model both take work to build, and both can be gamed or left to rot if the organisation is not serious. The failure mode is a mapping workshop that produces a beautiful diagram and no changes, or a cost-of-delay number that every stakeholder inflates until it is meaningless again. Resolve this by tying the practice to action and to a small set of tracked flow metrics. A map is worth making only if you will attack the bottleneck it reveals, and a cost-of-delay estimate is worth arguing only if it will actually reorder the backlog. Precision is not the goal; a better decision is.

Questions to discuss with your team

If we mapped our real value stream from idea to production for the last three features, what would our flow efficiency actually be, and where is the biggest pool of waiting? Most teams have never computed this and are startled by the answer, because the working steps they see feel busy while the waiting between them is invisible. Bring timestamps from your tools rather than memory, and walk one recent item end to end, writing process time and total lead time for each step. The evidence you want is the single largest gap between when work could have moved and when it did. That gap, not the speed of any individual, is your first target, and naming it out loud is usually enough to make the team want to fix it.
Where is our one true constraint, and are we accidentally optimising everything except it? The theory of constraints says only the bottleneck governs throughput, yet teams routinely pour effort into steps that are already fast because those steps are the ones they control. Look for the step with the longest, most persistent queue in front of it, and be honest about whether recent improvements touched it or merely made a non-bottleneck faster. The uncomfortable but valuable conclusion is often that a shared, scarce resource (one reviewer, one environment, one specialist) sets the pace for everyone, and that protecting and elevating that resource matters more than any local speed-up elsewhere.
When two stakeholders both say their work is priority one, how do we decide today, and would cost of delay give us a different order? Right now the answer is probably seniority, volume, or whoever escalated hardest, none of which reflects economic value. Bring two genuinely contested items and try to estimate, even roughly, what a month of delay costs each one and how long each takes, then compute cost of delay divided by duration. The point is not the exact numbers but the conversation they force: stakeholders who must attach a delay cost to their request suddenly reason differently, and the item that wins on economics is frequently not the one that was winning on volume. Watch what that does to the room.
Which handoffs in our value stream could we remove or collapse, and who would have to give up control for that to happen? Every handoff is a queue and a loss of context, so the count of handoffs often predicts flow efficiency better than the skill of any team, yet handoffs persist because they encode ownership, approval rights, and someone’s sense of accountability. For a large organisation this is where the map turns political: collapsing a handoff usually means giving one team end-to-end ownership and asking a control function to trust an automated gate instead of a manual sign-off. Bring the handoff-by-handoff wait times, the rework loops that each handoff triggers, and an honest note on which handoffs exist for real risk reasons versus historical habit. In enterprise and government settings, name the control owner for each contested handoff and what evidence (a passing automated check, an audit trail, a delegated authority) would let them accept its removal, because a handoff nobody will relinquish is a permanent tax on your lead time.
How confident are we in the cost-of-delay numbers we are using to sequence work, and what stops every stakeholder from simply inflating theirs? Cost of delay only breaks the “everything is priority one” tie if the estimates carry some discipline; the moment each party learns that a bigger number wins, they all produce bigger numbers and you are back to a volume contest wearing an economic costume. The competing consideration is that demanding precision kills the practice, since rough figures agreed by people who understand the value are the whole point, so you need enough rigour to compare items without pretending to a false accuracy. Bring a few real estimates broken into their components (value, time criticality, deadline pressure) and look for the ones that are suspiciously round or unbacked. For an enterprise portfolio or a government programme spending public money, decide who arbitrates disputed numbers and whether estimates get checked against realised outcomes later, because a cost-of-delay model nobody calibrates against reality is one everyone will eventually game.
Do we actually manage work in progress and batch size deliberately, or do we let both drift upward until lead time quietly doubles? Little’s Law makes the lever concrete: lead time equals work in progress divided by throughput, so uncontrolled WIP lengthens every item’s wait even when no one is working slower, and large batches compound the effect by stuffing the queues you already found on the map. The tension is cultural, because capping WIP feels like enforced idleness and small batches feel like extra overhead, so teams resist both even though they are the cheapest interventions available. Bring your current WIP counts per stage, your typical batch sizes (release, pull request, requirements document), and the lead-time trend that goes with them. In a large or public organisation, tie this to the release and change-approval cadence you are contractually or procedurally bound to, since a quarterly release window or a monthly board can force big batches on you, and naming that constraint is the first step to negotiating it down.

Sector lens

Startup. With a handful of engineers and little runway, your value stream is short but your constraint is usually a person: a single founder who approves everything, or the one engineer who owns deploys. Do not run a heavy mapping exercise; spend half a day tracing the last few features by timestamp, find the human bottleneck, and delegate or batch around it. Skip formal cost-of-delay models and use a rough cost-of-delay-divided-by-duration ranking to end the weekly “what do we build next” argument, and keep batches tiny so feedback stays fast while you are still learning what the market wants.

Small business. You have no flow-metrics specialist and a tight budget, so lean on the tooling you already pay for: pull timestamps from your issue tracker and version control rather than buying a value-stream platform. Map one representative work item, compute a back-of-envelope flow efficiency, and attack the single largest pool of waiting, which is often an approval that sits with one busy owner. Treat cost of delay as a conversation, not a spreadsheet product to purchase, and prefer cutting work in progress and batch size (both free) over any tool that promises to visualise flow for a monthly fee.

Enterprise. The value lives in seeing across many teams, where a feature crosses product, platform, security, and release management and the waiting between groups dwarfs the work inside them. Standardise value stream mapping as a repeatable practice, make cost of delay divided by duration the shared prioritisation language so groups stop arguing from volume, and enforce WIP limits and smaller batches to expose the real constraint rather than hiding it under started-but-unfinished work. Tie flow metrics to DORA and Little’s Law so the portfolio has one diagnostic and one scoreboard, and put governance around who owns the constraint and who arbitrates disputed delay estimates.

Government. Procurement rules, transparency duties, and public accountability shape every choice, and a legislated deadline usually dominates the urgency profile of everything else. Map the stream across policy, engineering, security accreditation, and operations, because the hard constraint is frequently an accreditation or compliance gate with a queue measured in months, and elevating it (adding reviewers, moving evidence-gathering upstream) buys more than any downstream speed-up. Make value stream management a standing practice with a regular review so oversight bodies get auditable evidence that flow, not just spend, is improving, and price cost of delay openly so the sequencing of public money can be explained and defended.

Examples

Startup. A fifteen-person startup keeps missing its own roadmap and blames the engineers. A half-day value stream mapping session tells a different story: features spend most of their life waiting for the single founder who approves every design and every release. Flow efficiency is under 10 percent, and the founder is the constraint. They apply the theory of constraints directly: the founder delegates design approval below a size threshold, batches releases into a daily window instead of ad hoc sign-offs, and stops being fed more decisions than she can make. Lead time roughly halves within a month, with no new hires. They then adopt a simple cost-of-delay-divided-by-duration ranking for the backlog, which quietly ends the weekly argument about what to build next.

Enterprise. A large bank maps the value stream for a customer-facing change and finds it crosses nine teams with a lead time of eleven weeks, of which about six days is actual work. The rest is queues: a security review that runs monthly, a change-approval board that meets weekly, and environment bookings measured in days. Rather than push teams to work faster, the bank attacks the waiting: it moves security review earlier and automates most of it (per chapter 11.2), converts the weekly board to a lightweight standing approval for low-risk changes, and caps WIP so teams finish before starting more. Cost of delay becomes the portfolio’s prioritisation language, deflating the perpetual “everything is critical” backlog into a ranked one, and lead time for changes (a DORA metric) drops from eleven weeks to under two.

Government. A national tax agency runs a multi-year modernisation under a legislated deadline. Leadership cannot see where the public money is buying progress, because the programme reports on activity, not flow. The agency maps its value stream across policy, engineering, security accreditation, and operations, and discovers that accreditation is a hard constraint with a queue measured in months. It treats accreditation as the bottleneck to elevate, adding staff and moving evidence-gathering upstream so items arrive review-ready. It prices cost of delay using the urgency profile of each mandate: the fixed legislative deadline dominates sequencing, while flat-value cleanup work waits. Value stream management becomes a standing practice with a quarterly review, giving oversight bodies auditable evidence that the flow, not just the spend, is improving.

Business case: motivations, ROI, and TCO

The return on these practices comes from converting invisible waiting into delivered value sooner. When flow efficiency is 15 percent, most of your lead time is waste you are already paying for in the form of slower feedback, later revenue, and stakeholders who lose faith in the roadmap. Removing waiting is nearly free compared with hiring: WIP limits, smaller batches, an earlier security review, and a delegated approval cost little and often halve lead time. Every week of lead time you remove is a week of value pulled forward, and cost of delay lets you quantify that gain in the same money your leadership already tracks.

Cost-of-delay prioritisation has its own distinct return: by sequencing with CD3 or WSJF, you provably minimise the total economic delay across the whole backlog, which means the same teams, working the same hours, deliver more value simply by doing things in a better order. That is the cheapest improvement available, because it requires no new capacity at all. The cost to adopt is modest and mostly one-time: a few mapping sessions, a lightweight cost-of-delay model, and the discipline to track a handful of flow metrics. The ongoing cost is the honesty to keep the map current and to resist inflating delay estimates.

The cost of neglect compounds quietly. Unmapped streams accumulate handoffs and rework loops that no one is accountable for, backlogs prioritised by volume drift away from value, and the organisation plans around averages while queues explode near full utilisation (chapter 11.3). To make the case to leadership, connect these practices to metrics they already watch: DORA lead time for changes, throughput, and the value delivered per quarter. Frame value stream management as the diagnostic that explains those numbers and cost of delay as the economic logic that improves them.

Anti-patterns and pitfalls

Map and forget: a polished value stream diagram produced in a workshop that leads to no change to the actual flow.
Optimising non-bottlenecks: speeding up steps that are already fast, which just piles inventory in front of the real constraint.
Watermelon flow metrics: green dashboards (high throughput) hiding a red reality (huge WIP and lengthening lead time).
Cost-of-delay inflation: every stakeholder assigns a huge number, restoring the “everything is priority one” tie you were trying to break.
Duration blindness: ranking purely by value and starting a valuable six-month job ahead of ten quick wins, ignoring CD3.
Ignoring the urgency profile: treating a decaying-value item and a flat-value item as interchangeable, and shipping the wrong one first.
Local efficiency worship: keeping every team 100 percent utilised, which maximises queues and lead time rather than flow.
Big-batch releases: bundling changes into rare, large drops that lengthen queues, delay feedback, and raise the risk of each release.
Averages-only planning: using mean lead time and ignoring variability, then being surprised by the long tail (chapter 11.3).

Maturity model

Level 1, Initiate: No one can see the end-to-end flow. Priority is set by volume, seniority, or escalation, and “everything is priority one” is the norm. Waiting between steps is invisible, and improvement effort lands wherever a team feels busy, usually not the constraint. Nobody separates process time from wait time, so the huge pools of queueing go unnoticed and unpriced.
Level 2, Develop: A team or two has mapped at least one value stream and can point to the biggest queues and a rough flow efficiency. Some flow metrics (lead time, WIP) are tracked in pockets, and prioritisation sometimes considers value, but the practice is inconsistent across teams: cost of delay is informal, the map is a one-time artifact, and each group does it its own way if at all.
Level 3, Standardise: Value stream mapping is a documented, repeatable practice used org-wide, the constraint is identified and protected per the theory of constraints, and WIP limits and smaller batches are the enforced standard rather than local experiments. Cost of delay divided by duration (CD3 or WSJF) is the agreed way to sequence backlogs across teams, and flow metrics connect explicitly to DORA using a shared definition of lead time, cycle time, WIP, and throughput.
Level 4, Manage: Flow is measured and controlled with data against baselines. Flow efficiency, lead time, WIP, throughput, and DORA lead time for changes are tracked continuously against agreed targets, with control limits that flag when a stream drifts. Cost-of-delay estimates are calibrated against realised outcomes so inflation is caught, the constraint’s queue is monitored with real numbers, and go or no-go decisions on process changes are made on evidence rather than opinion.
Level 5, Orchestrate: Value stream management is continuous, integrated across the organisation, and adaptive. Urgency profiles inform sequencing, the constraint is elevated and re-identified as it moves, cost-of-delay models are refined from real outcomes, and mapping, prioritisation, and queue management feed one another and the wider portfolio. The organisation rebalances flow as conditions shift and can prove the improvement with auditable evidence.

Ideas for discussion

What is your current flow efficiency, and if you removed half the waiting rather than speeding up the work, how much faster would you be?
Where is your one true constraint right now, and what would it take to keep it from ever sitting idle or doing work a cheaper step could do?
For your top five backlog items, what does a month of delay cost each one, and does ranking by cost of delay divided by duration change the order?
Which of your major initiatives has a decaying urgency profile, and are you at risk of shipping it after most of its value has already evaporated?
If you cut WIP in half tomorrow, what would Little’s Law predict for your lead time, and what cultural resistance would you have to overcome to try it?
How large is your typical batch (release, pull request, requirements document), and what would halving it do to your feedback speed and per-change risk?

Key takeaways

Map the whole flow from idea to value and compute flow efficiency; the waiting between steps, not the work inside them, is where your leverage lives.
Find the single constraint and respect the theory of constraints: optimising any other step improves nothing and just feeds the bottleneck faster.
Make delay costs explicit in money to defeat “everything is priority one,” and read each item’s urgency profile to know when the cost lands.
Sequence with cost of delay divided by duration (CD3 or WSJF) to minimise total economic delay, letting short, valuable work jump the line.
Manage queues with WIP limits and small batches, tie your flow metrics to DORA and Little’s Law, and run value stream management as an ongoing practice.

References and further reading

Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development
Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement
Mike Rother and John Shook, Learning to See: Value Stream Mapping to Add Value and Eliminate Muda
Karen Martin and Mike Osterling, Value Stream Mapping: How to Visualise Work and Align Leadership for Organizational Transformation
Mik Kersten, Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
Dean Leffingwell, SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework