My first piece of advice is this: DON’T DO IT!!!
Probably the worst possible setup for a team is spreading them around the country, world, or the universe and expecting them to behave and deliver like a close, cohesive team. My second bit of advice for those of you that blame it on management and say you don’t have any say in the matter, is, you have lots of say in sustaining distributed teams or creating another strategy!
I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it, except complain about it.
I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:
Key Takeaways
- Team structure reflects in product architecture
- Distributed teams can perform pair programming by using some remote pairing techniques and tools
- Microservices influence a good distributed team structure
- Increase co-ordination within a team by encourag
ing T-shaped engineers - DevOps tools and practices are valuable for distributed teams in agile
- Increase efficiency of Continuous Integration and automation testing in agile remote teams by using the cloud
While the article includes “culture” in the title, and implies a focus on it, the piece focuses more on technical tactics or tooling as the key to distributed teams.
I want to share my own take on keys that have nothing to do with microservices, T-shaped people, or the others from the article. Don’t get me wrong, It’s not that I disagree with the article’s items or focus. I just don’t think these are the highest priority or impact focus points to make distributed teams in agile work most effectively.
A DIFFERENT TAKE - 4 KEYS
As I said, I have a different view on what it takes to create high-performance distributed agile teams. I think the key is more on attitude, intent, and principles; particularly the part of the leadership team that is setting the stage for “distributed agile teams.”
1. Starting Properly
Starting up is the key. How you initially build, staff, train and position product/project work for each of your distributed agile teams is my number one basis for success.
All too often, organizations just throw a team together and throw work at them, with little to no effort to properly instantiate the team. However, there is this infernal expectation that they’ll behave as a high-performance agile team. Which never happens.
I often call this chartering the team. Where we:
- Get the entire team together for a period of time
- We conduct team introduction and building activities so that they get to know and understand one another
- We give them a chance to actually work together for a couple of sprints
- We allow the ScrumMaster and Product Owner to jell with their teams
- And of course, they get the chance to collaborate on their future backlogs (grooming, estimating, designing, etc.)
If you think about it, this sets the stage for the team’s continuity and performance.
You might also consider some sort of periodic rotation of team members or another get together where folks get more face time in order to better understand one another and increase their trust.
2. Committing to Agility
One of the early realizations for a distributed agile team is that they need to commit to solid behaviors and practices as if they were a co-located team. For example:
When I was working at Velocity Partners we often had off-shore (in South America, near-shore) teams that were inclusive with the exception of a customer-based Product Owner. With 90% of our teams, one of the common complaints was that the Product Owners were too disengaged from the teams.
Often this surfaced with them refining and building the backlog with local engineers or SME’s and then simply handing off the fully groomed stories to our Velocity teams for execution and delivery.
There was no collaboration or discussion around the stories. It was simply a hand-off. And no, it didn’t work very well at all.
When we convinced clients to actually embrace our teams as a partner, to respect them in the collaborations, and to make this a priority, things worked beautifully with outstanding results. And this wasn’t a time-zone thing. It was a commitment thing. We needed the clients to commit to agile practices, principles, and intent. Even in the zone challenged teams, this is a choice.
Want to learn how to utilize Scrum/Kanban methodologies as a means of delivering your software more effectively?
Check out our Agile 101 workshop, suitable for anyone interested in learning the basics of Scrum or Kanban.
3. Collaboration tools are important, but...
You saw quite a bit of discussion in the article about tooling. For example, DevOps tools. But I’ve seen an anti-pattern in agile teams for over 15 years. And I think it happens in most organizations. It’s that everyone leads with tools, expecting that the tools will solve all of their challenges. In the distributed team space, that a tool will somehow magically create x-team engagement and effective collaboration.
I hate to break the bad news to you, but it sadly isn’t so.
Of course, tools are helpful (and required) in distributed settings. But they won’t create a high-performance agile team. Only the team can do that. The tools are only a means to an end and the focus needs to be on the collaboration. Independent of the tools.
4. Compensation structure and incentives
It’s also important that distributed teams are incented to work together. I was working at Deutsche Bank a few years ago as a coach. I was asked to run some agile training sessions for team members in Ukraine.
I remember in one session that I was getting very little feedback or interaction from the Ukrainian folks, but I soldiered on. Toward the end of a 2-hour session, one man raised this point.
He said, Bob, while all of this agile collaboration and teamwork stuff sounds nice, we’re not incented to work together. Each of us is incented to only worry about their individual performance. That is how we’re incented by our consulting firm AND that is how our contract is structured with Deutsche Bank.
We’re all measured on individual performance as part of the SLA and the measures are skill specific. For example, developers are not incented to help testers.
This somewhat shocked me, but I did understand the point, and I closed the class down immediately.
It often turns out that we’ve set up our compensation systems, role & responsibility definitions, organizational charts and reporting relationships, and contractual agreements to undermine or, in the worst cases, provide no support for our agile initiatives. The counterpoint here is that we have the choice to completely change the way we incent our people and move toward team incentives vs. individual incentives.
At least creating incentives that don’t block the solid agile behavior we need in effective distributed teams.
WRAPPING UP
I’ll start explaining this guideline with an analogy.
Back to my original point, I highly recommend that any organization that has a highly distributed team structure AND is trying to commit to high-performance agility, should strategically:
- Commit to getting teams as closely together as possible; aggregating individuals, roles, functions, and groups
- Realize that the most effective agile team is a co-located team; one that can communicate face-to-face
- Invest in tools only as a means to create effective and efficient collaboration and teamwork
- Ramp up new teams and start new projects by bringing the whole team together and chartering the effort
- Invest in sufficient travel expenses so that team members can visit one another frequently…until they are co-located
- And finally, don’t create contractual relationships that de-incentivizes agile team behaviors
All of the above are possible in the real-world if you plan, budget, and commit to reducing the distributed nature of your teams. It just takes some time, focus, and a bit of courage!
Stay agile my friends!
Bob.
Up Next:
