Systems Thinking, Lean and DevOps Models

Introduction

DevOps is often described as a set of practices for combining software development and IT operations. That description is useful but incomplete. DevOps is also a way of understanding and improving a socio-technical system: a system in which people, processes, technology, information, policies and organisational structures interact.

A team may adopt automated testing, infrastructure as code and continuous integration yet still deliver slowly. The reason is that local technical improvements cannot compensate for a system whose work is overloaded, approvals are delayed, priorities change constantly or failures are hidden. DevOps therefore begins with a systems perspective. It asks how work flows from an idea to a reliable outcome, where constraints occur, how feedback is generated and how the whole system can be improved.

This chapter introduces systems thinking, Lean principles, feedback loops, the Theory of Constraints, the Three Ways and the CALMS model. These ideas are complementary. Systems thinking provides the perspective; Lean provides principles for reducing waste and improving flow; the Theory of Constraints focuses attention on the limiting factor; the Three Ways describe a DevOps pattern of flow, feedback and continuous learning; and CALMS provides a practical framework for assessing DevOps capability.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain systems thinking and distinguish system-level optimisation from local optimisation.
2. Apply Lean principles to technology delivery and identify common forms of waste.
3. Describe reinforcing and balancing feedback loops in delivery systems.
4. Use the Theory of Constraints to identify and manage a bottleneck.
5. Explain the Three Ways and relate them to DevOps practices.
6. Use the CALMS model to structure an improvement discussion.
7. Analyse a delivery problem and propose an improvement that is measurable, ethical and sustainable.

1. Seeing Technology Delivery as a System

A system is a set of interacting elements organised to achieve a purpose. In software delivery, the elements include customers, product owners, developers, testers, security specialists, infrastructure engineers, service-desk staff, managers, suppliers, tools, environments, policies and operational data. The system’s purpose is not merely to produce code. It is to create useful, secure and dependable outcomes for users.

Systems thinking emphasises four ideas:

• Interdependence: A change in one part can affect other parts.
• Emergence: System behaviour arises from interactions and may not be predictable from individual components alone.
• Boundaries: Every analysis selects what is inside and outside the system; poor boundaries can hide important causes.
• Purpose: Performance must be judged against the system’s purpose, not against an isolated local target.

For example, a development department may be measured on the number of features completed, while operations is measured on stability and low incident counts. If these measures conflict, developers may push changes toward operations while operations introduces more approval gates. Each department can appear rational while the end-to-end system becomes slower and less responsive.

Local and global optimisation

Local optimisation improves one activity without necessarily improving the whole system. Increasing the number of developers may increase coding capacity, but if testing or deployment is the constraint, queues become longer. Similarly, adding more approval steps may reduce the perceived risk of individual changes while increasing batch size, delay and the difficulty of detecting causes when failures occur.

Global optimisation asks: “How does this decision affect the complete path from customer need to operational value?” This requires visibility of queues, handoffs, rework, waiting time and outcomes.

A useful system boundary is the value stream: the sequence of activities required to deliver a product or service change. It may begin with a customer request and end when the change is operating reliably and its value can be assessed. Mapping this stream makes delays and repeated work visible.

2. Lean Thinking in DevOps

Lean thinking originated in manufacturing but has been adapted to knowledge work and software delivery. Its central concern is delivering value with less unnecessary effort, delay and variability. Lean does not mean simply reducing staff or demanding that people work faster. It means improving the system so that valuable work flows smoothly and problems are addressed at their source.

Five widely used Lean principles are:

1. Specify value: Understand what users, customers or other stakeholders actually value.
2. Map the value stream: Identify all activities, queues, decisions and rework from request to outcome.
3. Create flow: Reduce interruptions, handoffs, batch sizes and waiting.
4. Establish pull: Start work when capacity and demand justify it, rather than continually pushing more work into the system.
5. Pursue perfection: Improve continuously through experimentation and learning.

Value, waste and variability

Value is defined by the recipient of an outcome, not by the activity itself. Writing code, preparing a report or conducting a meeting is not automatically valuable. An activity is valuable when it contributes to a needed outcome and is performed correctly the first time.

Common forms of waste in technology delivery include:

