Lessons learned from 15+ GDS Discovery Projects

Lessons learned from 15+ GDS Discovery Projects

The Government Digital Service’s (GDS) Service Manual breaks down an Agile Project in DiscoveryAlpha, 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

101 Inspiring Quotes about Agile, Mountain Goat Software

Why you should NOT be writing weeknotes

Why you should NOT be writing weeknotes

Thoughts and considerations on why you should probably not be writing (or reading) weeknotes.

“I would have written a shorter letter, but I did not have the time.”

Blaise Pascal

I believe a big part of my job as a delivery manager is to maximize the amount of work not done. The more I can save money by not doing work and still producing a desired outcome, the better. A important part of this is to constantly challenge what I do and if I can’t find a good reason for it, I try a little experiment: I stop doing it. Then I inspect and adapt.

I have worked in government long enough to appreciate the importance of being concise. We like a good document around here you see, and riding on this trend comes the weeknotes, regular reports sent by departments, teams and people high in the chain aimed at sharing updates and news with stakeholders and the wider organization. Some places like them so much they have dedicated Slack channels for “broadcasting” them.

Personally, I feel that writing or reading weeknotes is akin to watch paint dry and I encourage my teams not to write them. If they really feel they need to, so have them as short as possible, ideally using a similar format every time, so that the audience knows what to expect and where to find what they need.

What’s the point of weeknotes?

People I spoke to gave several reasons to justify reading/writing weeknotes:

1) Promote awareness of tasks & progress within/between teams
2) Provide a useful record for formal delivery reporting
3) Practice clarity and brevity in communication skills
4) Publicise events and news
5) Praise successes and achievements
6) Looking sideways

All valid reasons that in my view should be addressed — most of the time — through different channels. This is why:

1) Promote awareness of tasks & progress within/between teams
Agile teams already (should) have multiple ways of radiating information — daily stand ups, a working board, sprint planning, reviews, releasable product increment, emails, slacks, … You do not need weeknotes. Weeknotes are non-standardized, lengthy and may not report on what your audience needs to know. Plus, you cannot be sure you are reaching the right audience.

2) Provide a useful record for formal delivery reporting
Weeknotes are informal by nature and bad medium to report on progress as I’ve explained above. There is minimum commonality between different weeknotes, sometimes even within the same team, making hard to mine what is useful or not. Also, they might not be centrally stored or shared online so it is difficult to compare and track the “progress” they aim to report.

A lot of content does not mean a lot of output…

3) Practice clarity and brevity in communication skills
Some weeknotes are like War and Peace and could be trimmed down to 1 page. Concision takes time and is a skill that has indeed to be practiced and mastered but not at the expense of the reader.

4) Publicise events and news
There are way more dynamic and appropriate channels to share those. Blogs, calendars, email groups, Slack, real boards down the hall… On weeknotes important messages are easily be buried within walls of texts and not get the required level of attention they deserve.

5) Praise successes and achievements
As above. There are way better ways for doing that. Praising people and teams face to face is one of them.

6) Looking sideways
This is a good reason for writing weeknotes and I totally get it that for high management weeknotes are a great avenue to communicate and share what is happening in and outside of the company. The problem is that weeknotes are mostly a one way street and again, many times only shared via e-mail making it hard for others to follow and even compare progress (and promises) from previous weeknotes.

Further issues with weeknotes

7) It encourage “Skype management” and distant relationships
When busy stakeholders and managers receive weekly reports they are less likely to engage directly with the team. You should foster face to face communication within your workplace.The best way to know about the progress and problems of a project is to talk directly to the ones involved with it.

8) It erode trust (or flag mistrust)
Weeknotes can be used to “protect” a person or a team. “If I wrote it, nobody can dispute it or claim not to remember the conversation” scenarios where scope and participants mind’s change so often that one feels they need to constantly preserver words and discussions to shelter themselves. Weeknotes can also be used as a way to “sneak in” complicated topics that people rather not talk face to face, such as project delays.

Weeknotes do not necessarily bring transparency or create an environment of honest, open and direct communication.

