When we were all back in the office, sitting at a table, most communication was synchronous. In fact, in my company, each team would have a large table to themselves and we’d all sit together. If you needed to collaborate with someone, you’d just walk up to them and get things done. When we work remotely, this communication pattern breaks down. This may be one of the biggest features of remote work, and also one of its most unrealised benefits. 

The “remote” feature of remote work makes it difficult for you to interrupt a colleague and so you reduce your chances of bringing down their productivity. This becomes an unrealised benefit when we try to slap on our old ways of working in the office when we’re working remotely. 

In today’s post, we’ll dive into the agile sprint - a time-box of approximately two weeks, when development teams work on a set of user stories they’ve prioritised to deliver. We’ll examine two synchronous collaboration practices - story kick-offs and dev-box tests or desk checks and how we can adapt them to a remote-native; async-first way of working.

Some context

This post can quickly get terminology heavy, so let’s take some time to get on the same page. If you’re familiar with agile development, skip ahead. If not, I promise to keep it short. 

User stories and agile development

First, let’s address user stories. Development happens in two-week sprints and we release functionality continuously, so the team gets fast feedback for its work. Besides, we break down large requirements into much smaller user stories. A single interface can generate dozens of stories which teams then analyse, threadbare and deliver in sprints. You can see an example of this in the image above and in this spreadsheet. The reason to use user stories is the simplicity they afford. 

• Stories should usually take just a sprint to deliver. If they get any bigger, teams will split the story.

• Since we write these from the perspective of a user, teams can align on the value each story delivers and can also negotiate the scope that’s essential to deliver that value.

• It’s easier to analyse the requirement when it’s that small.

• You lower the stakes by making each requirement tiny. If you’re wrong, you can’t be very wrong.

The three amigos

Next, let’s discuss roles. While many teams can be quite lean, where you have just a developer and a designer, two other roles are commonplace in large teams.

• Product owner (PO). Amongst other things, they manage the backlog and create user stories for the dev team. On distributed teams, a business analyst may play a product owner proxy.

• Tester. These are engineers who focus on validating that a user story satisfies all acceptance tests, is bug free and doesn’t cause any regression defects in the product. They’re responsible for the quality of the application, so some teams also refer to them as quality assurance analysts or QAs.

Many teams also designate a lead developer, also known as a technical lead (TL). This role provides design oversight and handles the quality of the technical solution. People in this role may coach other developers in a first-amongst-equals capacity. In some organisations, they’re also responsible for code reviews. Between the PO, tech lead and tester, you have representation for the three amigos of agile software development. 

Rituals to build feedback loops

Last, let’s discuss the two practices in question. The idea is to create feedback loops within the sprint.

1. Story kick-offs. Back in the office, these used to be a huddle at a whiteboard so developers could sync-up with the tester and the PO before they began development. The idea was to understand the user story, answer questions if any, and maybe even exchange some implementation ideas.

2. Dev-box testing or desk checks. As the name suggests, these used to be demos of in-development functionality, to the PO and the tester, at a developer’s desk. The idea was to catch obvious defects early, instead of going back and forth between the tester and the developer. 

Phew! That’s a lot of context. Before we move on to the best practice of making these practices more asynchronous, let me throw out a little disclaimer. Our aim is not to boycott or ban meetings. We just want to shift left and meet only when we have to. Disclaimer out of the way, let’s discuss the ideas.

While remote work gives you the theoretical advantage of hiring people from anywhere, it helps to have a reasonable overlap across members of your development team. The best case is for everyone to be in the same time zone. In the worst-case scenario, aim for at least a four-hour overlap. Organisations that choose to separate their testing and development teams should keep this in mind, even if they want people to work asynchronously. There will be the odd time when people need to synchronise, and having any less than four hours of overlap is just impractical. Even when working asynchronously, a lower overlap can cause a long waiting time and developers or testers might end up blocking each other.

This apart, you’ll need to agree to some team norms.

1. Identify your hours for synchronous work. This goes hand-in-hand with the team play of agreeing inviolate hours. POs and testers can make themselves available in those time slots and do deep work during the rest of the time. 

2. On the first day of the sprint, testers and POs can set aside some extra time to respond to questions from developers.

3. Create an instant messaging channel that testers and POs can monitor with greater urgency. Agree on a maximum turnaround time (TAT) for this channel.

Alphabet soup, isn’t it? Let’s demystify that. Yet again, we come back to team norms. As a unit, you need to agree on two criteria for your user stories (as well as other deliverables).

