Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

There are two reasons to hold backlog grooming meetings. The first is to make sprint planning more efficient and effective. The second reason is to make sure you understand your backlog. When teams don’t spend the time needed to groom the backlog, planning meetings can be very tense and extend for hours . . . and hours. Backlog grooming sessions can be whole team activities (rare) or sub-team activities (more common). The most common technique used to generate a sub-team for grooming is the Three Amigos (or some variant). The tallest hurdle all distributed teams face is ensuring effective communications, followed quickly by staying focused on the task at hand. Many of the same techniques we discussed for sprint planning in distributed teams will be effective, however, backlog grooming has a few unique twists. (more…)

Stand-ups are best on your feet!

Stand-ups are best on your feet!

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective making daily stand-ups work for distributed teams include:

  1. Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One usable solution that can be tried when distributed teams can’t overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  2. Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might just be starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  3. Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  4. Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get competed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well as distributed teams.

  1. Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  2. Make sure the meeting stays “crisp.” Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  3. Use a physical status wall. While the term “distributed” screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to moving tasks on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool that EVERYONE has access to. Keep tools as simple as possible.
  4. Don’t stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.

#6 Make sure the telecommunications tools work.

#6 Make sure the telecommunications tools work.

In Distributed Agile: Distributed Team Degree of Difficulty Matrix, I described the many flavors of distributed Agile teams and the complexity different configurations create. While all things being equal, distributed team are less effective than collocated teams. Never the less, distributed Agile with teams spread across countries, continents and companies have become a fact of life. There are techniques to help distributed Agile teams become more effective. In an environment using Scrum, the first formal activities for most team’s is sprint planning. There are numerous techniques that can help make distributed Agile more effective. These techniques include:

1.   Bring the team physically together. Co-location, whether for a single sprint or some periodic basis, will increase the team’s ability to understand each other and know how to work together more effectively.
2.   Develop a sprint planning checklist. The process of getting together and planning is a fairly predictable process. Capture the typical preparation and meeting tasks and make sure they happen. Items can include booking rooms, securing video or telecom facilities, publishing an agenda with breaks and more.
3.   Review the definition of done. Ensure that everyone understands the organization’s definition of done before the starting to plan. The definition of done will help the team know the tasks they need to complete during the sprint to meet the organization’s (or product owner’s) process standards.
4.   Focus on the stories. Don’t let distractions get in the way of planning. Before beginning the planning session, review the process that will be followed with the entire team. Make sure that planning the next sprint is the only topic on the agenda.
5.   Ensure that the stories have been properly groomed. The stories that the team will accept and plan need to be properly formed and have acceptance criteria. This generally means that the stories that are most apt to be accepted by team (and a few more) need to have been through a grooming session. Make this a prerequisite for the planning meeting.
6.   Make sure the telecommunications tools work and have a backup. Distributed planning means that all of the team will be using the phone or video conference. Make sure they are set up and tested. Also always have a backup plan in case your favorite collaboration tool fails because sooner or later it will. Planning is a whole team activity and when the whole team can’t participate planning, it will lose effectiveness.
7.   Everyone should understand the big picture. Have the product owner provide an overview of the goals of the project, and how the current sprint will support those goals. Repeating the big picture will provide the team with a common touch point to validate progress.
8.   Use physical tools for interaction. Physical tools, like flip charts and card walls, can be difficult when many locations are involved in sprint planning. However, when possible, use physical tools like flip charts and whiteboard and then use webcams (preferable) and cameras to share data. Have one location scribe one story and then switch locations for the next story.
9.   Try multiple facilitators. When a team is evenly distributed between two locations consider having another scrum master act as a second facilitator to ensure everyone stays on track. Similarly, have the Scrum master rotate between locations to facilitate the planning session. This can be very effective in helping each location feel connected.
10.Remember that sprint planning is a team meeting. Make sure everyone is involved.

Sprint planning, done well, helps a team understand what they have to do in order to consider a story complete, both from a functional and technical perspective. Distributed Agile teams will need to focus on making sure that everyone is involved and a part of the planning process. Remember to plan for planning, because when you are on the other end of a phone or videoconferencing the tools, process and logistics can make or break the meeting!

Professional Man Preparing for a Daily Stand Up

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple. (more…)

Use tools to keep the whole team engaged.

Use tools to keep the whole team engaged.

Distributed Agile planning is not any different from non-distributed in terms of its goal and process.  What should be different are the techniques and amount of facilitation.  Before we go further, I do not think there is any reason planning can’t be done amongst a distributed team. I do not believe there is any need to change the time parameters.  However, both of these statements are true only if the team stays engaged and the Scrum Master provides active facilitation.  The single biggest hurdle when a distributed team is involved in planning is keeping everyone engaged.

Visualization is a powerful tool to help foster engagement.  There are two types of visualization that are important.  The first and simplest is that all team members should be able to clearly see what is being discussed.  For example, I recently participated in an internal sprint planning meeting.  We used a screen sharing software that everyone on the team used.  As a story was discussed and planned, we brought it up on the screen so that everyone in the session could refer to the same set of words. Tasks, as they were identified, were typed directly into a shared document on the screen.  A second form of visualization relates to the team.  Use video on top of any screen sharing tools.  Seeing people as they discuss a point or talk about a story imparts significantly more information that just hearing them.  Think of how different the typical experience is when listening to radio compared to television.

IT personnel tend to be gadget and tool aficionados.  While a good tool for seeing the backlog or Kanban board is critical (emphasis on good, there are some re-purposed waterfall tools I would avoid like the plague . . . actually I might consider the plague first), the process needs to be simple enough that the set up time does not eclipse the planning time.  Tools like mind mapping software can be very useful to quickly capture and organize information. I personally use several including FreeMind (free and open source).  Another simple tool is Mountain Goat Software’s planning poker site at www.planningpoker.com.  I strongly suggest Scrum Masters (or coaches) walk through the tool suite they will use during planning before “going” live.  A simple check list of tools I use is:

  1. Screen Sharing Software: Tool examples include Webex or the like
  2. Video: Software examples include Skype Pro and OOvOO.
  3. Backlog/Kanban Boards: Examples include LeanKit, Kanbannery and Trello.
  4. Mind Mapping Tools: Examples include iTHoughts, FreeMind and Astah.
  5. Planning Poker Tool: www.planningpoker.com
  6. Egg timer (or sometimes the timer on my phone)
  7. DECENT PHONES

The last item is capitalized because all bets are off if team members can’t hear each other.

Once the team has gotten over the hurdle of using the communication tools, the final problem is one of facilitation.  The Scrum Master needs to facilitate the process with special emphasis on making sure everyone participates and stays engaged.  They also need to pay attention to pace.  I use an egg timer to remind everyone of both the overall time box and the time box needed for planning each unit of work.

In distributed Agile, the planning process does not change.  However, keeping everyone engaged might be more difficult. The Scrum Master can make engagement more likely by making the process as easy as possible and making the process as personal as possible.  Planning is still a whole team sport, make sure that the whole team participates, no matter where they are.

Distributed Team Degree of Difficulty Matrix

Distributed Team Degree of Difficulty Matrix

Distributed teams come in many flavors.  Distributed teams can be spread across floors, buildings, cities, time zones and/or nations. The term “distributed” evokes distance, but it is important to note that a distributed team can be housed within the same building but work apart.  An example of this type of distributed behavior can be seen when team members call into stand-up meetings from their cubes. As discussed in Distributed Agile: Cultures, the team, organization and national cultures contribute to the degree of difficulty when working with distributed teams.  Knowing where a team fits in the ‘Distributed Team Degree of Difficulty Matrix’ provides a means to decide if the effort required to make the team work out weights the benefits.

As distribution and cultural diversity increase, the time needed to ensure proper communication increases.  While techniques such as Agile chartering, which establish team norms and rephrasing agreements, don’t require a lot of effort they still add overhead to the development process.  Most distributed teams leverage software tools to create an effective communication environment.  For example, I use an online Kanban tool to manage my writing and podcasting efforts with co-contributors. Tool use requires an investment of money to buy or license the tool and effort to learn and maintain the tool. In a perfect world, that time would not be needed and rather it would be spent to develop and deliver functionality. Whether a distributed team has to learn a new technique or how to use a new tool, the impact is not instantaneous. Until the team gets over the learning curve they will be less effective than a non-distributed team.  Distributed teams require additional communication overhead to create and maintain a well-oiled distributed team.

Balancing the cost of distributed teams are the benefits. They include the ability to create teams with skills that can’t be developed quickly, leveraging team members in different locations lets organizations recruit more broadly, allows organizations to lower the salary profile of their IT department and when outside firms are used, it allows firms a mechanism to defray staffing risks across the economic cycle.  The benefits of outsourcing and distributed IT have been described in multiple publications such as The Benefits of Outsourcing IT. While we might argue about some of the benefits ascribed to distributed teams, their popularity suggests that CIOs and CFOs perceive that there are benefits.

Distributed teams are a fact of life in many IT organizations. The ‘Distributed Team Degree of Difficulty Matrix’ provides a mechanism to quickly visualize the degree of difficulty a team will face as they develop functionality.  The more distributed and cultural diverse a team is, the higher the communication overhead that is required for a distributed team to be effective.  Also more distributed and diverse teams will require more time to learn how to communicate so they reach their maximum effectiveness.  The matrix helps us predict team needs and behavior so we can tune processes, techniques and coaching to get them up to speed as quickly as possible.

Teamwork means pulling in the same direction!

Teamwork means pulling in the same direction!

Distributed Agile teams can be afflicted by a number of procedural issues that can impact the effectiveness of a team. While the root cause of most of procedural issues is either communication or culture (or both), in some cases it is expeditious to solve the current symptom then to circle back and tackle the potentially larger problem. There are no problems that, with a bit of creativity, a team can’t solve. Three relatively common procedural problems that distributed Agile teams encounter include: the failure of face-to-face communication methods due to scaling, workload imbalances between members and location-related status. Teams with any of these issues that don’t deal with them quickly will have major delivery issues.

Distance is one of the twin banes of intimate communication (culture is the other) as we have described in past Daily Process Thoughts. Distributed Agile teams with communication problems will fail, or at least will be horribly inefficient.  The majority of Agile techniques work best when team members communicate directly with each other either individually or in group sessions. As noted in Distributed Agile: Communication, communication is a major challenge in distributed Agile. When an organization wants to use Agile techniques, but can’t use the most efficient mechanisms for communization, their choices range from throwing up their hands and not using Agile to an equally controversial approach of using some paper-based communications tools to supplement face-to-face strategies or near face-to-face, like video or teleconferencing. Most practitioners of Agile have a significant aversion to documentation of any sort.  An example of how one very distributed team I observed (seven team members each in a different country and only two in the same time zone) solved the problem was to use multiple communication techniques. The team used a combination of diagraming, published notes/meeting minutes and an occasional video to capture decisions.  This solution also allowed team members that were struggling with accents or language to consume team interactions in multiple ways. In the team’s opinion, they adopted an approach that created just enough documentation to help them work (and they really liked doing the videos).

Everyone on a team is expected to pull their own weight.  Agile teams are no different.  Workload imbalances will cause bottlenecks and animosity between members (listen for comments like “why do I have to do everything?”).  Workload balancing on distributed Agile teams is complicated by distance and the probability that work is offset by time (India is starting when Los Angeles is ending their day). The complexity of the work flow requires that everyone pay close attention in daily standups as tasks are taken and completed so everyone stays on task.  As a self-managing team, all team members need to coach their peers to stay involved, even if their personal specialty (e.g. testing or architecture) is not needed at full capacity. Scrum Masters or coaches should help make sure all team members understand their role in managing the team and point it out if workload seems to be unbalanced. Techniques for visually tracking the flow of work, such as Kanban, are effective means of monitoring the balance of work across the team. Teams ignore imbalances at their own risk.

A final example of a practice that can harm a distributed Agile team is when a team falls prey to location status bias.  Location status bias is when members in remote locations are treated like “helpers” or second-class team members. It is very difficult to develop a team with esprit de corps if some members are treated like “helpers.”  This is important because if a team does not pull together and in the same direction they will not deliver as much value as possible. Coaches and Scrum Masters must spend time ensuring that team members view fellow team members as valuable and as equals. Start by taking the time needed to make sure that team members get to know each other. Try to get people physically together, or try virtual team events/games that require cooperative efforts between team locations. Another idea is to develop an Agile team charter that includes explicit statements on team norms and values. Statements of values and norms developed by the team give the team a tool to police their own behavior. Distributed Agile teams that have two classes of membership will quickly evolve into separate camps that will find it hard to work together.

The three common procedural problems that distributed Agile teams can experience will cause significant problems if they are not addressed. On a positive note, each of these issues can be solved through active coaching. Start by holding a team retrospective. One of the nice things about retrospectives is that you do not have to wait for the end of sprint (or the end of anything). Take an hour or two and start by getting the team to talk about the problems.  If you are facilitating the impromptu retrospective, help the team move from talking to finding a potential solution that they can execute. Have the team try the solution and then reconvene, discuss and refine.  Teams rarely run into an intractable problem if they are allowed to solve the problem themselves, but if they do, then is the time to seek outside help. Start by trying to solve the problem rather than getting someone else to solve it for you.

Even carousels are affected by different cultures.

Even carousels are affected by different cultures.

Cultural differences between members of distributed teams can substantially impact productivity and degree of difficulty. Therefore having a common way to talk about the impact of culture can help a team work as single unit. A model of culture that I have found useful in coaching teams is the Hofstede’s cultural dimension theory. Hofstede’s theory uses a set of dimensions that have measurable impacts on behavior. Hofstede’s dimensions include: individualism, power distance, certainty, achievement and time orientation.  Using these dimensions can be helpful by providing that common language. The descriptions below of each of the dimensions will help frame how we use the word culture.

Individualism describes the degree to which decisions are made that benefit the whole team versus the individual.  Agile teams make use of collective techniques such as swarming (I help you and you help me) to the work in order to get it done.  Other techniques, like sprint planning, leverage group-think techniques, which again, are collective behaviors. Team members from individualistic cultures might have difficulty adopting these types of Agile techniques.

Power distance describes the difference between a hierarchical and participative management structure.  Agile teams encourage participation through self-organization and self-management.  Cultures that value a more hierarchical orientation will view the participative management styles of Agile teams as ineffective. As a result, they will tend to seek out a strong leader, which can lead to non-Agile behaviors.

The certainty dimension describes the dichotomy between the need for firm conviction and ambiguity. Agile techniques, while disciplined, require a degree of comfort with more fluid scenarios where planning, re-planning and communication are required. Cultures that prefer structure, rules and certainty will need coaching as they begin using Agile frameworks, or they tend wander off task.

Achievement discusses the continuum between goal orientation and quality of life. Agile tries to balance the two by coupling the value of a sustainable pace with the the use of time boxes and public commitments. Mixing teams with members that are polar opposites on this dimension will create tension as commitment of work within time boxes pulls against the concept of a sustainable pace and quality of life.

The time dimension represents the dichotomy between a long-term and short-term orientation.  Agile techniques use of time boxes to artificially force a short-term view for a project, which can be at odds with how some cultures want to approach projects. Release plans can provide team members longer-term orientation that can meet some of the cultural needs of this dimension.

How can we leverage an understanding of culture to make distributed Agile teams work together better?  Start by finding a mechanism (or mechanisms) to create interaction so that team members can get to know each other at work and on a personal level, while learning about their cultural differences. Make sure everyone is trained on the type of Agile the project will use.  Do not assume that all team members will have the same experiences and interpretations of Agile. A team that understands how it will is going to work will be better positioned to recognized the remaining differences and address them. Discuss topics like leadership to ensure that everyone understands the concept and how the team will deal with it. Repeat those discussions as needed for other sticky topics. While cultural differences can occur with co-located teams, distance only exasperates cultural issues. It also makes them more difficult to spot until they are real problems.  The only way to mitigate cultural issues is to actively take steps to look for them and take action. Talk, listen, repeat and re-phase; test that communication is actually occurring.

 

Not everyone is on the same team!

Not everyone is on the same team!

I was recently reading the web and ran across a set of eleven characteristics of an effective team that were being referenced for Engineering: Leadership of Technology Ventures, a course at Stanford University in 2013. The material is a synthesis of two sources, The Human Side of Enterprise and The Wisdom of Teams[1]. It provides a framework that you could use to evolve or appraise teams. It focuses on a few specific characteristics that drive effective human behavior.  As with any model, this model is an abstraction and its power is to cut through the noise of behavior and provide guidance on how we should act. If we accept these as the characteristics of effective teams, then we can use this model to understand whether a distributed team can be truly effective.

Based on the distributed teams that I have appraised or interacted with, all of the characteristics of an effective team would also be important for a distributed Agile team. However, some of the characteristics are more difficult for distributed teams to perform.

Characteristics of Effective Teams

Distributed

 

Distributed:

Multiple Companies

There is a clear unity of purpose.

NP

SW

The group is self-conscious about its own operations.

SW

SW

The group has set clear and demanding performance goals.

NP

NP

The atmosphere tends to be informal, comfortable, relaxed.

SW

SW

There is a lot of discussion in which virtually everyone participates.

SW

SW

People are free in expressing their feelings as well as their ideas.

NP

MM

There is disagreement and this is viewed as good.

NP

NP

Most decisions are made at a point where there is general agreement.

SW

SW

Each individual carries his or her own weight.

NP

SW

Criticism is frequent, frank and relatively comfortable.

SW

MM

The leadership of the group shifts from time to time.

NP

MM

NP – No problem

SW – Some what harder

MM- Much more difficult

Inefficiencies of communication, differences in culture and geographic distance all impact distributed Agile teams.  All three of these attributes are interrelated and reinforcing.  These common attributes affecting distributed Agile teams don’t negate any of the eleven characteristics above, but some of these characteristics become more difficult to attain. For example, freely sharing criticism can be more difficult if the various cultures of the team members don’t find that type of sharing comfortable. In scenarios where communication is harder (for example finding meeting times across time zones) or less personal (teleconferencing versus video-conferencing) it will more difficult to connect, collaborate or share.

Helping Agile teams reflect the characteristics of effective teams becomes more difficult when the team’s composition includes multiple organizations. Teams that are comprised of multiple organizations often have different primary business objectives given that each organization will have its own culture and goals. This reduces effectiveness as team members pull in different directions. A classic example of this scenario can be seen when someone in a rowing crew is “off”.  Secondly, as noted above, cultural difference can make it difficult to express feelings and ideas or provide criticism among team members. This reduces the impact of retrospectives. When individual contractors are layered into teams, the contractor will feel that they have lower positional power, which can put them in danger of not getting additional work if they share their feelings honestly.

Scrum Masters, Agile coaches and organizational leaders need to create environments in which teams can be effective.  Each team should begin by making sure the team has one well-understood goal (consider Agile chartering). The organization must ensure that every team has the tools to communicate and the support to use those tools. Where multiple companies are supplying the personnel for an Agile team, the senior leadership of each company must ensure that the team members feel safe within the Agile team’s boundaries (much akin to the saying “What happens in Vegas, stays in Vegas”).   The same eleven characteristics of an effective team can be used to help guide or judge both co-located teams and distributed teams. The degree of distribution and cultural diversity makes performing to these characteristics harder, but not impossible.


