I'm Lorraine Hennessy, part of the team working to transform the way we work across the Strategy, Policy and Analysis Group (SPAG) at the Department for Work and Pensions (DWP).
We’ve just finished a great three-day design sprint with BTG and Digital Academy colleagues. We wanted to understand whether it was feasible to build a policy tracking tool or 'Policy Portfolio', and whether this would give us a clear enough view of people and policy priorities across the department.
Understanding the problem
DWP has several policy priorities and due to the size of the department, the policy challenges tend to be large in scale.
In the first few months of the SPAG programme, we've spent a lot of time talking to DWP colleagues to understand the issues around how we work in order to develop and deliver government policy.
What we’ve found is that the scale of the department means that there is a significant amount of policy work happening across a range of areas at the same time, and we need to be efficient at coordinating and prioritising the work.
Using a design sprint to answer key questions
Colleagues working in the Business Transformation Group (BTG) and the Digital Academy suggested that we work together on a design sprint to answer some key questions.
Ben Holliday, Head of User Experience at DWP, explains the purpose of a design sprint like this:
"Design sprints are a way for small agile teams to work through and test design problems. The idea is to agree and understand the problem we’re trying to solve together, and then create a realistic enough prototype or testable prototype in 3-5 days."
As Ben set out, the real benefit of the design sprint is that it encourages you to get to a testable prototype or proof of concept, something tangible that we can show to people who would potentially use the product.
What we did during the design sprint
Day 1 was all about why are we doing this, what’s the problem we want to solve, understanding policy and the processes we use to develop and deliver policy.
It was also a good introduction to Agile ways of working for the SPAG people in the room, some of whom hadn’t worked in an Agile way before.
By the end of the day we had mapped out the journey for a bit of new policy work and started sketching some possible solutions to how we might track this in a digital product.
Day 2 saw us further developing our sketches which we then started to test as paper prototypes with other policy colleagues.
During day 2 we had drop-ins from a couple of the SPAG directors to have a look at our progress and were encouraged by their reaction to the work we’d done so far.
Day 3 was our chance to review the prototyping which we’d produced so far and start preparing for the show and tell. I was really impressed with the skill of the BTG team, who were able to translate our multiple asks and turn it into something which looked so slick and polished. We soon learned that the important thing was that the prototype felt real enough to test with our colleagues.
As the day went on, we pushed on with the final refinements ready for the show and tell in the afternoon. We also had further visits from SPAG directors during the morning.
The show and tell in the afternoon was really well received and Jeremy Moore, Director General for Strategy, Policy and Analysis, and Kevin Cunnington, Director General for Business Transformation, were both able to attend and take part in the question and answer session afterwards.
Showing the art of the possible
As part of the final show and tell, the proof of concept work done by the team really helped to show how we could use something like this to fix some of our resourcing and prioritisation issues but also how we could work in a more people-focused way.
I felt so proud of what we had achieved. My colleagues, Paul Smith, Tom Morgan, Maxine Divers, Rob Banathy and Ben Holliday, did such a great job of showcasing the art of the possible.
Feedback from the SPAG volunteers was overwhelmingly positive. We formed a real bond during those few days, despite not knowing each other beforehand, and we developed a great team spirit. We found that this collaborative approach to working is the real benefit of a small, focussed agile team.
The willingness to work together to get a proof of concept built really helped make the intensive three days’ work really enjoyable.
Next steps
It's been important to get everyone to understand that we weren't building working software during the design sprint. The proof of concept answered some of our key questions and we now plan to stand this up as a digital product team.
This means taking more time to run a discovery to better understand the user needs for tracking and planning policy within government.
It will also mean that we take the time to fully develop any digital solution as part of an 'alpha' with a dedicated agile team that will look to iterate and explore different solutions, starting with some of the things we've learned by building our proof of concept.
2 comments
Comment by Bev Smith posted on
Really interesting to hear how it all comes together - thank you for sharing
Comment by Antony OBrien posted on
fascinating yes, thanks.