This is an attempt to write down the approach we are starting to formalise around our ‘squads’ — it is a work in progress but is starting to make sense. It is inspired by working practices I witnessed or experienced at Defra, mySociety, ONS and elsewhere →
We work in the open by default — if something needs to be dealt with in private we deal with that be exception.
What open looks like for us:
A new squad gets a new repository on the Notbinary Github.
This repository is used for:
- Online Kanban board (Github Projects)
- Issues are used for tracking ongoing tasks
- All code and prototypes
- Github Pages site to document outcomes and decisions
- Weeknotes should be published at the end of each week summarising activity and link circulated to the team and client(s)
At the end of an engagement we want to be able to provide a single Github repo that represents everything we did with a Github Pages site that provides all the relevant context — the expectation isn’t that the code is reusable in the open source sense but that all our learning is available and we show our workings (through the code!). Also our ambition is that when we do Service Assessments or similar we don’t need a slidedeck — we just step through the repo using the Github Pages site as the guide (as such we have created a GOV.UKesque Pages template — as well as an upcoming Notbinary one.)
We are agile not Agile™. We do daily updates via Slack rather than traditional stand-ups, we do regular retrospectives (using FunRetro and Slack calls), for Alphas we work with a loosely one week sprint cadence but a Kanban-esque backlog. We are #noestimates during Alpha.
For Beta we take a more rigorous approach but still relatively lightweight by default. Two week sprints are more likely. Some high level estimating is likely to creep in. We will also be much more driven by TDD and as such the ‘stories’ will be much more precisely articulated that during Alpha.
In both cases we maintain public roadmaps as well.
Each squad has a private channel on the Notbinary Slack.
Slack is the default team communication channel.
This channel includes
- A user-group so all members can be contacted at once
- Invited members from the client-side (one channel guests in Slack parlance)
- ‘The Standup Alice’ chatbot to handle daily updates via Slack
When email communication is required with the client(s) the team email should be BCC’d in to all communications to ensure nothing is lost in team members inboxes if they are unavailable (the archive can be searched via Notbinary’s Google Groups account).
We have ’Show and Tells’ per sprint. These are facilitated by the Delivery Lead. They should also act as the primary stakeholder meeting for broader conversations.
Otherwise seek to minimise large group meetings. Where possible one-to-one or small target conversations with subject matter experts are our preference.
We firmly believe in what David Kelly of IDEO said;
“A prototype is worth a thousand meetings.”
The goal of our squads is software not slideware.