[1] Sources: The Human Side of Enterprise, by Douglas MacGregor, McGraw Hill Professional, 2005, 256 p.  and The Wisdom of Teams, by Kaztenbach and Smith, HarperBusiness Essentials, 2003, 320 p

The phone many times is the communication tool of choice!

The phone many times is the communication tool of choice!

There are many challenges for distributed Agile, however one stands head and shoulders above them all – communication. At a recent speaking engagement, I asked the audience to write down three problems they were having related to distributed Agile. Communication was most commonly mentioned problem with approximately 60% of the responses. Finding solutions to the communication problems that plague distributed Agile teams is critical. Some that have been tried (and work to a greater or less extent) range from low tech (get up and walk across the building to talk to someone), moderate tech (video or telecommunications) to high tech (collaboration tools). The method is less important than the fact that each team member must understand the additional communication responsibilities that are required when working with remote team members.

There are several low-tech approaches that teams can use to stay connected and pass information amongst the team members.  When team members are in the same neighborhood (different floors, different parts of a building or separate buildings on a campus), standing up and walking over in order to talk face-to-face is more effective than sending an email. However, team distribution makes some of the most effective low-tech Agile tools less effective.  For example, card walls or paper Kanban boards don’t work well if everyone on the team can’t see them. Therefore, you will need to use other techniques. Once upon a time, video conferencing was just science fiction.  Today almost every laptop has a video camera and tools like Skype make connecting computer-to-computer free. Video makes communication personal.  It is easier to know someone if you can see them.  Another benefit to using video is that it shows a person’s face, which increases the amount of data passed during a conversation AND more importantly it tends to keep participants off their cell phones and email. Widely distributed teams will face time-zone challenges that require hardcore scheduling. Standard meetings (e.g. stand-up, sprint planning, retrospectives and demos) need to be scheduled to ensure everyone can participate (I use Doodle, but paper and pencil can work too). Other low-tech communication tools that many organizations use include end-of-day calls or notes to synchronize activities among the team members in different time zones.

High-tech tools and high price tags usually go together, which keeps some organizations from using commercially available tools. One high-tech tool that is purely oriented to communications is tele-presence. Tele-presence is like sitting across the table from your colleagues. It is video conferencing on steroids, lots of lights, lots of cameras and lots of electricity (therefore pricey). I have used facilities of this type and frankly they are better than high-end video conferencing. Tele-presence is almost as good as being in person. Given the expense, I doubt a typical Agile team would ever have on-demand access to tele-presence, but if you get a chance, try it.  Other high-tech tools typically combine collaboration tools and Agile project management features. Agile collaboration tools try to recreate the low tech tools (white boards, sticky notes and burn-down charts) so they be taken advantage of in a distributed Agile environment. I have used many Agile tools, examples include tools by Computer Associates, Rally and VersionOne, LeanKit Kanban and Kanbanery. All of these tools keep teams focused on the goal at hand though sharing information. Some commercial tools integrate video and teleconferencing along with wikis, task lists, scheduling, status tracking and reporting components. The problem is that none of these tools are as effective as an in-person team, but they are generally a lot better than the alternative of trying use repurposed waterfall tools or no tools at all. Tools that keep project information in one place make it easier for distributed groups work together.

Communication is best face-to-face with communications occurring not only through words, but also through facial expression and body language. Unfortunately, it isn’t always feasible. Distributed teams need to take steps to make communication as intimate as possible.  The best distributed teams use combinations of tools rather than to fixate on one. [WHAT DOES THIS MEAN?] They use the tools that are the least complicated, and that best fit each communication scenario. For example, combine standard meeting times (rotate the times, so no one always has to deal with the time zone pain) with videoconferencing and tool-based card walls to share stories and tasks. Finally, talk to each other as much as possible and as much as makes sense.