Software delivery / Process models
Choose how the work learns and decisions get made.
A process model should explain when evidence changes the plan, who can make that change and what makes the software ready to use. Start with those questions before choosing a method name. The right arrangement depends on the work, its failure consequences and the people available to make decisions.
Different choices, different levels
A method name is not a delivery agreement.
Consider a business replacing an internal booking system. Its users may need to try the workflow before requirements settle, while its records require a carefully controlled migration. Frequent product feedback and a formal migration decision can both belong in the same delivery plan. Explain how each works and how they meet.
- Lifecycle model
- Organizes development across stages or repeated builds. It helps explain the order of work and the evidence needed to move forward.
- Delivery framework
- Scrum defines accountabilities, events and artifacts for iterative, incremental work. Its structure does not supply every engineering or operating practice.
- Flow strategy
- Kanban defines and improves how work moves through a system. It can complement other delivery approaches; a board alone does not establish that system.
Six arrangements to examine
Match the feedback mechanism to the work.
These choices operate at different levels and can overlap. The situations below are selection questions, not rules that assign every project to one category.
Staged development
01Selection question: Can the important requirements be settled before later work depends on them?
- Situation to examine
- A bounded change with understood behavior and explicit review dependencies.
- Before choosing
- Confirm what is stable, what remains unknown and how earlier decisions can be reopened.
- Illustrative application
- For a specified export replacement, review the record contract before implementing and accepting the transfer.
- Decision responsibility
- Name the owner of each transition and the route for changing an approved assumption.
- Evidence to review
- Accepted requirements, review findings and applicable completion criteria.
- Failure mode
- A signed document is mistaken for proof that the proposed workflow will work.
- Reconsider when
- Late user feedback repeatedly overturns decisions treated as settled.
Incremental and iterative development
02Selection question: Can the team deliver a useful part and learn from using it?
- Situation to examine
- A product can grow in accepted capabilities while the details of use become clearer.
- Before choosing
- Identify a complete first slice, shared foundations and the integration work between slices.
- Illustrative application
- Let one booking workflow run end to end, then use observed exceptions to shape the next capability.
- Decision responsibility
- The product owner sets priorities with users; engineering owns the integrity of the combined system.
- Evidence to review
- Usable behavior, feedback, unresolved exceptions and checks against earlier functionality.
- Failure mode
- Each increment is a disconnected screen or component that nobody can use.
- Reconsider when
- Work accumulates behind integration or acceptance barriers without usable results.
Risk-led spiral development
03Selection question: Which uncertainty could invalidate the next major commitment?
- Situation to examine
- An integration or technical approach needs evidence before wider implementation.
- Before choosing
- Name the risk, alternative approaches and a result that would change the decision.
- Illustrative application
- Test whether representative legacy booking records can be reconciled before committing to the migration design.
- Decision responsibility
- The technical and business risk owners decide whether to continue, change approach or stop.
- Evidence to review
- Investigation results tied to the original risk and the next investment decision.
- Failure mode
- Repeated prototypes continue without resolving a decision or becoming maintainable software.
- Reconsider when
- The investigation has no clear consequence for the plan.
Scrum
04Selection question: Can an empowered team work toward a goal and inspect usable results regularly?
- Situation to examine
- Complex product work with an available Product Owner and the skills to complete an increment.
- Before choosing
- Check decision authority, stakeholder participation and a shared Definition of Done.
- Illustrative application
- Work toward a useful booking outcome, inspect the result and adapt the backlog as evidence changes.
- Decision responsibility
- Scrum defines Product Owner, Developers and Scrum Master accountabilities.
- Evidence to review
- A usable increment and progress toward the product goal, not ceremony attendance.
- Failure mode
- The team runs meetings while every useful decision waits for an unavailable sponsor.
- Reconsider when
- The organization cannot support the framework's accountabilities or complete usable increments.
Kanban
05Selection question: Does the work need explicit control of flow and unfinished items?
- Situation to examine
- A stream of changes whose waiting, blocked work and capacity need attention.
- Before choosing
- Define work items, start and finish, policies, WIP control and a service level expectation.
- Illustrative application
- Make booking fixes and improvements visible through acceptance, then investigate where items wait.
- Decision responsibility
- People operating the workflow maintain its policies and resolve impediments with the relevant owners.
- Evidence to review
- WIP, throughput, work item age and cycle time, used to change how work flows.
- Failure mode
- The board records an expanding queue while the team keeps starting more work.
- Reconsider when
- Measures are collected but do not influence selection, unblocking or workflow changes.
An explicit combined approach
06Selection question: Do different parts of the initiative need different decision mechanisms?
- Situation to examine
- Product learning, external approvals and a consequential transition have distinct constraints.
- Before choosing
- Map which decisions belong to the delivery team and which require other accountable owners.
- Illustrative application
- Iterate the booking experience while rehearsing migration and reviewing its separate release conditions.
- Decision responsibility
- One overall owner resolves conflicts between product priorities, technical readiness and transition approval.
- Evidence to review
- A shared plan connecting accepted changes, dependencies and release evidence.
- Failure mode
- The word hybrid hides contradictory commitments or duplicated approval chains.
- Reconsider when
- A decision has multiple apparent owners, or none can explain what permits progress.
A practical selection record
Compare the constraints before the labels.
Write down the answers for this initiative. A process proposal should explain how it handles the difficult rows, including constraints that the team cannot remove itself.
| Constraint | Establish | Design response | Decide with | Warning sign |
|---|---|---|---|---|
| Uncertainty | What remains unknown | Feedback before commitment | Product and engineering | Assumptions treated as facts |
| Consequence | What failure would affect | Proportionate verification | Accountable risk owner | Cadence replaces readiness |
| Divisibility | A usable independent slice | Integration and acceptance | Delivery and users | Only components finish |
| Feedback | Who can inspect real work | Available review points | Business sponsor | No empowered reviewer |
| Dependencies | External work and approvals | Explicit handoffs and waits | System owners | An internal plan assumes access |
| Team context | Skills and actual capacity | Work limits and responsibility | Delivery lead | A method conceals missing skills |
Choose and test the arrangement
Make the process itself reviewable.
The first version is a reasoned choice. Keep the reasons visible so the team can change the arrangement when the evidence changes.
- 01
Describe the decision landscape
List unresolved business rules, technical uncertainties, failure consequences and external decisions. Separate a learning need from a fixed obligation.
- 02
Find the earliest useful evidence
Choose a usable slice, prototype or investigation that answers a material question. State what the result can establish and what it cannot.
- 03
Assign decisions and completion criteria
Name who prioritizes, who accepts behavior and who authorizes consequential release steps. Describe the evidence each needs and their availability.
- 04
Run a bounded delivery interval
Agree a review point appropriate to the work. Observe accepted results, waiting, rework and unresolved decisions without inventing a universal target.
- 05
Change the specific mechanism
If progress stalls, identify the cause: unclear scope, missing skills, unavailable decisions or integration delays. Adjust that part and check the effect.
Keep governance usable
Protect the decisions that matter.
Frequent feedback does not remove responsibility for quality, records or release consequences. Formal reviews also need evidence from the software itself.
- Separate review from release
- A demonstration can inform priorities without authorizing a migration. Specify the applicable operational decision. In Scrum, the Sprint Review is not a required release gate.
- Make changes visible
- Record why a decision changed and its effect on scope, dependencies and remaining work. Replanning should preserve the earlier basis for comparison.
- Keep quality inside completion
- Include the verification and integration necessary for the accepted change. Moving required work into an unnamed later phase makes progress harder to assess.
- Measure the system, not busyness
- Review useful accepted work, time spent waiting and recurring rework. Do not turn ticket counts or meeting attendance into unsupported claims about business value.
Questions before adopting a method
Ask what the team will do differently.
A clear answer describes an observable change in the work or its decisions.
- Which software development process model is best?
- There is no useful universal choice. Start with uncertainty, consequences, available feedback and whether the work can be delivered in usable parts. A proposal should explain its fit and the evidence that would cause the team to reconsider.
- Are agile, Scrum and Kanban the same thing?
- No. The Agile Manifesto describes principles including working software, collaboration and adaptation. Scrum is a defined framework. Kanban is a strategy for managing and improving flow. They should not be compared as three equivalent lifecycle models.
- Can staged governance coexist with iterative delivery?
- Yes, when the boundaries are explicit. The team can learn through working increments while a migration or other consequential transition has separate evidence and authority. Do not make every small change wait for an unrelated approval.
- Does a process model determine the contract or price?
- No. Commercial scope, payment, acceptance and change terms need their own agreement. A label such as agile or waterfall does not establish a fixed price, unlimited changes or the meaning of a completed deliverable.
- When should the team change its approach?
- When recurring evidence shows that its mechanism does not fit: useful feedback arrives too late, work cannot be accepted, decisions wait indefinitely or risk investigations do not resolve anything. Change the failing mechanism and review the result.
Source basis
Sources behind the control model.
- 01
NASA Software Engineering Handbook
SWE-019: Software Life CycleHistorical original-handbook guidance, last updated June 2023, supports the staged, incremental, evolutionary and spiral descriptions. Used for model concepts, not current NASA policy or requirements for business software.
- 02
Ken Schwaber and Jeff Sutherland
The 2020 Scrum GuideThe official November 2020 guide defines Scrum's framework and usable increments. The article offers a selection comparison, not a replacement for the complete guide.
- 03
Kanban Guides
The Kanban Guide, May 2025Defines workflow, work-in-progress control and flow measures. Its service level expectation is a forecast, not a Werkon delivery promise.
- 04
Agile Manifesto
Principles behind the Agile ManifestoPrimary statement of working-software feedback, collaboration, technical quality and adaptation. These principles do not establish a specific process or commercial agreement.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD