Single Point Of Contact (SPOC)
It is essential for your client to understand that Agile can deliver great results if one commits to the methodology. In this particular case, it means allocating one person to act as SPOC on their side, while you do the same on yours. Even if more resources are allocated, one person should always be accountable on each side regarding communication and reporting. This concept, however simple, is sometimes difficult to assimilate in organizations used to involve everyone in meetings. But remember, the idea here is not to limit communication, but to channel it. Knowing that one person is always available to answer questions or clarify doubts is invaluable, as it allows to eliminate waste in the form of delays and noise. It is this level of customer involvement that really fosters rapid design and development. Meetings can still have their place in the form of reviews and so forth, but they are not spontaneous happenings necessary to answer a question… Rather, meetings become specific gatherings to assess milestones — which is exactly what they should be.
While on Agile projects, I play the product owner role. Basically, once we understand the needs of our clients and state a vision for the project, I am accountable for deciding what we design and when, with the help of the whole team, naturally. I get to be our SPOC, and our clients assign one person on their side. SPOC’s are stipulated in contract, all communication is thus channeled, and eventually ends up in digital format, at our central repository and through e-mail. This way, everything is saved for backup or reuse.
That said, keep in mind that what may start as a funnel of communication can easily end up as a bottleneck if the information does not flow. If SPOC’s are not responsive enough, the project will suffer from it. So, it becomes critical to address such issues on time. After a mishap with a client that caused serious delays in project completion, we now set a 24h benchmark for information workflow. I would recommend to set your own benchmark upto an iteration’s length — definitely a clear sign that something is wrong.
Iteration demos
An iteration demo is a special communication where the product owner shows concrete proof of progress to the client. As their name implies, iteration demos happen at the end of every iteration. Since there is no need repeating everything that has been said before, these demos can be quite short, and simply present the state of the art.
As product owner, I like to keep this simple by reporting to the client’s SPOC through his preferred form of communication (meeting on location, web conferencing, e-mail) and facilitating a demo of the product so far — a wireframe, a mock-up, a live demo on a test server, etc. Other teams prefer to communicate to stakeholders, but I feel this somehow defeats the purpose of an SPOC. Your mileage may vary.
Just make sure that you ask the client if he is satisfied with the progress, so that you may address issues and plan future iterations accordingly.
That’s all, folks!
These are the only two forms of client communication we use, and things have been running smoothly on our projects. A demo of work done is real proof of progress, so there really is no need to write extensive litterature about it, to supply timesheets, and so on.