Nuts and bolts for delivering in Agile

Salsa’s agile delivery methodology

Salsa has a mature and proven methodology to deliver government and enterprise digital projects. This methodology uses a classic agile process to deliver highest value features via a series of iterations.

Salsa’s typical agile delivery methodology is broken down into five phases:

1. Discovery
2. Planning
3. Delivery (build iterations)
4. Go-live
5. Business-as-usual (BAU) support

Discovery

Our initial discovery services include:

• Identifying pain points and assessing client vision — Crystallise the purpose of the site, and identify critical content and overarching design expectations.

• Alignment on people, teams, process, project goals, assumptions, timelines, deliverables, dependencies and project success criteria.

• Get a clearer understanding of the expected outcomes, the epics, user stories, the existing information architecture and the content available on the website (if applicable).

• Visual audit and mapping for designs to design system components.

• Functional audit and mapping for requirements against chosen distribution. Module assessment (existing, configuration, custom) to drive solution direction.

• Deep dive into functional requirements to define the business benefit and technical complexity of each feature of the website to then prioritise functionalities.

• Content audit and mapping ahead of defining content migration configuration and tooling (if existing site).

• Defining baseline functional and technical requirements and laying a foundation for project success.

• Creating a technical blueprint, which allows us to set a well-resolved technical foundation.

• Exploring any security requirements to ensure these are accommodated for in our solution direction.

• Potentially define a minimal viable product (MVP), should all desired features only be achievable outside the defined timeframe or budget and define future phases of work accordingly.

Planning

The planning phase continues the work undertaken in discovery to prepare for the upcoming build phase. These services include:

• Grooming epics/stories with solution direction to meet the agreed acceptance criteria.

• Sizing the requirements and prioritising ahead of the build sprints.

• Identifying gaps for either design system components or content gaps and resolving.

• Prioritising build sprints for different streams including design, functional (defined requirements) and content migration (if applicable).

• Platform setup for the chosen platform and distribution to on-board the project team ahead of executing on build requirements.

Note: The set of epics/stories would be expected to evolve somewhat under the control of the product owner as the sprints are executed.

Delivery (build sprints)

Discovery and planning outcomes are used to govern an agile delivery process, which delivers the project via a series of agile sprints. Inherent in the agile process is feedback and prioritising requirements allowing a product owner to have flexibility in the build of the new requirements across all streams.

The services provided in the delivery phase include:

• Implementing the functionality via the discovery/planning in iterations and making them available for testing by Salsa and the client on a bi-weekly basis.

• Informing further decisions.

• Ultimately building the prioritised requirements for the project and meeting appropriate deliverables.

• Aligning with the project team on a bi-weekly basis for sprint planning before each iteration.

• Allocating time for further story grooming and continuing to prioritise the product backlog with the Product Owner

The anatomy of each sprint is as follows:

• Sprint planning — A one-day exercise at the start of each sprint that re-visits stories for each sprint and adds definition and acceptance criteria detail as required.

• Sprint execution — A two-week exercise that delivers the stories of the sprint. Heartbeat stand-up meeting each day is used to monitor progress, issues and clarifications.

• Sprint showcase (demo) — On the last day of sprint development sprint outcomes are presented to the project team. Any issues are noted and added to the backlog.

• Sprint close and retrospective — Once issues are addressed the sprint is formally closed by the client and a retrospective meeting is held to reflect on the sprint and come to conclusions for the next sprint.

Go-live and BAU enablement

The go-live services include:

• Providing any content administration training required. Salsa will prepare training documentation for agreed topics during the later sprints. These are defined, validated and sized.

• Remediating any feedback from the final user acceptance testing.

• Ensuring the website is “fit” for go-live.

• Coordinating the go-live process and any activities associated with this; and making the cutover to the new website.

• Remediating any issues or bugs covered under warranty.

• Transition-out: If/as required a mature transition out and BAU enablement plan.

Testing

Testing is continuous in Salsa’s agile process. Salsa’s process has formal steps for internal quality assurance (QA) testing as well as testing by the Product Owner or other client testing resources.

Types of testing

Salsa’s process has various types of testing, such as:

• Grooming agile stories with measurable acceptance criteria — An agreement of acceptance criteria between Salsa and the client during discovery and in sprint preparation starts the testing/validation process as early as possible and allows developers to test to known outcomes.

• Unit testing of development — Developers are expected to test their development. Developers are also expected to write regression scripts to test code via automation when practical.

• Formal QA agile step per story — Salsa’s workflow has a formal step for a Salsa quality assurance engineer or business analyst to test each story before it’s demonstrated and moved to UAT. Defects are reported and the story sent back to development if/as required.

• Formal UAT step per story — Salsa’s agile workflow sends successfully QA’ed stories to UAT state. During UAT the story’s acceptance criteria is tested by the Product Owner.

