What are whole-of-government digital platforms?
Whole-of-government digital platforms bring disparate, legacy content management systems onto a unified platform. For example, the Department of Premier and Cabinet’s Single Digital Presence (SDP) is being considered as a whole-of-Victorian-Government platform.
How to make a whole-of-government platform work
Whole-of-government digital platforms require vision, rigour, experience, scale and flexibility to deliver. Successful implementation usually involves a multi-disciplinary team blended across government and vendor(s). Flexibility is delivered by employing an agile methodology.
Delivering SDP using agile
SDP is a great example of a whole-of-government digital platform that was delivered using agile.
Salsa designed a multi-stream, multi-disciplinary team to deliver SDP. These blended teams included experts from Salsa, amazee.ie and Victoria’s Department of Premier and Cabinet. These teams were also spread across the globe, with three ‘satellites’ in Canberra, Melbourne and Switzerland. The multi-disciplinary team included:
Project managers
Business analysts
User experience (UX) designers
Application architects and engineers (backend and frontend engineers)
Platform architects and engineers
Quality assurance
DPC’s product owner
Other experts including subject matter experts, e.g. content strategists
Three parallel streams with centralised program governance were designed:
Platform stream — This stream designed and implemented the technical platform for the SDP program.
UX stream — This stream was focused on the UX. Salsa worked with DPC’s internal UX team, ensuring the work was aligned with other work and took place over two sprints.
SDP Drupal 8 distribution stream — This stream took input from the UX stream to build a backlog of user stories that enforced the makeup of the Drupal 8 SDP distribution (Tide). The agile delivery team executed many sprints to deliver the requirements of this stream, with many team members involved. You can find out more about the overall SDP solution on our SDP page.
SDP and agile
In general, agile methodology delivers flexibility, and building agile into your processes is also a good way to mitigate risk.
Projects generally have three key parameters — time, budget and scope. The project itself will drive the ‘location’ of the flexibility. In this case the costs (available budget) was fixed and the flexibility lay in the scope and dates. Although all boundaries were important (e.g. meeting dates and deadlines were important deliverables) there was some flexibility.
Each stream had an agile team called the “Development Team”, which was made up of multiple disciplines, with a slightly different mix of experts based on stream requirements. Subsets of the project team including product owners, project manager and business analyst (with regular touch points with the scrum master) formed part of both the distribution build team and the UX/UI team.
The product backlog of initial project requirements was established during the discovery phase. These requirements were created using a standardised workflow and template to groom user stories with valid acceptance criteria, devise technical solutions for each requirement, provide estimates and then validated by the client before being moved to development. Jira was used for collaboration between parties after user stories were created.
DPC had a design/UX stream that informed requirements for the project. This stream created wireframes that were user tested and tweaked based on test results. High definition designs were created and used by the build project. The design of these components informed the build requirements for both backend and frontend development and ultimately the API integration that displayed the backend captured CMS data via the frontend components on the new site.
During each sprint, UX/UI designers should focus on building functionality and building knowledge. So with every sprint while the Drupal 8 distribution build team was coding and testing one part of the product backlog that was prioritised, the UX/UI designers will focus their time looking further down the product backlog at upcoming items. These items were set by DPC.
Within each sprint, a UI designer will usually be helping the rest of the team turn a design into implemented, tested code while simultaneously thinking about the next feature (or two) to be built. So the designer is both in the sprint and looking ahead, at what comes next. This happened to a degree in the SDP project.
Sprint planning and user story prioritisation allowed us to align on sprint priorities ahead of each sprint and make sure there was plans in place to deal with cross-stream dependencies. As soon as UX/UI designs for upcoming priorities were completed, user story writing and requirements discovery was happening to continue to build backlog. Sometimes those stories would form priorities for the next sprint, depending on how many stories were captured, the size of the requirements, the sprint team’s capacity, etc.
The product backlog, which consists of all stories making up all the requirements, evolved over time with some new requirements discovered along the build. These would be groomed to include acceptance criteria, validated by the client and then estimated by Salsa. Agile methodology means these new requirements could be accommodated, as long as the product backlog was prioritised. If these had any impact on costs (e.g. more sprint capacity was required), then we could have this discussion with the client. Otherwise they could prioritise over other requirements so original requirements get pushed back to later phases of the project.
The different streams each had sprints running in parallel, each with scrum masters running daily stand-ups across each stream. While the streams ran in parallel (or working ahead in some cases) the platform stream had its own development team with its own set of user stories, executed within a series of sprints following the same agile methodology. The platform stream was about establishing and setting up of the platform, i.e. the infrastructure layer that SDP is built on.
The platform stream ended when completed, but the UX/UI stream and the distribution build stream are still going, building out all the requirements DPC has prioritised for the initial distribution.
The project has gone through the first two major phases including alpha release and beta release (currently in beta) and is due to go live early in 2019.
Salsa’s take
Whole-of-government digital platforms deliver on Salsa’s key focus — to help governments become more open, more connected and more consolidated. SDP is a great example of whole-of-government digital platforms at work and delivering value to citizens and government.
