How to establish an agile, user-centred digital function in Government organisations
Over the last 12 months, our delivery team have been delivering exciting new projects across the organisation as well as supporting our existing suite of processes and applications. Alongside this core delivery activity, we have also been focused on how we can:
- Introduce multi-disciplinary teams
- Adopt agile ways of workingand deliver to the GDS Service Standard
- Establish a clear portfolio process to operate within sustainable WIP limits
- Introduce user-centred design professions and principles
- Support colleagues navigate change with clear guidance and training
- Improve communication and collaboration by working in open
- Sign up to the digital and technology spend controls process
Delivering this would prove to be a difficult endeavour given the significant cultural and technical change required, under the unique circumstances of a global pandemic, whilst maintaining our capacity to deliver projects for the organisation.
To kick things off, we worked as a community to understand what problems we were trying to solve:
- Communication and understanding of strategic priorities, leading to difficult portfolio planning and alignment of priorities.
- There is insufficient representation from all professions during the triage stage when new project requests are received.
- The perceived benefits of a project are not clearly surfaced at an early enough stage to support effective prioritisation.
- When projects are approved there is an indeterminate period of time before it is started (Further projects are also approved in that time).
- There is a lack of visibility of team capacity and availability to pick up new projects.
- Operational team limits aren’t factored in when projects are being defined
- Project (or phase) outcomes aren’t clearly defined and result in scope creep and delays.
- Support work is prioritised in isolation of other problems in each business area which may potentially be of higher priority or bring greater benefits.
Each problem statement represented a symptom of an organisation growing its capacity and capability to deliver digital services. To progress, we needed some strategic initiatives around people, processes and culture to provide the structure and stability to be successful.
In our previous model, we had project teams. These would generally be formed to solve a pre-determined output. We would identify people from a ‘pool’ to deliver a project, the team would deliver x over a limited period of time and then each person would move on to the next thing.
This isn’t a sustainable way of working for many reasons:
- It makes planning very difficult, as you scramble to find the right people to deliver a project
- You cannot build mature teams as people constantly switch context from one temporary team to another
- There is no ownership of output or long term support and development/tech debt
- Very difficult to build relationships with users and stakeholders.
Introducing service teams will promote local prioritisation and decision making; shifting the focus away from one-off projects and isolated bug fixes to a regular discussion between the team and stakeholders to define long-term goals that bring the most value to users. Funding teams not projects.
This would be a team of digital specialists empowered to build and support services quickly and iteratively. Keeping the team together retains knowledge, improves ways of working, collaboration and supports better planning and prioritisation.
To give these service teams the best chance of success, we wanted to embed all the people they would need to identify, understand, validate and solve whole problems. These multi-disciplinary teams would include delivery, product, technical and UCD roles.
Teams will also work closely with an empowered Service Owner who is accountable for the quality of the service. They have overall responsibility for developing, operating and continually improving a service.
This joint relationship between stakeholders and the team can work together to design, build and iterate a service based on the user needs and business priorities.
Some organisations have also signed up for the Tech Talent Charter. The amazing initiative to increase diversity across the tech and digital workforce.
We put a lot of thinking and energy behind how we would support colleagues navigate through this change with clear communication, coaching, training and collaborating with them to establish best practice.
We sought the help of experienced Agile Coaches, to help us prioritise learning paths, identify the correct audiences and the most appropriate medium to share the information – as well as deliver aspects of the training.
We planned a series of open lunch and learntype training sessions where we covered a syllabus of topics ranging from Agile ways of working and UCD to the GDS Service Standard. These sessions were recorded and made available to the whole team.
We also scheduled short lean coffee style drop-in sessions on Friday’s to troubleshoot any specific issues teams were facing. Finally, we had 121 sessions with colleagues to coach and mentor them through change.
To supplement our internal training, we curated online training via Pluralsight for each profession and also encouraged people to attend formal training. This included training by GDS, Agile Project and Delivery Management (ICP-APM) and some also attended training to become fully-fledged service assessors.
Throughout the process, the community started to document the new processes, policies and ways of working. The culmination of this was a documented body of knowledge that we refer to as the Digital Playbook. It’s been useful for us to use as a reference point and we have been iterating on it over time and have recently published it online for others to use 👍
Agile ways of working
Embedding the principles and patterns of Agile go beyond the delivery team, but that is still a great place to start reaping the benefits of Agile and to bring consistency across teams.
All of our Multidisciplinary teams work utilise established Agile frameworks, including Scrum, Kanban and Lean. They work in sprints, using common Agile artefacts and patterns to create an environment of self-organisation and collaboration. This includes:
- Daily stand-ups
- Weekly backlog refinement
- Monthly Show & Tells
- Retrospectives and Team Health Checks
Alongside this, the delivery community worked with internal users to bring consistency to our planning tool:
- Open backlogs and sprint boards
- Use of wiki and shared documentation
- Establish access levels, security groups, board templates, requirements hierarchy structure
- Utilise delivery metrics to help teams become more efficient, identify issues and support planning (Burndown, Velocity, Cycle time, Dwell time, throughput)
We are also working to extend these practices to operational teams who are absolutely essential but can often be overlooked when new projects are being planned.
The role of Digital in the organisation is to enable, empower and inspire people with great technology products and services.
In its most basic form, this translates to delivering products and services that solve the organisations most pressing problems. However, with a fixed headcount, there is limited capacity which forces us to really think carefully about what problems projects are trying to solve and how it weighs up against other priorities.
We needed to get a systemic, end to end view of projects with clearly defined routes to work (continuous improvement or project). Furthermore, to ensure a sustainable pace, we needed to implement appropriate WIP limits at the portfolio level so teams in digital have enough notice to support and deliver a piece of work.
The summary of this was a system with the right checks and balances:
- An established Single front door where stakeholders will work with the Business Relationship Manager and Assurance Lead to discuss all new digital projects.
- Empowered Product Managers to work collaboratively with stakeholders and service owners to understand user needs and define clear problem statements
- Introduced Heads of professions upstream, to support and advise stakeholders, suppliers and teams, establish best practice and surface team capacity and wellbeing.
- Use a Highly visual open, planning aid that helps everyone see the pipeline, progress of projects, blockers etc…
- Surface Portfolio Metrics to help make informed decisions
We needed to get this right. Too much governance and we potentially become a blocker for the organisation risking shadow IT spawning up. Not enough governance and we risk overwhelming our teams.
This approach will help us limit projects in progress, visualise the systemic workflow, improve collaboration between professions and help us prioritise finishing over starting new where possible.
The Portfolio Metrics we are surfacing to help us make informed decisions are:
- Lead time — Ave. time it takes for a new request from initial submission to being picked up by a team
- Cycle time — Ave. time it takes for a team to finish once started
- Aged WIP — How long a project has been in any particular stage of the process
Organisations are increasingly working to the GDS Service Standard and are complying with digital and technology spend controls, which means that we have to take a user-centred approach for projects and meet the Technology Code of Practice.
This way of working was a significant culture change and we had to collaborate with our colleagues across the business to introduce user-centred design professions and principles and demonstrate why it’s important to understand a perceived business or user need before committing to significant projects.
- A clear understanding of user and task requirements.
- Incorporating user feedback to define requirements and design.
- Early and active involvement of the user to evaluate the design of the product.
- Integrating user-centred design with other development activities.
- Iterative design process
We recruited new Product Management and UCD (User Research, Service Design, Interaction Design, Content Design) roles into the organisation. We encouraged teams to work iteratively by starting with a Discovery to understand the problem that needed to be solved, followed by an Alpha to try experiments to solve the most important challenges before we commit and build the product or service in Beta and Live.
In an environment where there can be a perceived need to deliver at short notice, asking for early sight, the space to plan long term and the opportunity to work closely with users has been a challenging but important lesson.
Working in the open
Being more open and transparent was at the heart of our objectives. To deliver successful change, you have to bring people on a journey and this applied to every single item of change we were introducing. It’s also crucial that you continue to share and work in the open throughout any delivery activity.
We asked ourselves, how can we get better at communicating what we are working on and share the progress teams are making to support and deliver services?
The first step for us was to establish communities of practice (CoP) across professions. Multi-disciplinary teams by their nature include people from different professions so it’s important to give people an opportunity to grow with their peers. Communities are a great way to build a support network and share learning and expertise.
The second step was for us to run regular show & tells. We aren’t a big team so we combined our show & tells into one monthly event and we extended the invite to everyone. This creates an environment for the cross-pollination of ideas is a great way for teams to showcase what they’ve been working on in recent sprints. It’s important to make the content accessible to the whole audience, but this can be challenging when discussing very technical concepts.
Finally, we introduced weeknotes and encouraged people to start writing blogs. Weeknotes are a good way for the team to reflect in small updates. What’s going well, what challenges they’re facing, achievements and shout outs. This is also a good way of being open and transparent.
We’ve been careful to gradually make these changes over a period of 12 to 18 months so as to not cause too much disruption. This will give us an opportunity to see how things go, get feedback from colleagues on what’s working well and what isn’t so much.
What does good look for us? Well, our purpose is to ‘enable, empower and inspire people with great technology products and services’. For us, this means we want to create an environment where we can support the organisation solve important challenges with digital solutions that meet users needs; whilst maintaining the wellbeing of our colleagues to deliver them.
I’m aware I didn’t go into too much detail about each topic so If you have any questions or are going through your own transformation and would like to share notes, please reach out 😄