There are literally three things that come up in any of my training adventures—
How to handle estimates and forecasting with fixed-date projects?
What are “Good” agile metrics?
How to be “Agile” with distributed teams?
I thought I’d explore the last question on distributed teams in this post by listing some references that you might find helpful.
First, I think the Jutta Eckstein was the first author in this space. She wrote—Agile Software Development with Distributed Teams: Staying Agile in a Global World in 2010 and updated it in 2018. She was probably one of the first folks who started sharing her experiences in distributed agile and her work has stood the test of time.
Next, Johanna Rothman and Mark Kilby have written perhaps the most complete work on the topic in agile contexts. From Chaos to Successful Distributed Teams: Collaborate to Deliver is an incredibly useful look at how to make distributed teams work in agile contexts. Written by two seasoned coaches from their work in the real world. And here’s an Agile Alliance article they wrote about collaborating on the book.
And here’s Johanna and Mark’s contribution to Comparative Agility’s assessment tool.
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.
Book References
Project Retrospectives - A Handbook for Team Reviews by Norm Kerth
Sort of the “Godfather” of the modern day, agile retrospective is Norm Kerth. I always try and mention norm and his work as a means of giving folks a sense of the pre-Agile legacy of retrospectives. Point being, it pre-dates agile approaches.
The other nice thing about Norm’s work is his notion of “safety” in retrospectives and his Prime Directive. I almost always reference the prime directive at one point or another with each of my clients and in my teaching. It epitomizes the “mindset” of a healthy retrospective.
I frequently get asked about the dynamics of building agile organizations from an organization structure point of view.
The most important point is that you don’t create a high-performance agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.
Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.
Whew! I’m glad, because I never figured out how to do that perfectly anyway.
By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.
Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.
It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.
