What do you think?
Rate this book
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
Bridging the Communication Gap is a book about improving communication between customers, business analysts, developers and testers on software projects, especially by using specification by example and agile acceptance testing. These two key emerging software development practices can significantly improve the chances of success of a software project. They ensure that all project participants speak the same language, and build a shared and consistent understanding of the domain. This leads to better specifications, flushes out incorrect assumptions and ensures that functional gaps are discovered before the development starts. With these practices in place you can build software that is genuinely fit for purpose.
284 pages, Paperback
First published January 5, 2009
74 people are currently reading
540 people want to read
About the author
Gojko Adzic
16 books153 followersGojko Adzic is a partner at Neuri Consulting LLP, winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko's book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.
Gojko is a frequent keynote speaker at leading software development conferences and one of the authors of MindMup and Narakeet.
Gojko is a frequent keynote speaker at leading software development conferences and one of the authors of MindMup and Narakeet.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 23 of 23 reviews
October 6, 2015
Recently I bought "Bridging the Communication Gap" written by Gojko Adzic. It is certainly a 'must read' for all those working on agile teams trying to deliver what the customer really wanted.
In Gojko’s view, the reason for most project failures is a breakdown in communication between the technical and non technical roles. The book shows how important and difficult it is for a team to reach common understanding and communicate about requirements, design and acceptance criteria.
Agile Acceptance Testing, the subtitle of the book, is not just for testers! In fact it affects all of our jobs starting with the customer and functional analyst. But everyone in the team must be involved in achieving Executable Specifications. This is done in Specification Workshops, which take place in the beginning of each iteration. These topics are discussed in depth in the book.
What I really like about this book is that teams can actually start implementing the practices based on the books content.
I’ve recommended the book too five people so far and if you are concerned about delivering what a customer really wanted, I recommend it to you too.
In Gojko’s view, the reason for most project failures is a breakdown in communication between the technical and non technical roles. The book shows how important and difficult it is for a team to reach common understanding and communicate about requirements, design and acceptance criteria.
Agile Acceptance Testing, the subtitle of the book, is not just for testers! In fact it affects all of our jobs starting with the customer and functional analyst. But everyone in the team must be involved in achieving Executable Specifications. This is done in Specification Workshops, which take place in the beginning of each iteration. These topics are discussed in depth in the book.
What I really like about this book is that teams can actually start implementing the practices based on the books content.
I’ve recommended the book too five people so far and if you are concerned about delivering what a customer really wanted, I recommend it to you too.
December 17, 2018
As an agile and technology instructor, I read quite a bit. The ideas and principles from this book find their way into almost every course I teach. At its core, all of our organizational fumbling in marching toward the realization of corporate goals is an exercise in communication. This book more than any other lays bare this idea while tending to all the "ya buts" we try to put in the way. Left with the clarity that communication is the gap, we can now get on with being effective in its use. If you're a developer, a leader or a project manager, do yourself and your teams a favor, read this book.
September 15, 2017
A good description of the problems that you can end up with when you can’t bridge the communication gab. I liked the introduction into BDD and using examples to describe what software should do. It’s not as technical as Specification by Example and therefore could work with the business side as well. I have read different books by Gojko but here I missed that surprising realisation the other books offered. Nevertheless, if you work in agile projects this book will be a great help.
March 20, 2018
The book cover topic of how to bridge the gap when analysing project requirements in a very comprehensive manner. The author writes on how different teams in different circumstances should deal with the issue and introduce acceptance tests/SBE to the project setup.
I liked the content quite a lot. Though I was expecting more examples. The book is a bit dry and you have to push your self through some long discussions sometime.
I liked the content quite a lot. Though I was expecting more examples. The book is a bit dry and you have to push your self through some long discussions sometime.
July 24, 2017
There is something interesting in reading books on the same topic in reverse order of their publication date.
Anyway, this book gives interesting insights on Specification by Example and AAT (as the title suggests). But you have to keep in mind that this book was written almost 10 years ago and the tooling and acceptance of these approaches/ideas changed too.
Anyway, this book gives interesting insights on Specification by Example and AAT (as the title suggests). But you have to keep in mind that this book was written almost 10 years ago and the tooling and acceptance of these approaches/ideas changed too.
August 25, 2020
As of 2020 a bit dated but most of the non tools specific nuggets are still valid. Many links do not work.
Good in most parts
Links do not work for the most part. Provides a good overview handle of why how and what of Acceptance Test driven development.
Good in most parts
Links do not work for the most part. Provides a good overview handle of why how and what of Acceptance Test driven development.
November 28, 2018
I couldn't get through it.
February 17, 2013
The core of this book is a simple concept – executable specification. Much has been said about how to write requirements. They should be specific, concise, they should not use negatives; in a word, they should be testable. Why not write your requirement as a test that can be executed?
This book provides suggestions on how to make that happen. The book discusses who should write the tests, how the tests should be written, how to gather the specification, how roles will change, the benefits to the project and parties concerned, and the tools that can help implement the specification.
There are several key concepts that a team must employ in order to attain project success with this approach. First, a team must get away from traditional requirements (e.g., ‘shall’ statements) and in favor of user stories. User stories should be understandable from the standpoint of business analysts, developers, and testers. Most importantly, they should be testable. Adzic discusses some methods of encouraging interested parties to discuss requirements of the system as tests. In brief, when a requirement is given, can the question be answered “how would you write that as a test?” I love this question. More than just asking someone “is this testable,” ask them “how would you test this?” Clients should have some notion of how they will be able to tell if the software they asked for works the way they expect, which makes this a great question to ask. Some clients don’t like to talk in terms of tests and Adzic offers some suggestions of alternative language.
Another excellent concept in the book is the use of examples in the specification. We all know how specifications can become convoluted. When this happens, the book suggests asking “Isn’t this a great time for an example?” Examples are testable, realistic, and can easily be communicated to all members of a team. As a tester, I would only be too happy to have more examples of how a piece of software is supposed to be used.
Another concept in the book is the practice of specification workshops. When discussing this, Adzic encourages having a specification workshop meet regularly with all parties present. When specification is made early and members don’t meet regularly, gaps form between what developers, testers, and clients understand to be the function of the software. To help facilitate this, a common language needs to be developed that is consistent between all groups. The language must evolve and be well defined for all members of the team.
I like the concepts that the book discusses and could probably apply them easily. Getting clients to buy into this method of working will be more challenging. For some clients, it will be most difficult to stop beating the old, dead horse of traditional requirements. For other clients, the challenge will be providing regular feedback, instead of being available only once every two months with sparse feedback. But, that is something to work for.
This book provides suggestions on how to make that happen. The book discusses who should write the tests, how the tests should be written, how to gather the specification, how roles will change, the benefits to the project and parties concerned, and the tools that can help implement the specification.
There are several key concepts that a team must employ in order to attain project success with this approach. First, a team must get away from traditional requirements (e.g., ‘shall’ statements) and in favor of user stories. User stories should be understandable from the standpoint of business analysts, developers, and testers. Most importantly, they should be testable. Adzic discusses some methods of encouraging interested parties to discuss requirements of the system as tests. In brief, when a requirement is given, can the question be answered “how would you write that as a test?” I love this question. More than just asking someone “is this testable,” ask them “how would you test this?” Clients should have some notion of how they will be able to tell if the software they asked for works the way they expect, which makes this a great question to ask. Some clients don’t like to talk in terms of tests and Adzic offers some suggestions of alternative language.
Another excellent concept in the book is the use of examples in the specification. We all know how specifications can become convoluted. When this happens, the book suggests asking “Isn’t this a great time for an example?” Examples are testable, realistic, and can easily be communicated to all members of a team. As a tester, I would only be too happy to have more examples of how a piece of software is supposed to be used.
Another concept in the book is the practice of specification workshops. When discussing this, Adzic encourages having a specification workshop meet regularly with all parties present. When specification is made early and members don’t meet regularly, gaps form between what developers, testers, and clients understand to be the function of the software. To help facilitate this, a common language needs to be developed that is consistent between all groups. The language must evolve and be well defined for all members of the team.
I like the concepts that the book discusses and could probably apply them easily. Getting clients to buy into this method of working will be more challenging. For some clients, it will be most difficult to stop beating the old, dead horse of traditional requirements. For other clients, the challenge will be providing regular feedback, instead of being available only once every two months with sparse feedback. But, that is something to work for.
December 21, 2016
If you or your team are involved in building software then this book is highly recommended. Be prepared to approach the book without holding on to your existing notion of how software is built because this thinking can make you change the way you approach and execute software development.
Who are the intended readers?
1. Managers who are accountable for delivering software. If you oversee delivery of software from conceptualization all the way to deployment to production, then this book is something worth every minute of reading time. In fact, the recommended practices here do benefit long term total cost of ownership of the software which your clients (internal or external) can benefit from (perhaps your career too).
2. Business Analysts, Testers and Programmers are also targeted readers because these are the key roles that contribute to the success of the software delivery team.
This is not just another book evangelizing a thesis, but the later chapters give you key takeaways on what the exact tools are recommended to implement it. Although you should not treat that list of tools as the final list because this book is already 'old' as far as that list is concerned today, instead go to Adzic's website to see a more up to date list of tools recommended. Even without the tools, the lessons advocated in this book are classic teachings on software quality -- that we should start addressing good quality software before we even start writing the first line of code.
Agile software development is a game changer some years back but it remains to be an approach that folks are uncomfortable with in traditional organizations with established "tried and tested" methodologies. This book will add further justification on why you should go agile. If you are doing agile now, then this book will improve on that practice further which can help you convince your stakeholders to side with you on the agile movement.
This is a review from somebody who actually wrote code for a living and managed software delivery for years.
Who are the intended readers?
1. Managers who are accountable for delivering software. If you oversee delivery of software from conceptualization all the way to deployment to production, then this book is something worth every minute of reading time. In fact, the recommended practices here do benefit long term total cost of ownership of the software which your clients (internal or external) can benefit from (perhaps your career too).
2. Business Analysts, Testers and Programmers are also targeted readers because these are the key roles that contribute to the success of the software delivery team.
This is not just another book evangelizing a thesis, but the later chapters give you key takeaways on what the exact tools are recommended to implement it. Although you should not treat that list of tools as the final list because this book is already 'old' as far as that list is concerned today, instead go to Adzic's website to see a more up to date list of tools recommended. Even without the tools, the lessons advocated in this book are classic teachings on software quality -- that we should start addressing good quality software before we even start writing the first line of code.
Agile software development is a game changer some years back but it remains to be an approach that folks are uncomfortable with in traditional organizations with established "tried and tested" methodologies. This book will add further justification on why you should go agile. If you are doing agile now, then this book will improve on that practice further which can help you convince your stakeholders to side with you on the agile movement.
This is a review from somebody who actually wrote code for a living and managed software delivery for years.
January 2, 2017
I found this book very inspiring. I'm new with agile methods. Well actually at the beginning of my career as a system developer and working in a small company we did work agile and got good results. We just didn't call it agile. I think this book describes an interesting framework e.g. how to solve communication issues and produce and keep documentation alive (up to date) and some practical tips how to actually put them on practice.
I was very excited about this book. When I talked about it for colleagues and friends I got mixed feedback. Some got enthusiastic as well and saw the potential. Some said that this is pretty much same than in any other agile approaches and wished me good luck (with a little bit of cynicism). So perhaps this is a good book for beginners and optimists.
I was very excited about this book. When I talked about it for colleagues and friends I got mixed feedback. Some got enthusiastic as well and saw the potential. Some said that this is pretty much same than in any other agile approaches and wished me good luck (with a little bit of cynicism). So perhaps this is a good book for beginners and optimists.
January 2, 2012
I think this book addresses a very real problem in most software development teams, and I think any team working on domain-specific end-user software could certainly benefit from it.
It's fairly readable for a tech book, and although parts of it can end up sounding repetitive, it's possible to read it straight through.
I hesitated between 3 and 4 stars, but I went with 4 because I think my opinion was tainted by the fact that it's not particularly relevant to my current project, even though this was the context in which it was suggested. Thinking back to previous projects, I think we could have put some of these ideas to very good use.
It's fairly readable for a tech book, and although parts of it can end up sounding repetitive, it's possible to read it straight through.
I hesitated between 3 and 4 stars, but I went with 4 because I think my opinion was tainted by the fact that it's not particularly relevant to my current project, even though this was the context in which it was suggested. Thinking back to previous projects, I think we could have put some of these ideas to very good use.
July 22, 2019
Interesting book about Communication in Agile
Message of the book is introduction to communication and discussion to discover missing (stories/hidden assumptions) + clearing between teams in organization (many teams).
It's very useful for anyone first step in Agile and need to know difference between tradition and new wave. This book does not mention tools for automation however it is enough to find automation that conformity and approciate to Agile team.
"Document is nothing, documenting is everything" - this quote book is impressed to the most value are communication and concensous/commitments.
Message of the book is introduction to communication and discussion to discover missing (stories/hidden assumptions) + clearing between teams in organization (many teams).
It's very useful for anyone first step in Agile and need to know difference between tradition and new wave. This book does not mention tools for automation however it is enough to find automation that conformity and approciate to Agile team.
"Document is nothing, documenting is everything" - this quote book is impressed to the most value are communication and concensous/commitments.
November 26, 2013
This book contains interesting ideas. Unfortunately, it repeats them over and over and over again until you want to throw the book out the window. If you remove all the sections of the book that just repeat things from earlier chapters and remove the advertisement chapter (that's all I can call it since it reads as an ad for various specific automated testing tools) you end up with 3 good chapters of material. This really should have been a few chapters in another book, but the material was not nearly enough to fill the 14 chapters of the book.
July 12, 2016
Leitura obrigatória para quem trabalha em qualquer time na linha ágil!
Ele até pode parecer "antigo" mas traz muitos insights importantes para todo o time e do real motivo (e correto) de usar a especificação por exemplos.
Antes de aprender sobre BDD ou qualquer técnica para detalhamento de requisitos na linha ágil leia este livro.
Ele até pode parecer "antigo" mas traz muitos insights importantes para todo o time e do real motivo (e correto) de usar a especificação por exemplos.
Antes de aprender sobre BDD ou qualquer técnica para detalhamento de requisitos na linha ágil leia este livro.
November 4, 2014
Leitura obrigatória para todos aqueles que trabalham com desenvolvimento de software independente do papel.
O maior responsável pelos problemas nos projetos é a falta de comunicação e esse livro nos mostra formas de melhorar a comunicação e criar uma linguagem que seja comum a todos os membros do projeto através da especificação por exemplo e agile acceptance testing.
O maior responsável pelos problemas nos projetos é a falta de comunicação e esse livro nos mostra formas de melhorar a comunicação e criar uma linguagem que seja comum a todos os membros do projeto através da especificação por exemplo e agile acceptance testing.
August 14, 2016
As so many people say: a "must" for anyone involved in software development.
Because of the age of the book, written in 2009, most concepts might sound "too obvious" nowadays or someone already familiar with agile software development. Despite that, I highly recommended, it's always good to read all together the logic and sense of lots of practices.
READ IT, YOU FOOLS!! :-p
Because of the age of the book, written in 2009, most concepts might sound "too obvious" nowadays or someone already familiar with agile software development. Despite that, I highly recommended, it's always good to read all together the logic and sense of lots of practices.
READ IT, YOU FOOLS!! :-p
Read
October 12, 2010Booked out by Rob Hare 12/10/2010
June 6, 2016
Not exactly brain surgery - but full of really practical advice about software development from someone who has clearly done this a lot
October 19, 2013
Examples trump specifications. This is my simple takeaway from this book, but there's much more to it than that.
October 13, 2013
There are lots of people with different backgrounds working in the development of an application and this book can help you to improve the communication between them.
February 11, 2014
Excellent - stuff I knew, stuff I didn't know and stuff to challenge. Brian Marwicks counter is referenced and that's great. I believe this can work in some situations as well.
Want to read
January 24, 2016agile
July 21, 2016
Pretty dry and abstract, not as many usable examples as other books I've read. Maybe it was just a little too technical for me.
Displaying 1 - 23 of 23 reviews