© Ashalatha / Shutterstock.comCollocate the team
If at all possible, the scrum team needs to be collocated — that is, physically located together. When a scrum team is collocated, the following practices are possible and significantly increase efficiency and effectiveness:- Communicating face-to-face, taking advantage of the fullness of both verbal and nonverbal communication
- Standing up — rather than sitting — as a group for the daily scrum meeting (to keep meetings brief and on topic)
- Using simple, low-tech tools for communication
- Getting real-time clarifications from scrum team members
- Being aware of what others are working on
- Asking for help with a task
- Supporting others with their tasks
All these practices uphold agile processes. When everyone resides in the same area, it’s much easier for one person to lean over, ask a question, and get an immediate answer. And when the question is complex, a face-to-face conversation, with all the synergy it creates, is much more effective and efficient than any form of electronic communication.
This improved communication effectiveness is due to communication fidelity — the degree of accuracy between the meaning intended and the meaning interpreted. Albert Mehrabian, PhD, a professor at UCLA, has shown that for complex, incongruent communication, 55 percent of meaning is conveyed by physical body language, 38 percent is conveyed through cultural-specific voice tonality interpretation, and only 7 percent is conveyed by words. Keep this in mind during your next conference call to discuss the design nuances of a system that doesn’t yet exist.
Alistair Cockburn, one of the Agile Manifesto signatories, created the following graph. This graph shows the effectiveness of different forms of communication. Notice the difference in effectiveness between paper communication and two people at a whiteboard — with collocation, you get the benefit of better communication.
Better communication through collocationFace-to-face communication means we are physically face-to-face as we communicate. Although technology today supports bringing geographically dispersed people together more effectively than ever before, technology cannot replicate the social effects of people working in the same physical location on effective and real-time collaboration.
Scrum teams are most effective when they are physically collocated. However, that doesn't mean agile frameworks such as scrum will not work for a dislocated team. In fact, for the success of a dislocated team, a framework such as scrum is even more important due to its clarity of roles, transparency, and tight empirical feedback loop.In the following discussion, we describe the ideal situation for enabling a scrum team communication, realizing that opportunities to achieve the desired benefits of collocation exist even when collocation isn’t possible.
Set up a dedicated area
If the scrum team members are in the same physical place, you want to create as ideal a working environment for them as you can. The first step is to create a dedicated area.Set up an environment where the scrum team can work in close physical proximity. If possible, the scrum team should have its own room, sometimes called a team room or a scrum room. The scrum team members create the setup they need in this room, putting whiteboards and bulletin boards on the walls and moving the furniture. By arranging the space for productivity, it becomes part of how they work. If a separate room isn’t possible, a pod — with workspaces around the edges and a table or collaboration center in the middle — works well.
If you’re stuck in cube city and can’t tear down walls, be creative and ask for a group of empty cubes and configure them in a way that works for your team, even if that means removing panels. Create a space that you can treat as your team room.
The right space allows the scrum team to be fully immersed in solving problems and crafting solutions. Visualizing ideas and work-in-progress brings about shared understanding among the entire team. Unfettered access to other team members is also key for effective and real-time collaboration. Create a space that enables these things.
The situation you have may be far from perfect, but it’s worth the effort to see how close you can get to the ideal. Before you start an agile transition in your organization, ask management for the resources necessary to create optimal conditions. Resources will vary, but at a minimum, they should include whiteboards, bulletin boards, markers, pushpins, and sticky notes. You’ll be surprised at how quickly the efficiency gains more than pay for the investment.For example, when one client company allocated a dedicated team room and made a $6,000 investment in multiple monitors for developers, they increased productivity and saved almost two months and $60,000 over the life of development. That’s a pretty good return on a simple investment.
Removing distractions
The development team needs to focus, focus, focus. Agile methods are designed to create structure for highly productive work carried out in a specific way. The biggest threat to this productivity is distraction, such as . . . hold on, let me quickly respond to this text message.Okay, I’m back. The good news is that a scrum team has someone dedicated to deflecting or eliminating distractions: the scrum master. Whether you’re going to be taking on a scrum master role or some other role, you need to understand what sorts of distractions can throw the development team off course and how to handle them. This table is a list of common distractions and do’s and don’ts for dealing with distractions.
Common Distractions
| Distraction | Do | Don’t |
| Multiple objectives | Make sure the development team is dedicated 100 percent to a single product objective at a time. | Don’t fragment the development team between multiple objectives, operations support, and special duties. |
| Multitasking | Keep the development team focused on a single task, ideally developing one piece of functionality at a time. A task board can help keep track of the tasks in progress and quickly identify whether someone is working on multiple tasks at once. | Don’t let the development team switch between requirements. Switching tasks creates a huge overhead (a minimum of 30 percent) in terms of lost productivity. |
| Over-supervising | Let development team members decide among themselves how to accomplish the work to be done after you collaborate on iteration goals; they can organize themselves. Watch their productivity skyrocket. | Don’t interfere with the development team or allow others to do so. The sprint review meeting provides ample opportunity to assess progress. |
| Outside influences | Redirect any distracters. If a new idea outside the sprint goal surfaces, challenge the product owner to add the item to the product backlog rather than put the accomplishment of the sprint goal at risk.
|
Don’t mess with the development team members and their work. They’re pursuing the sprint goal, which is the top priority during an active sprint. Assigning even a seemingly quick task can throw off work for the entire day. |
| Management | Shield the development team from direct requests from management (unless management wants to give team members a bonus for their excellent performance). | Don’t allow management to negatively affect the productivity of the development team. Make interrupting the development team the path of greatest resistance. |
Distractions sap the development team’s focus, energy, and performance. The scrum master needs strength and courage to manage and deflect interruptions. Every distraction averted is a step toward success.