• Sprint acceptance testing — The entire sprint is tested as an integrated product to supplement each story being tested in isolation.

• Automated testing — Setup and configuration of the automation test framework (including visual regression testing). This involves configuring a continuous integration (CI) service to run tests on each change to a codebase. Writing automated behavioral test scripts that cover the most critical user journeys.

• Other testing — More specialised testing such as security/penetration testing, accessibility testing or load testing is executed via dedicated agile stories (if executed by the project team) or stories to remediate if executed by independent parties.

Defining requirements that span multiple (blended) teams

Salsa often works with agency staff plugged into a blended Salsa team. These models can greatly help knowledge sharing, resource constraints, increase project velocity and help ensure requirements/business alignment.

For blended team scenarios Salsa will work closely with the blended team during discovery. The team may include a designer (within the agency, within Salsa or from a third-party vendor), agency team members and other stakeholders.

Many requirements need collaboration between various parties. Below is a typical plan used during discovery to define the features that will be delivered across teams.

Upfront in discovery all teams will work closely with client stakeholders, the technical team and subject matter experts to identify the features (epics). An epic is a larger body of work that can be broken down into a number of smaller stories.

For each epic defined, the user stories are made up for the different parts of the implementation. They are:

1. Backend configuration

2. Design system component (if applicable)

3. Frontend logic (consume API)

A typical user story is made up of the following:

• User story description in the typical form — As a <user> I can <do things> so that <I can achieve something>

• Context — Trace back to deliverables

• Acceptance criteria — List of requirements that ensure all user stories are completed and all scenarios are taken into account (this criteria is validated by the client)

• Assumption/questions

• Solution direction — This is formed during discovery through to ready for development. This is a suggestion of how to implement from a technical point of view. If the developer has a better approach, that can be discussed at sprint planning or followed through when working on the requirement.

Each user story will comply to:

• Definition of ready (DoR) — The requirements the user story must adhere to before being ready for development.

• Definition of done (DoD) — The requirements the user story must adhere to that allows completion of the single feature.

The above process allows for feature requirements definition to be a collaboration between all parties. Features can also be prioritised so the same feature priorities are shared between all parties. This allows for development of each side of the project to start working without blocking each other. For example, the design team can start working on the presentation of a feature without the need to work on the frontend logic because the API may not be ready.

The key here is that the epic is defined along with user stories that are grouped and shared among all project teams. This provides greater alignment to ensure we’re working towards the correct requirements for all features that require collaboration across multiple teams.

This also allows overall project governance to track the progress of all the parts of a feature and how they are tracking.

Agile plan

As a deliverable from discovery and planning a considered agile plan is presented to the client, including:

• An all-inclusive discovery during transition-in, resulting in a co-designed and fully aligned and considered agile project plan, which maturely handles multi-disciplinary teams (blended), co-location, and multiple streams — each with clear boundaries of responsibility and frequent/clear touch points (daily standups, etc.) and lines of communication.

• The technical outcomes/deliverables of this are:

  • A prioritised matrix of features ranked by business benefit/value with technical complexity evaluated.

  • Grouping of cells of this matrix by functional area and mapped to epic.

  • Mapping of cells to agile stories in the project backlog.

  • Module assessment (existing, configuration, custom) to envisaged distribution for future state vision.

  • Refinement of the architecture blueprint.

  • Solution direction for project, epic and selected stories.

Sprint reporting/project status reporting

The collaborative team will commit to rigorous project and iterative sprint reporting.

Salsa recommends:

• Daily standups with the client project team and Product Owner to ensure heartbeat on sprint progress. During discovery we’ll align on the right level of involvement in stand-ups across multiple teams working on the project and determine the optimal path to ensure the right level of involvement across streams.

• Formal mid-sprint review that tables:

  • Sprint velocity

  • Projection of effort/time to close

  • Risks/issues

  • Recommendations

• A weekly status report that’s usually:

  • Tabled/discussed at a status check for the project

  • Tabled/discussed at a status check for the program management (usually every second week)

Communications between Salsa and clients

Salsa often works in a collaborative mode with our clients, ensuring communications are seamless. Our communication methods include:

• JIRA/Confluence — Salsa formalises our agile process with JIRA. Salsa has tailored workflows in JIRA to effectively handle the story grooming and sprint execution process.

• Slack — In Salsa’s experience the slack IM tool is very effective for informal, fast turnaround communications. Slack is effective in bringing teams closer together and driving higher performance because it unifies the project team, particularly if they are geographically dispersed. Salsa drives informal conversations via Slack in our projects. This can include other vendors to ensure that communications are open between all parties.

• Formal reviews — Salsa drives formal reviews such as:

  • Sprint demonstrations
  • Mid-sprint review
  • Formal sprint planning/compilation
  • Sprint retrospective

These processes will use face-to-face and video conferencing as required.