A commitment to asynchronous agile is also about a commitment to thoughtfulness. That thoughtfulness is a marked contrast to the constantly distracted, hyper-active environment of the open office. Over the last several articles on this site, we’ve examined many agile practices through the lens of modern, remote-native delivery. You may have noticed that we’re eschewing collaboration for collaboration’s sake. Sometimes we give a free pass to any activity that seems collaborative. Before you know it, you’ve built half a dozen gate checks to deliver a single user story. Each of those “collaborative” gate-checks doesn’t just create interruptions and context switches. It also leaves an attention residue - your mind continues to think about the interruption even when you’ve switched to the task on hand. There is such a thing as a collaboration curse, as the Economist described some years back.

Slapping Zoom and Slack over in-office collaboration techniques is one of the most common anti-patterns I’ve observed in the last two years. For one, we know that the open office was no paragon of productivity. The moment you blindly mimic office patterns on Zoom, you’ll generate inefficiency at speed! In today’s post, I want to use the asynchronous agile lens to examine a common interaction pattern amongst dev teams. That pattern is the “huddle”. 

Before I dive into how I think about the pattern, let me explain the two variations I’ve seen. 

1. The ad hoc huddle. Teams use these to solve day-to-day technical problems. The expectation is that you shouldn’t need to look up calendars and you can just pull a bunch of people into a conversation and thrash the problem out. 

2. The scheduled huddle. In this pattern, the dev team builds up a list of topics over a week and meets at a predictable frequency to thrash these out.

While I think we have to reimagine both these patterns, let me tell you up front that I’m more tolerant of the second one. I’ll explain that soon. On that note, let’s dive into how you can get better value from variations of these patterns on your distributed agile teams. I want to explore this topic through a series of questions. 

Do you have enough autonomy on your teams?

“Requests for time-sapping reviews and approvals can be reduced in many risk-averse cultures by encouraging people to take courageous action on decisions they should be making themselves, rather than constantly checking with leaders or stakeholders.” - Rob Cross, Reb Rebele, and Adam Grant, Harvard Business Review

User stories are such an outstanding way to specify requirements because they lower the stakes. Each requirement is so small that even if you go wrong, you can’t be very wrong. Teams tend to overcomplicate their development process for this simple unit and make it more heavyweight than it needs to be. Before you know it, there’s a debate at the sprint planning meeting, a kick-off, a bunch of huddles, a tech-check, a desk-check and whatnot to just get one user story out of the door. Sure you need feedback and collaboration, but you should study if all this collaboration really creates all the value that it promises. Or do you have all of this ceremony because your team has just become risk averse?

The teams I’ve seen being really effective in a distributed setup devolve responsibility to smaller units where possible. If everyone’s asking everyone before taking every single decision, this creates noise in the system. This is model A in the above diagram. A better model; model B above; is to create smaller decentralised pods inside the team. These pods can be as small as two people and no larger than four people. Here are some characteristics of effective pods.

• Align the pods to an outcome. It could be to deliver a feature or an epic. 

• Nominate a directly responsible individual (DRI) for each outcome. This person is a “first amongst equals” (FaE) and can help take tough calls for the pod in case it comes to that.

• Pods operate autonomously and the larger team encourages each pod to make their own decisions with help from their DRIs. 

• To encourage knowledge sharing and to bust silos, keep the pods short-lived. When you achieve the outcome, disband the pod. Any longer than a month and you should question the existence of the pod.

• Apart from the DRI, you can rotate people across pods even before delivering the outcome, if that’s something you want to do. While more people will be able to engage with the corresponding part of the codebase, you may lose the benefits from expertise and continuity.

• Radiate information across the team so everyone’s up to speed with what’s happening on each pod and so you don’t create walled gardens of information.

So now if you really need help, you have a smaller, more focussed group of people to reach out to. The result - lesser noise and fewer interruptions in the system.

Do you really, really need to “sync up”?

In a previous article, we discussed how “quick syncs” may be in the flow for you, but can disrupt the people you interrupt. Your need to solve the issue on hand is important, but spare a thought for your colleagues who also need uninterrupted time to do their work. A little empathy goes a long way. Your proposed huddle is a quick sync that could instead be async. 

Meaningful problem-solving discussions benefit from writing things up. Consider a sketch or a video to explain things in more detail. There’s an expression in Latin - festina lente. It means “make haste slowly”. I know we optimise for speed in software development. Deep work is often the casualty in this quest for speed. Slowing things down through writing has several benefits.

• The act of writing helps get other people on the same page quickly. If you’re looking for help, it helps you set context and explain where you’re stuck.

• The artefact you produce can also speed up problem-solving. Instead of spending a long time understanding the problem, someone who’s trying to help can get straight to their inputs.

• The chain of written communication can become a decision record for others to refer to at a later point in time.

• Often, writing and sketching things out can clarify your own thinking and help you get to a solution without help!

Cliff Berg, author of Agile 2, summarises this brilliantly.

“Unless you want people to stay at a surface level in their thinking, mostly able to execute simple tasks but largely unable to go deep and conquer hard problems, then it is essential to set things up so that they can focus without distraction.”

As I’ve mentioned earlier, writing is your super-power to go deep and conquer those hard problems.

Have you considered defaulting to action?

Several weeks back, we discussed the idea of defaulting to action. Working independently is a superpower you need to recruit for and encourage amongst your colleagues. If you’ve built a team of high ability individuals, then everyone needs the confidence to give the problem at hand the hardest crack they can. When some information or input is unavailable, the culture of the team should be to the best they can and backtrack or refactor if necessary. Amazon codifies this in their company principles as “bias to action”. 

Moreover, if your team’s pairing, then you already have two heads at the problem. That’s risk mitigation right there! If you’re not pairing, you probably have a code review process to mitigate design and implementation risks. It’s ok - you may not need that huddle after all. Use “defaulting to action” as a way for team members to think deeply about their work and to build a culture of entrepreneurship and calculated risk taking.

If you have to huddle, how do you make the meeting effective?

Remember, meetings are the last resort, not the first option. So everything we know for a good meeting should still apply if we have to meet. Right? I’m glad we’re agreed! Here’s what I suggest, so we make these meetings productive.

1. Don’t start any such meeting without a written artefact everyone’s looked at. The least prepared person often derails the meeting and it just wastes everyone’s time. 

2. Huddles should be tiny meetings with a tiny group of participants. Remember that these were supposed to be quick, standing meetings at a whiteboard. Over 30 minutes and a group larger than four participants, and you’re probably doing this wrong.

3. The decision to huddle and not go async or default to action means this was complex and high stakes. You’ve got to document the meeting and the decision for everyone’s benefit. No excuses.

The frequency of these last resort huddles should give you a sign of how you’re doing when building an async-first development culture. Too many huddles may mean that you’re not defining stories and implementation decisions clearly or that you haven’t built a culture of autonomy in the team. Something needs fixing.

So that was all about the great ad hoc huddle on agile teams. As I mentioned at the start, I don’t mind the scheduled huddle as much. The way teams often do this is by first creating a backlog of topics they want to discuss. You then pick a day of the week to meet up and you discuss items from the top of the backlog and get done with them. Remember that this can’t be for stuff that’s crucial to the project. It’s a top level triage of things to discuss. Examples could be a possible new library to try out; or a new static analysis tool to integrate into your pipeline; or how you plan to do an accessibility audit for your product. Whatever grabs the team’s fancy! Once you decide on doing something, it should go onto your backlog. From then on you track it; business as usual. 

The value of doing these scheduled huddles isn’t so much that the meeting itself is the most efficient. Think of it more as a social gathering for technologists to talk about things that fascinate us. In our guidelines for async-agile, we talked about being human. Having these fun sync-ups can help your team feel connected even when most of your work becomes asynchronous.