Introduction
My first piece of advice is this:
DON’T DO IT!!!
Probably the worst possible setup for “team” is spreading them around the country or the 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:
WRONG, YOU HAVE LOTS TO 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. That is but 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 encouraging T-shaped engineers
- DevOps tools and practices are valuable for Distributed Agile Teams
- Increase efficiency of Continuous Integration and automation testing in distributed teams by using cloud
While the article is titled and implies a focus on culture, it really 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. And, don’t get me wrong. It’s not that I disagree with the articles items or focus. It’s just that I don’t think these are highest priority or impact focus points to make distributed agile teams 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 and intent and principles. Particularly on the part of the leadership team that is setting the stage for “distributed agile teams”.
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” some work at them. There is 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.
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 around the stories. There was no discussion. 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 time zone challenged teams, this is a choice.
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.
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. Towards the end of a 2-hour session, one you 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 towards 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
And then 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 starting 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.