Salt’s delivery framework
SPARK: clear decisions.
Reviewable progress.
A practical framework for building, modernizing, and improving software. SPARK connects five delivery stages so your team can understand the scope, evaluate the work, and know who owns the next decision.
Five connected stages
What happens.
What you receive.
What you decide.
The stages are a working structure, not a fixed calendar. Architecture and risk review begin early; testing and feedback continue throughout. Scope, timing, and included deliverables belong in your proposal.
Scope & Shape
What are we solving?
Align the business goal, users, constraints, and the measures that will tell us whether the work is useful.
- Useful outputs
- A focused brief, success measures, priorities, and an initial risk list.
- Your decision point
- Agree on the problem and the boundaries before committing to a delivery scope.
Plan & Pilot
What should we validate first?
Plan a useful first increment. Where uncertainty warrants it, use a pilot to test the approach and working relationship.
- Useful outputs
- An agreed scope, acceptance criteria, responsibilities, and a reviewable result.
- Your decision point
- Review what we learned and decide whether to proceed, adjust, or stop.
Architect & Automate
How will we build on it?
Make architecture, access, testing, and release decisions explicit. Automate the checks that suit the application and its risks.
- Useful outputs
- Architecture decisions, a test approach, and the agreed build and release workflow.
- Your decision point
- Confirm that the foundation supports the next increment and its operating requirements.
Release & Run
Who is responsible when it goes live?
Review release readiness, plan rollout and recovery, and agree who operates the system and handles support.
- Useful outputs
- Release evidence, handover notes, a rollback approach, and named operational owners.
- Your decision point
- The agreed release owner decides whether the evidence supports launch.
Keep Improving
What deserves attention next?
Use feedback, operating evidence, and business priorities to choose the next improvements within the agreed engagement.
- Useful outputs
- A prioritized improvement backlog and a review of relevant results and risks.
- Your decision point
- Agree what to improve, what to maintain, and what no longer needs investment.
Working with your delivery process
How is SPARK different from Agile?
Agile provides values and principles for adaptive software delivery. SPARK describes how Salt structures an engagement: scope, validation, engineering decisions, release, and improvement. SPARK can work alongside Agile practices and Scrum when the agreed working model preserves their responsibilities.
| Buyer question | Agile | Salt’s SPARK |
|---|---|---|
| What does it provide? | Values and principles for collaboration, adaptation, and valuable software delivery. | A client-engagement structure with agreed outputs and decision points. |
| How is work organized? | Teams choose suitable practices and frameworks, such as Scrum. | Five connected stages adapted to the work, without prescribing a sprint schedule. |
| Who is accountable? | The chosen framework and working agreements define responsibilities. Scrum includes explicit accountabilities. | The proposal defines Salt’s scope, client approvals, release ownership, and handover. |
| How do priorities change? | Teams use feedback and learning to adapt their work. | Review the impact on scope, cost, dependencies, and acceptance criteria, then agree on the next increment. |
Agile already emphasizes technical excellence, good design, and continuous improvement. Scrum also addresses quality and accountability. SPARK makes Salt’s engagement commitments explicit; it does not establish superior delivery results by itself. Sources: Agile Manifesto, Agile principles, and the Scrum Guide.
Does SPARK replace Scrum?
No. Scrum defines a framework with accountabilities, events, and artifacts. SPARK addresses the Salt–client engagement. Agree how engagement reviews fit around Scrum without duplicating meetings or overriding the Product Owner’s prioritization.
Can SPARK work with our existing Agile team?
Yes. Define the boundary of Salt’s work and use your existing backlog, review practices, and tools where appropriate. Dedicated engineers follow your process. A managed team agrees on coordination and approvals for its workstream.
Are the five SPARK stages sequential, like Waterfall?
They are not intended as a single pass of isolated phases. Architecture and risk decisions start during scoping; testing and feedback continue throughout. Learning from a pilot or release can change the scope and plan.
What additional deliverables should we expect?
Agree on useful outputs in the proposal: a scope brief, pilot acceptance criteria, architecture decisions, release evidence, or handover notes. Reuse equivalent artifacts your team already maintains. Every stage does not require a separate document.
SPARK and Agile in practice
A dashboard for
your sales team.
Follow one small project from the first conversation to a dashboard your team can use.
Agree on the first version
You and Salt agree to start with a customer list. Define the data needed, what the list must show, and how you will check it.
What you haveA clear, focused scopeBuild, try, and improve
The team builds in short cycles. Your sales managers try the list and ask for a filter by salesperson. Their feedback shapes the next update.
What you seeWorking software to reviewCheck it and roll it out
Check order dates and account access. Agree who approves the rollout and who handles a failed data update before more people use it.
What you knowWho owns release and support
How they work together
Build in small steps, learn from feedback, and adapt.
Make the commitments between your business and Salt clear: scope, reviews, release, and support.
A hypothetical project to explain the approach.
A practical example
Make the first milestone tangible.
Illustrative acceptance criteria for a reporting pilot. This is a planning example, not a client artifact or a promise of project results.
Scope brief
Connect one approved order-data source to an account activity view for sales managers. Agree on the record fields, users, date range, and access permissions.
Pilot acceptance criteria
Reconcile the agreed sample to source records. Show when the data was refreshed. Verify that users can access only the accounts their role permits.
Release review
Record known exceptions, review test results, assign refresh-failure ownership, and agree on recovery and user handover before wider use.
Adapted to your engagement
The right depth of process.
Managed teams
SPARK structures the agreed delivery workstream, with Salt coordinating engineering and reviews while your business owns priorities and approvals.
Explore managed teamsProjects and pilots
Use the relevant stages for a defined deliverable or an uncertain technical question. A pilot is useful when there is something specific to validate; it is not mandatory for every project.
Compare engagement optionsDedicated engineers
Your team’s delivery process leads. We agree on the engineer’s responsibilities, review practices, and handover rather than imposing a separate framework.
Find an engineering roleExplore the work
Start with evidence.
See how Salt’s published projects handle business workflows, data, review, and testing. Use these examples to discuss the decisions your own project will need.
Sales intelligence and reportingClinical intake and human reviewWeb, mobile, and workflow testingA good place to start
Define a useful first milestone.
Share the challenge. We'll help you work out the next step.