FROM THE ARCHIVES OF PRAGPUB MAGAZINE AUGUST 2019
Geographically Distributed Agile Teams, Part IV: Equal Access
By Johanna Rothman and Mark Kilby
In this fourth article in their series, Mark and Johanna address the importance and the challenge of giving equal access to tools across your distributed team.
This is the fourth of a series of articles on how to provide a successful environment for your distributed agile teams.
Does everyone on your team have equal access to all the team’s tools? By equal access, we mean licenses, permissions, and training. We’ve seen too many teams — especially distributed teams — where not everyone has equal access to all the tools.
That unequal access doesn’t just challenge collaboration — it makes collaboration impossible.
Even if your team is collocated, if only some people can kick off the build or kick off tests or reserve meeting space, your team’s collaboration is at substantial risk. For distributed teams, it’s a disaster.
Why are we so focused on equal access for collaboration? Because agile approaches demand a collaborative team, and if unequal access to tools prevents people from collaborating, it subverts the agile approach.
Licensed to Collaborate?
Like James Bond with his license to kill, agile team members each require tool licenses to collaborate and deliver value. Lacking the licenses, you have a problem.
We see this license problem most often with far-removed team members. And we also see this problem when team members start to work out of their homes, even if they are not far-removed.
Back in Article 1, Distributed Team Workspaces Start with Hours of Overlap, we explained how one team, all based in the Eastern U.S. time zone, had to shift some of their working hours to succeed as a team.
That team had started as a collocated team and only moved to a distributed team after one team member moved to New Hampshire, and the organization hired a replacement in Indiana. Back when the team was collocated, management had only bought floating licenses for some of the tools. Management was concerned that the team spent “too much” money on tools. Management wanted people to share access to the tools.
Management had calculated the cost of sharing licenses with concurrent licenses. Across all the tools, the difference per person for the team was $2,000 per year versus $7,000 per year. Management realized that with 20 teams, the difference in cost was $40,000 versus $140,000.
When the team was collocated, they had a few instances of people forgetting to relinquish their license, but when they could yell across the room, it wasn’t so bad. Now that they were distributed, the license problem became obvious but not as easily solved. Yelling across time zones was no longer an option.
One day, one tester used the only floating license for the test automation tool. While using it, he was called away because his child had fallen on the playground and appeared to have a broken bone. Understandably in the circumstances, he forgot to relinquish anything on his machine: he just left immediately.
Hours later, when other people wanted to use the test automation tool, they couldn’t. While he had texted the team to tell them why he was out — and everyone wished his family the best — the team was stuck. They could not continue with the tests until the tester physically returned to his machine.
You might wonder why the admin didn’t reset the license. Good question. The answer is, in this situation, the tester was the admin.
For lack of a concurrent license, the entire team came to a stop for several hours that day. The tester felt terrible, but he was not the source of the problem.
The concurrent license cost for this specific tool was an additional $2,000 per year. When management decided to save $2,000 a year on licenses for this team, they incurred the cost of seven people for six hours that day. Assuming a loaded labor cost of only $75/hour, the team cost for not being able to work was 7 (people) * $75 (per hour) * 6 (hours) = $3,150.
The team would have recouped the additional cost for just this particular tool on that one day. Because of the cost to the team, the team would have recouped the entire cost of all the tools if they had just one more problem like this over the course of the year.
Too many managers don’t see the value of the tools to the team, just the cost of the individual licenses. When team members have equal access to all the tools, they have the ability not only to work as a team, but to support each other in the team.
Lesson: Team members need a license to collaborate.
Once people have licenses to collaborate, they need access to collaborate. That is, they need permission.
Permission to Collaborate?
Once every person on the team has a license, it matters how the people can use the tools: the roles for the tools. Many of the tools we use on a regular basis require various permission levels. Many people can use the tools, but only certain people can create, start, or stop the processes.
For example, many distributed teams use meeting tools. Does everyone on the team have the ability to start and stop a meeting? How about recording a meeting? If only one person has administrative privileges, that one person creates a bottleneck for the team. Mark encountered this recently in a meeting rotated between his fellow coaches. He forgot to switch to his account with the other coach’s account and could not record the meeting. This left out participants whose available hours did not overlap with the meeting.
Review the tools your team uses every day. Which tools require “extra” permissions? While we are not fond of branching in version control, can anyone on the team create a branch? Can anyone on the team start and record a meeting? Can anyone on the team run the build and any other necessary tests?
Lesson: Team members need appropriate permission to collaborate.
Understand How to Collaborate?
Does everyone on your team understand why the team has these tools? Does everyone understand how to use them?
In one recent meeting, Mark rotated facilitation of the meeting with two other coaches. He forgot to change the meeting link to his account. The meeting was set to start without the host, but it meant that Mark could not record the meeting. Since this was a demo of what many teams had done for a hackathon, the coaches expected that many people would watch the video later.
One team member realized the importance of the recording and was able to capture video and audio from the meeting using open source video streaming software. The video helped spread the knowledge across the organization — exactly what the coaches had expected and planned.
In this case, team members understood the importance of demonstrating their solutions and having their software ready. Other team members realized the importance of recording the meeting so that sales engineers and support engineers who may not be available for the live meeting could view the recording later.
Everyone understood how and why to use the tools at hand.
In your teams, do you provide different ways to learn about the tools available for development and collaboration?
In some cases, this could be more formal training. If the software is sufficiently complex, it may require several team members to attend a course. In other instances, it could be allowing one team member to dive deep into a new tool and provide training or “how-to” guides for their fellow teammates.
If you choose to create guides, we suggest you encourage all team members to update the guides as they learn more about the tool. That helps the entire team share their knowledge as fast as possible, and helps the team to maximize their use of the tool.
Finally, one of the most efficient ways to learn new tools is through pairing or mobbing. In these situations, the keyboard passes from team member to team member on a regular basis. In a distributed team, you might have to literally say something like, “I’m passing the keyboard.” When someone new to the tool gets keyboard control, other team members can guide them on how to accomplish the task.
The key is to allow time for learning regardless of the form the learning takes. We find it’s best to have the team determine how they best learn. As a leader, it’s your responsibility to make sure time for learning occurs and that each team member shares their learning.
Lesson: Team members need to know how to collaborate.
Equal Access for the Entire Team
Even when time and space separate team members, ensuring that each team member has equal access to all the team’s tools will save you time, aggravation, and money on the team. Equal access makes collaboration possible. It includes licenses to collaborate through the tools, permissions to use the tools, and an understanding of how and why to use the tools.
And that’s one way your distributed agile team can succeed.
