On this page:
Agile at the core
Engaging Salsa is to engage a proven delivery methodology tuned and refined over years of pleasure, pain and everything in between. Salsa’s continual appraisal of our delivery success and areas for improvement has led to a lean agile delivery process tailored to be true to Salsa’s values and ethos and a kitbag of project tools proven to work at any level of complexity and project scale.
Salsa uses agile because it provides flexibility for our clients and a focus on the highest business value being delivered for any particular budget. Salsa’s process is to continually assess and re-assess project success factors and work with clients to re-focus and re-prioritise as necessary.
Delivery stages
While Salsa’s delivery process is agile and iterative it does follow a proven set of execution stages.
Pre-sale request for quote
Salsa’s delivery process doesn’t start during the formal project kickoff. Salsa’s focus on customer service starts in the earliest stage of the relationship, with our rigorous request-for-quote (RFQ) response process, which delves deeply into customer needs and how we can best meet these needs. This often involves innovative thinking, and identifying different and better ways to deliver a project to benefit the client and/or citizens and the open government movement.
Intake and preparation
The first step of the actual project is intake and preparation. This stage is key to orientate the project and thus Salsa is keen to listen deeply — and also challenge if/where appropriate — for client/project critical success factors, pain points, budgets, timelines and vision.
The project team relationships are formed in this stage. Significantly the Salsa Engagement Manager is plugged into the client team and runs forward as the day-to-day contact. A Salsa Relationship Manager interfaces with the client project team as well as the client executive team. These relationships last for the duration of the project with the Relationship Manager lasting beyond.
Inception
Salsa uses kickoff and inception workshop(s) to align on people, process, project goals, assumptions, timelines, deliverables, dependencies and project success criteria. During this stage, we crystallise the purpose of the project, critical content and overarching design expectations.
Intake
Salsa intake consists of receiving and reviewing all client-supplied items, in particular:
- Statement of requirements: Review statement of requirements. Validate and compile discovery topics.
Where relevant, depending on project type:
User research outcomes: Review provided user research blueprint, UI wireframe and high fidelity prototype.
User journey: Validate other supplied context such as user journeys and content, and assess/validate the digital content strategy.
Content: Assess content and content strategy. Compile preliminary approach to content staging.
Preparation: Prepare for all onsite discovery workshops including daily sessions, required stakeholder participation, schedule alignment, expected outcomes, requirements capture process, tooling, etc.
Vision/Discovery
The vision/discovery phase is used to understand business requirements in detail. The following are facets of this phase:
Understanding and expanding on your roadmap/vision
The Salsa process is to extend original discussions on project success factors to more fully understand the project roadmap/vision.
Compilation of MVP
Salsa’s lean agile process leads to as-early-as-practical discussion of minimal viable product (MVP) with clients. While MVP assessment changes as projects evolve, early strawmodels are helpful to promote focus and ensure alignment for the project’s success.
Other requirements solicitation
Other aspects of discovery may include, depending on the project type, activities such as:
Theme alignment
Alignment on UI theme designs that appeal to key stakeholders. This exercise can quickly determine what level of design will suit clients and looks at the option of using standard themes or existing design patterns with specific adaptations.
Functional alignment
A series of functional sessions to expand on the provided statement of requirements to ensure functional requirements are clear. Each function will be mapped to an agile story with agreed acceptance criteria.
Technical alignment
As required, technical sessions/discussions will agree technical approaches and solutions. The agreements will manifest as solution directions within agile stories, which will contribute to and qualify story estimates and prioritisation. This stage compiles a solution blueprint.
Technical proof-of-concepts are often employed during discovery for risky or unknown technical requirements.
Planning and development onboarding
The planning and onboarding phase completes discovery via the compilation of a set of agile user stories to deliver the project. This set of stories would be expected to evolve under the control of a client product owner. Structured activities include:
User stories: Translate user-validated designs and features into a series of agile user stories.
Groomed backlog: Create user stories with clear acceptance criteria and solution direction to support estimations.
Estimation: Led by the technical lead, conduct consensus-based estimations on the groomed backlog.
Prioritised backlog: Prioritise backlog factoring business benefit, implementation cost and available sprint budgeted capacity.
Sprint plan: Define the sprint plan with a clear list of prioritised user stories along with relevant milestones, dates, go-live, etc.
Onboarding: Begin to onboard the technical implementation team including finalisation of sprint plan reflecting prioritised backlog, development environment, etc.
Agile delivery
Agile build is via a series of agile build sprints. Each sprint follows a structured agile process working through the steps of:
Develop:
Backend config and optional customisation: Configure all relevant backend changes and enhancements to meet the requirements as reflected within each of the prioritised user stories.
Frontend theming: Implement all frontend theming to reflect user-tested and approved responsive visual designs.
QA/Test: Conduct internal QA testing to validate that functionality and design meets acceptance criteria.
Demo: A formal demonstration of the sprint outcome to the client product owner and other stakeholders.
Acceptance: Testing of each story from the client product owner. Acceptance of the sprint as a delivered package of work.
Retrospective: Review meeting per sprint with a focus on lessons to carry into subsequent sprints.
Plan: Compilation and planning of the next sprint. This is the opportunity for the product owner to re-assess business value of the story backlog and re-prioritise if/as required.
QA and UAT
If content loading and/or automation is in scope for the project Salsa’s approach is to continuously run the content automation to prove the approach and iterate the content as the project evolves. The content loading step as part of UAT is considered the juncture where the final content is loaded.
UAT
User acceptance testing involves a release to be validated and approved by the product owner and client team. UAT also includes the formalisation of backlog items for future phase and remediation items for current release. Steps include:
Remediation — agreement, scheduling and implementation of UAT observations and re-testing as required.
Business acceptance — formal acceptance of the build/product ready for release.
Go-live scheduling — Agreement of the go-live process, dependencies and timeline.
Go-live and training
The go-live and training phase includes:
Go-live coordination — Coordinate release and technical go-live process.
Live cut-over — Execute the steps to put the build live.
Communications — Work with the client to appropriately communicate the new site live.
BAU planning — Finalise the process to transition from project mode to BAU/support mode.
Training — Instructor-based training so users can raise questions about managing the site and content.
Business as usual (BAU)
Salsa transitions clients from projects to BAU/support via:
Initial production monitoring — Carefully monitor the production site in the first hours and days of operation. Be on stand-by to troubleshoot and solve any production issues.
Salsa support — Transition to agreed Salsa support service.
Engagement principles
Salsa’s delivery process is underpinned by a well-defined set of engagement principles. These include:
Sell well — Salsa takes pride in setting up projects for success right from the pre-sales process. Salsa business development professionals are highly knowledgeable (Salsa’s directors all come from engineering backgrounds) and apply rigour, maturity, and deep knowledge in the sales process. Salsa attempts to ‘sell well’ to ensure expectations are aligned at all stages of projects and avoid downstream surprises for clients.
Communicate well — Salsa’s delivery ethos encapsulates transparency, accountability, and consistency. If project issues arise Salsa delivers bad news early and formulates path-to-good in consultation with the client.
Deliver well — Salsa is committed to quality of delivery. Issues will arise in projects and Salsa is experienced in practical methods of engagement to navigate such issues. If mistakes are made they are corrected, where appropriate grace is shown and shared risk is taken.
Tools we use
Salsa’s core set of tools has proven to be industry strength and practical in many projects. While Salsa is flexible and able to adapt our tool suite should a particular client have a strong preference or constraint, Salsa’s go-to tools include: