Lots of organisations as they grow start to struggle with how to stay aligned while maintaining the autonomy of when they were smaller. What works for one or two squads starts to fall apart at four or five and is straight up untenable above Dunbars number (~120 people).
Here’s a rough way to organise and operate that helps with maintaining momentum as you scale, keeping squads aligned to outcomes and keeps the broader organisation in the loop and engaged. It works by establishing a “heartbeat” of events and touchpoint, represented in the graphic below. Worth repeating: the mission with this is to support and enable the momentum that teams need, which is essential to trust between the Product Development part of the org, and other areas (Operations, Marketing, etc.)
Starting at the smallest loop and working our way out…
Daily Sync + Continuous Delivery
Hopefully don’t need to say too much about this. Neither of these are new and lots of orgs have been doing these things for ages.
This is simply the team coming together each day for 10-15 mins to check in on the various things they have in progress. I have a preference for walking backwards (from Done) through a Kanban board view of the team’s in progress work. Anything they’re stuck on or might need a pairing session, help from outside the team, need a decision on something or anything else? This is where those get surfaced and quickly sorted (hopefully). Much better to go through the items in progress than to go person by person. Not a fan of “What I did yesterday, what I’m going to do today, blockers”. Too much focus on the individual and not enough focus on the work. Kanban is typically how folks refer to this.
This is covered very well by the book of the same name that Jez Humble and Dave Farley published back in the early naughties, when CI/CD was considered batshit crazy. Now it’s accepted wisdom, but still not widely practiced. The DORA metrics are a good way to check yourself and compare with others. If you’re not there yet, make efforts to halve the “Last Mile” from “It works on my machine” through to “It’s working for end users/customers”.
Fortnightly Planning and Demos
Again, none of this should be new. Scrum, XP and various others have slightly different interpretations or rules for these, but the principles behind them are sound. For completeness…
(For the US audience: Fortnightly = Fourteen Nights. Biweekly is confusing, so please don’t use it.) In effect, at least every couple of weeks stop work and put some effort into planning what you think is coming up. So many different ways you can do this, but if you’re not doing something like this at least this often you’re probably dealing with insufficient analysis up front, or analysis that was done too long ago and it’s probably gone off. Don’t break down and plan out more than a fortnight worth of work though. That’ll elongate your fuzzy front end.
Feedback time! This doesn’t have to be on a fortnightly cadence, but you should be doing it at least this often. Gather some end-users, customers, subject matter experts and show them what you’ve developed. And yes, invite feedback. This is their chance to clarify things without writing huge PRD and doing tonnes of detailed analysis. Slow feedback and lack of iteration is a killer in Product Development. I still find plenty of organisations who skip this part, but think they’re faithfully doing “Scrum”. Nope.
Moving on to the next layer of the onion…
This is perhaps not so common, but quite important. The purpose of this is to bring squads together on a regular cadence and celebrate some of the value delivered, whether that be learning, improvements made or other. It’s a huge part of getting a sense of momentum.
Primary focus should be on the Product teams, but this is also an opportunity to get better visibility across the organisation. You’ll want to make it safe and fun for squads, so the mood needs to be light and not polished. Keep the slide ware to a minimum and focus as much as possible on working software/working products and the value delivered, even if that value is learning.
Often, squads are so busy beavering away in their own space, they may not be super aware of the challenges that other squads are working on, or the things they’ve done. This is often a chance to learn some things, share tips and tricks and more than anything it makes everyone feel like less of a cog in a machine in the feature factory, and more like part of a wider tech/product community.
Format that’s worked well is to allow each squad 10-15 mins to walk through a problem they’ve been working on, show the before and after and link it back to the strategic objectives and value delivered. If you’ve got dozens of squads, you’d probably want to do this at the Tribe level, or something around Dunbar’s number.
If you make this the same time and day every month, it’s much easier to plan it out for the whole year in advance. If you don’t get it in the diary and stick to doing it, or push it back regularly, you’re more likely to drop it. So it’s good to be religious about doing it. Try doing the first Wednesday of the month and just book it in. Make sure it’s not the same person in each squad doing it every time, share the love (and burden). Lots of people hate public speaking, so make it as friendly and easy as possible. Treat it as a professional development opportunity for folks to get better at. The more you do it, the easier it gets. Or, in CI/CD parlance, “if it hurts, do it more often”.
Quarterly Look Ahead (QLA)
Planning in the presence of uncertainty is both essential and useless. Or as Winston Churchill put it:
“Plans are of little importance, but planning is essential”.Winston Churchill
I’d tweak that to avoid the paradox:
“Plans are of little importance, but looking ahead is essential”.Me, standing on Winston’s shoulders
Change the wording to make it more clear what’s actually happening. In Product Development, we can make pretty good plans in the short term (fortnightly is good). It’s the longer term where none of us have a crystal ball, and making estimates and predictions and setting deadlines is a fools errand. But the wider organisation still needs to align. There’s no avoiding that tension, you have to put something into that space otherwise you’ll find yourself in top-down planning world that creates all sorts of headaches.
Started expanding on what the QLA looks like, some tips on communication etc, but it’s a big enough topic to warrant it’s own page… Head over there to continue if you’re interested in the what, why and how of QLAs.