When you started the new year, did your teams come back ready and refreshed, or were they worn down from working long hours? What about the project managers, ScrumMasters or coaches? Did you come back exhausted or refreshed?
One of my first jobs out of college was at a small engineering firm that set ambitious goals that made 60 to 80-hour weeks a common practice for team members. Unfortunately, illness and high turnover also became common as people became tired of running to exhaustion, and the quality of the work suffered greatly.
Sustainable Pace: A Challenge for Both Teams and Leaders
Distributed teams need to keep an eye on sustainable pace even more so than other teams. That’s because the time zone differences can put some team members at risk of working long hours just to stay synchronized with their fellow team members. The same is true for team leaders: They may feel even more compelled to keep track of everyone on a distributed agile team and spend additional time trying to shepherd their results.
The concept of maintaining a sustainable pace can help you and your teams deliver more predictably and be ready to push hard in those rare times an opportunity comes to the organization that needs rapid results (no more than two to three times a year). This is very similar to sports. If you play any type of sport, you quickly learn that you cannot run at 100% capacity all the time because it can lead to exhaustion (or even physical injury). When that occurs, the athlete can no longer compete. Similarly, software team members (or you as a project leader) cannot run at 100% all the time.
Finding Sustainable Pace
What you need to find is the capacity the team can maintain indefinitely. How can you find that sustainable pace of a distributed team? There are several ways to achieve this…
1. Use a task board. First, use agile practices to “train” the team as well as to “execute” the work. For instance, many agile teams use a task board to track the work in progress and signal when certain events occur in their workflow. However, the task board can also be used to determine when collaboration with others may need to occur. One example is when one teammate’s work is blocked and may need the help of another. Another is when one team member may be ready for another team member to review the work. Both are collaboration and knowledge transfer opportunities where team members can exchange information on new technology or other parts of the system under development.
2. Talk with a team member who is bogged down. There is more to consider when someone gets bogged down on a task. Approach this one carefully so the team member does not feel they are being personally evaluated. If you can establish safety for the conversation (perhaps start with a one-to-one meeting), find out what has slowed down their progress. Are they waiting on someone or something? Do they not have sufficient knowledge of the part of the system they are working on? Sometimes, bringing this up in a daily standup for the team member after a one-to-one conversation can lead to a day or two of collaboration with a more knowledgeable team member, resolve the issue and result in knowledge sharing. However, your one-to-one conversation may reveal alternative solutions. So don’t skip this step when one team member struggles.
3. Challenge the team to come up with a solution. What if there is a challenge that impacts most of the team? Look for opportunities to emphasize an agile principle with the team. How might you challenge the team to suggest several agile practices and principles that can help the team solve that specific challenge? For instance, if everyone is working solo and all the work committed to for the iteration is not being completed, you could spend a few minutes at the end of the daily standup asking, “Why do we do the standup?” It is for the team to collaborate on its goals for the iteration. What is blocking that collaboration among team members? Just leave them with that question to ponder how they can better work together. This approach can lead to more productive discussions in the next retrospective.
4. Allow time for individuals to work alone. Also, keep in mind that distributed agile software teams are knowledge workers that need focus time. This may sound obvious, but I’ve seen some ScrumMasters overload the team with meetings to aid collaboration. These are usually meetings the team never asked for. Ask team members, “Why are you in this meeting?” If it’s not clear to most of them, is it time to consider a different way for the team to coordinate?
The amount of focus time can vary by person. A discussion on how certain meetings help or hurt their focus time may be a good topic for the next retrospective, especially when team members and time zones change on your distributed agile team. This could lead to ideas on shifting meeting times, conducting meetings more effectively or replacing meetings with alternative methods to collaborate on iteration goals.
Also, keep in mind that someone new to the team will need more collaboration time to understand the different parts of the system and ramp up quickly. Ask the team how they can spread this collaboration and training time out among team members based on expertise, overlap in time zones and availability in coming iterations.
5. Have team members double up on new learning opportunities. I find that team members perform best when they are working in their area of expertise or are motivated to learn a new technology. When it’s their area of expertise, it may be tempting to let them work solo as they can finish faster. However, this will create a missed opportunity for other team members to learn about this other part of the code base or technology. Use some of these opportunities so that no one person becomes the sole expert for a particular part of the code base or a new technology, and to build relationships within the team. In fact, having two team members work together on a new area can help motivate them and also get them more excited in sharing what they learned with their teammates.
By keeping a balance between the focus work needed by individuals and exchanging knowledge through collaborations, distributed agile teams can better manage when they need to coordinate across time zones (and with which members on the team). By using a shared task board driven by the team, all team members are aware of when collaboration is occurring and may even suggest some future collaboration with different team members as we watch the trends on the task board. These tips can help distributed agile teams find a more sustainable pace over trying to coordinate with everyone across all time zones and all “working hours.”
A previous version was published on ProjectManagement.com March 30, 2017 by Mark Kilby.