Agile methods were originally intended for small co-located teams. Can they work for geographically distributed teams? In fact, due to the challenges of working with distributed teams, I believe the fast feedback and validation afforded by agile methods provide a distinct advantage for distributed teams because problems are found sooner. I have experienced great success with teams split between the US, India and China. In this post I share some tips on making distributed agile teams succeed.
For a more in-depth treatment of this topic, see my presentation on Distributed & Offshore Agile Teams.
1. Prepare your collaboration infrastructure
You may need phone, web, & video conferencing, wiki/intranet, source control, VPN, remote desktop tools, SFTP for large file transfer, testing and integration environments, and project management software. Obtain high quality full-duplex speaker phones, headsets, and webcams.
2. Have an agile coach or agile champion at each location
In addition to providing agile training to every team member, you want ongoing guidance at each location from an experienced agile practitioner who can establish an effective team culture.
3. Be extra disciplined in your technical practices
The technical practices from XP (pair programming, TDD, refactoring, continuous integration, coding standard, simple design) are fundamental for any high-performing agile team, but when people are scattered across the globe, they become even more important. These practices ensure that quality is built in from the start, they enable knowledge sharing, and ensure rapid feedback.
4. Do cross-location travel throughout the project
Get the entire team together in one location at the beginning of the project and again at each release. Establish a rotating travel schedule so each team member visits another location for 1-2 iterations. This face time will reap big returns in establishing trust, sharing knowledge, and maintaining an effective team culture.
5. Maximize opportunities for real-time communication and collaboration
Even with a time zone difference, find at least a few hours every day when all team members are available by IM & phone for real-time communication. Share time zone burdens fairly between locations. Hold daily stand-ups and iteration planning meetings with the entire team using video and web conferencing. Many studies have shown that the majority of information shared in a conversation is non-verbal, so use video chat & conferencing often. Google, Yahoo and Skype offer free 2-way video, and Paltalk has free video for up to 10 parties. Webex and many other commerical services offer multi-party video conferencing.
6. Facilitate cross-cultural communication: speak slowly, avoid jargon and idioms
If your team members don't all share the same primary language and culture, be sure that everyone speaks slowly and avoid using jargon, idioms or expressions - they usually don't translate well. Announce your name each time you speak on a conference call: "This is Sally..." Start each meeting with a virtual seating chart as described by Jean Tabaka in her book Collaboration Explained. Appoint a facilitator to ensure each meeting is effective.
7. Find effective, lightweight tools for distributed collaboration
Intranets, wikis and source control systems allow easy information sharing. Virtual white boards such as scriblink, skrbl, and dabbleboard enable remote collaboration. Many web conferencing systems such as ReadyTalk have drawing tools allowing free-form annotation of a shared screen. Instant messaging supports both one-on-one and group chat. VNC, remote desktop and similar tools even allow cross-continent pair programming. For iteration planning and task tracking, share photos or video of your physical task board, or make the leap to an electronic tool. There are numerous open source agile tools plus commercial tools, most with trial or free editions, but choose a lightweight tool unless you truly need the more advanced features.
Wednesday, August 19, 2009
Monday, August 17, 2009
Eight tips for better retrospectives
I am often surprised at how many self-described agile teams don't hold retrospective meetings every iteration. For those team that do hold retrospectives, I often find they have a lot of room for making them more effective. An attitude of continuous improvement is fundamental to successful teams, and the retrospective is the primary mechanism for improving, so it follows that effective retrospectives are one of the key elements of a good agile team.
In this post, I offer five tips on how to conduct more effective retrospectives.
1. Review notes & actions from the previous retrospective
This is step #1 in the retrospective, which of course implies that you must first record notes from your retrospective meetings. (See tip #8) Use a projector to display notes & action items from the past meeting. Keep it short - five minutes at most. If you have remote team members, use a webinar and/or video conferencing so everyone sees the same screen. If you find your team bringing up the same problems as in previous iterations, ask why - five whys, actually (see tip #5).
2. Ask what problems, successes and opportunities you have with the team, the product, and the process
The facilitator will ask the team, "What did we learn about the team, the product, and the process? What were our problems, successes and opportunities to further optimize?" Capture these items in a grid as shown below. Use a white board if everyone is in the same room, or take notes in a wiki or other electronic document - preferably the same one you'll use to archive your retrospective notes (See tip #8).
3. Let each team member speak without discussion
The facilitator gives each team member the opportunity to speak without any group discussion; no one else is allowed to comment on anyone's opinion - yet. Only clarifying questions are allowed at this time. Discussion will come later when the team is discovering the root causes of problems. (See tip #5)
4. Vote on the most important items to take action on
You may not be able to immediately address every concern raised in the meeting, but you certainly need to prioritize them. Every team member is allowed to vote for 3 items that he/she believes are most important to take action on. Tally the votes and add the items to your process improvement backlog based on priority. Note that some items may not require any further action. Even successes may need action however; for example, a good pattern or practice may need to be documented in the Definition of Done or added to the coding standard.
5. Use "five whys" to discover the root cause of problems
For each of the highest-priority problems identified, the facilitator will ask "why did that happen?" Once an answer is given, ask the same question again, repeating the process five times. This should lead you to the true root cause of the problem.
6. Create an action plan for your top priority items
For each top priority item, decide what to do, and who can do it - which may be more than one person. Any actions requiring work by team members should be planned and assigned during iteration planning. (See tip #7) Actions assigned to members outside the team must be coordinated and scheduled. Of course the action plans should address the root causes of problems, not just the symptoms.
7. Explicitly allocate time for improvement actions
Maintain a backlog of improvement actions. At each iteration planning, pull the top improvement actions into the iteration. Improvement items should be prioritized along with product backlog items based on overall value to the organization, but teams should reach an agreement with the product owner on a percentage of their time to be spent on improvements.
8. Record your retrospectives & actions
Maintain two artifacts: (1) a process improvement backlog and (2) retrospective notes. The notes may be captured in real-time during the meeting using a wiki, intranet, or other electronic document. Record just enough information to support a review at the next retrospective (tip #1). Appoint someone other than the facilitator to take notes. For the process improvement backlog you may use the same tool you use for product backlogs; this backlog can be owned by the scrum master.
In this post, I offer five tips on how to conduct more effective retrospectives.
1. Review notes & actions from the previous retrospective
This is step #1 in the retrospective, which of course implies that you must first record notes from your retrospective meetings. (See tip #8) Use a projector to display notes & action items from the past meeting. Keep it short - five minutes at most. If you have remote team members, use a webinar and/or video conferencing so everyone sees the same screen. If you find your team bringing up the same problems as in previous iterations, ask why - five whys, actually (see tip #5).
2. Ask what problems, successes and opportunities you have with the team, the product, and the process
The facilitator will ask the team, "What did we learn about the team, the product, and the process? What were our problems, successes and opportunities to further optimize?" Capture these items in a grid as shown below. Use a white board if everyone is in the same room, or take notes in a wiki or other electronic document - preferably the same one you'll use to archive your retrospective notes (See tip #8).
| Problems | Successes | Opportunities | |
| Team | |||
| Product | |||
| Process |
3. Let each team member speak without discussion
The facilitator gives each team member the opportunity to speak without any group discussion; no one else is allowed to comment on anyone's opinion - yet. Only clarifying questions are allowed at this time. Discussion will come later when the team is discovering the root causes of problems. (See tip #5)
4. Vote on the most important items to take action on
You may not be able to immediately address every concern raised in the meeting, but you certainly need to prioritize them. Every team member is allowed to vote for 3 items that he/she believes are most important to take action on. Tally the votes and add the items to your process improvement backlog based on priority. Note that some items may not require any further action. Even successes may need action however; for example, a good pattern or practice may need to be documented in the Definition of Done or added to the coding standard.
5. Use "five whys" to discover the root cause of problems
For each of the highest-priority problems identified, the facilitator will ask "why did that happen?" Once an answer is given, ask the same question again, repeating the process five times. This should lead you to the true root cause of the problem.
6. Create an action plan for your top priority items
For each top priority item, decide what to do, and who can do it - which may be more than one person. Any actions requiring work by team members should be planned and assigned during iteration planning. (See tip #7) Actions assigned to members outside the team must be coordinated and scheduled. Of course the action plans should address the root causes of problems, not just the symptoms.
7. Explicitly allocate time for improvement actions
Maintain a backlog of improvement actions. At each iteration planning, pull the top improvement actions into the iteration. Improvement items should be prioritized along with product backlog items based on overall value to the organization, but teams should reach an agreement with the product owner on a percentage of their time to be spent on improvements.
8. Record your retrospectives & actions
Maintain two artifacts: (1) a process improvement backlog and (2) retrospective notes. The notes may be captured in real-time during the meeting using a wiki, intranet, or other electronic document. Record just enough information to support a review at the next retrospective (tip #1). Appoint someone other than the facilitator to take notes. For the process improvement backlog you may use the same tool you use for product backlogs; this backlog can be owned by the scrum master.
Subscribe to:
Posts (Atom)
Posts
