January « 2010 « VeriQual

Archive for January, 2010

Effective Communication in Agile

Monday, January 25th, 2010

Agile development emphasises face-to-face communication in a single open environment. So what do we do when offshore teams are required for a project but we still want to work in the Agile mode?

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.

Communication Strategy	Within Team	With Stakeholders
Face to face (F2F)	4.25	4.06
F2F at Whiteboard	4.24	3.46
Overview diagrams	2.54	1.89
Online chat	2.10	0.15
Overview documentation	1.84	1.86
Teleconference calls	1.42	1.51
Videoconferencing	1.34	1.62
Email	1.08	1.32
Detailed Documentation	-0.34	0.16

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:

What was done yesterday;
What will be done today; and
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:

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