Working as a Delivery Manager in an agile team has necessitated introducing agile ways of working into our primary stakeholder team. I shared learnings from my experiences of this in a session for Digital, Data and Technology (DDaT) Week at DIT (Department for International Trade), 25 to 29 April 2022.
Rather than present this as a past tense 'success story', I sought to provide a living case study. I shared the ongoing work my team is doing to improve our ways of working and communication with stakeholders and the challenges we still face. In addition, I wanted to signpost useful resources that colleagues across the DIT can use to start their own agile journeys.
For those who are unfamiliar with agile methodology, Atlassian provide a great definition:
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments.
You can read more about agile ways of working in the GOV.UK Service Standard.
Setting the scene
I currently work on the Tariff Application Platform (TAP). Our vision is to provide a service that supports the management of the UK Trade Tariff.
Team roadmap for stakeholders
To deliver this vision, we are developing 3 products:
- the platform: the data and model used to hold the UK Global Tariff and the infrastructure to support sharing this with operational users across government
- Tariff Management Tool (TaMaTo): this is the user interface allowing users to maintain and update the UK Trade Tariff
- open data: the mechanisms and data models we are using to make sure the UK Trade Tariff is open to internal and external users
We need to make sure that the interface is usable for Tariff Managers in the Multilateral Tariff Policy and Operations (MTPO) team. Their role is to update the UK Tariff to reflect policy changes.
Our team follow agile ways of working, but our primary stakeholders (MTPO) work differently. Alongside the pressures of navigating a rapidly changing trade policy landscape, delivery was slowed by miscommunication and gaps in our strategic collaboration last year.
The starting point
From working across teams in different sectors, I have observed and been part of teams where there are difficulties around ways of working with stakeholders.
In the case of TAP, to start iterating the state of collaboration between us and our stakeholders, we needed the following:
- acknowledgement that things could be improved
- acceptance that the road ahead will be long
- willingness to compromise on our current ways of working
Even in previous teams where delivering agile products wasn't a factor, the above would still have applied.
The agile 'bridges'
Agile can appear complex and overly focused on 'technical language' for those in the policy arena. However, there are some 'bridges' in an agile team that can produce common language and understanding across teams.
Service Design
Introducing a Service Designer to your team can create dialogue around your service that is far more accessible than granular product-level conversations. Service Design is often visual and process-focused, so can give your stakeholders points of entry (e.g. mapping pain points or user stories).
Discovery
The so-called 'Discovery phase' is a period of exploration into an issue or issues concerning users. It can also create the means of stakeholder engagement through user research techniques and data collection.
Operational Performance Reports (OPRs)
OPRs are used in DDaT and Cyber as a living risk register for digital services. Bringing relevant stakeholders in to shape these reports can ensure that delivery risks are flagged and communicated consistently across the piece.
Show and Tells
Show and Tells are used across by teams to communicate and demonstrate new features teams are developing, They can also be useful for stakeholders to ask questions and learn more about the products they use.
Other resources
DIT offers other resources for teams outside DDaT to better 'acclimatise' to agile practices.
In the TAP team, we used:
- Introduction to Agile workshops - these are recurring foundation-level sessions aimed at colleagues with little or no experience of agile and its methodology, but would like to understand the basics
- GDS Agile Coaches - the Government Digital Service (GDS) offers coaching to help teams understand their agile maturity and identify future process changes and iterations to bring them closer to their goals
- Firebreak Week - for 1 week every 3 months, teams pause non-critical development. Everyone has the chance to have some self-directed time to work with colleagues across DDaT to develop new solutions and product ideas. 'Pitches' for DDaT projects can be written by teams outside of DDaT, such as HR and Finance
What are we doing now?
This is an ongoing process and we will continue to iterate and likely misstep in places. There are currently many moving parts, all of which we are discussing and modifying as we go.
Discovery outputs
This process started in March involving our User Researcher and Service Designer. Working with our stakeholders, they identified areas for improvement in how data from our service is sent across the policy and operations space. The outputs - two service maps and a report - were finalised in June.
A shared roadmap
We are now integrating our stakeholder's input more directly into our roadmap. This is so that we can align closer on our short-term and long-term vision of the service without enforcing rigidity and arbitrary timelines.
Sharing ownership of governance
In order to create a governance structure that supports all our reporting needs, we share the accountability of preparing for and documenting our steering board.
Mapping user journeys and stories
We have created sessions with our users to talk through features we've developed and closer integrate the voices of our users into our design process.
What comes next?
We're very much still on this journey, but here are the next steps for us in a nutshell:
- agile coach recommendations - we are waiting to receive recommendations from the coach we've been working with on how we can continue momentum with our stakeholder relationship
- introducing retrospectives - our stakeholders have adopted team retrospectives, an agile 'ceremony', as a way for them to introduce regular reflection and iteration to their ways of working
- mapping service pain points - one of the deliverables our Service Designer has produced is an as-is map of our service. This will show the pain points that our users, team members and stakeholders are contending with in relation to the service we are building
In the spirit of agile, our service will never be 'finished'. We will continue to evolve in line with the nature of the UK's post-EU exit trade policy. The team managing TAP will always need to collaborate with both internal and external stakeholders to deliver value to traders and the citizens they serve. The practices outlined in this blog can support in maintaining and improving this collaboration.