Back in January 2020, not long after we finished our Discovery sprint, we posted about a project called Readiness Reporting and Deployability Discovery, or R2-D2 for short.
On May the 4th (obviously), we established a complete multi-disciplinary delivery team and started an in-depth, week-long induction for the new members, before then moving properly into the alpha phase of delivery.
The induction was intense and tiring, as we (Rob and Iain, who continued from the discovery team) had to explain both how the Ministry of Defence works – a feat in itself – and enough detail of the discovery phase outputs to be able to be effective in alpha. We followed that induction with hypothesis generation exercises, spin-off deep-dive sessions, and so on, before creating our first Trello cards, beginning to find the right users, and all that good stuff. The effort was entirely worth it!
As if that wasn’t challenging enough, we were doing all of this having never met and working fully remotely (we’ll be blogging about our experiences of doing so soon), apart from a single, in-person, socially-distanced meeting in a park in Basingstoke.
Challenges along the way and a series of firsts
Our first challenge predates the team arriving and was not particularly glamorous: how do we a) get funding, and b) hire a team? Not as easy as you may think, in a large part because there was no great precedent in Defence for hiring agile delivery teams, using a Government framework, in a reasonable amount of time. With more than a little help from financial and commercial colleagues, and some bureaucracy hackers whom we had got to know well, we finally welcomed the team you see above.
That challenge overcome (and documented, so that we can do it again more easily), the next challenge was far more wholesome and the first major counter-cultural shift that we were asking Defence to make: namely, allowing us to store sensitive data in a public cloud hosting environment.
We in the Defence Digital Service (DDS) are quite clear that data is more secure in public cloud, but this is not a common attitude in Defence. This is understandable, since much of the MOD’s work is extremely sensitive – secret, even – and the department has had a more difficult journey than most other Government departments in transitioning from the old classification system to the new.
Nevertheless, we were adamant that we would do things the right way, and so began the challenging process of gaining accreditation and generally meeting the requirements of a piece of policy called Joint Service Publication (JSP) 604. The challenges were twofold: firstly, JSP604 is called ‘Network Joining Rules’ and, as the name suggests, is designed for a paradigm in which one is using on-premise hosting solutions, which we are not. Secondly, nobody had done this in Defence before and adoption of public cloud generally (let alone with sensitive data) was sparse, so there were no patterns to copy.
I am delighted to say that after many meetings, workshops, documents and discussions, we achieved accreditation and migrated sensitive data onto the public cloud, thereby setting a precedent for the rest of Defence and hopefully expediting any future attempts to do the same. To take this one step further, we did this in a completely repeatable manner, declaring all of our infrastructure as code, and storing it on GitHub, where the rest of Defence can access it.
Other challenges included cultural ones, such as those mentioned in our blog about user research in Defence, and undertaking (voluntarily) a GDS-run alpha assessment.
We passed our alpha assessment!
Even before we got the team on board for R2-D2, we knew we were going to ask GDS if they would kindly facilitate putting a panel together to assess at least our alpha phase. We didn’t need to: this is an internal-facing, non-transactional system (we call it a ‘system’ rather than a ‘product’ or ‘service’ deliberately) and so falls outside of the mandatory criteria for assessment; however, we were very keen to show that it needn’t be scary, and it’s totally possible to meet the Government Service Standard, even in a sensitive, complex, internal, Defence-specific context.
While they don’t often do so (since there are so many eligible services across Government that need panels), GDS kindly partnered with us and made it happen. We had fortnightly (sprintly) meetings with them to help ensure that we were on the right track and wouldn’t come unstuck when it came to the assessment. Both GDS and DDS knew that there was more at stake with this assessment than is often the case, since it could have, in the worst case scenario, made or broken the concept of assessments within the MOD being seen as a positive thing.
And back in September 2020, we passed our assessment, becoming one of only a few MOD services ever to have done so, and the first internal one ever! We ended up having to have the assessment in two parts, since the first one left too many questions unanswered (the subject matter is highly complex and the Defence context genuinely is tricky to explain and understand), but the outcome was excellent.
Onto the next episode
We’re now knee-deep in private beta – getting tantalisingly close to delivering our minimum viable product to our first subset of users, having recently seen our first complete user journey come to life with real data! Stay tuned for more as we progress on this exciting adventure.
4 comments
Comment by Paul Duffin posted on
Great work and I am in a similar position. Please keep us updated on your progress and hopefully success.
Comment by Kirsty Rhodes posted on
Really enjoyed reading this blog Iain and the milestones you and the team are achieving, well done.
Comment by Howard Alcock posted on
What/who is GDS for the un techie of us?
Comment by Rebecca Carden posted on
Hi Howard,
GDS is Government Digital Service
https://www.gov.uk/government/organisations/government-digital-service