Antipattern of the Month: Distributed Team
Antipattern of the Month: Distributed Team
While there are plenty of obvious antipatterns, some will take a little more fight to overturn. Learn how to face the corporate norm of "distributed" teams.
Join the DZone community and get the full member experience.Join For Free
The easiest antipatterns to sort out will often reveal something that's clearly out of kilter. Failure to observe agreed time-boxes would obviously be a problem, because a degree of discipline must surely have been lost. The team will acknowledge the situation and find a way to improve. However, not all antipatterns expose something incontrovertibly whacked. A reluctance to deliberately limit Work in Progress, for example, can seem to be quite reasonable. Surely it's better to try and do more stuff? The malaise of reduced throughput, poor focus, depreciation, and other waste that arises from trying to do too much at once can need explaining. Only then might it be recognized that there is an "antipattern" to be tackled at all.
Antipatterns which involve entrenched cultural practices are even harder to deal with. People can become resigned to corporate folly when there is no realistic prospect of change. Which individual can hope to solve a company’s Waterscrumfall problem? What about the insistence of managers to conduct their business through reports? Who's game to sort that one out? Face it: you're up against the system. Robust sponsorship from the very top is needed to overcome organizational gravity, which tries to mold and squash everything around an institution's current shape. It's the enterprise version of Stockholm Syndrome. The pressure is on employees to conform until they self-identify with the power which holds them in thrall. They will eventually regard its norms as "common sense" and perhaps even as the righteous thing to do. Anything less than a top-level drive for enterprise change will either succumb to inertia, or to the reactionary tendencies of that gargantuan sucking force.
Now consider the familiar and wearisome problem of having "Agile" team members who are not co-located with one another. The most tricky antipatterns of all are those which represent not just normed behaviors, but assumed corporate values. Asserting the irrelevance of distance does not make it so. It's essential to recognize there’s no such thing as a “distributed” Agile team...just a dislocated one. Executives who are transparent about this fact might stand a chance of addressing the problems which dislocation creates.
On the one hand, the advantage of keeping team members in physical proximity is well understood and generally accepted. Everyone knows that the most powerful communication is face-to-face and that a great deal of it is non-verbal. Yet managers also expect team members to be smart and resourceful enough to compensate when they are geographically separated from each other. The potential cost efficiencies to be had from a globalized workforce are too tempting to ignore. Moreover, the savings to be gained from this model can be swiftly calculated as a dollar amount. The losses to be incurred through reduced collaborative potential are far harder to quantify. "Anyway," the bean-counters say, "our people are smart enough to find workarounds. They'd better be. We'll declare a one-team culture irrespective of location, and we'll state this as our credo." Similar attempts at dislocation may have already resulted in failure, but it doesn't really matter. Things will be different this time. Look at the numbers. Remember the credo.
And so it becomes incumbent upon team members to find those workarounds. Promises of technical remedies, including high-bandwidth videoconferencing suites, might be hinted at by management. There could be talk of some individuals flying out to physically meet with others. In the mean time development is expected to proceed regardless. Employees and contractors struggle to collaborate by email and messaging apps across different time zones, while events may be split to reflect geographical reality and the skill-silos which have become entrenched. In vestigial "daily standups", those in one location will huddle over speakerphones and intermittent VoIP connections, laptops perched on benches showing task boards that few see reason to care about. They strain to hear those in another country above local chatter, and the din of office refurbishments which will, perhaps next time, make the organization's "distributed team" model effective at last.
Intent: Claim the benefits of Agile practice without co-locating team members
Proverbs: United we stand, divided we fall; 90% of communication is non-verbal
Also Known As: Non co-location; Split Team; Dislocated Team
Motivation: Physical constraints, such as desk space and the wider geography of an organization, may inhibit the co-location of team members. The need for Agile team members to work in proximity to each other can present logistical issues that managers are unwilling to overcome. As such, a logical team boundary will be made to span physical boundaries. Managers can thus avoid an immediate resourcing issue, while offloading the management of any risk incurred to the teams themselves.
Structure: A team will try to release project increments on an iterative basis. However, the team members will be spread across multiple locations, and peer collaboration will be correspondingly impaired.
Applicability: Teams in large organizations are particularly susceptible to having non-colocated members. This is because such bodies are often geographically distributed themselves or outsource work to distant third parties.
Consequences: Agile practice is heavily dependent on individuals and their ability to interact with each other. Teams with low WIP limits are particularly impacted by the effects of distributed membership, as each item in progress will require collaborative actioning. There is an increased risk of skill silos emerging as a result of non-colocation, since the opportunities for pairing and cross-training will be reduced.
Implementation: Scrum teams may have some of their functions outsourced or even offshored. Testing is one common example.
Distributed Team is Antipattern of the Month at agilepatterns.org
Opinions expressed by DZone contributors are their own.