The Ambysoft 2008 Agile Principles and Practices survey explored the effectiveness of communication strategies between developers within an agile software development team and between team members and stakeholders.  The results are summarized below (+5 most effective, -5 least effective)

Table 1.  Effectiveness of communication strategies on agile development teams.

So what should I use?

You have several communication options available to you and which communication tool you use will vary depending on what is most effective at that time. Underpinning the communication is trust. The trust factor should not be underestimated as the communication will be effective only when all the parties involved trust what the others are saying.

Effective communication also comes down to the proper communication opportunities being provided to the team apart from simply using tools on an ad hoc basis. Based on our experience, we have listed some of the best practices which have boosted our communication effectiveness.

1. Wikis

We love Wikis because they are easy to use and the information structure can evolve with time to suit the project. It is recommended to assign one team member to act as an organiser of the Wiki to structure the information as it grows. Common information such as story cards, designs, burn down charts or anything else that would be useful for all team members to see can be put there.

2. Short Iterations and Regular Builds

At VeriQual we tend to prefer one or two weeks sprints. For larger projects, a 4 week sprint may be suitable; however, we tend to prefer shorter cycles to provide greater clarity.

On an agile project the customer needs to monitor progress frequently and spot misunderstandings quickly. Regular integrated builds allow the customer to look at what’s built regularly, even if it’s only partial functionality. The short feedback loop means that a customer can spot any miscommunication quicker and remedy it.

Demos of the working software can be given online and we recommend using one or more of the tools below to accomplish this:

http://www.dimdim.com/
http://www.teamviewer.com/index.aspx
http://webvideocall.oovoo.com

3. Status (Scrum) Meetings

Agile promotes short (15 minute) stand up meetings. In the context of an offshore team this may mean using a video conferencing or voice chat tool to have short meetings to discuss three main things:

1. What was done yesterday;
2. What will be done today; and
3. What are the roadblocks in achieving today’s task.

A lot of flexibility is required from both sides with regard to time zones and sometimes we end up having meetings at midnight, but we prefer this over not talking to clients for lengthy periods. With UK the time zone issue is less prominent, however with US clients, a 10 – 12 hour time difference means the client as well as the offshore team have to be flexible and understanding.

4. Sprint planning meetings

We ask our customers to send the user stories to us by email or on wikis. We then work to turn the user stories into tickets in a ticketing system like TRAC with the Agilo plugin. The tasks are viewable by our client and as the Product Owner, it is his/her responsibility to assign a business value and status such as blocker, critical etc to each ticket.

During the sprint planning meeting we go through the tickets and update as necessary based on the client feedback. We try to keep the meetings to a manageable time limit but it usual for Sprint Planning meetings to run to a couple of hours.

5. Many to many communication is preferable

Email has its benefits but also many pitfalls. Instead of person-to-person try to broadcast to mailing lists or preferably maintain a history of the communication using tools like Campfire. When communication becomes searchable and gets context it is enables teams to share information across domains and promotes them to become responsible for everything, not just their bit of the code.

6. User Stories

Keep user stories short – elaborate on them during the sprint planning meeting, but keep the clutter to a minimum by focusing on what is important, not what might be useful to know.
Consistent vocabulary – It is very important to develop a standard vocabulary for the basic building blocks of your project. A “comment” may be confused with a “review” but may mean completely different things in the content of your application.

7. Documentation

The following is a list of important points about documentation and when to use it:

1. The fundamental issue is communication, not documentation.
2. Use documentation where there is no better way to communicate your points.
3. Document things when they are stable, not fluid.
4. Don’t document in isolation. Seek feedback and use collaborative tools such as Google Documents to evolve the document collaboratively.
5. Code and test scripts are preferable to documents.
6. Keep documents concise.
7. The benefit of having documentation must be greater than the cost of creating and maintaining it.
8. Document because you need it, not because you want it.

8. Summary

Best Practices

• Daily conference calls
• Use of issue tracking application
• Use of IM with accurate status
• Desktop sharing applications
• Document sharing applications
• Short iteration cycles
• Frequent builds
• Concise user stories
• Standard vocabulary

Fundamentals

• Commitment to good communication
• Collective ownership
• Knowing where to find information
• Understanding expectations
• Transparency

References

http://www.ambysoft.com/surveys/practicesPrinciples2008.html

http://www.agilemodeling.com/essays/communication.htm

www.thoughtworks.com

Calm morning

Cricket at the beach

Beautiful

]]> http://www.veriqual.com/blog/2009/06/out-with-the-boys-in-lahore/feed/ 0 http://www.veriqual.com/blog/2009/06/welcome-to-the-new-site/ http://www.veriqual.com/blog/2009/06/welcome-to-the-new-site/#comments Tue, 23 Jun 2009 10:17:46 +0000 admin http://www.veriqual.com/blog/?p=10 Even though we build sites and applications for our clients, we haven’t been able to give time to update our own site for far too long. We resolved at the start of the year, our fifth year in operation, to do something about it. It still took four months to get around to it though!