As a team of different disciplines working on the committees pages for beta.parliament.uk, we recently crossed the finish line of our first discovery. We’d conquered the mountain that was dissecting committees within Parliament. We’d built some good relationships across both Houses as well as within PDS.
For the alpha phase, we were ready to reassemble the component parts we’d gathered during discovery into something more friendly for our users. It was with passionate optimism that we aimed to continue the momentum we had during discovery.
Trying out Google Ventures methodology
To support this momentum, we tried using the Google Ventures (GV) design sprint methodology. GV encourages a rapid way of proving or disproving theories on how to solve user issues uncovered during a discovery phase. It advocates close management of time and resources to help teams with ideas, concepts, prototypes and testing to focus on user needs in just five days. It was quite a revelation.
We found four high-level areas in discovery that needed to be addressed during the alpha:
- information – what users want to know about committees and committee activities
- interaction – how users get involved with the work of committees
- engagement – how the committee manages the two way dialogue between contributors to the work of committees and the committees themselves
- enhancement - how we can support committees ever evolving needs
With this in mind, we were assigned four five day sprints to deliver a well-rounded series of tested designs. Each sprint focused on the high-level areas above with an additional one for reflection and preparation for alpha.
The first sprint presented some challenges that weren’t anticipated. The guidance GV provide outlines a timetable with allocated timeslots for various activities for each day. This is something we most definitely underestimated the value of!
Running out of time
As a result of our lax timekeeping, the first sprint felt quite disorganised and rushed. We had a pretty definitive idea of what we wanted to deliver by the end of it (a basic information architecture in case you were wondering). However it felt far more difficult than it should have been.
The first sprint left the team feeling a little deflated. In our retrospective we discussed it and changed our approach for the next sprint.
Different interpretations
The second sprint was an improvement. We stuck to the allocated timeslots a little better and things felt less chaotic. We also realised just how high-level the areas we had initially outlined were. This meant that the direction we could have taken for the second sprint (and all subsequent sprints) could have gone many different ways.
The issue with this? Everyone had interpreted it in a slightly different way. This meant lots of discussions which tended to be fairly cyclical. During this sprint we discovered the importance of having a strong decision maker to reign in discussions. Again this was discussed in our retrospective for this sprint and we changed our approach as a result.
Weariness sets in
The third and fourth sprints almost seemed to merge into one as we began to get a little weary as a team. It felt like we had gotten into the mindset of delivering within the GV way of working. At this point though it seemed like we wouldn’t be able to cover everything we would have liked to during the initial sprints.
I would attribute this to the sheer size of the project and the prospect of only being able to address small chunks of the high-level concepts within tight timeframes.
My thoughts on Google Ventures methodology
I don’t think that engaging in four consecutive design sprints helped create the usable ideas we expected or hoped for. This is for a few different reasons:
- there wasn’t a targeted backlog. Having one would have lifted a lot of the uncertainty over the direction of sprints
- running design sprints consecutively left little time for reflection or iteration especially because the concepts for each sprint differed
- there wasn’t anyone experienced in running design sprints of this nature, to provide guidance and certainty (like a scrum master). This would have been an invaluable addition to the team during the first couple of sprints
- it took a while to empower a decision maker. Even once this had been done, it was still difficult to define the vision or direction for committees as a product
More than anything else, I felt that working with an unfamiliar methodology strengthened our relationship as a team. It reinforced our desire and tenacity to deliver results under whatever circumstances we were presented with. It also highlighted the strengths of us as individuals and as a product team.
What’s especially noteworthy is that we also engaged our new network of contacts across both Houses in this new way of working too. This saw us strengthen those relationships and highlight the value of the work we do as a digital department.
Even though we didn’t deliver fully realised designs, the experience gave us valuable insights we wouldn’t have been able to gain otherwise.
In addition, the fact that we were given the licence to experiment with new ways of working and discover new techniques is testament to the innovative nature of PDS as an organisation. It also shows the desire to deliver the best experience for our users, by whatever means we need to.
Interesting in working in PDS? Take a look at our current vacancies.