The scrum team I work with – like the company that I am part of – is globally distributed.  We have coders and testers spread across offices in Europe and South America as well as in our home office in the US.  This means that our daily scrums involve video calls linking the team members and our work progress each day requires frequent contacts among the team members to make sure we are making meaningful progress toward our sprint goals every day.  It also means that we are working with team members with different native languages – adding another level of complexity to some of our conversations.

All of this makes clear communication crucial.  When we don’t make the effort to ensure that we accurately express our plans and questions and that we fully comprehend the answers and explanations of others, we end up facing the dilemma illustrated here: http://www.youtube.com/watch?v=OdKa9bXVinE

These kinds of communication problems can happen even in teams that sit together all the time, but globally and linguistically diverse teams can fall more easily into communication problems.  So what steps can I take as a product owner to make sure our team communication is clear?  Here are a few things that I am working to do that seem to be helpful:

1. Daily scrums.  For those already working in an Agile Scrum methodology this may seem like a given, but I cannot overstate the value of taking 15 minutes at the start of each day to touch base on the previous day’s accomplishments, the current day’s plans, and any impediments to moving forward.  These daily meetings also help foster a sense of team cohesion that facilitates tackling any issues that the team faces.  Having worked before in software development firms using a waterfall approach that relied on only periodic check points, I see exponentially more value in having this daily connection for the coders, testers, and product owner.
2. User stories. Here’s an area where I am growing (maybe I’ll even blog more about this in the future), but I already see its importance in fostering clear communication.  Stating requirements and expectations in story form (for example, ‘A client needs to enter financial projection data for several business units’ or ‘An internal accountant needs to run a monthly report on required journal entries’) has two advantages over a more formal requirements document.  First of all it describes the desired outcome in a way that invites more conversation where needed; and second it allows coders the freedom to find the best way to solve the problem since the story focuses on the what rather than the how of the requirements.  As anyone who has been reading this blog knows, I find stories a great way to communicate content, which is why my posts link back to stories from other places rather than simply standing alone as abstract ideas or how-to lists.  I’m still learning about the best way to craft user stories, but so far I like the approach and hope to get better at it.
3. Iterative testing.  Having coders and testers work together on new features, or testers and the product owner regularly reviewing progress during the scrum, or the product owner meeting with testers and coders to define feature specifications – all of these focused conversations promote the kind of deep communication that leads to more successful development.  Iterative testing – where features and bug fixes are shown to testers and the product owner not simply at the end of a development cycle but at frequent intervals during the process – allow for quick course corrections and helpful clarifications about exactly what is expected from the development process.  Of course, doing this well means that I have to be very available as a product owner so that I can spend regular time on the phone, at a computer screen or white board, and in conversations with members of the sprint team.
4. Sprint retrospectives.  Good communication isn’t just valuable during a sprint; wrapping up each development cycle with a debrief session allows the team to talk together about how they communicated and where they can improve.  Evaluating the quality, relevance, frequency, and accuracy of the communication as part of a retrospective encourages growth in this area and makes the whole team stronger as they continue working together.

There are of course many other techniques to ensuring clear communication on sprint teams.  The solution starts with making clear communication a top priority and then doing whatever it takes to strengthen that communication.  In the busy world of regular sprints and active client support, however, you can quickly find that in truth it’s not that simple.