One of the reasons I think Agile practices are successful is their handling of the requirements and planning phases of a project. Or more correctly, just doing away with it on a grand scale and dealing with them on small, manageable scale. Until Gojko Adzic’s Bridging the Communications Gap I hadn’t had anything more than just my own anecdotes and experiences to back it up.

But the how discussed isn’t nearly as important as the why which is the main point of the book. In Gojko’s view, the reason for most project failures is a breakdown in communication between stakeholders and the development team.

Involving developers and testers from the start, communicating business goal to everyone and removing communication obstacles is the way we can take control of projects, and not leave success or failure to pure chance

Using that as a springboard he explains how to achieve the communications breakthrough and resulting project success through the creation of Agile Acceptance Tests during Specification Workshop(s) which take place at the beginning of each iteration. Both of those topics are discussed at length and I can see teams starting to implement both practices based on the book’s content.

Parallel to this is another thread around communication between stakeholders which I think is even more important than acceptance testing and specifications workshops. It is also one that could be applied by groups still in a rigid Waterfall or Wagile environment.

Describing how and what but not why left the success of the project to pure chance.

This was the big take-away for me, especially given what I have been doing at work recently. People following me on twitter have seen be complain about JQuery and widgets over the last couple weeks. That is because we had a widget produced for us by an outside company, and they delivered exactly what we asked for (or what I think we asked for at any rate). However, it does not do it in a way that lets us achieve our long-term goals for the product so I’ve had to engineer some major infrastructure into the codebase to allow to easy per-client customization. I don’t blame them, I blame us for that as it was the communications gap that caused it. Had we done a better job explaining the why of the project and its business need I think the project would have turned out quite different. (Though I wouldn’t have learned JQuery — which wouldn’t have been so bad now that I think about it.)

Bridging the Communications Gap is not a perfect book though. Parts 1 and 2 were excellent and I found lots of interesting material in them, but Part 3 I blew through in a couple minutes. If you have a bit of exposure to Agile planning will also likely be able to skim through it, but I can see how their might be value to someone completely new to Agile. Part 4 explains the pros and cons of acceptance testing from the perspective of business analysts, testers and developers and seemed a bit long. The content was basically a rephrase of parts 1 and 2 but aimed at each audience so one sentence would have been enough instead of a couple paragraphs per point.

I’ll admit to not having read many books on trying to tackle the Requirements Problem which I now see as the Communications Problem. I’ve been dealing with requirements for almost 11 years now from a testing perspective and the approaches and concepts presented in Bridging the Communications Gap are the best I have seen with trying to rein in this beast. I’ve recommended it to two people I’ve taught so far and if you find you are having issues determining or delivering what the customer really wanted, I recommend it to you too.