9) “Weeknotes is where issues goes to die”Issues should be raised and act upon by talking to the people you need to get them sorted. Issues should be made visible on a wall and constantly chased. Issues should also be dealt over beer, coffee or your preferred beverage of choice.

Coffee can solve problems.

10) They take a stupid amount of time to prepare
Weeknotes can take a week to write! Imagine the collective cost that all weeknotes require to be produced and consumed by an organization!

And finally and more importantly,

11) Working software over comprehensive documentation
Weeknotes deliver nothing but text. They do not contribute towards a product increment. Let your deliverables — or lack of them — speak for itself. I can write you 5 pages about my past week when in practical terms we have made no progress towards a product increment.

Should I be writing weeknotes?

The vast majority of weeknotes can be replaced by the standard agile ways of radiating information, regularly recorded Show & Tells, blog posts, project reports — against goals and KPIs — and regular face to face communication.

To find if you need to write weeknotes follow the simple test I have created:

If you are not writing them, do not start.
If you are writing them, stop.
And wait.
And observe.
And when “they” ask for it, get to the core of the question. Not what is it that “they” want but what is it that “they” (really) need.

Most often than not your audience do not want a 3 pages document. They want to know if you have done what you said you would and if there are issues they should be aware of. Are you on track? Are you late? Should I be worried? Can I help?

Wishes and needs might not go hand in hand

“What is it that you need?” and “What problem are we trying to solve?” are key components of the Weeknotes Test and will help you to go a long way in producing the right material for the right people.

On being human (and vulnerable)

On being human (and vulnerable)

Often my main source of writing inspiration comes from the daily struggles at work. Not this time though. This is about sharing an experience I had a while ago and some important lessons I was reminded and will be carrying with me from now on.

One thing that our Delivery Manager (DM) Community of Practice (COOP) has being encouraging its participants to do is for delivery managers to facilitate each others retrospectives. This allow us to sit down with our team at the same mental level and fully contribute to the session instead of being torn between two hats, the one of a team member and the one of a facilitator.

With that in mind I’ve asked my colleague Andy to give me a hand. Before that I knew Andy from brief chats down the hall, from participating on the COOP meetings and from a Scrum Masters course we did together sometime ago. Let’s put that way, we were not close.

Beforehand we sat down for a quick chat about my perspectives on the current challenges I felt my team was facing and potential activities he could explore on the day. To my surprise, Andy was actually surprised that “someone with my experience” would have a team with the issues I was describing. That really stayed with me and it took me awhile to understand why.

You see, until that conversation Andy saw me from an outside perspective. He saw me for the years that I have being doing what I do, for the courses I have on my profile, and perhaps from the certainty and assureness on which I would help and contribute to our COOP discussions. Through that brief chat, by opening and exposing myself, my challenges and doubts, I unknowingly allowed him to see me for what I really am. No more than just another human being, trying my best to get things right, sometimes fucking it all up, and trying it again and again and again.

In hindsight I can now say that that was the moment we started to have a real meaningful conversation. And connection. The mask is off. Let’s get to the core.

It can be hard to admin but nobody knows it all. Nothing is for sure and unless you admit that you just do not know, there is very little help others can offer you. You are not ready to receive help and others (sometimes) cannot see you need help.

As owners, managers, and fellow employees, one should not fear the brave ones who dare opening up about their own doubts but the ones who seem totally sure of their ways. The ones who are so rooted in their own sureness that such certainties prevents them from seeing others perspectives.

What’s the point of a mind if it cannot be changed?

The main point of a retrospective is to inspect and adapt. Its main premise is that nothing is perfect and we — ourselves and the team — are on a constant journey of self-improvement. As team members and as human beings.

People have different styles. They explain — and understand — things in different ways. They way I explain something may not ring true to everybody. Hence why it is important to be constantly going over the same topics through different approaches and metaphors, learning alternative ways to go about the same things. Observe others doing what we do and learn from their successes and mistakes.

For a very long time I felt what is known as the impostors syndrome, the feeling of being uncovered, the feeling that I was not good enough and all that crap you can google about. Do you want to know how I got over this nonsense?

