Accountability: Behavior-Driven Development’s Other Leg

Accountability is a huge part of agile development.  Behavior-Driven Development (BDD) drives accountability deep into development by having developers maintain the language of the business through the continuum of development process artifacts from user stories, through specifications, and into the application code.

BDD tools support accountability by surfacing specification documents from the executable descriptions of the application that developers have incrementally created through the plain-old Test-Driven Development process with a BDD framework like RSpec.

Stakeholders rarely get a glimpse into the stuff that developers are doing until shippable functionality is shipped, at which point, the software speaks for itself.  But simply having working software in-hand isn’t always enough, if it were, the drive for ever better acceptance testing tools and practices wouldn’t exist.

Part of our accountability to stakeholders rests in proving that we implemented what they assumed we would implement, and that we understood their requirements in the same way that they understand them.

In BDD, developers engage customers in a feedback dialog in the language of the business.  A customer would say, “I want you to implement X in such-and-such a way,” and the developer replies, “I understood that you’re asking me to implement X in such-and-such a way.”  This is partly what it means to say that a story is a placeholder for a conversation.

Using a BDD framework, developers write executable versions of the customer’s user stories and the acceptance criteria of those stories, and does so using plain business language.  If the customer were to read the executable specifications that were written by the developer, he should recognize the requirements that he laid out.

The BDD specifications become part of the feedback dialog, except that they do so in the form of a report that is generated from them specification code rather than from a conversation.  The report doesn’t replace conversations, but it does support the dialog and it gives concrete testimony to the developer’s understanding of the requirements at the time that he implemented them.

A stakeholder can read the specification document and gain the confidence that the developer understood the requirements, or that he misunderstood them.  As long as the developer strives for an ability to capture the specifications in clear and sensible language, a stakeholder will recognize his business behaviors and processes in the spec doc.

Subsequently, when the developers discipline themselves to write executable specifications in the language of the business, they are caused to think through the wording of a specification and this causes them to be constantly immersed in the consideration of the domain and the domain language.  Class libraries and API’s that emerge from this kind of consideration typically have a much greater affinity to the business domain that the application serves, and this is also a form of accountability.

By ensuring that the application code respects the domain language, the application code is more recognizable and thus easier to understand, which makes it easier to learn and easier to change and to maintain.  Keeping the software code true to the domain is a critical part of an application’s resilience to change and resistance to rot.  From a BDD perspective, respecting the domain language is as fundamental a design principal as testability.

BDD instills a 360 degree accountability feedback loop.  Stakeholders write stories; they add acceptance criteria to the stories; developers talk to stakeholders to understand to business of the story and to get an earful of the domain language; developers capture the acceptance criteria in domain language as executable specifications using a BDD tool; developers implement the application code using practices and patterns like Domain-Driven Design that further respect and enforce the domain language; stakeholders are given access to a report that is generated from the executable specifications that are themselves based on the domain model, and this report is used to vet the developer’s understanding of what was to be built.

A specification document is a developer’s way of saying, “I heard you ask me for this, and this is what I built (handing the user the spec document).  Have I correctly advocated your needs to the software?”

The spec document along with working software to play with as well as some form of customer acceptance test give the customer a tremendous amount of confidence that the developers are building the right thing, and that communication between customer and developer is unfettered.  This feedback also helps the developer to built better and more accurate abstractions, and doing so through the plain-old Test-Driven Development processes helps him build the right thing in the right way according to solid design principals.

Through BDD stakeholders and developers work to remain accountable to each other for the clarity of communication that ensures successful product development.

This entry was posted in Agile, Behavior-Driven Development, Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

Leave a Reply