One of my Scrum Masters was inspired by Adam Weisbart's Agile Anti-Patterns presentation at the Scrum Gathering Paris and has shared many of the ideas in a workshop at his own organization. Knowing that the topic can be sensitive, my Scrum Master explains that an anti-pattern does not mean that we are doing something completely wrong and against the agile principles because we are bad people--the truth is, we have good intentions and want to be successful in our work. There is something about the anti-pattern that is appealing and may seem agile at a first glance. But in the long-term, something about the anti-pattern is preventing us from becoming more agile, hence its name.
In the last workshop he gave, someone brought up that they are on a distributed team across timezones, which means they do not follow the below agile principle:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Should we point our fingers and shame management for creating a distributed team that cannot possibly follow this agile principle? I don't think so. I feel empathy for the team because I know it can be incredibly hard to be successful with that kind of arrangement, but shaming someone and blaming them for an anti-pattern does not seem productive. Especially because this person said they've found a way to work well together as a team--to create human connections across distance.
Last week one of my peers, Josh, gave a presentation on Distributed Agile Teams based on his recent experience as a Scrum Master for a fully distributed team (and I'm happy to say he'll be presenting on the same topic at DFW Scrum this month). Another team has found a way to work well even though they are in different locations. Should we tell them that it is an agile anti-pattern to have a distributed team and have management do something about that? I don't think so.
The problem with most distributed teams isn't that they are unable to talk face-to-face; it's that something (or many somethings) is preventing them from following the below principle:
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
If the individuals are not motivated, if they don't feel like a real team, if they don't have the environment and tools and support they need, then they will not be successful. Making a distributed team successful takes effort. A motivated team with the right support will find a way to deliver results.