--- slug: toc-software-devops type: pattern summary: "Apply TOC to software delivery: read the pipeline as a flow system, find and protect the constraint, subordinate other work, and keep it visible." created: 2026-05-21 updated: 2026-06-07 related: five-focusing-steps: relation: specializes note: "ToC for Software and DevOps is the software-delivery specialization of the Five Focusing Steps: identify the delivery constraint, exploit it, subordinate upstream and downstream work, elevate only after exploitation, and repeat when the constraint moves." constraint-type-identification: relation: uses note: "Software constraints can be capacity, policy, paradigm, or market constraints; the pattern fails when every queue is treated as if it were the binding constraint." drum-buffer-rope: relation: complements note: "The deployment pipeline can be read as a DBR-like flow system: the constrained step sets the pace, release discipline limits upstream work, and time-based protection keeps the constraint fed without flooding it." buffer-management: relation: uses note: "WIP aging, blocked-work review, and deployment-risk signals play the role buffer penetration plays in production and project environments." critical-chain: relation: complements note: "Software delivery often carries both flow work and project work; Critical Chain and Agile CCPM cover the project side while this pattern names the operating-system side." agile-ccpm: relation: complements note: "Agile CCPM is the TOC project-management bridge for software teams; ToC for Software and DevOps is the broader delivery-system bridge." flow-metrics: relation: measures note: "Flow metrics make the non-physical constraint visible: work in process, cycle time, throughput, aging work, blocked time, and flow efficiency replace the visible queue in front of a machine." throughput-economics-software: relation: complements note: "Throughput Economics for Software Organizations supplies the financial frame for deciding which software-delivery improvements and roadmap choices are worth the scarce engineering capacity they consume." throughput-accounting: relation: depends-on note: "The software pattern still judges improvement by the joint movement of throughput, inventory/investment, and operating expense, even when the throughput unit is feature value, subscription renewal, deployment reliability, or customer outcome rather than a manufactured unit." --- # ToC for Software and DevOps > **Pattern:** A named solution to a recurring problem. *The application of TOC to software delivery and IT operations: read the delivery pipeline as a flow system, find the constraint that limits value reaching users, exploit and protect it, subordinate surrounding work to it, and keep the constraint visible as it moves.* *Also known as: DevOps TOC; Phoenix Project TOC; constraint-focused software delivery.* Most software teams meet TOC through a story before they meet it through certification vocabulary. In *The Phoenix Project*, Bill Palmer's IT organization behaves like Alex Rogo's plant: work piles up, local priorities collide, Brent becomes the scarce expert everyone needs, and every department can explain why its emergency deserves priority. The setting changes from a factory to IT, but the logic holds. A delivery system still has a goal, a constraint, dependent events, statistical fluctuations, work-in-process, and measurements that either expose or hide the constraint. ## Context Software delivery and IT operations sit in the knowledge-work side of TOC. The work is intangible, and queues often hide inside ticket systems, pull requests, calendars, and approval rules. The constraint may be a person, a review policy, an automated test stage, a release gate, a deployment window, or market demand for the next useful increment. The flow is real even when it is not physical: an idea becomes a ticket, the ticket becomes code, the code passes review and tests, the release reaches production, and the user either receives value or does not. The application stands on three bodies of work. The TOC side supplies the [Five Focusing Steps](five-focusing-steps.md), [Drum-Buffer-Rope](drum-buffer-rope.md), [Buffer Management](buffer-management.md), [Critical Chain](critical-chain.md), and [Throughput Accounting](throughput-accounting.md). The DevOps side supplies the Three Ways: flow, feedback, and continual learning. The software-specific TOC literature supplies the bridge. *The Phoenix Project* makes the translation memorable, while Ujigawa and Updegrove show how CCPM changes when software scope and duration are discovered during execution rather than known up front. Software organizations should not copy factory controls literally. The useful claim is narrower: software delivery is still a constrained flow system, so the TOC question remains valid. Which part of the system limits value reaching the goal right now? ## Problem Software organizations are full of plausible constraint candidates. Code review is slow. The test suite is unreliable. Security approval takes a week. Deployments happen once a month. A senior engineer reviews every database change. Product managers keep changing priority. Operations will not accept the release. Sales has sold work the platform cannot support. Any one of those may be a bottleneck; only one is the constraint that limits the system right now. Without a constraint discipline, improvement effort disperses. One team adds more developers while the deployment window stays monthly. Another team automates tests that weren't the constraint. A third lowers review standards to raise local output and sends more defects downstream. The organization reports motion while value to users remains limited by the same step as before. ## Forces - **Software queues are easy to hide.** Waiting work lives in ticket columns, pull-request lists, incident backlogs, change-advisory boards, and chat promises rather than in visible inventory piles. - **The constraint can be a person, policy, or paradigm.** Brent may be the visible capacity constraint, but the deeper constraint may be the rule that sends every change through Brent or the belief that only Brent can touch production. - **Local efficiency feels virtuous.** Keeping every developer fully assigned increases work started, not work finished; it often starves the constraint with context switching and floods it with half-ready work. - **Automation can improve the wrong place.** Automating a non-constraint step is useful only when it protects or eventually elevates the system constraint; otherwise it makes local work faster without moving goal-unit flow. - **Agile autonomy and system-level commitment pull against each other.** Teams need adaptability, but the organization still owes customers cost, schedule, scope, security, reliability, and support commitments. - **The constraint moves quickly.** A deployment bottleneck can become a test-data bottleneck after one good platform change; a Brent constraint can become a market or policy constraint once knowledge is spread. ## Solution Run software delivery as a constraint-focused flow system, using the DevOps feedback loop to keep the TOC loop current. **Identify the delivery constraint.** Start with the goal: value delivered safely to users, measured in terms the organization actually uses, such as customer outcomes, protected revenue, subscription renewal, incident reduction, or a regulatory obligation met. Then trace the flow from idea to production and support. Look for the point where work waits longest, aging work accumulates, expediting happens most often, or one person, test environment, approval rule, or release window sets the pace. Use [Constraint Type Identification](constraint-type-identification.md) before acting. A capacity constraint, policy constraint, paradigm constraint, and market constraint require different moves. **Exploit the constraint before adding capacity.** If the constraint is deployment approval, remove avoidable rework before approval: clearer change packages, complete test evidence, smaller releases, better rollback plans. If the constraint is a scarce reviewer, route only ready work to that reviewer, move obvious checks upstream, and protect review time from interruption. If the constraint is a fragile test suite, stop treating failures as random noise. Quarantine unstable tests, fix the highest-failure tests first, and keep the constraint running on work that can pass. **Subordinate surrounding work.** Limit upstream work-in-process to what the constraint can absorb. A team that keeps starting work because developers are free is not subordinating; it is building inventory ahead of the constraint. The release plan, sprint commitments, review queues, incident work, and customer promises all have to answer to the constraint's rate. In DevOps terms, this is the flow rule behind small batches and work-in-process limits. In TOC terms, it is the same subordination rule DBR uses when the rope prevents over-release to the floor. **Elevate only after exploitation and subordination are exhausted.** Add reviewers, buy test infrastructure, expand environments, automate deployment, train more people, or change the architecture only after the existing constraint has been fully exploited. Elevation is not forbidden; premature elevation is. Hiring a second Brent before removing the Brent-policy constraint preserves the policy and doubles the dependency. **Repeat when the constraint moves.** Successful DevOps work moves constraints. Deployment frequency improves and test data becomes the limit. Test data improves and security review becomes the limit. Security review improves and the market doesn't know what to do with the new release cadence. The process of ongoing improvement continues only if the team stops protecting yesterday's constraint and returns to identification. Buffer Management translates into software through time and aging signals rather than physical buffer penetration. Aging pull requests, blocked tickets, deployment queue age, incident wait time, escaped-defect aging, and change-failure recovery time are the signals that tell the team which work needs attention and where the next improvement target sits. The exact metric set belongs in [Flow Metrics for Knowledge Work](flow-metrics.md); the constraint discipline is the pattern here. ## How It Plays Out **The Brent constraint.** In *The Phoenix Project*, Brent is the archetypal human constraint: he knows the legacy systems, production configuration, database behavior, and emergency fixes. Everyone needs him; nobody can get him reliably. The TOC reading is not "Brent works too slowly"; it is that the organization depends on Brent's knowledge and approval. Exploitation protects his time and filters requests before they reach him. Subordination stops teams from starting work that will require unscheduled Brent intervention, while elevation spreads the knowledge, automates repeatable checks, and changes the policy that made one person the path through production. **A deployment pipeline with a monthly change window.** A financial-services platform can build, test, and package changes daily, but production release happens once a month through a change-advisory board. The visible queue is the release backlog, but the constraint type is policy: the board's approval batch sets the system's pace. Exploitation improves change packages and rollback evidence so the board's time isn't spent reconstructing risk. Subordination limits release candidates to changes that can be reviewed cleanly. Elevation changes the policy: lower-risk changes move to an automated standard-change path, while high-risk changes keep board review. The goal isn't "deploy more"; the goal is more safe value reaching users. **A software project adopting Agile CCPM.** A product organization has enough uncertainty that absolute task-duration estimates don't hold. Ujigawa and Updegrove's Agile CCPM formulation keeps the TOC project-management logic but replaces absolute time estimation with relative size estimation, velocity-based buffer management, and a scope buffer. The project still has a critical chain and a buffer; what changes is how the team estimates and reads the work. The move matters because software uncertainty is often real, not laziness or poor discipline. > **⚠️ Do not turn TOC into local automation:** Automating a non-constraint can be useful, but it is not the TOC move unless it protects, exploits, subordinates to, or elevates the current constraint. The common software failure mode is to automate the step the platform team owns because the platform team can automate it, while the release policy, security gate, or customer-feedback loop remains the system limit. ## Consequences **Benefits:** - **Improvement effort concentrates.** Teams stop treating every slow queue as equal and direct automation, hiring, policy change, and architecture work at the current constraint. - **DevOps vocabulary gets a TOC spine.** Flow, feedback, and continual learning become the operating expression of the Five Focusing Steps. - **Work-in-process limits become defensible.** Limiting work started is no longer a team preference; it is the subordination rule required to keep the constraint from being flooded. - **The Brent problem becomes structural.** The organization can distinguish a scarce expert from the policy and knowledge-transfer failures that made the expert scarce. - **Software uncertainty is handled without abandoning TOC.** Agile CCPM shows how relative sizing, velocity, and scope-buffer thinking can preserve TOC project discipline in software environments where absolute task estimates are weak. **Liabilities:** - **The physical-production analogy can mislead.** A software queue is not inventory in the factory sense, and a deployment pipeline is not a literal shop floor. The analogy earns its keep only where it helps identify and protect the constraint. - **The pattern can be reduced to "find the bottleneck."** That shortcut loses the TOC distinction between a bottleneck and the system constraint, and it often misses policy and paradigm constraints. - **Local productivity measures fight the pattern.** Story points completed, tickets closed, pull requests opened, and server utilization can all improve while the delivery constraint remains unchanged. - **The constraint can move faster than governance updates.** A team may improve the deployment pipeline and keep running the same change-review ritual after the policy is no longer protecting anything binding. - **DevOps and TOC communities use overlapping words differently.** Throughput, flow, buffer, and constraint all need the TOC definitions when the discussion is certification-grade; casual DevOps usage can blur them. The result is a software organization that treats delivery as a system, not a set of team-local backlogs. The operational question becomes sharper: what limits value reaching users now, and what has to change so that limit is exploited, protected, subordinated to, or elevated? ## Sources - Kim, Behr, and Spafford, [*The Phoenix Project*](https://openlibrary.org/works/OL16806686W) (2013) — the canonical narrative bridge from *The Goal* to IT operations and DevOps, including the Brent constraint, work-in-process overload, deployment failure, and the Three Ways framing. - Kim, Humble, Debois, and Willis, [*The DevOps Handbook*](https://openlibrary.org/works/OL19730495W) (2016) — the practitioner expansion of the Three Ways, small-batch flow, feedback, and continual-learning practices that make the DevOps side of this pattern executable. - Forsgren, Humble, and Kim, [*Accelerate*](https://openlibrary.org/works/OL19542983W) (2018) — the empirical DevOps performance work that supplies the modern measurement vocabulary for software delivery speed, stability, and organizational outcomes. - Ujigawa and Updegrove, "*Agile* CCPM: Critical Chain for Software Development" (TOCICO White Paper Series, 2016) — the TOCICO-recognized software-specific extension of CCPM, with relative size estimation, velocity-based buffer management, and scope-buffer handling for software uncertainty. - Goldratt and Cox, [*The Goal*](https://openlibrary.org/works/OL2463051W) (1984) — the originating production-flow story whose constraint logic *The Phoenix Project* deliberately transports into IT operations. - Goldratt, [*What Is This Thing Called Theory of Constraints and How Should It Be Implemented?*](https://openlibrary.org/works/OL4186015W) (1990) — the formal Five Focusing Steps source for the identify, exploit, subordinate, elevate, and repeat sequence applied here to software delivery. - Cox, *TOCICO Dictionary* (2nd ed., 2012), entries "constraint," "bottleneck," "five focusing steps," "drum-buffer-rope," "buffer management," "critical chain," and "process of ongoing improvement" — the certification-grade vocabulary this software translation cross-checks against. - Schragenheim, Camp, and Surace, "Using Throughput Economics to Make Better and Safer Business Decisions" (TOCICO, 2022) — the contemporary TOC decision-economics extension that underwrites the adjacent software question: which roadmap, platform, or capacity move is worth scarce engineering capacity under uncertainty? --- - [Next: Flow Metrics for Knowledge Work](flow-metrics.md) - [Previous: Knowledge Work and Software](knowledge-work-software.md)