Pretty simple. The minute I started to be and act like myself. A high energy, passioned, foul mouthed Brazilian dude who cares for people and their work. That moment I realise I could not be uncovered because I was not pretending to be anything else. I am being me. I play myself.

I am open, I am honest, I am transparent. I say “I don’t know” and them I ask others opinions. I fuck up. I apologise. I fix. Repeat.

Between what others see and what I feel I truly am, lies others interpretations and expectations of me and part of my job should be to demystify this. To help them to see me for what I am. To be brave and courageous and inspire others to follow a similar road.

Back in the day, on my first days working at a restaurant, realising how rubbish I was at pretty much everything, from serving wine, to making coffee, my manager always stressed the fact that what they were looking for, was personality. And I had loads of that. “We can teach a monkey to serve food, but we cannot teach someone to be happy, passionate and engaging.”

The same principle applies to office life. There are no software problems, only people problems. Heard that before? No amount of process, and theory can solve lack of communication. One can have all the knowledge in the world but if they are incapable of creating meaningful relationships with their work colleagues, no amount of theory will cut it. People won’t open to you, they will not listen to you. They will run away from you. Physically and mentality.

When sailing through those harsh dark moments of self doubt and anxiety, my advice to you is simple, be honest. Be real. Be human.

“Practice, not perfection.”

The power of Acronyms

The power of Acronyms

“The single biggest problem in communication is the illusion that it has taken place.”

George Bernard Shaw

Sometime ago an old memo from Mr. Elon Musk on the overuse of acronyms on SpaceX made headlines. I don’t know Mr. Musk but I can certainly relate to his pain. I have being working in IT and Government projects long enough to know a thing or two about acronyms.

Consider that we have dozens of Ministerial and Non-ministerial departments, mostly with an acronym associated to them. Add to that agencies, public bodies, the hundreds of different groups, teams, projects, systems, platforms, networks, environments, databases most of which are referred through an acronym, or codename, and you start to have an idea of the kind of cryptic communication one can come across from time to time.

Departments also have their own vocabulary and another list of acronyms and jargons has to be mastered or you might feel people are not really speaking English.

To make things more interesting the same acronym can mean different things and some things are called by different acronyms by different people. It can be hard to know when something has fundamentally changed or it is in fact only a “rebranding”.

Sadly, things don’t get any better in the private — and personal — sector. Who has never come across those long email/Linkedin signatures portraying a long list of meaningless acronyms referring to titles and certifications? VP, PO, PMP, CSP, EA, EMEA, CT, … all for the sake of SEO?! 🙂

So let’s start with my standard question: What problem are we trying to solve?

A software or on a broader scope a “project”, is nothing but the expression of (several) conversations. When those conversations are hard “to get”, you are unlikely to reach a good outcome.

In general people use acronyms as a way to save time. Acronyms can also improve memorability. There are also those who feel insecure at work and think acronyms make them look professional. It gives some kind of credibility, like a dialect for the initiated, “yo G, I’m from the gang”!

For the ones who are not part of the gang, they can distract, confuse, impare, alienate, obliterate, and generally f* up a conversation.

You want to improve quality? Start by improving your conversations.

So here are a few ideas on how to escape the DBA, deal with acronyms and improve communication at your workplace.

Challenge who ever say it

Challenge, ask, confirm what does the acronym mean. Even if you already know. Be sure you are all talking — and understanding — the same thing. This is specially important on meetings where you have people from different areas or levels of expertise.

Challenge who ever hear it

Confirm during your conversations that everybody in the group knows what the acronym that is being used really means. People will often let it slip without asking because they “an understand the context”. My old history teacher always used to say that “if you can’t explain what is it, you don’t know what it is”.

Acronym Free Day

Fun challenges at your workplace to spend a whole day — or week — without using acronyms!

Acronyms Quiz

This is a good idea for team and company events.

Acronym Glossary

Do you really needed? If so, go ahead but make sure people are aware of it, that they use it and maintain.

Are acronyms an issue where you work? How do you deal with it?