DevOps Practices: Flow, Lean, Agile and Continuous Delivery
Flow and Lean
Flow is the smooth, uninterrupted movement of work from idea to customer. Lean thinking, adapted from manufacturing, supplies the tools: identify value, map the value stream, remove waste (waiting, handoffs, rework, partially done work, excess approvals), limit work in progress, pull work rather than push it, and improve continuously (kaizen). Small batch sizes reduce risk and shorten feedback. Bottlenecks, not average speed, set the pace - apply the theory of constraints.
Agile
Agile favours iterative delivery, cross-functional teams, working software over documentation, and short feedback loops with the customer. Scrum and Kanban are common frameworks; Kanban adds explicit WIP limits and visualised flow.
Continuous delivery
A deployment pipeline automates build, test, packaging and release. Continuous integration means merging to trunk frequently with automated verification. Continuous delivery keeps software in a releasable state at all times, with the release decision taken by the business. Continuous deployment goes further: every change that passes the pipeline is released automatically. Deployment (installing into an environment) and release (exposing to users) are different events, separable with feature toggles. Trunk-based development and automated testing keep the pipeline fast and trustworthy.
Traps in questions
- Confusing continuous delivery with continuous deployment; the exam often assumes CD means the former.
- Treating "release" and "deploy" as synonyms.
- Assuming Lean means cutting staff, or that Agile means no planning or documentation.
- Believing large batch releases reduce risk; they increase it and delay feedback.
Worked example / rule of thumb
Little's Law: average lead time = WIP ÷ throughput. Twelve items in progress with a throughput of four per week gives roughly three weeks of lead time. Halving WIP halves lead time without hiring anyone.