In the absence of ongoing collaboration, even the most talented distributed software team can slow down. Agile principles and practices show how a regular rhythm can maximize flow.

In forming distributed software development teams, some managers will gather the most skilled professionals across the globe to form the teams, work with them to set up processes to follow, then ensure that work flows into the teams and that value flows out. Good managers also work to remove impediments. All well and good, but can these teams keep up a rhythm?

For instance, on many distributed software teams, team members and managers alike will seek to reduce collaboration time in preference to individual work time. However, without regular collaboration on your distributed software team, your team can slow down even if you have the best developers and testers on the planet. Agile principles and practices show how a regular rhythm can help. Let’s look at a couple of examples…

An Example of How One Broadly Distributed Team Struggled

One out-of-rhythm distributed team consisted of a product manager on the U.S. west coast and developers on the U.S. east coast. The team decided to improve the quality of its software by adding a tester in India.

Since members all worked for the same organization, the team assumed the tester was familiar with the product line. This was not necessarily the case. The tester was dependent on documentation that the developers did not keep up to date. Figure 1 illustrates how a feature typically flowed through the team’s development process:

Figure 1: A U.S./India team struggles with rhythm

The figure tells more of the story. Because there were multiple developers and only one tester (let’s call him Vijay), we observed an immediate delay in Vijay even looking at the new feature by one day since he was wrapping up other testing.

The testing of the feature took longer than the development of the feature (two days) as Vijay lacked subject matter expertise in this particular type of application. For each feature, Vijay had to learn the feature as well as the environment in which the feature operated. Furthermore, the work idled another day until the customer could review the feature. The customer was often busy, so could only devote a couple of hours per day. This sometimes caused the total review to spread out over two days.

Fortunately, in this illustration, the customer discovered no problems with the feature. Otherwise, work may have looped back to Vijay or the developer before the feature could be declared done. So in the best case, this team could produce a feature every seven days.

Where Rhythm can Help

This team decided that it needed to bring Vijay up to speed. It chose to set a rhythm around daily standup meetings and set the time for 9 a.m. Eastern (this translated to 6 a.m. for the product owner and 6:30 p.m. for the tester).

Here’s how team members used their standup: They would quickly walk through status of features in development and test (typically less than 10 minutes) and reserve any questions until the end. Vijay always had questions, and due to his years of experience in quality assurance (QA), he kept his questions to the point to fill his knowledge gaps.

One or two developers (and sometimes the product owner) would stay on the call for an additional 20 minutes for a question-and-answer session. These sessions helped Vijay better understand the features coming out of development, as well as related work. After a few weeks, the team started showing a workflow as shown in Figure 2:

Figure 2: A U.S./India team finds its rhythm with daily standup meetings

As Vijay gained knowledge of the overall system, he could start to anticipate how to set up tests for new features as they became available. The daily standups also provided an “early warning” of features coming soon that allowed Vijay to ask questions about the feature before it was available from the developers. This team learned that keeping a rhythm with their daily standup could reduce the overall feature development time from seven days to 4.5 days (in the best case).

Another Team Finds Its Rhythm

Another team, composed mostly of developers, relied heavily on automated tests and peer review of code. Often, their workflow would look like Figure 3:

Figure 3: A Euro/U.S. distributed agile team struggles with rhythm

While this team felt it was “agile enough” holding daily standup meetings, its workflow told a different story. The features varied in size, and this provided a number of challenges. The developer in central Europe was more familiar with the server side of the product. The developer on the U.S. east coast would take smaller customer-facing features, but sometimes these features would still result in large code changes. Hence, the central European developer had a difficult time reviewing all of the changes and would switch between his larger coding tasks and asking questions of the other developer while reviewing. Reviews often stretched out for two days or more.

By the time the U.S. developer got feedback from the review, he had moved onto another feature and would take an entire day to get back to the first feature reviewed by the other developer. It then took the U.S. developer an additional two days to address the issues, run the automated tests and do a final submission of the code.

This distributed team decided to adopt more agile and lean concepts. It first decided to split its features into smaller features of roughly equal size. This approach was chosen because lean software theory indicates work can flow more easily with consistent and smaller size pieces of work.

This team also decided to make its work more transparent. Members decided to give each other early warning in the standup meeting when they might finish a feature so the other could anticipate a review request.

Third, they each decided to take regular “review breaks” every four to six hours of their work day. This would allow them to focus on the feature they were developing and then spend a shorter amount of time reviewing another developer’s code. Since the features were smaller, the reviews went more quickly and the developers could complete them in one review session. This resulted in the rhythm illustrated in Figure 4:

Figure 4: A Euro/U.S. distributed agile team finds its rhythm

By finding a better rhythm, this team went from producing a feature every seven days to creating new features every three days.

How to Keep Your Beat

The examples above show that distributed teams struggling to deliver features in a timely manner can benefit by assessing their current rhythm and finding actions that will improve their rhythm. In particular, teams can seek to:

  • Organize a fast synchronization across the team every day
  • Provide opportunities to bring everyone up to speed on the features, the system under development and the business context
  • Provide “early warning” when work is about to transition
  • Set a regular daily rhythm to individual work to allow for quick collaboration opportunities

By using these techniques, a distributed team can find a better rhythm to improve its throughput and flow.

A previous version was published on August 7, 2018 by Mark Kilby.