How we work and why it matters
Recently, some of our colleagues at the National Lottery Heritage Fund have asked us to explain more about how we work, and why we do things the way we do. We thought we’d share these in a blog post here, as part of our commitment to working openly. Some of the ways we work are a bit skewed towards software development, because that is a big part of what our team does. However, lots of the things we do can be used or adapted in other contexts and for other kinds of work.
Generally, we find that these practices have a far greater impact on our work and wellbeing than the specific tools or software we use to organise ourselves, so there isn’t a lot of discussion of particular tools or software in this post. We choose the tools that fit the team and support our practices — and team principles — with enough flexibility for us to change together as we learn.
Shared principles
When we first formed as a team, we spent some time together to set boundaries and agree on how we were going to work.
There were two activities at the heart of this:
User manual for me — in this activity, we each spent time writing down what we needed in order to be our whole selves and to do our best work. We all read a blog post about this from Cassie Robinson before we started, and had a week to write our own guides using a template the team’s designer made for us. We used Lego Serious Play to share elements of this with each other in a group, and then had some follow up discussion to share other elements, if we felt comfortable doing so.
This activity was about treating each other as humans first, and being aware of our differences as much as our similarities. Our work involves lots of trial and error, and that means making mistakes. It’s a lot easier to try new things that might mean making mistakes knowing that we have the support of our team mates, and a sense of collective safety at work.
Team principles — we also set some principles as a team. These covered how we want to work as a group, but also how we wanted to approach our work and communicate with our users, colleagues, and stakeholders.
We have decided as a team to keep these internal to us, but there are brilliant examples all over the place that are open, including these principles from the Government Digital Service which are available to print for yourself, and these from a team at the Parliamentary Digital Service.
As with lots of these things, the most important thing is having the open and safe conversation as a team about what you would like your shared agreements to be, and finding things that everyone on the team can commit to. As an example, a more prescriptive principle like ‘everyone has a spotless desk all the time’ might be harder to commit to than ‘respect each others’ space when working in the same place’.
We used a format called ‘playing emergence’ from Lego Serious Play . It helped us think through aspects that could threaten the team and our progress, how we would respond, and what would make that the right thing to do. By getting to the heart of what makes it the right thing we reach an underlying principle. In the past, I’ve also used formats like 1–2–4-all to do sessions like this in an inclusive and supportive way, and have had some success with a slightly more in-depth exercise to prepare the whole team for inclusive thinking. It’s worth finding a format that you feel comfortable with and that you think will help everyone contribute and be heard.
At the heart of all of our working practices is a shared belief that it’s worth investing time and effort in finding working practices that suit our team members, context, and purpose. We accept that will involve a bit of trial and error, and we build space for that into our work.
Retrospectives
The best example of this investment in ourselves and our team is Retrospectives. In this context, Retrospectives are a meeting we have as a team where we talk about the things that we’ve done and felt in the past two weeks, and discuss things we’d like to change or try for the next two weeks.
Because we’re a distributed team, we’ve had to adapt some common formats for retrospectives, which often rely on everyone being in the same room at the same time. We tried a tool called Trello, but for now we’ve settled on a shared Google Sheet. We take it in turns to facilitate each retrospective, and the person facilitating chooses a format for the discussion and reflects that in the shared spreadsheet. They circulate a link ahead of time to give everyone time to think and contribute before the meeting if they want to.
There are countless formats for running retrospectives. Sometimes we use the Start, Stop, Continue format. Sometimes it’s about things we’ve Liked, Lacked, Learned, and Longed For. The format is less important than the conversation, but a simple, structured format helps us cover lots of topics and gives everyone space to contribute. In every retrospective, we follow something called the ‘retrospective prime directive’. It’s a short statement that sets the tone for the discussion:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
— Norm Kerth, Project Retrospectives: A Handbook for Team Review
We protect this time quite carefully. It can be easy to get rid of a meeting that doesn’t have any externally visible output when things are busy, but we believe that taking this regular time as a team to talk about our work and explicitly about our wellbeing, helps us work more effectively all the rest of the time. It’s an hour well spent.
We do this on a fortnightly basis because we currently plan our work two weeks at a time. For a while we planned our work on a weekly basis, and then we held our retrospectives every week. They’re part of our rhythm as a team.
Having a rhythm
Retrospectives are one of several regular meetings, or ‘ceremonies’ that help us maintain a rhythm as a team. We also have a fortnightly review or ‘show & tell’, and a fortnightly planning meeting. We have a short call every morning to share what we’ll be working on that day and find ways of collaborating and overcoming obstacles on those things as a team.
Planning our work
We start and finish work together as a team, even if an individual or smaller group within the team have done most of the work together. In practice, that means that we talk about what a piece of work involves and what it’s aiming to achieve in planning, and then we get back together when the work is done to see how the work turned out.
In practice, this means the product manager does some upfront thinking about what we’ve seen in user research about problems we need to solve or needs we should be meeting, and writes some ideas down. These are usually written in a way that sets out what we’re trying to achieve, and why, like ‘design and develop iterated version of ‘run your project’ page so that it’s clearer to users which steps they need to take immediately, and which are ongoing or later steps’.
During the planning meeting, the team will discuss these ideas to make sure we all have a shared understanding of what we’re trying to achieve and why it’s important. This is a chance for the team to challenge priorities and suggest alternatives. We also try to think about potential obstacles, and make a plan for clearing those as part of the work. We capture all of this in our trello board, which helps us all keep up to speed during the week when we are spread around locations.
We discuss our capacity and who has the skills needed to do a particular piece of work, and make sure we think about the effort or complexity for a piece of work. We agree as a team which pieces of work we can commit to in the next fortnight. We try to be ambitious, but realistic. It doesn’t help anyone if we drastically overestimate our capacity.
Reviewing and showing our work
This is an opportunity for the whole team to see how an individual or sub-team approached a given problem or task that we discussed in our planning session. We’ll ask questions about their approach, and satisfy ourselves as a group that we achieved what we set out to. We use this meeting in place of any formal sign off. We’ve already agreed in our planning meeting what the goal of the work is, so this review allows us to validate that we’ve met the goal, or agree a plan for further iterating, testing or validating it, before we can consider the work done.
We run these meetings just before our regular planning sessions, so that we can pull any iterations or further testing into our plan for the next two weeks.
These are a great way for us to share in each others’ learning and achievements, as well as to share different approaches and perspectives that we can then apply to our own work. They also mean that everyone on the team has the autonomy to apply their experience and skills to a particular problem — as long as the desired outcome is achieved, the method used to get there is up to individuals.
We’ve recently opened these up to others in our organisation by sharing videos of us showing our recent work and posting these on internal communication channels. We’ve had a really fantastic response with lots of questions and feedback that are helping us work even more effectively, and get to know our colleagues and their roles.
One of the biggest aspects of the way we work is that we’re always inspecting and adapting. We’re regularly reflecting on how well our working practices are supporting and enabling us to do the best job we can, and trying new practices if they aren’t.
This creates an environment where it feels safe for anyone in the team to let the others know if a certain tool or practice is making their job harder than it could be, and means that we’re always open to new ways of doing things. It builds trust within the team generally, as much as it builds trust in the practices and tools we use.
