6 . Agile and Remote Work
How Agile Principles Helped me Be a Successful Remote Worker
SUMMARY
I appreciated the first teams I worked with as a Scrum Master and agile coach. Not only were they willing to experiment, but they often put me in unusual situations. From them I learned that principles are far more important than practices.
By Mark Kilby
In a job not long ago, I encountered the challenge of a team that went suddenly distributed. We didn’t have many collaboration tools available, but I was asked to guide them. But “not long ago” was actually in 2004 with one of my first agile teams. Little did I realize then how powerful “inspect and adapt” would be in the future of my remote work and my career.
I struggled with those first remote teams, but one phrase kept running through my mind from all my training and everything I read: “inspect and adapt”. If I were to find a way to make agile work, I would need to use this agile practice more than any.
Do I Need to See You to Collaborate With You?
At first, working remotely from the rest of my team felt very uncomfortable. I could not see how they reacted in meetings. I could not casually bump into them in the hallways to get to know them better. I didn’t know their strengths or weaknesses or their concerns about the work.
How could I get to understand my remote team? How could I help them from far away?
First, I asked for a budget to fly to where the majority of the team was located. I really didn’t want to travel because my wife and I had two young children and this would put a tremendous burden on my her. However, I needed to meet the team face-to-face to get to know them. Once I knew their strengths and weaknesses, what concerns they had, and let them know how I was willing to help, I knew I could work with them anywhere. After discussing this with my wife, she supported my hypothesis.
In some of these first trips, I met one of the senior developers named Gary. Gary worked for the organization many years, knew most of the developers, and tended to be very collaborative. He was somewhat skeptical about agile practices as he felt they represented another fad. But he heard good things about me, and he felt if you had a good team, you could accomplish anything. Gary’s reputation for fostering “good teams” spread around the company for years. As Gary and I spent time together, we realized we both wanted the best for the team and that included them succeeding with this latest project.
With that, Gary introduced me to the rest of the team and even found space for me to sit with the team. We worked closely together for two weeks and then it was time for me to return home.
Inspect-and-Adapt Lessons: At first, this remote experience seemed not to match the principle from the Agile Manifesto that states “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”(1) However, as I worked with more remote teams, I found that “connection” was more important than “face-to-face”. I had worked with teams in the same location that never really connected with each other. Other research would later prove that distance had less effect on “connection” in remote teams.(2)
In the years following, I looked for many ways to connect with remote team members and for them to connect with each other. Collaboration technologies eventually made face-to-face easier for remote teams.
My initial contact with Gary, taught me the value of having some sort of one-to-one meeting with team members whenever I guided a new team. I realized I didn’t need to see team members every day, but I did need to “hear” them in some way and truly understand what they were saying in email, code comments, or voice. Distinguishing upset, frustration, joking, and playfulness in any media became a key skill to develop. Through studying co-active coaching(3) and clean language,(4) my “hearing” for the team members improved.
I also found that tending to the relationships on the team were key. Some would be curious to learn how I “listened” for the team. Some team members were not so interested. So, any time I could get a remote team together in the same place, we would spend as much time outside of work as we would in work. Sometimes, a short, simple exercise would allow us to understand each other when we could not easily get together.(5)
Teaming Our Way to Remote Success
In some of those first remote teams, we didn’t have the collaboration technology available today. However, Gary and I discovered the team had excellent patterns to build upon.
First, several of our developers had contributed to various open source projects and brought with that experience a useful mindset. Many of them understood the minimum tool sets needed to coordinate and collaborate on building a sophisticated code base. Complex commercial solutions were often not needed to manage the code. There were sufficient open source solutions that these team members could easily use.
Second, open source projects don’t often run with hard deadlines, these developers contributed to those projects to leverage that code. So, while the company did not financially back these open source projects, they did allow developers to contribute code that allowed the quality of the open source project to improve without giving away any proprietary solutions.
Third, these developers also understood the importance of communication flow (especially, tone and intent) and the timeliness of a response. A quick and courteous response means no team member stalled too long on a specific task. One could always reach out for help and expect replies. They understood that asking for help meant moving the entire team forward. Feedback became critical to these remote teams.
Fourth, their open source mindset encouraged experimentation. Very often, one open source project will leverage the advances of other open source projects. To do so, meant that developers built a flexible and modular architecture that could support swapping out different modules.
Inspect-and-Adapt Lesson: As I learned from these early agile remote teams and the many remote teams I coached later, the collaboration in the team is key. This also reminded me of these principles from the Agile Manifesto:
- Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
- The best architectures, requirements, and designs emerge from self-organizing teams
If I could help the team build trust with each other and trust of the team with stakeholders, these remote teams could be more agile. But it also depended on what example the stakeholders provided.
Collaboration and Communication at ALL Levels
The teamwork outside the teams became as impressive as the teamwork inside these early remote teams. The leadership supported and modeled their own form of teamwork with other leaders and with the teams.
For instance, they not only helped clarify the needs of the customers, but they also understood the importance of the teams working directly with the customers to empathize with their needs. In one of these early teams, we did not have a product owner available within our organization. But we had someone in the client organization that was well-versed in the technology and the business needs. So, the team adopted him as the product owner. We quickly developed a team charter with the approval of our management on how decisions would be conducted. Our client/product owner worked closely with the team to deliver several releases of the product with great success for both organizations.
Our company leaders also understood the importance of keeping teams informed. They sought status on the project, but often reflected back the importance of the progress to the customer and the business. Also, any critical information, like quick shifts by competitors, echoed from direct managers and through all-hands meetings. This allowed developers to understand the importance of their work as they heard the same key messages from multiple sources.
With these and other practices, the remote teams often felt that leadership “had their back” and would support them in any situation.
Inspect-and-Adapt Lesson: This experience allowed these remote teams to live these principles from the Agile Manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (and products).
- Business people and developers must work together daily throughout the project.
A team can only go as far as their leaders support them. If there is no support for experimentation, customer communication, transparency and flexibility outside the team, why would you expect it in the team?
Later, I would work with other remote teams and organizations where the leadership operated very differently from the teams. This separation made it difficult for the teams to be successful, let alone agile. Sometimes these difficulties arose when the teams had little flexibility in changing their process to meet their delivery context. This “break practices” approach often became a test to see how an organization could truly support their teams.
Breaking Practices and Rebuilding with Principles
Some of the real challenges came in following agile ceremonies. Stand-ups, planning, reviews and retrospectives all had to be re-thought for our remote teams. We couldn’t just follow what we read. Much of what was written assumed people were standing around a board or a table together. We had to step away from the practices and truly think about the principles that inspired them.
In some cases, we were able to modify practices. It was not unusually for us to tape the names of our remote colleagues on the speaker phone to remind us of who else was on the call.
In other situations, we had to create new practices. For instance, in some of my earliest teams, we were usually only 1-3 time zones apart from each other or our customers. But in some cases, we would be 13 hours apart. The type of products these remote teams developed were designed for high security environments worldwide. This meant that team members may be spread half-way across the world from 1-2 months as they went on-site to install the products and test them with the customer.
However, these teams had some unique ways to handle this huge difference in time zones. Usually, developers would travel to the customer sight in pairs for installation and testing. The rest of the team back in their home offices would stay in support mode. There would be two stand-ups each day so that the morning shift in one time zone could sync up with the evening shift in the other. If the on-site team found a problem they could not resolve, they would pass it on to the other team. At the next standup, the solution would typically be provided.
As team members rotated who went onsite for installation and support, everyone empathized with the on-site installation team members. Those in the home office responded to on-site staff as if they were responding to urgent requests from the customer. Next time, it could be them on site. So they treated their remote colleagues just as they wished to be treated when they were in that situation.
Also, anyone in a supporting role could rotate into one of these installation and test shifts. As Scrum Master at the time, I took one of those shifts even though it wasn’t required. I could not ask team members to do what I was not willing to do. It was a difficult two weeks for me and my family, but it helped me understand what my team experienced.
Also, as these installation events happened roughly every two months, the company leadership would hold their own after-action review of the event, how it went, and what they might do differently at all levels to support the customers and the installation team for these events. Immediately after, the entire team would go into a slow-down mode for a week to recover.
Inspect-and-Adapt Lesson: Since we could not simply push software out to our customers, installation and testing became another ceremony followed by a ceremony of reflection. This reminded me of the principle of the Agile Manifesto that states:
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
But this remote team had multiple cadences depending on the development mode versus delivery mode. Those different cadences and how they were used led me to experiment with other remote teams and realize they also needed to:
- Establish acceptable hours of overlap
- Assume good intention
- Create a project rhythm
- Create a culture of resilience
By shifting their operating mode, finding a rhythm to overlap when team members were far apart, and treating the installation team with highest priority, they supported each other and became a highly resilient team. They could truly resolve any problem the customers found in the product in an amazing amount of time.
The way these teams operated became well known and they started to beat out larger and larger competitors. Eventually, the success of how these teams could respond to customer needs led to a successful acquisition of the company.
Principles over Practices
Time and again, these early remote teams taught me more about agile than I ever learned in an article, book or class. They showed me that practices don’t make a team agile. What makes a team agile depends on clear communication with each other, stakeholders and the customer and responding to changes as needed by those groups. Clear communication depends on treating people as people and getting to know how they work best and supporting them. From that point on, you merely inspect the current situation and adapt.
KEY POINTS
- Avoid treating a practice as a rule
- When a practice does not work, rediscover the principle that inspired it
- Get to know the people and the work
- Never ask anyone to try something you would not try yourself
“Break practices and rebuild with principles”
(1) http://agilemanifesto.org/principles.html
(2) Karen Sobel Lojeski and Richard R. Reilly, “Uniting the Virtual Workforce: Transforming Leadership and Innovation in the Globally Integrated Enterprise”, April 2008, John Wiley & Sons
(3) https://coactive.com/resources/coactive-coaching-4th-edition/
(4) https://www.cleanlanguage.co.uk/
(5) https://www.markkilby.com/compass-activity/
I am Mark Kilby and these are my agile-thoughts
2021 © Orlando, Florida, USA by Mark Kilby
With over two decades of experience in agile principles and practices, Mark Kilby 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.
Mark shares this experience in his latest book with Johanna Rothman – From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver.
Mark also co-founded a number of professional learning organizations. His easy-going style helps teams learn to collaborate and discover their path to success and sustainability.