Selling executable specifications to stakeholders, testers and developers

In this post I want to share how we made a breakthrough in using executable specifications in our latest project.

Executable specificationsExecutable specifications are scenarios created by developers, testers and stakeholders working in collaboration that check the behaviour of a system every time code is committed. For more information and a podcast about Executable specifications check out this Hanselminutes episode ‘Executable Specifications with Gojko Adzic, Jonas Bandi and Aslak Hellesoy’.

The need for change

A few months ago after joining the team, there was a lot confusion how a previous project worked.

Stakeholders weren’t sure what functionality had been implemented, testers weren’t sure if everything had been tested and developers didn’t want to go anywhere near the code.

While there was a wiki no one was sure if was 100% accurate which meant it could do more harm than good because it could lead to false assumptions.

As a result of this the relationships between the groups had suffered.

Inspired by Dan North’s talk ‘How to sell BDD to the business’ I suggested using BDD (behavior driven development) and executable specifications to help prevent this happening in the future.

Testers and business owners were open to the idea but were skeptical to how valuable it would be.

So we decided to try it out on a small part of the project.

And it worked!

Working collaboratively we found relationships started to improve and there was a lot more trust between the groups.

TickAt the end of the project stake holders, testers and developers agreed executable specifications were an excellent way to develop software and keen to adopt the approach for other projects.

So what sold executable specifications to the stakeholders, testers and developers?

  • Scenarios that matched the business problems the stakeholders wanted to solve.

    This gave stakeholders confidence and lowered fear and resistance to change.

  • Easy to read scenarios that matched the domain language the stakeholders were using.

    Stakeholders could relate to scenarios and therefore felt involved.

  • Using scenarios to fill out the blanks.

    When the test team or developers found new scenarios they communicated using with stakeholders leaving out what should happen (the then step) for them to fill in.

  • The use of tables.

    Tables allow the reader to visualise the data, reduce reputation and mean you don’t have to cram in lots of words.

    For example instead of having 

    Scenario: Submitting form with invalid password displays error
  Given I am on the registration page
  When enter the password 'a'  
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    and then repeating this for every permutation of invalid passwords, you can do this

    Scenario: Entering an invalid password displays error
  Given I am on the registration page
  When enter the password  
    | a						| 
	| aaaaaaaa				| 
    | AAAAAAAA				| 
	| aaaaAAAA				| 
	| 12345678				| 
	| 1234567A				| 
	| 1234567a				| 
	| 12345678aaaaaaaaA		| 
  And submit the form
  Then I should see the message 'Passwords must be 8 to 16 characters long and include at least one capital letter, one lower case letter, and one number'

    We found this gave us valuable input from stakeholders and testers who were able to come up with scenarios much faster than before.

  • Living documentation.

    Running tests to ensure the scenarios still reflected the behaviour of the system after every code change meant documentation was reliable and accurate.

The future

I’m pleased stakeholders, testers and developers have recognised the value of using BDD, scenarios and executable specifications.

By taking small steps, inspecting and adapting along the way, I hope that more projects I work on can adopt this approach.

Agile Retrospectives – A picture is worth a thousand words

A while back I went to Rachel Davies excellent ‘Inspect & Adapt with Agile Retrospectives‘ talk about agile retrospectives at a Software East.

One thing that has stuck in my head ever since has been her tip about getting people to draw a picture to represent how the sprint went.

The fact that it’s simple and easy to do is what makes it’s great.

She gave two examples, one was a group of people climbing half way up a very steep mountain and the other was a stretched limousine packed full of people without a driver.

This is definitely worth trying out in your retrospectives becuase it’s an excellent way to lighten the mood and get people contributing.

Whether you decide to keep it anonymous or not is up to you.

Here’s a drawing I’ve shown in a retrospective.

Agile Parenting

Earlier this year my wife gave birth to our first child, as shown below ;)

Since that day I’ve noticed that parenting shares many similarities with agile development.

I say this becuase from the moment a baby enters the world it’s all about inspect and adapt.

You’re forever analysing what they’re doing, checking they’re alright and planning and pirotising what to do next.

And while friends, parents and books give sound advice you have to look at your own context, every baby is different and so not every tip will work.

And this is when you’ll start doing mini retrospecives as parents. Every so often you’ll sit down with your partner discuss what went well, what didn’t and what to try next.

Using short feedback cycles you’ll soon work out what works best with the aim of developing sort form of structure.

You can’t do this waterfall becuase babies are unpredicatble and constantly changing.

As soon as you think you sussed it and plan too far ahead, the baby will go thru a growth spurt or learn something new and you’re back to square one before you know it.

It’s like a game of snakes and ladders, you’ll look at your partner and say this didn’t happen yesterday.

We’re four months in by working together and constantly sharing throughts and ideas we’re developing a routine which can cope with changes and… getting more sleep as each week passes!

Page 1 of 3123