Waste is often a symptom of system design rather than individual carelessness. A developer who starts several tasks may be responding rationally to slow reviews. A tester who maintains a long queue may be constrained by environments or unclear acceptance criteria.

Work in progress and flow

Work in progress (WIP) is work started but not completed. Excessive WIP increases context switching, obscures priorities and lengthens feedback cycles. Limiting WIP is therefore a control on the system, not a restriction intended to punish staff.

A useful relationship for stable delivery systems is Little’s Law:

Here, L is the average number of items in the system, λ is the average throughput in items per unit of time, and W is the average time an item spends in the system. The units must be consistent: for example, items, items per week and weeks. The relationship applies approximately to a stable system over a meaningful observation period, where average inflow and outflow are reasonably balanced. It is not a promise that every individual item will have the average lead time.

For example, if a team has an average of 12 work items in progress and completes 4 items per week, the average time in the system is:

Reducing WIP to 8 items while maintaining throughput of 4 items per week would produce an average time of 2 weeks. However, reducing WIP alone does not guarantee improvement if throughput falls or if work is hidden outside the visible system.

3. Feedback Loops and Learning

A feedback loop occurs when the results of an action influence later actions. Delivery systems require feedback because teams cannot predict every consequence of a change. Examples include automated test results, deployment health checks, security scans, customer behaviour, incident reviews and service-level indicators.

A balancing loop counteracts change and tends toward a target. For example, as error rates rise, an automated rollout controller may reduce deployment traffic or stop a release. This loop seeks stability.

A reinforcing loop amplifies change. For example, reliable automated tests may increase confidence in small releases; small releases produce faster feedback; faster feedback improves the tests and delivery process, which further increases confidence. Reinforcing loops can be beneficial or harmful. A defect that reaches production may create incidents, interruptions and rushed fixes, which create more defects.

Figure: A continuous DevOps feedback loop connecting delivery, operation, measurement and learning.

Feedback is useful only when it is timely, credible and connected to decisions. A report produced three months after a release may be accurate but have little learning value. Feedback must also be psychologically safe. If incident data is used primarily to blame individuals, people will hide problems, weakening the system’s ability to learn.

4. The Theory of Constraints

The Theory of Constraints (TOC), associated with Eliyahu M. Goldratt, proposes that a system’s performance is limited by one or a small number of constraints. A constraint is a factor that prevents the system from achieving more of its goal. It may be a technical resource, a policy, a skill, an environment, a decision process or market demand.

The TOC improvement cycle is commonly expressed as five focusing steps:

1. Identify the constraint. Find the point that most limits end-to-end performance.
2. Exploit the constraint. Use its existing capacity effectively; remove avoidable interruption and rework.
3. Subordinate other activities. Align upstream and downstream work with the constraint’s pace.
4. Elevate the constraint. Add capacity or change the system when exploitation is insufficient.
5. Repeat. Once one constraint is relieved, another may become the limiting factor.

Suppose a delivery system can code 20 items per week, test 8 and deploy 6. Increasing coding capacity is unlikely to improve completed delivery because deployment is the current constraint. Starting 20 items creates queues and increases age. A better approach may be to automate deployment checks, simplify release approval, improve environment availability or reduce the size of changes.

TOC does not mean that all other work is unimportant. It means improvement effort should be prioritised according to system impact. A constraint should be verified with evidence such as queue length, utilisation, waiting time and throughput rather than assumed from reputation or seniority.

5. The Three Ways

The Three Ways are a DevOps teaching model that describes essential patterns of work.

The First Way: flow from left to right

The First Way focuses on the flow of work from development toward operations and customers. Its practices include small batches, trunk-based integration, automated testing, continuous integration, deployment automation, visualisation of work and WIP limits.

The goal is not simply speed. Flow should deliver value safely and predictably. Small batches reduce the amount of change that must be understood when a problem occurs. They also shorten the distance between an idea and evidence of its outcome.

The Second Way: fast and constant feedback

The Second Way improves feedback from right to left. Operations, users and monitoring systems provide information that influences development and design. Examples include production telemetry, automated acceptance tests, security findings, customer support data and post-incident learning.

