I’m Ash and I work in the GDS Transformation team. Recently I’ve been part of a team looking at the tricky topic of governance. This post is aimed at people who govern service delivery. It’s long, and we’re sorry about that, but there’s a lot to say.
GDS is working with 8 government departments to build 25 exemplar services. These departments often ask us how to govern agile service delivery. We think it’s incredibly important because governance should support delivery rather than restrict it. Having said that, it’s a hard thing to get right.
Our team has been working with departments to try out some early GDS guidance on governance to improve the way that services are governed. We’ve taken what we’ve learnt and combined them with our experience at GDS to create 6 alpha principles.
We’ve developed these so people can test them in conversation. Here they are with some explanation. We are planning to write further guidance later but in the meantime please let us know what you think, there’s a survey at the end.
The alpha principles are:
- Don’t slow down delivery
- Decisions when they’re needed, at the right level
- Do it with the right people
- Go see for yourself
- Only do it if it adds value
- Trust and verify
1. Don’t slow down delivery
We help build services that are continually improved to meet user needs.This means:
- unblocking anything that slows down delivery
- being available when needed - throughout service delivery
- being mindful of the balance between features and quality
- making decisions to keep pace with delivery teams
We gauge success through delivery of services that meet user needs. Governing well means:
- actively seeking out delivery impediments, being accountable for them and removing them before they affect teams
- protecting the team from, or helping them handle, external pressures - service teams will be familiar with these!
A bit more detail
Scrutinising services in development at regular ‘show and tell’ meetings provides the best evidence of progress. This evidence, alongside data that delivery teams are already using to manage delivery, should provide the information needed to govern service delivery.
If ‘show and tell’ meetings aren’t happening, find out why. If they are, you should go along if you have governance responsibility for that service.
Governance is also about creating an environment where people can thrive. We have a flat organisation structure so everyone can contribute to the success of the team.
2. Decisions when they’re needed, at the right level
Embrace that things change. Make sure:
- decision making is evidence-based and focused on meeting user needs
- the service manager and team are empowered to make decisions and only escalate when they need to
- you handle changeand improve quality through continuous iterative development
- people who govern keep up with the pace of delivery by having short, frequent meetings
- high impact, high probability risks are managed when needed, and our controls (eg on spending) are based on the balance between costs and benefits
A bit more detail
Services will only succeed if we recognise that user needs emerge and change throughout a service’s life. This means that a service team can’t define a set of features at inception and expect them to stay the same.
People who govern should support this ‘evolutionary’ model of development, recognising that change is inevitable and can’t be eliminated or designed away. They should also ensure that service teams know:
- that they have the authority to make decisions about the service
- what the boundaries of that decision making are
- who is accountable for helping them when decisions outside the boundaries need to be made
Iterative development is the best way of handling change and improving service quality. We can support this by devolving decision making to service teams and by unblocking them quickly for decisions that haven’t yet been devolved.
People who govern should also participate in regular delivery meetings like stand-ups and sprint planning. This makes sure they’re fully informed and can make decisions quickly. It also improves the ways they communicate and work with delivery teams.
We know we can’t eliminate or transfer risks. We encourage highlighting and owning them, but we only actively manage risks that could tangibly affect service delivery.
Our approach to risk management isn't about scheduled discussion of a risk register - it's about dealing with risk at the right time. We identify the best possible moment to respond to important risks and only then start to plan and carry out our response.
3. Do it with the right people
Our people are:
- capable, motivated and empowered
- focussed on goals and key performance indicators (KPIs)
- open and honest about what they do
Trust people to organise and work towards team goals to get the job done so that services continue to improve in response to user needs.
A bit more detail
The only people who should have governance responsibility are those who can:
- make the right decisions
- steer and assure both delivery and quality
They contribute by supporting the delivery team to bring in the right people, in the right environment, at the right time.
Services are developed by multi-disciplinary delivery teams where people have different skills and roles to achieve the team goals. They can include technical experts, business people and may also include legal and policy staff. Teams should keep the same service manager but the specialist skills needed will change as the service develops, so the makeup of the team will change.
We make sure delivery teams have all the skills they need - and we provide them with the environment, workspace and tools to collaborate, organise and deliver.
4. Go and see for yourself
By visiting delivery teams, you can see the value that's being created for yourself.
It's everyone's responsibility to stay well informed. We talk face to face wherever possible, and the best way to measure progress is to ‘see the thing’. This means going to regular service demonstrations and giving feedback.
A bit more detail
We use what the delivery team is already producing for reporting. So we’ll look at things like their wall, sprint reports and demos to get information instead of longer, formal reports.
We regularly plan together. We visit teams to find out and openly and honestly discuss:
- what they're working on right now
- plans for the future
- what blockers they face
The best way to gauge progress, check on the mood of the delivery team and assure a service is by meeting them face-to-face in their workspace. There are several ways to do this without adding overhead. These include:
- at daily stand-up meetings - these last 10-15 minutes and team members give updates on work completed the previous day, work being taken on that day, and any blockers.
- regular planning sessions at the beginning of each iteration, where the team commits to work to be done
- regular reviews or ‘show and tells’ at the end of each iteration to show work completed in that iteration and discuss any issues or changes that need to be made to the service
- regular retrospectives, where the team can reflect on what went well, what didn’t and anything they should change
People who govern should regularly attend these meetings, if only to observe.
Delivery managers should collect data during these meetings to use for simple, highly visual reports. These should be displayed where people can easily see them, such as the team walls or the service's wiki/collaboration tool. The reports will help frame discussions at future meetings.
Walls are an excellent way to track work and show important things, like the work that the team is doing and how they’re progressing. It helps planning and communication, within the team and to others.
Delivery teams should make sure that their walls are up to date and being used.
Visiting a team’s wall gives a current view of its work without anyone needing to produce lengthy reports that take the focus away from delivery. You should take the time to visit them regularly.
5. Only do it if it adds value
We keep user needs at the forefront of everything we do and focus on delivering value early and continuously. This means:
- we set out a clear vision and measures of success - and we communicate these regularly
- we value quality and making sure that user needs are met - and we give the team time to do this
- we explore and develop ideas that could add value - and if they don't work, we stop
A bit more detail
“Delivering value” means introducing a quality service that meets user needs and doing that in an incremental manner. Service delivery - through discovery, alpha, beta and to live - is the most effective and efficient way of understanding user needs and getting a service into users’ hands.
Good governance allows us to do this as quickly as possible by focussing delivery teams on developing things that meet their needs. Governance decisions, like service delivery decisions, should always be evidence-driven.
The service delivery team should develop a charter that describes:
- their service vision
- quantifiable goals
- key performance indicators (KPIs) that show how they will meet user needs
Governance teams collaborate on the development of this charter and help to build consensus and understanding of it across the organisation and in third parties.
Service development is a learning process - and we add value when we learn. Everyone should be encouraged to create better ways to meet user needs. Even if something doesn’t quite work in user research, the lessons learned will guide further service development. This avoids creating an expensive dead-end that doesn’t meet user needs.
6. Trust and verify
We build simple, supportive governance that trusts individuals and empowers teams so they can focus on delivering.
We regularly speak to the team so that we can help to support, steer and assure.
To monitor progress, we use a light touch, checking services a little, but very often. We focus on outcomes from delivery and identify areas for improvement.
A bit more detail
To create the right environment for the delivery team to flourish we form teams with the right mix of people, supporting rather than slowing down delivery and empowering decision makers. Frequent interaction with the team provides regular opportunities for people who govern to support, steer and assure rather than waiting for less frequent, formal meetings.
Regular reflection on how we’re doing and finding ways to improve is an important part of good governance. At the end of each iteration every delivery team holds a retrospective where it discusses lessons learned - both what went well and what didn’t. This lets us identify actions which are planned into future iterations. Retrospectives should also be used across programmes of work.
Regular feedback from the team and from users enables delivery of the right outcomes.
We’d welcome your feedback, so please do get in touch in the comments below or fill in our short survey here to help us develop and improve our future guidance.
3 comments
Comment by David Alexander posted on
Ash, excellent post, very resonant with our own approach, particularly like the six alpha principles we also have a principle of "there are no stupid questions" and "commons sense should always be applied" and given the nature of what we do consider the worst scenarios as well as the ideal
Comment by Davina Sirisena posted on
Great post. I'd like to add that under the 'go and see for yourself' section it those who govern should go and observe some user research sessions. They are invaluable for getting closer to users and their needs and how the service or product is meeting them.
Comment by Leisa Reichelt posted on
+1 Davina.
The go and see for yourself principle is the perfect opportunity to encourage leadership (and everyone else in the team) to observe user research sessions. These research sessions should be happening every iteration, and we encourage everyone in the team to get at least 2 'exposure hours' every six weeks (research shows this is significant in enabling teams to create better services). Ref: https://userresearch.blog.gov.uk/2014/05/29/5-ways-to-help-user-research-work-better-in-agile/