Key Takeaways
- As an agile coach supporting distributed teams, you learn to be in several spaces simultaneously to "listen to your teams," but signal where your focus lies and when you are available for open collaboration to more broadly support the organization.
- Four key activities help you navigate change in your distributed organization: be clear on your vision, manage and model for change, amplify communication and collaboration, and focus on principles over practices.
- Change navigation becomes a critical skill in a distributed agile organization as the internal collaboration environment can change as quickly as the market.
- Question troublesome practices to learn the underlying principles and experiment toward better practices.
- Exemplifying change navigation can help others feel more comfortable with change and experimentation.
Introduction
Many agile coaches describe themselves as change agents. I prefer to think of myself as a change navigator. Sometimes I select a path for change, but sometimes circumstances put me (and my organization) on a path of difficult changes. Either way, change becomes our work as agile coaches and leaders. So we must always be prepared to navigate our way through it. Experimentation becomes the primary tool to aid our change navigation. With that need, it becomes important for a leader to model and teach how we handle uncertainty, navigate change daily, and provide new solutions in our organizations.
When your teams and organizations are distributed, the importance of experimentation amplifies. As online collaboration technologies improve and we begin to understand how flexibility and choice become critical in distributed work, modeling and teaching experimentation is important not just for agile coaches, but all leaders in a distributed organization.
Coaching day-to-day while working with distributed agile teams
Currently, I work as an internal agile coach for an organization called Sonatype, which is almost completely distributed. While we have some administrative and finance staff in a main office, everyone in engineering works from their homes. This includes directors, product managers, engineering managers and coaches. That represents a major shift in the work environment for most people even five to seven years ago. It’s becoming more common now.
What’s different in a distributed environment is you can be in a few of these spaces at the same time. You will always be in your physical home office which you can adjust to your comfort so it supports you throughout the day. Then you can also be in a virtual team space (or more than one), in an online meeting with product managers, and be contacted by an executive. What’s different is that people in the other workspaces may not be aware that you are in multiple spaces.
So you experiment and model how to signal where your focus lies: it could be in collaboration, or deep thought on some new workshop or white paper, or it may be in a 1-1 coaching conversation.
Also, you experiment, model and teach how to make the work visible to each other. How do you signal that you need to focus, or you would like to pair work, or possibly mob on a problem? First, indicate your collaboration and focus times on your calendar and communication channels and let people know how you do this. I’ll keep my "status" updated in my chat tool and mark "focus time" in my calendar. Collaboration time shows through available time on my calendar and a clear status in chats. You can further make this clear by explaining how you indicate these times in a personal communications page on your company’s internal website.
Second, change your behaviors in focus time versus collaboration time. When I’m in focus time, I do not respond to emails or chat messages. Of course, there may be exceptions, but when you respond to messages all the time, are you truly focused? When I’m open to collaboration, I’ll respond immediately. Sometimes quick responses suffice. Sometimes someone just needs to just talk through a difficult situation 1-1. What if I’m focused on a conversation while collaborating? That’s focus time too. Don’t let distractions divert your attention while working with others unless it aids the collaboration.
How do you signal when work completes and can be shared out to other parts of the organization to stakeholders and others interested in the work? Signal that by writing up (or video recording) a summary on your company’s internal website and pointing stakeholders to the results via email or chat messages (or both). In our distributed teams, getting everyone together for a demonstration may prove challenging when spread across many time zones. So if your output lends itself to live demos, do it, but be prepared to record the demo and share it with stakeholders who cannot attend.
For instance, in preparing for our annual face-to-face meetups, written travel and logistics information as well as guidance on how to prepare for upcoming collaboration are followed by multiple ask-me-anything (AMA) sessions. After the AMA sessions, we summarize questions and answers into a Frequently Asked Questions (FAQ) page that helps other colleagues unable to attend to get caught up. They may end up asking questions later in a chat or email that also become additions for the FAQ page.
You can constantly be in the gemba as are each of your distributed colleagues. So you learn to tune your communication channels and your senses to a different way of noticing what’s in the virtual space. Again, experimentation is the key. Through my current experimentation, I look at what teams and initiatives I’ll focus on the coming week, ensure notifications in email and in chat are tuned for those communications (usually by channel in the chat) and then mute or lower communications notifications in other "gembas" I’m not focusing on for the week. I can still check these other gembas at the end of a day if needed, or just ask managers or team members in those gembas to reach out if they need anything in my open collaboration times.
For the gembas I’m focusing on, I’m tuned in all the time to the work and the collaboration. I may ask questions of those teams as I notice interesting approaches or gaps in the work. I may remind them of new experiments the team wanted to try. I may just gather data for an upcoming retrospective. This could include what is shared in email or chat.
Leading people we may never see in a distributed organization
Whether you are a coach, team leader, manager, director or executive, you lead by your example. In a distributed organization, take care on what you amplify and what you dampen in your example through your online communications and behavior. Keep these four things in mind to help you share the example that will help your organization:
- Be clear on the vision
- Manage (and model) for change
- Amplify communication and collaboration
- Focus on principles over practices
Be clear on the vision - If you run an organization, make the vision crystal clear and repeat it often and in many communication channels (email, Slack, on the company intranet, in blog posts). When your colleagues propose some new initiative, ask how it relates to that vision, even if you feel you know. Asking helps test who else knows.
When people start repeating the vision back to you or start asking others how their ideas tie to the vision, you know people are starting to grasp the vision. This will help guide others in how they move their part of the business forward.
And, if you are a team member, do you know your team’s vision? If so, how does that relate to the overall vision of the organization? Keep asking until you get an answer from your teammates, other colleagues and leaders that starts to sound similar. You can also lead where you are in the organization. You don’t need a title.
You may wonder if being clear on the vision (and testing often) differs that much between collocated and distributed teams. It doesn’t. It only depends on the communications channels.
Manage (and model) for change - Business challenges us daily. As a distributed leader, you need a model to safely navigate your team through these challenges. Too many variables are at your disposal between technology to build and collaborate, staffing, business needs, market shifts, regulations, and more.
Your best choice is to become comfortable with change and help those you influence become comfortable with change. Talk about change through internal blogs or talks. Set up a "change agents" channel in your chat tools to discuss how to navigate change. Demonstrate your model. Show how you set up simple experiments to test a new challenge. Invite others into the planning to see what must be done to control the experiment and prove your hypothesis and how it fulfills the vision.
You might experiment with a new technology that allows your team to innovate. Another technology might improve how your team collaborates. Your team may come up with new ideas to leap past the competition or completely disrupt them. You may propose a new way of using a tool. Each of these are seeds for a hypothesis.
As a leader, influence others to safely experiment and prove or disprove that hypothesis. Give them a template, such as an A3 template, and show them how to work with others to fill it out. Collaborating with others helps make the experiment safer, can clarify the hypothesis by getting feedback, and can determine how long the experiment should run to prove or disprove the hypothesis. Also, demonstrate how you communicate updates on the experiment to interested stakeholders and then publish results and conclusions of the experiment. If you never publish your results and whether the hypothesis is true or not, learning becomes lost within the organization.
Amplify communication and collaboration - As you move forward with your experiment, you should communicate to those impacted how the experiment may change things, how you will gather information on the experiment and keep them updated, and how you need feedback from them.
Find out who is impacted the most. Be sure to collaborate with them on planning the experiment. Experiment with them, not on them. I sometimes see experiments imposed upon teams. This imposition definitely affects the outcome, and rarely for good. For instance, rather than impose metrics on a team, why not have a discussion on how metrics can help the team, provide some suggested metrics and your reasons for suggesting them, but also listen for what the team wants to measure.
In a distributed environment, we tend to communicate more than we would in a co-located environment. A leader may share an important message in a meeting, then in an email and then again in a blog post. This helps distributed colleagues who may be working at the same time as you (or not) to keep the experiment in mind and notice how it may impact their work if they are not directly involved. Again, when you hear others repeat the message, you can tell it’s starting to be received by your distributed colleagues.
Focus on principles over practices - As I mentioned earlier, I’ve seen experiments (or just changes) imposed on teams. Often for distributed teams, it’s imposing practices that work well in a colocated environment on a distributed team’s environment.
When practices for one environment are imposed in another environment, strange things happen, for instance, people having to attend a stand-up or planning at 3am because their other team members are several time zones away. I don’t function well at 3am. I don’t know of anyone who does.
So, distributed teams and leaders need to think about the principles behind the practices and how we can experiment toward altering the practice or come up with a new practice that satisfies the principle.
In the instance of a stand-up meeting, the principle is to collaborate daily on the work, see who needs help and plan new tactical changes to the work to keep the work moving forward. If a team finds they have four or more hours of overlap in their normal workdays, they may just adjust the time for the stand-up. This also gives them some time to collaborate and help each other.
Managing change through experimentation
Let’s look at the last example around the stand-up meeting. What if there is less than an hour of overlap in the team’s day?
You need to go back to the principles, ask questions about how those principles work in your context, and create an alternative practice to the stand-up to coordinate daily on the work. How can the team keep each other informed? How can team members ask for help and get help? Can some of the team find time to collaborate, if not all of the team at once? What experiment could the distributed team run and how will they know when they see improvement? How long would they have to try the new idea to recognize the improvements? These questions help form an experiment.
Focus on principles over practices
Let’s consider another example: the retrospective. Is it difficult to find time to have everyone in a retrospective? What’s the purpose of the retrospective? (To reflect on how we work, look at amplifying what works well, and setting experiments to change what does not.) Can we do part of the retrospective asynchronously without everyone in the same room? Data gathering might be a possibility. What can we do to analyze and decide what to do next? Do we do it in one session every two weeks, or do we try something different like spreading the conversation out over the same two weeks?
One of my distributed teams decided they would have mini-retrospectives (they called them "kaizens") once a week and captured ideas or any concerns in a separate retrospective chat channel. Some analysis happened asynchronously in the chat channel. Most of this analysis was to determine if it was a quick change or needed discussion. Discussions on the quick changes occurred in the kaizens after the stand-up and anything requiring deeper analysis and discussion was queued up for a retrospective discussion.
Advice for agile coaches working with distributed agile teams
I find we need to experiment frequently in distributed workplaces as the collaboration technology changes as fast as the solutions we build for customers. You need to discover and amplify the mission, manage and model for change, amplify communication and collaboration in your distributed environment, and focus on principles over practices in setting up your experiments.
Finally, you need to share your results across the organization. Don’t keep solutions within teams or silos. Describe the team’s context, problems they were trying to solve to collaborate and deliver, and how they experimented toward a solution. This just becomes another form of "publish or perish." Don’t let the innovation within your organization perish.
As an agile coach, publishing results of your own becomes critical for modeling proper experimentation. Working across an organization, an agile coaches’ work sometimes is not immediately visible to some parts of the organization. Just as it’s valuable for any team to publish what they are experimenting on and the results, agile coaches need to make their work visible and how that work supports the broader organization vision.
So grab your lab coat and come experiment with me toward better online collaboration. Let me know how it goes!
About the Author
Mark Kilby, with over two decades of experience in agile principles and practices, has cultivated more distributed and dispersed teams than collocated teams. He has consulted with organizations across many industries and coached teams, leaders, and organizations internally. Kilby shares this experience in his latest book with Johanna Rothman - From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver. Kilby also co-founded a number of professional learning organizations such as Agile Orlando, Agile Florida, Virtual Team Talk, and the Agile Alliance Community Group Support Initiative among others. His easy-going style helps teams learn to collaborate and discover their path to success and sustainability. Read his most recent ideas and articles here.