Feedback should reach the people able to act on it. A dashboard that nobody reviews is not an effective feedback mechanism. Nor is a test that reports failures without making the cause understandable.

The Third Way: continuous learning and experimentation

The Third Way creates a culture in which improvement is a normal part of work. Teams conduct safe experiments, practise failure recovery, share knowledge and investigate systemic causes. This includes blameless post-incident reviews, game days, improvement backlogs and deliberate practice.

The Third Way is not permission for uncontrolled change. Experiments require a hypothesis, a bounded risk, an observation method and a decision rule. Ethical practice requires that users, data and service availability are protected.

6. The CALMS Model

CALMS is a framework for discussing DevOps capability across five dimensions:

CALMS should not be treated as a maturity score that labels teams as good or bad. It is a diagnostic lens. A team may have excellent automation but weak sharing, causing knowledge to remain with a few specialists. Another may measure deployment frequency while ignoring customer outcomes and operational harm.

Measurement and responsible interpretation

Useful delivery measures commonly include:

• Lead time for changes: time from a change being committed or requested to its successful operation, depending on the defined measurement boundary.
• Deployment frequency: how often changes are deployed to a target environment.
• Change failure rate: proportion of deployments that result in rollback, remediation or service degradation, using a clearly defined denominator.
• Mean time to restore: average time required to restore service after a failure, with the start and end points explicitly defined.
• Reliability and customer measures: availability, latency, error rate, user satisfaction and achievement of product outcomes.

Metrics can distort behaviour. If teams are rewarded only for deployment frequency, they may divide changes artificially or deploy low-value work. If incident counts are used to punish teams, reporting may decline. Measures should therefore be interpreted as signals, reviewed together and connected to purpose.

7. Integrated Application: Online Admissions Service

Background

The following is an illustrative case. A university’s online admissions service receives frequent changes during the application season. Development, database administration, security and operations are separate groups. Releases occur every six weeks after a manual approval board. Users experience intermittent failures after releases, and staff often work late to resolve them.

Problem

The university wants faster delivery but must protect applicant data and service availability. Management initially proposes hiring more developers. A preliminary value-stream review shows that coding takes an average of five days, testing takes eight days, security review takes ten days, and release scheduling adds up to two weeks. Work is frequently returned because test data differs from production conditions. Several changes are bundled into each release.

Analysis

Systems thinking reveals that coding capacity is not the main constraint. Security review and release scheduling create large queues, while poor environment consistency produces rework. The system also has weak feedback: production errors are reported through the service desk but are not routinely linked to development priorities.

Lean analysis identifies large batches, waiting, handoffs and rework. TOC identifies the approval-and-release path as the current constraint. The Three Ways indicate the need to improve flow, feedback and learning. CALMS shows strong motivation but weaknesses in automation, measurement and sharing.

Approach

The teams agree on a staged intervention:

1. Define a small, risk-based change classification so routine low-risk changes use automated evidence rather than waiting for a full board meeting.
2. Create a shared delivery team including development, security and operations representatives.
3. Build a standard test environment using infrastructure as code and masked representative data.
4. Introduce automated unit, integration, security and deployment checks.
5. Limit the number of changes in progress and reduce release batch size.
6. Establish production dashboards for error rate, latency and failed transactions.
7. Conduct blameless reviews after incidents and track improvement actions.
8. Measure lead time, change failure rate, restoration time and applicant experience together.

Outcome

After several release cycles, routine changes move through the system more frequently and with less waiting. Failures are detected earlier because deployment checks and production monitoring provide faster feedback. The approval board spends more time on high-risk architectural decisions and less time reviewing routine evidence. The organisation does not eliminate all risk; instead, it makes risk more visible and manages it proportionately.

Learning points

The case illustrates that “go faster” is not a sufficient improvement strategy. The university improved flow by reducing batch size and queues, feedback by connecting telemetry to development, and learning by reviewing incidents without blame. Automation was valuable because it supported a redesigned system; automation alone would not have solved the approval constraint or conflicting measures.

8. Implementation Guidance and Limitations