1. Definition of ready (DoR). A story doesn’t come into a sprint before it fulfils the DoR criteria. Teams need to agree on the amount of detail they need in a story before developers pick it up. Sometimes, teams may want to estimate the fully detailed story and compare it with any initial estimates they’d attached to it. This allows them to quantify scope change, if any.

2. Definition of done (DoD). These are a collection of criteria that the team must complete to term a story as “done”. This doesn’t just include business logic or acceptance tests. Depending on the team, the DoD can include logging, monitoring and even documentation.

 Why do we need these agreements, you ask? Well, the DoR allows the team to set a standard for user stories that developers pick up. In an asynchronous setup, you need more detail in the story itself. That’s a good thing, because it leaves less room for ambiguity and it helps everyone in the team understand the requirement. The DoD ensures developers aren’t aiming for a moving target. It gives them a common standard to aim for with every user story.

Sweat the details at the story level

To reduce the need for meetings, your stories need to have all the details developers will need. This is where the three amigos need to collaborate on writing user stories. The PO provides the business logic and the acceptance criteria. The tester specifies the testing approach, the test cases, and the test data. And the tech lead adds implementation notes, if any. If the story addresses a user screen, then it should link to a mockup or a clickable prototype. Your DoR should tell you what’s the necessary level of detail in your stories.

Use collaborative documents to build out user stories so there's room for everyone to add comments inline. You can copy-paste these into Jira or whatever task board you use or attach them to the card if you want to leave the discussion history alive.

Queue up "ready" stories in advance

Asynchronous communication deliberately slows down communication to make it more thoughtful. If you slow down communication, though, you need to give people time to respond. If you’re a product owner, give your dev team a chance to see the stories before the sprint starts. Queue up candidate stories for the next sprint, about a week in advance. Invite devs to look at stories they'd like to sign up for so they can drop questions which the PO, TL or tester can respond to, inline. In fact, this Q&A can enrich a story description and further reduce the need for a story kickoff.

Replace desk checks with recorded video

A good practice with desk-checks is to time-box them to 15 mins otherwise they can end up being exploratory tests on the dev's computer. So there's only so much depth you can go into. While a lot of obvious defects show up in these dev-box tests, you can preempt them with a checklist. Teams can develop their own checklist based on the DoD that developers can then enrich with the acceptance criteria for individual stories. 

Once such a checklist is in place, developers can use it to create a simple recorded demo showing each of the test conditions, and other completion criteria such as logging and monitoring. They can attach it to the card and shout out to the tester and the PO to do an asynchronous dev-box test. A good practice is to create this video while there’s still some minor work to complete for the story. That could include adding unit tests in parts of the codes that you may have touched, or refactoring some of the code you’ve encountered, final touches to your own code and writing up the eventual commit message.  

Even when everyone’s in the same physical space, sometimes no one’s available for a desk check. Instead of waiting to synchronise, recorded video is a good way to "default to action" until the PO and tester are available. TAT agreements can ensure that devs don't have to feel blocked for too long. You’ll find some suggestions for async video tools here.

Meet if you have to

Whether it’s to kickoff the story or for a dev-box, there will be times when you have to meet. For example, if the feedback’s going back and forth, it’s just too slow and impractical to be asynchronous. In such cases, set up a call and sort things out in real time. Just be sure to maintain two important bits of hygiene. First, follow all the best practices for meetings. Second, learn from the experience and write up how you can make this async the next time around. Remember, it’s not about changing everything on day one. Small steps go a long way.

So those are the six ideas I had to help your team reduce the meetings you’d have otherwise needed for story kick-offs and desk-checks. Before I sign off for today, I have one overarching piece of advice. Measure, measure, measure! You won’t know if your process is getting better if you don’t see tangible benefits. Reducing the number of kick-offs and desk checks should have some benefits in the long run. Here are some examples.

• If developers are getting uninterrupted time to work, then is it showing in code quality, unit test coverage, and overall throughput?

• If POs and testers are getting time for deep work, then does that show in reduced defect leakage, and a healthier backlog of work?

• Lesser meetings should make you all feel more satisfied with work. How do you feel about the way you’re working as a team? How has this affected your sense of wellbeing?

It goes without saying that you’ll need to baseline yourself to measure the change. Align your baseline measurements to the conversation you have about the value you’re seeking from shifting left. This last piece of advice is a way to keep yourself honest with the entire program of change. Make no mistake, change will be chaotic to start with and you will experience a productivity dip. As I’ve mentioned earlier, your goal should be to make the period of chaos as short as possible and align the team so you get the payoff you’re looking for.