CHOOSE THE COORDINATION MODEL
What changes from Waterfall and Agile—and what to keep from Scrum, Kanban, DevOps, Lean, XP, and specification-driven development.
Concerted Engineering is a proposed operating model for coordinating customer intent, bounded autonomous execution, and independent evidence. Its distinguishing proposal is a shared versioned state governed by three contracts. It can work alongside existing methods; it does not establish that those methods are obsolete.
OpenKedge editorial guide · Updated · Comparisons explain design differences, not measured performance rankings.
Agile is a set of principles; Scrum is a framework; Kanban is a flow strategy. DevOps and engineering practices address additional concerns. Compare their purpose before treating them as substitutes.
| Approach | Primary focus | Practices to retain | Compare with Concerted Engineering |
|---|---|---|---|
| Waterfall | Plan and govern work through sequential phases. | Requirements discipline, explicit acceptance, and accountable change control. | Read the difference |
| Agile | Adapt through collaboration, working software, and feedback. | Customer collaboration, frequent feedback, technical excellence, and adaptation. | Read the difference |
| Scrum | Inspect and adapt toward goals within Sprints. | Clear goals, transparent work, inspection, adaptation, and a Definition of Done. | Read the difference |
| Kanban | Improve value flow by managing work in progress. | Work-in-progress limits, explicit workflow policies, and flow measurement. | Read the difference |
| DevOps & continuous delivery | Make software reliably deployable with rapid feedback. | CI/CD, automated tests, observability, reversible rollout, and operational feedback. | Read the difference |
| Lean | Improve customer value while reducing wasted effort. | Customer value, system-wide flow, respect for people, and measured experiments. | Read the difference |
| Extreme Programming (XP) | Support change through disciplined technical practices. | Test-first development, continuous integration, refactoring, and collective learning. | Read the difference |
| Specification-driven development | Make intended behavior explicit before implementation. | Explicit behavior, versioned specifications, and traceability to implementation. | Read the difference |
Waterfall coordinates delivery through successive project phases. Concerted Engineering proposes a continuous loop in which product intent, execution permissions, and independent evidence stay linked as work changes. The difference is the coordination mechanism, rather than a guaranteed delivery speed.
A phase-based lifecycle makes requirements, design, implementation, testing, and acceptance explicit. It can suit work with stable commitments and contractual milestones. Real implementations can include iteration; Royce’s 1970 paper warned about the risks of a simplistic one-pass sequence.
Instead of repeatedly translating a phase’s documents for the next discipline, teams maintain three versioned contracts against the same engineering context. Verification requirements are established before execution, and production admission remains separate from code generation.
Consider a bounded Concerted Engineering pilot when approval queues and stale specifications dominate lead time. Retain required milestone reviews and acceptance records where the project needs them.
Requirements discipline, explicit acceptance, and accountable change control.
Agile is a set of values and principles for adaptive software development. Concerted Engineering is a proposed operating model for coordinating humans and coding agents through explicit contracts and independent verification. It can preserve Agile’s customer focus and feedback while adding boundaries for autonomous execution.
The Agile Manifesto emphasizes customer value, collaboration, responding to change, and frequent delivery. Agile does not require sprints, story points, standups, or delayed verification. Those choices depend on the framework and team.
Concerted Engineering makes three questions explicit: what outcome matters, what an executor may change, and what independent evidence permits release. A shared versioned state connects those answers across product, engineering, verification, and operations.
Keep effective customer conversations and retrospectives. Pilot contracts if faster implementation leaves intent ambiguous, permissions implicit, or review queues overloaded. A team already practicing continuous coordination may need only a small change.
Customer collaboration, frequent feedback, technical excellence, and adaptation.
Scrum structures empirical product work through accountabilities, events, artifacts, and Sprints of one month or less. Concerted Engineering specifies how intent, execution authority, and evidence remain coordinated during that work. Contracts can be used inside Scrum without making the Sprint Review a release gate.
Scrum provides a Product Goal, Sprint Goal, and Definition of Done. Usable Increments can be delivered during a Sprint; teams do not have to wait for the Sprint Review to release value.
An Intent Contract can clarify an outcome behind backlog work; an Execution Contract can constrain an agent’s scope; an Evidence Contract can define independent proof beyond a shared quality checklist. The distinction is protected verification and admission authority, not the mere existence of acceptance criteria.
Retain Scrum when its goals and inspect-and-adapt rhythm help the team. Add contracts around one service first. If you remove Scrum’s required elements, describe the resulting workflow accurately rather than calling it unchanged Scrum.
Clear goals, transparent work, inspection, adaptation, and a Definition of Done.
Kanban optimizes the flow of value through a defined workflow. Concerted Engineering adds explicit intent, execution boundaries, and independent evidence to the work flowing through it. Kanban and Concerted Engineering can be combined: one helps manage flow; the other defines coordination and authority around a change.
The Kanban Guide describes defining and visualizing a workflow, actively managing work, and improving that workflow. Work-in-progress controls and flow metrics help teams understand congestion and predictability without requiring a sprint cadence.
Each work item can reference the current contracts and required proof. A change blocked on evidence stays visibly blocked rather than appearing complete because an agent opened a pull request. Verification capacity constrains execution intake.
Use Kanban when queues and competing work need visibility. Add the contracts if items flow quickly but lose customer context or lack clear authority to execute and release. Measure total lead time and blocked time together.
Work-in-progress limits, explicit workflow policies, and flow measurement.
DevOps connects development and operations; continuous delivery keeps software in a releasable state. Concerted Engineering extends coordination upstream to customer intent and explicitly separates generation from verification and production admission. It builds on delivery automation rather than replacing pipelines, observability, or operational ownership.
Continuous delivery relies on capabilities such as automated testing, deployment automation, and fast feedback. DORA distinguishes the ability to release on demand from requiring every change to be deployed immediately.
A passing pipeline is evaluated against the intended outcome, the allowed mutation scope, and independently controlled evidence requirements. The generator cannot change the acceptance policy or grant itself production access. Runtime outcomes feed the next Intent Contract.
Keep your CI/CD system and operational practices. Pilot the model when pipelines are fast but teams still disagree about what should change, who may change it, or whether the proof is sufficient for release.
CI/CD, automated tests, observability, reversible rollout, and operational feedback.
Lean starts with customer value and improves the work that creates it. Concerted Engineering applies a specific coordination model to software delivery with autonomous execution: shared contracts, bounded permissions, and independent proof. Lean helps identify a constraint; the contracts are one proposed way to address it.
Lean thinking emphasizes understanding the customer’s problem, improving work through experimentation, and involving the people doing that work. It is broader than a software delivery framework or a set of tools.
Treat repeated translation, waiting for approvals, and unverifiable output as candidate sources of waste. Connect an improvement hypothesis to customer outcomes, execution cost, and evidence quality so local coding speed does not become the sole target.
Use Lean inquiry before adopting any new operating model. If your bottleneck is customer discovery or a poorly understood system, address that first; adding contracts without fixing the underlying problem can create more work.
Customer value, system-wide flow, respect for people, and measured experiments.
Extreme Programming emphasizes practices such as test-first development, continuous integration, refactoring, and close collaboration. Concerted Engineering adds an operating model around that engineering work: customer-backed intent, constrained execution, and independent admission evidence. These practices can reinforce each other.
XP treats technical discipline and short feedback cycles as foundations for responding to change. Tests and refactoring help teams maintain the ability to modify software safely as requirements evolve.
Implementation tests remain useful, but their authorship and control matter. A coding agent’s own tests do not alone establish independent evidence. Protected verification checks evaluate invariants and behavior that the generator cannot silently weaken.
Keep XP practices that improve design and feedback. Add independent evidence and scope controls as agent execution expands. Do not discard pair work or human design judgment simply because code can be generated quickly.
Test-first development, continuous integration, refactoring, and collective learning.
Specification-driven development uses explicit specifications to guide implementation, including AI-assisted coding. Concerted Engineering also asks who may execute, which resources they may change, who controls the evidence, and how production outcomes update intent. A specification can support an Intent Contract without covering all three contracts.
Implementations vary. GitHub Spec Kit is one concrete toolkit that organizes specification, planning, and implementation tasks; it is not a universal standard for every specification-driven workflow.
Concerted Engineering treats the specification, permission boundary, and independently owned proof as related but distinct responsibilities. Contract versions must agree, and changes to intent can invalidate earlier evidence. A document alone does not enforce these relationships.
Use a specification workflow where it improves clarity. Add execution and evidence controls when a correct-looking specification still leaves agents over-permissioned or lets the same actor generate code, adjust tests, and authorize release.
Explicit behavior, versioned specifications, and traceability to implementation.
These are adoption hypotheses to test in your organization. No framework substitutes for understanding where your delivery system actually waits or fails.
If you cannot explain the customer problem or measure an outcome, improve discovery and product collaboration before accelerating execution.
Use flow measurements and work-in-progress limits to find waiting and rework. Introduce shared contracts where repeated translation is a measured constraint.
Pilot Execution and Evidence Contracts with protected checks and a separate admission authority. Limit intake to what verification can support.
Keep the workflow that already delivers safe customer value. Test the smallest useful addition and scale only after the outcome justifies its cost.
Test one customer problem, one bounded service, and an explicit evidence gate.
Framework descriptions link to primary sources. The proposed combinations and adoption guidance are OpenKedge’s interpretation. Read the foundational article for the Concerted Engineering model.