A practical improvement initiative can begin with a short value-stream mapping workshop. Include people who perform the work and people who receive its outcomes. Record activities, waiting periods, rework loops, queues, policies and information used for decisions. Establish a baseline before changing the system.

Next, select one improvement hypothesis. For example: “If routine low-risk changes receive automated security evidence, average approval waiting time will decrease without increasing the change failure rate.” Define the observation period, measures, safeguards and review date. This makes improvement an experiment rather than a slogan.

Important limitations should be recognised:

• Models simplify reality and can hide power relationships, legal obligations or human effects.
• A constraint may be political or organisational and therefore harder to observe than a technical queue.
• Automation can reproduce incorrect assumptions or create a false impression of safety.
• Metrics can be gamed and may measure activity rather than value.
• Continuous delivery is not appropriate in exactly the same form for every system; regulated or safety-critical environments require evidence, traceability and controlled risk management.
• Small batches reduce exposure but do not remove the need for architecture, security, privacy and accessibility.

Governance should be designed into the flow. Access controls, segregation of duties where justified, audit trails, data minimisation, privacy protection, secure secrets management and rollback or recovery procedures are compatible with DevOps when they are automated, proportionate and based on risk. Ethical practice also requires attention to who may be harmed by service failures, biased automation or inaccessible interfaces.

Contemporary Developments

Cloud platforms, platform engineering and artificial intelligence are changing how delivery systems are designed. Internal developer platforms can provide standardised paths for building, testing, deploying and observing services. Their success should be evaluated by developer experience, reliability and customer outcomes, not by the number of platform features.

AI-assisted coding and operations can reduce routine effort, but generated code and recommendations require review, testing, security assessment and respect for intellectual property and confidential data. AI may amplify feedback loops: it can rapidly generate changes, but without strong tests and monitoring it can also amplify defects. The systems-thinking question remains essential: what new risks, dependencies and bottlenecks does the technology introduce?

Chapter Summary

Systems thinking treats DevOps as improvement of an entire socio-technical delivery system rather than optimisation of isolated departments. Lean thinking focuses on customer value, flow, pull, small batches, reduced waste and continuous improvement. Little’s Law shows the relationship among work in progress, throughput and average time in a stable system.

Feedback loops allow teams to detect outcomes and adjust behaviour. Balancing loops support stability, while reinforcing loops can strengthen either improvement or failure. The Theory of Constraints directs attention to the factor currently limiting system performance. Its five focusing steps are identify, exploit, subordinate, elevate and repeat.

The Three Ways describe flow from development to operations, rapid feedback from operations and users, and continuous learning through experimentation. CALMS provides five complementary diagnostic dimensions: Culture, Automation, Lean, Measurement and Sharing. Together, these models help organisations improve delivery while preserving reliability, security, privacy and human responsibility.

Key Terms

Systems thinking: Understanding how interacting parts produce behaviour in a whole system.

Socio-technical system: A system comprising people, technology, processes, information and organisational structures.

Value stream: The activities and queues through which a request becomes a delivered outcome.

Local optimisation: Improving one component without ensuring improvement to the whole system.

Lean: An approach focused on value, flow, waste reduction and continuous improvement.

Waste: Activity or delay that consumes resources without contributing sufficient value.

Work in progress: Work started but not yet completed.

Little’s Law: The relationship L = λW between average WIP, throughput and time in a stable system.

Feedback loop: A process in which results influence subsequent actions.

Balancing loop: A feedback loop that counteracts change and supports a target or stable condition.

Reinforcing loop: A feedback loop that amplifies change.

Constraint: A factor that limits a system’s ability to achieve its goal.

Theory of Constraints: An improvement approach centred on identifying and managing the system’s limiting factor.

The Three Ways: DevOps principles of flow, feedback, and continuous learning.

Continuous integration: Frequently integrating changes and validating them automatically.

CALMS: Culture, Automation, Lean, Measurement and Sharing.

Change failure rate: The proportion of deployments that require remediation, rollback or cause service degradation under a defined measurement rule.

Blameless learning: Investigation that seeks systemic causes without using hindsight to assign personal blame.

Review Questions

5 Short Answer Questions

