When I started this series about team brittleness and resilience, I expected to discuss winter weather in the Boston area. Every year, we expect several large snowstorms. And, when it snows hard and long, we should stay off the roads so the plows can clear the snow.
Everyone has weather of some sort that threatens our ability to work. Maybe you don’t have snow, hurricanes, or tornados. Maybe someone cut a necessary wire and your headquarters no longer has internet access or power.
Now, as I write this series, the coronavirus is winging its way around the globe. Companies are now thinking about what it takes to work from home.
This is one of the reasons Mark and I wrote From Chaos to Successful Distributed Agile Teams. Your team might not need an agile approach. However, almost every team needs a team workspace that allows the team to collaborate at distance.
When your team can collaborate “anywhere,” the team builds resilience. Even if just for weather, team members cannot always participate as a collocated team.
Teams who have a virtual team workspace can work “anywhere.” They are resilient for location.
What Tools Does Your Team Need in its Workspace?
Mark and I listed these tools for the team’s workspace in the book:
- The code repository.
- The test repository.
- The defect repository. That repository might differ from the backlog.
- The place to store backlog items for near term work on feature sets.
- The place to see the roadmaps for the longer term.
- The team’s project workspace so the team can put project documents in one specific place.
- The place to gather team data. This includes the team’s board and the team’s metrics.
- The place to report project status.
We didn’t specifically talk about how to collaborate when writing stories, code, or tests. We didn’t list the various communication tools here.
(Update: I should have mentioned cameras and microphones. Every person on a team needs a reasonable camera and a reasonable headset/microphone.)
Note: We also didn’t discuss bandwidth for internet access. Every team member needs high bandwidth access. If you want people to work remotely for weather or health event, they need high bandwidth access in their homes.
If you start with these tools, you’ll then see the other tools you need.
When Mark and I talk about boards, we often suggest a distributed team start with a paper board. That’s so they can learn what their flow is. There’s no point using a “standard” board if your team doesn’t follow that flow.
If your team is new to virtual work, consider creating a new board where you can create columns without committing to a specific board or tool yet. Your virtual flow might differ from your collocated flow.
Who Has Licenses?
In the early 2000s and into the teens, I led many workshops for distributed teams. In every case (yes, through about 20+ workshops), the people in my workshops reported that not everyone had licenses for all the necessary tools.
I wrote Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams with Shane Hastie back in 2013. At that time, we still saw managers try to save money with licenses. Even now, I hear the horror stories.
I understand managers’ desires to manage expenses. I manage my corporate expenses, too.
How do you know if the licenses are worth it? Measure the cycle time. How long does it take the team to finish (really finish) a given feature? Where do they have delays?
I bet you’ve seen this, too: In one organization the managers asked the team to share licenses for the defect tracking system. The developers were in New York, the testers in Vietnam. (Insufficient hours of overlap to collaborate, but the managers thought they could save money.)
One week, the developers forgot to release their licenses when they left for the day. Another week, the testers forgot to release their licenses.
And, when the developers and testers were all willing to get on a call, they didn’t have enough licenses to see the same data in the tool. And, because the internet access was iffy in New York (a big telco had trouble), and the New York people had all the licenses for the meeting tool, the Vietnam people couldn’t restart the meeting from their end.
The managers had assumed New York would have all the necessary infrastructure. That wasn’t true that day. And, the managers thought the “team” could share licenses. Short-term, misguided thinking.
Worse, they thought people could work anytime.
Should People Work Anytime?
Too many managers think people should work when the organization needs them to work. Mark calls this being “voluntold” when to work.
I like reasonable hours that a team chooses. Sure, the team might need to have hours of overlap with other people, too.
(A note about hours: I have not seen people be able to work more than about eight hours a day on a regular basis. When my clients measure cycle time, they realize the organization wastes at least a quarter of everyone’s day. Sometimes, up to half the day. If your team can collaborate together and work together, people might be done after 5-6 hours. That’s fine. They put in a full day of work. See Management Myth #10: I Can Measure the Work by the Time People Spend at Work.)
If you haven’t read Mark’s and my Distributed Team Workspaces Start with Hours of Overlap article, please do.
And, in the book, we tell the story of a project manager who was supposed to be on the phone with a far-off team at 3 am, in the office at 9 am and keep 8 pm available for another call with a far-flung team.
Can You Optimize for Resilience?
When we optimize for resilience, we consider risk management for our ability to work.
If people have a weather event such as snow, they need time to shovel. If they expect a health event, they need time to stay or get healthy.
And, if their children are home from school, the adults are not as available as they might like to be. If the team decides when “anytime” is, the adults might be able to find a reasonable approach to their childcare responsibilities and their work responsibilities.
The more the team collaborates as a team (part 1), and the more they normally shorten their feedback loops (part 2), and the more the team can work when they are virtual (this part), the more resilient they can be.
The series (I’ll add links as I publish):
- Build Team Resilience: Work Together (Part 1)
- Build Team Resilience: Shorten Feedback Loops (Part 2)
- Build Team Resilience: Work “Anywhere” and “Anytime” (Part 3)
- Build Team Resilience Summary (Part 4)
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Build Team Resilience: Work “Anywhere” and “Anytime” (Part 3)
Opinions expressed by Java Code Geeks contributors are their own.