A few years ago when I first joined GOV.UK Verify as Programme Manager we didn’t have a huge need for a complex governance structure to maintain our agile workflow. Back in the ‘good old days’ there was only one development team working on a single product, and named individuals who led the commercial, legal and engagement parts of the programme.
But Points 4 and 5 of the Digital by Default Service Standard say:
Build the service using the agile, iterative and user-centred methods set out in the manual.
And
Build a service that can be iterated and improved on a frequent basis and make sure that you have the capacity, resources and technical flexibility to do so.
As GOV.UK Verify has matured, the programme has evolved, both to meet demand and meet these criteria. For example, we now have fully staffed teams onboarding new government services and certified companies onto our platform using a refined gating processes. Our development team has grown in size and is now working on multiple, high-quality products and services that form part of GOV.UK Verify and we continue to ‘keep the lights on’ operationally with consistently high availability.
Along with the increase in growth, we’ve had to iterate our governance structure to ensure that our programme is continuously working towards our agreed aims. Our ultimate aim was to create a programme structure that was both lightweight and mostly flat, but at the same time adhering to agile best practices. With our current structure, I believe we’ve achieved these goals.
Scaling Agile for GOV.UK Verify’s governance
Below is a diagram that illustrates our governance structure. At the top of our internal programme governance structure we have Programme Director, Janet Hughes, who is ultimately responsible for GOV.UK Verify. Janet interacts with many external stakeholders, privacy and steering groups within government, the private sector and senior colleagues within GDS.
We operate within the governance principles for agile service delivery and have two main groups that manage the programme: the Senior Management Team (SMT) and the Portfolio Group.
The SMT meets on a weekly basis and is responsible for setting the vision for GOV.UK Verify, executive stakeholder management, managing programme budgets and team recruitment. The SMT includes all the people who lead teams in the programme, and the weekly meeting includes each team reporting what’s going on for them that week. This helps us make sure everyone across the programme is aware of what’s going on that week, which is important given the range of things we’re involved in.
The Portfolio Group also meets weekly and is responsible for managing the project portfolio within the programme. This is commonly where individual projects report on overall status, ask for additional resource and solve delivery issues. The Portfolio Group, along with the Risk Management Group, is responsible for managing programme assets, such as the risk/issues register, programme plan and programme roles and responsibilities.
Once a project has been approved and prioritised for delivery by the Portfolio Group, it is up to the SMT Sponsor, Delivery Manager and Product Owner for each project to determine how they best deliver their projects with their teams.
Although teams are required to track their work and report status, we have a Management by Exception principle in place where projects can autonomously deliver as long as they stay within any confines (time, scope, budget) set by the Portfolio Group. This means that teams are free to choose the tools and the methods that best suit the task at hand.
Though this governance structure has been in place for a while, there is still plenty of room for improvement. With Agile principles in mind, we are continuously refining the processes and ways of working as we go along.
Agile vs Waterfall in the challenge of online identity
Agile delivery management is known for having an iterative approach to development. This means that there are cycles of developing new features, releasing them often and gathering feedback from users before starting the cycle again using the newly gained insights to inform the next set of priorities. Working in co-located, cross-functional teams and focusing on high-value and high-risk features first are other characteristics of agile development.
Waterfall management typically includes a series of stages, from defining requirements, to design, to development, to testing, to release, and finally to operational handover. One issue Waterfall management has is that there can be a lengthy period of time between the stage where requirements are gathered to the point where a user actually sees the end result. During this time the user’s need could have changed dramatically.
Although our default position is to manage projects in an agile fashion, certain projects within our programme need a full range of tools and methods to successfully deliver. We choose whichever approach is appropriate for each situation. For instance, software development tends to be more successful using agile methods and we can get user feedback and real-world data to drive our future roadmap more quickly. On the other hand, in certain situations where there is a contractual onboarding gating process to follow or a major systems-integration needs to line up, sometimes a more waterfall-style approach is more appropriate. This is why we tend to use the right tool for the job and we are not dogmatic about the agile approach.
The ‘good old days’ are yet to come...
Although sometimes I reminisce about the old days, where a smaller team felt more intimate and manageable, I do think that we have created a robust governance process where much of the control over projects is where it should be; with the people actually working day to day on the projects. As we continue to grow and further complex relationships evolve, working with more diverse government departments and undertake more industry engagement, as long as we are still able to maintain a transparent process that works for the team, then I believe the ‘good old days’ for GOV.UK Verify are yet to come.
Sign up for email updates and get the latest blog posts, straight to your inbox.
4 comments
Comment by Marcus Ferbrache posted on
Does the continued existence of an onboarding team for certified companies imply that there are likely to be further identity providers coming onboard in the next 12 months?
Comment by Rebecca Hales posted on
Hi Marcus
We currently have 8 certified companies for users to choose from and at the moment there are no plans in place to add more. The team working with our certified companies will help those companies with their continuing development of user journeys and the introduction of new methods and data sources.
Comment by Mark Dalgarno posted on
Would be great to find out more about this: On the other hand, in certain situations where there is a contractual onboarding gating process to follow or a major systems-integration needs to line up, sometimes a more waterfall-style approach is more appropriate. - what stages doed the waterfall have in these cases? How is it managed?
Comment by Tom Bassett posted on
Hi Mark,
Thanks for your question and apologies for the delay in response over the festive period.
Where waterfall techniques are more appropriate, we would use more traditional waterfall phases to manage the work, e.g. Analysis, Design, Development, Integration and Test. Management would be more milestone based and involve more traditional project management methods and techniques in such cases. Where feasible, we would seek to bring in lean/agile practices into such projects to de-risk the issues that are common in waterfall methods.
Regards,
Tom