Lessons learned from 15+ GDS Discovery Projects
The Government Digital Service’s (GDS) Service Manual breaks down an Agile Project in Discovery, Alpha, and Beta phases. Most government organisations where I have worked try to replicate this approach even though there’s often confusion about what each phase aims to achieve and when is it that one ends and the next one starts.
Over the past few years I’ve facilitated several Discoveries and observed recurrent challenges affecting teams and organisations. Below is a not so small list of things that could help your Discovery to save time and money.
1. You need less people than you think
A Discovery requires a quick turnaround of research and validation of user needs. You do not need a football team for that, just the right players. Often you can get away with a good product owner, an experienced user research, sometimes a subject matter expert — when digging into a really specialised area — and help from a designer.
2. Don’t start if you not really ready
Securing office space, recruiting and onboarding your team, approving business cases, finding your stakeholders, pinning down your first few research trips and interviews, … all that takes time. This stuff will block you. Do not start if you do not have them in place.
3. Focus on the ball and not on the players
The ball is your project. The players are your team. Focus on the progress of the project rather than in keeping everybody busy. A common pattern is “bosses” thinking the “workers are not too busy” and moving them around to help other teams. This is detrimental to your project and to your team.
Local optimisation, context switching, single point of failure, you name it. A Discovery is a short term thing and your team should be doing this thing only. Focused team and full time commitment. Work hard, finish early and then people can go and do something else.
4. Collocation & face to face collaboration
A Discovery takes between 4 to 8 weeks, barely enough time to create a sense of a team. Make your life easier by being collocated and favouring face to face communication over lengthy chats and email updates.
5. Have at least one team member who’s “seen the light”
I often see new Product Owners and Delivery Managers being sent to a “3 days GDS Agile crash course” and them being assigned to a “very important project” with a team who’s also new to Agile ways of working. This is akin to competing on the F-1 after just receiving your driving license. Often, it is after the course that you actually learn to drive properly. Without a PO and/or DM with good Agile experience you will struggle. Save time and money by investing in experienced people and pair them with less experienced ones so knowledge is shared.
6. Agree on “ways of working” and what do you mean by “agile”
Agree and regularly revisit which “elements of agility” you want to have in your team. What methodology and/or framework you are going to be using, how you will measure progress and success, which ceremonies are necessary, why and how often. Go as far as discussing roles and responsibilities and how to go about overlapping work between collaborative disciplines such as business analysis and user research.
Keep stakeholders and the rest of “the business” involved and aware as much as possible so they can understand why it is that your team works in a certain way. Use every opportunity to educate and share understanding — in and outside of the team — about all the things agile, without using the word agile.
7. Keep small. Keep focused.
The smaller the problem the quicker you can explore it and complete your project. Be laser focused and push back on anything that does not align to your goal. Goal and scope creep are likely to sour your Discovery by producing vague non-actionable results.
Do you need more research? Perhaps a different area you want to explore? Finish your current Discovery and then start a new one.
8. Less time is better than more time
In Agile we time box everything. Having an “end” forces you to make a decision even though it might not be the “best” one — you can always change later on but you do have to make a choice. A Discovery should be done at a quick pace, you are “looking for “just enough” rather than “all of it” and the challenge lies in deciding where to draw the line.
Teams who normally complain about lack of time have either been side pulled by external commitments and/or lack experience in finding the right level of detail a Discovery requires. Too much time is a problem because it destroys any sense of urgency and it allows for external noise, interests and agendas to be inflated into your project making your delivery ever more challenging.
9. You do not need a pre-Discovery
This seems to be an emerging trend. A Pre Discovery normally means “we have no clue what we are doing so let’s waffle it”. You do not need a pre-research to decide on your research. If you do not know what you are doing, do nothing. Think before acting and maximize the amount of work not done.
10. Work in the open and integrate as early as possible
Multidisciplinary teams new to agile often struggle to integrate their work in a way that it looks like a cohesive narrative. Integrate iteratively and start as soon as possible, encouraging the team to work together from early on.
New team members might avoid sharing documents from the start because they want to get it “perfect” before the rest of the team can see it. Encourage people to work in the open and focus on progress rather than perfection. The earlier you can get feedback the quicker you can be sure it’s good enough and move on.
11. Transparent communication and expectation management
Be clear and honest about external expectations such as the ones from ministers and senior stakeholders. Those are normally ambitious, broad and distant from the reality on the ground. Agree what is it really fixed or changeable such as costs, deadlines and scope so you know where to compromise.
Keep all the “chain of command” in the loop as your project matures and takes shape so they are aware of where you’re going, when you will be getting there and what to expect by the end of it. There should be no surprises at any point.
Does your team have the capacity (time) and skills to deliver what you have been asked? Are your stakeholders and users going to be in touch for the duration of the project? These can be hard conversations to have.
12. Get a grip of of the wider picture
Understand where and how your team’s work fits into the wider picture. Who you are doing it for and why it is important. This will help you to narrow your scope and also to create a real sense of purpose on the work you are doing thus motivating your team.
13. Inspect and adapt: regular retrospectives
Retrospectives are crucial to any Agile team and a regular opportunity to discuss how to work better as a team. You don’t need to wait for them to address problems but they are a formal opportunity to reflect and do so. Aim for sessions ending with well defined actions that the team will be working towards — i.e. “let’s improve our stand up so that we can finish it in 15 minutes or less” — and that you revisit those on your next retrospective.
14. Commitment & discipline
A lot is said about the importance of “an agile mindset”. Mindset has to be supported by discipline. Discipline to stick to your team agreements, commitments, deadlines and to starting and ending ceremonies on time. Environment and experienced leadership goes a long way in supporting and fostering such behaviours.
15. Preserve the knowledge
The output of a Discovery is knowledge. Your team might finish with a drive full of files, spreadsheets, videos, etc. All that is normally encapsulated in some expensive slide deck and a presentation. What happens to all that afterwards is uncertain. There aren’t initiatives allowing for an organised storage of these very expensive artefacts in a way that they can be easily consumed in the future. This causes duplication of work that has already been done and even questioning about the quality of previous research.
Make sure your team’s work is stored and shared in a way that can be preserved and consumed by others, now and in the future. Consider how others will know your research exists when they need it.
16. Do not take an Alpha for granted
A common misconception of a Discovery is that it will lead to an Alpha. A common misconception of an Alpha is that it will lead to a Beta. One of the main advantages of using an agile approach to a project is to minimize risks by validating user needs and user problems before throwing massive amounts of money into a project. A key requirement of this approach is that it must be ok to “fail” because “failure” means saving money by stopping sooner rather than later and trying smaller rather than big.
Quite often a Discovery starts with pre-existing assumptions of what your Alpha will look like or worse, the Discovery is orchestrated in a way that it will lead to an Alpha regardless. Biased research is a problem and likely to demotivate your team. If a “ministerial requirement” requires an Alpha regardless, i.e. “something has to be created and trailed”, your Discovery should make this explicit and be shaped around steering and recommending approaches to your Alpha and how to better support the “needs” of the ones this project is really for.
I guess that’s it for now. I would love to hear from you about your current and past challenges with this sort of work, in and outside government.
Speak soon!
References
10 experiments you can try to improve discovery, Scott Colfer