1. What is meant by local optimisation in a DevOps system?
2. Identify four forms of waste that may occur in software delivery.
3. What is the purpose of a balancing feedback loop?
4. State the five focusing steps of the Theory of Constraints.
5. What do the letters in CALMS represent?

5 Long Answer Questions

1. Explain how systems thinking changes the way an organisation approaches delayed software delivery.
2. Discuss the five Lean principles and illustrate each with a technology-delivery example.
3. Explain the Three Ways and show how they complement one another.
4. Describe how metrics can improve DevOps decision-making and how they can also create harmful incentives.
5. Compare the Theory of Constraints and value-stream mapping as approaches to improvement.

3 Analytical / Application Questions

1. A team has 15 items in progress and completes 5 items per week. Use Little’s Law to estimate average time in the system, state the assumptions required, and explain why the result may not describe every item.
2. A release process contains a two-week security queue, although coding takes only three days. Apply the Theory of Constraints and propose two interventions that preserve appropriate security governance.
3. Using CALMS and the Three Ways, analyse an organisation that deploys frequently but experiences frequent outages and rarely shares incident learning. Recommend a sequenced improvement plan.

Multiple Choice Questions with Answers

Question 1

Which statement best expresses systems thinking in DevOps?

A. Optimise each department independently using its own targets.

B. Focus only on the speed of writing and reviewing code.

C. Examine how interacting people, processes and technologies affect end-to-end outcomes.

D. Replace human decisions with automation wherever possible.

Correct Answer: C. Examine how interacting people, processes and technologies affect end-to-end outcomes.

Question 2

Which activity is an example of waste as defined in Lean technology delivery?

A. Testing a high-risk change before deployment

B. Waiting two weeks for a routine approval while work remains idle

C. Monitoring a service after a release

D. Clarifying acceptance criteria with a customer

Correct Answer: B. Waiting two weeks for a routine approval while work remains idle

Question 3

A stable system has an average of 15 work items in progress and throughput of 5 items per week. What is the average time in the system?

A. 2 weeks

B. 3 weeks

C. 5 weeks

D. 75 weeks

Correct Answer: B. 3 weeks

Question 4

Which action corresponds to the first step of the Theory of Constraints?

A. Elevate every team’s capacity simultaneously

B. Identify the factor currently limiting system performance

C. Subordinate the constraint to all upstream activities

D. Automate all manual activities immediately

Correct Answer: B. Identify the factor currently limiting system performance

Question 5

Which example best represents the Second Way?

A. Reducing batch size so changes flow more smoothly

B. Using production telemetry to improve development decisions

C. Increasing the number of simultaneous projects

D. Adding an approval stage after every commit

Correct Answer: B. Using production telemetry to improve development decisions

Question 6

In the CALMS model, which dimension most directly concerns making repeatable work consistent through pipelines and infrastructure as code?

A. Culture

B. Automation

C. Measurement

D. Sharing

Correct Answer: B. Automation

Question 7

What is a characteristic of a reinforcing feedback loop?

A. It always reduces change toward a fixed target.

B. It amplifies a change, which may produce beneficial or harmful results.

C. It operates without measurement or information.

D. It prevents any adaptation after deployment.

Correct Answer: B. It amplifies a change, which may produce beneficial or harmful results.

Question 8

Why can reducing work in progress improve delivery performance?

A. It guarantees that throughput will always increase.

B. It eliminates the need for testing.

C. It can reduce context switching and shorten feedback cycles.

D. It ensures that every task is completed simultaneously.

Correct Answer: C. It can reduce context switching and shorten feedback cycles.

Question 9

Which practice best supports the Third Way?

A. Hiding incidents to protect performance statistics

B. Conducting bounded experiments and learning from failures without blame

C. Increasing release batch size to reduce deployment frequency

D. Separating operations data from development decisions

Correct Answer: B. Conducting bounded experiments and learning from failures without blame

Question 10

In the illustrative admissions case, why was hiring more developers unlikely to solve the main problem initially?

A. Development capacity was already greater than the approval and release capacity.

B. Developers cannot contribute to operational systems.

C. The service required no software changes.

D. Lean principles prohibit increasing staff.

Correct Answer: A. Development capacity was already greater than the approval and release capacity.