Didn’t write any weeknotes last week because I went to Paris over the weekend. Almost decided not to write any this week because I’m tired. It’s sure is December, huh?
I’ve not been tracking my tasks like usual because it’s been a chore, if I’m honest. This means I’ve done way more than what I’ll write about below. But here’s the half-remembered highlights.
- Introduced our new director to the GOV.UK Design System: the why, how and where it makes an impact (a lot of places)
- Convened a meeting of designers and developers in GDS looking at establishing principles for app design (which I’m calling an assembly, ‘working group’ is 🤢)
- Took my fellow team leads through the strategic objectives for the year ahead, so that we could come up with next steps together
- Collaborated on a new product model with the team leads, throwing out two-week sprints for longer cycles
- Built and agreed a team leads charter
- Joined the release party for GOV.UK Frontend v5.0.0
- Wrote up our experience of bringing in a coach to help with capability development
- Reviewed our accessibility strategy to see what we’d achieved and what we’d need to do in the new year
- Reviewed and updated our accessibility statement, now that v5.0.0 is out
- Did other bitty things in the background while the team had a firebreak
Cycles, not sprints
Traditional two-week sprints and Scrum provide good training wheels for teams who are new to agile, but I don’t think they work for well established or high performing teams.
For research and development work (like discovery and alpha), you need a little bit longer to get your head into a domain and have time to play around making scrappy prototypes. For build work, a two-week sprint isn’t really two weeks. With all the ceremonies required for co-ordination and sharing information – which is a lot more labour-intensive in remote-first settings – you lose a couple of days with two-week sprints.
Sprint goals suck too. It’s far too easy to push it along and limp from fortnight to fortnight, never really considering whether you should stop the workstream. It’s better to think about your appetite for doing something, and then to focus on getting valuable iterations out there rather than committing to a whole thing.
I’m not describing this in detail because the team will likely write about it after a few months of trying out the new model, and it’s very specific to this team and its context. However, there’s a few principles that are essential:
- Fixed time, variable scope
- Think in iterations: vertical not horizontal slices
- Each cycle ends with something shippable or showable
- R&D cycles end on decisions around scope
- Each cycle starts with a brief, but the team can deliver it how they like
I’m pretty confident in these principles. It worked at GOV.UK Pay and the startup. Key enabling conditions are experienced people who are empowered and passionate about the mission, but I’m lucky to have worked on teams made up of people like that.
Firebreaks for team culture
Traditionally, a firebreak is an opportunity to have some self-directed time to improve your product or service any way you want. I always really enjoyed them, it’s a chance to flex the creative muscles and scratch an itch.
The only problem is that you’re still working on your product or service, and you do that all the time anyway. I’m a big believer in putting time and effort into team culture, feeding the vibes: it’s the work that makes the work work. I’m also starting to create more opportunities for teams to play together, because it recharges the batteries and builds trust.
So I thought, hey, what if we spend a week playing around on team culture bits?
The culture problem staring me in the face was ‘hybrid-working’. Hybrid-working is bullshit, if you ask me. It’s this sitting-on-the-fence middle ground where you don’t have to declare any opinions about how people should work or how to optimise the conditions for good work to happen. Instead, you should call yourself remote-first, define when in-office collaboration is necessary, and optimise everything else to factor in geographic distribution and asynchronous communication. (I’ve written about free-range working before but should write something else.)
Anyway, one symptom of hybrid-working and not optimising conditions is that you haven’t tuned your team culture around this. In the Before Times, we lived and breathed team culture through ambient media and shared spaces. We’d put posters up on the wall. We’d huddle around a TV during standup. We’d stick things on our desks, and we’d scribble on whiteboards as part of our work.
But that all happens inside tools now. Those tools look different for each person on the team, and there’s no personalisation. The sense of team unity and having a shared space becomes fractured.
So several weeks ago I asked the team what we might do to rekindle that sense of unity in a way that embraces
hybrid remote-first working. They came up with tons of ideas which all looked grand.
Off the back of those, I wrote a brief for the firebreak: ‘Create a warm, informative and engaging onboarding experience for new team members.’ I planned a basic firebreak around that which allows people to remix and combine ideas, then split off into teams to work on their projects. And instead of ‘firebreak’ we’ve been calling it ‘creative jam week’ – jam together and have fun!
On Thursday we had a show & tell and the team came up with some blindingly good answers to the brief.
- Team avatars that go beyond Manual of Me, emphasising the person over the work persona
- A timeline of the design system, why it exists and how we got here (with scope for design history and weeknotes)
- A box of stickers, posters, pamphlets and handwritten notes to welcome new joiners and make them feel a part of the crew
The beauty of what they came up with is that it combines elements of virtual realities, tangible things, shared identities, plus synchronous and asynchronous timelines.
Not only will the team be able to welcome new joiners and make them feel at home, they’ve also created some stuff that brings them all closer together.
Feed the vibes. Let people jam together.
This has fallen off a cliff. Likely because I don’t have a goal and, to be honest, I’m just tired. I’ll work out a light schedule that’ll maintain fitness for the half-marathon in February, but I need a summer goal to build up to. I’ll make a plan for running between the bothies in Eryri.
We didn’t have a bad meal in Paris – except a cold hot dog at La Defense Arena watching Harlequins beat Racing 92 – so here’s all the places we went that you should try too.
- Café Les Deux Gares, 2 Rue des Deux Gares
- Le Cadoret, 1 Rue Pradier
- Bouche, 85 Rue Jean-Pierre Timbaud
- Willi’s Wine Bar, 13 Rue des Petits Champs
- The AI trust crisis, 7 mins
- As God is my witness, gluttony is not a sin, 9 mins
- Does the Enlightenment still matter?, 8 mins
- Hackers (1995), 15 mins
- A day in the life with Mark Williamson, 3 mins
- How an English upstart changed Parisian wine bars ‘for ever’, 4 mins
- Hold it lightly, 3 mins
- The economics of chicken-shop Britain, 9 mins
- Service delivery is broken – it’s time to join it up, 6 mins
- What Kwasi Kwarteng knows now, 3 mins
- Alternatives To Product Leaders, 6 mins
- An example of ‘good’ UX not being good enough, 4 mins
- Loss, 2 mins
- Weeknote zero, day one, 2 mins
- You Must Fuck Around and Find Out, 2 mins
- Opinion A Trump dictatorship is increasingly inevitable. We should stop pretending., 28 mins
- Making an image with generative AI uses as much energy as charging your phone, 5 mins
- iA Writer 7, 6 mins
- Sam Altman explains being fired and rehired by OpenAI, 7 mins
- Alternatives To Product Managers, 7 mins
- The role user-centred design (UCD) should play in AI development, 6 mins
- Thoughts on harmful design, 2 mins
- Test often to keep your designs simple, 3 mins
Got comments? Contact me, let’s talk.
Wrapping up my time on the GOV.UK Design System.
Slack is annoying, wine is nice, the product community rules.
Highlight of the week was getting big strategy thoughts out of my head and on a whiteboard. But did some thinking about asynchronous communication and ‘AI patterns’ too.