What Should I Do If My Agile Team Can’t Be Co-Located?
One criterion for team selection is member co-location. Whether working in nearby cubicles or in an open space, short distances between members contribute to communication and collaboration. The ease of casual interaction, the ability to observe facial expressions and body language, and the immediate sharing of artifacts facilitate team evolution. When a co-located team experiences conflicts, they are more likely to manage them healthily, rather than to pretend they don’t exist.
Depending on your office layout, you might be able to secure a team open space, also known as a “bullpen.” If your office is all desks or cubicles, and members work in various parts of a single office, see whether they can switch locations to be within walking distance of each other.
A new Agile team was spread all over one huge floor, with no hope of desk switching or dedicated space. When I suggested that they take over the windowless, cramped classroom in which I taught them the Agile fundamentals, they were excited! Their project manager obtained the right approvals, and for several weeks they worked happily and productively in this otherwise-dismal space. In the meantime, other arrangements were made for them.
If team members’ locations are fixed, hopefully they are not too far apart. A 30-foot distance (about ten meters) suffices to deter people from leaving their chairs to engage colleagues in face-to-face conversation.[i] In closer quarters, your team may be more inclined to communicate in person and use phones and chat software the rest of the time.
But what if your team cannot all be in the same place? Industry experience shows that, despite the extra challenges, the increased overhead in time and money, and the loss of productivity, dispersed teams can nevertheless be quite Agile.
The alternative to direct communication tends to be technology. Nowadays, person-to-person video calling costs next to nothing, works reasonably well, and is fairly easy to set up. Group conference calls are still at the shared-screen and conference-call evolutionary stage. More powerful, almost-in-person solutions are becoming more commonplace, but they are not immediately and constantly available at the individual team level.
However, once a team cannot make do with visual and presence-based communication, they must rely on tools to capture and track their plans and artifacts. These tools make some parts of planning and tracking easier, and some harder. They might also have the following negative effect: even when many of a team’s members do inhabit the same space, they may gravitate to the tools, email, and chat to converse among themselves, rather than leveraging the potential of closer in-person communication.
Teams are quite vulnerable to “out of sight, out of mind.” If you see a teammate — on screen or in person — for only two hours a week, you’re less likely to feel the bond of shared purpose and mutual commitment. If most of your communication is on the phone, that’s another discouraging factor. Most team members are likely to process information visually rather than auditorily, [ii] which makes concentrating on a phone conversation difficult for them. And the remote people participating on speakerphone usually have a rather poor experience; for the most part, they struggle to hear and identify speakers. Their temptation to disengage and multitask during a conference call is huge. They might tell you “I can’t hear,” but they won’t tell you “It’s hard for me to focus and be on the phone for so long.”
Geographical team distribution has three common forms:
- Most of the members are co-located; one or two are remote (probably at home).
- Half the team is in one site; the other half is in another site.
- The entire team is distributed (for instance, they all work from home).
If you have the choice, avoid form 2. Such a team naturally devolves into two subteams that work largely independently. The situation is even worse from the perspective of team growth and collaboration when one of the halves is the obvious “home team” and the other one is known as the “offshore team.”
Distribution form 1 is less susceptible to the clique problem. It might work well with highly engaged people who already have a previous working relationship. Since onsite folks can easily make progress and decisions, the constant risk is that they don’t remember or care to pull remote ones in and involve them. It’s an effort they don’t always wish to make.
The best option is form 3, since it puts all team members on an equal footing. They will invest in communicating and coordinating with each other. They will set up their technology effectively and adjust their process and practices to their reality. Many successful open-source projects operate this way.
A company in downtown Boston allowed every employee to work two days of every week at home, to reduce their commute time. One of their teams was a hybrid of the co-located and the distributed. All its members chose to work from home the same two days, and the rest of the time they were co-located.
If your team has even a single remote member, one technique to strengthen the entire team is pair programming. Block off several hours every day during which the entire team is available and pair programming is the norm. Help the team make this an explicit agreement. Make sure technology is not an issue: everyone should have personal headsets, fast computers, and fast screen-sharing software. If the pairs switch around at least once a day, this pair-wise way of growing a team will strengthen team bonds in a matter of weeks.
About the book and the author
The excerpt above is from the book The Human Side of Agile: How to Help Your Team Deliver which will be available September the 12th. With this book, Gil Broza has created a practical, universal guide to navigating the least manageable, understood, and appreciated asset in an Agile environment: its human side. Even if your customers are reasonably happy and your developers seem to be doing okay, you know your team is capable of more: delivering great products and staying ahead of ever-changing demands. You want to feel good about using Agile and to create the conditions for great results, but the skills you honed in traditional environments don’t always apply to the role of Agile team leader. The Human Side of Agile fills this gap, guiding you to:
- Establish yourself as a confident and capable leader who adds value
- Build and lead an engaged team that can handle almost any challenge
- Cultivate collaboration and a continuous improvement mind-set
- Reap the full benefits of Agile in the real world with real people
Gil Broza has mentored more than 1,500 professionals in 40 companies within the last 10 years who then delighted their customers, shipped working software on time, and rediscovered passion for their work. Gil offers much-needed services (beyond basic education) to help ScrumMasters and other Agile team leaders grow in their roles. In addition, he provides workshops, consulting, facilitation services, and enablement programs to fix lackluster Agile attempts and support ongoing Agile improvement efforts.
Don’t forget to leave your comments below.
team completes a sprint (see Terre Haute, IN on the map) it evaluates if the same destination is still desired by the business sponsor. If so, the development team will work with the next user story in the backlog.
This article recognizes resistance as a source for requirements risk. Business analysts recognized assumptions, constraints and dependencies as the major sources of requirements risk. However, in every analysis there is some level of resistance to change. This article reviews the three traditional sources of risk and makes the case for including resistance as an additional source.
• Assumptions – business conditions that if changed would affect the requirements or requirements development
• Resistance is a barrier encountered by the business analyst in developing requirements from stakeholders
Dick and Jane are a couple with a nice home and are business analysts for a large firm in a downtown business center. One day Dick and Jane decided to upgrade the single pane windows of their home. Being experienced business analysts, they first listed their major sources of risk (assumptions, constraints, and dependencies) and then prioritized their requirements.
Remember Dick and Jane live in a nice house, in a nice neighborhood, with a not-so-nice Home Owner Association. Upon the first week of window installation, they received a letter from their HOA advising them to cease all work until they submitted a request to the HOA detailing the change to their house. Although Dick and Jane own their nice home, they have come to realize there is a third stakeholder – the HOA and the HOA can be quite resistant. Lesson learned: always consider four major sources for risk – assumptions, constraints, dependencies, and resistance.
