BlogsComputerworld Archive
Computerworld UK Archive
Bridging the Communication Gap
Published 15:42, 04 January 09
Gojko Adzic is one of those guys who leads an enviable life, being darn good at what he enjoys doing, getting paid to do it, and still finding time to share his amazing range of knowledge with the rest of us via his website, his open source projects, his free seminars, and now his new book. Just released and available both as a paperback and as a PDF, "Bridging the Communication Gap" is certain to be a 'must read' for all those working on agile teams trying to improve the way the technical and non-technical roles interact.
I was honoured to be a reviewer during the production of the book, although I can take no credit for the excellent end result. One of the interesting decisions Gojko made was to change the working title from the original of "Agile Acceptance Testing", and move this to the subtitle. I wondered if in doing so he would miss the opportunity to grab the attention of his primary target audience. His response was that the more he wrote, the more he felt that the issues he was encountering and resolving on agile teams were not about testers, not about tooling, not about techniques, but about how well a team is able to reach common understanding and communicate freely about requirements, design and acceptable quality.
His concern was that if he kept "Testing" in the title, it would not get read by team members who were not primarily testers, and he felt that mental 'not-my-job' separation in a team was precisely the problem he was trying to overcome with this book.
I think it is an entirely valid point. I have been saying for some time on my training courses that agile quality is a whole-team responsibility. I have been lucky to work in and to coach successful agile teams where all team members fully embrace the notion of being test-driven, at all levels. Ironically, problems can occur on teams that have specialist "agile testers" assigned to them. This is not because of anything these testers are doing wrong or inadequately, but because having certain team members 'labelled' as testers tends to create a feeling that testers test and hence non-testers don't test. This is bad logic and a bad outcome for the team. I prefer agile team members to leave their labels at the door, and remember that everyone in the team shares a common goal of delivering quality software to the satisfaction of their Customer.
Print
Email
