Archive for July, 2012


What is Specification by Example?

by Arnaud Lamotte

Setting Business goals, gathering requirements and providing specifications are fundamental activities of product development. However these activities are only partially covered by traditional Agile methodologies, which tell us how to build software the right way but not necessarily how to build the right software.  Beautiful working software that does not reach the business goals it was built for is still a failure. Iterative development, deferring commitment, regular reviews and quick feedback mitigate potential problems in that regard more than they tackle them. To address what can be seen as the second constraint of software development, a second generation of Agile practices is currently developing, putting even more emphasis on collaboration with customer/business, while keeping if not reinforcing the ability to adapt to change. I recently went to an interesting workshop run by Gojko Adzic on ‘Specification by example‘. ‘Gojko Adzic has identified seven process patterns followed by companies that continuously deliver valuable software. These seven process patterns are the following:

  • Deriving scope from goals
  • Specifying collaboratively
  •  Illustrating specifications using examples
  •  Refining the specifications
  •  Automating validation without changing the specifications
  • Validating the system frequently
  • Evolving living documentation.

In this blog I summarize each pattern and relate ‘specification by example’ to other practices to hopefully provide a clear presentation of what it is.

deriving scope from goals

There are two main causes for the wrong software to be built: requirements are misunderstood or not communicated correctly, or the software has little business value or it is not the most effective way to achieve the expected business value. Companies that follow the ‘deriving scope from goals‘ pattern address this second cause. Instead of presenting the development team with solutions to implement, business representatives introduce the business goals and the tangible and measurable expected outcomes of a project. This way, all stakeholders can work out together elegant and valuable solutions within the software constraints. When the delivery team knows the business goals behind a project or a feature, it is obviously more likely to be able to help reaching them. This pattern overlaps with the following one: ‘Specifying collaboratively’.

Effect mapping is a collaborative mind map aimed at deriving high level scope from business goals. The first step is to clearly communicate the business goals and a way to measure them: why are we starting this project, what are we trying to achieve, how will we know we achieved it? This last question is almost as equally important as the business goals themselves. If the business goal is to increase the number of customers, it is probably not the same product/feature/action that will increase it by 5% or 50%. The second stage is to identify all the stakeholders: who can help us achieve these goals? The third stage is to identify how each stakeholder can help the project reach its goals. These are the business activities. Then the last stage is to ask how the delivery team can support or help the stakeholders with each of these business activities. Typically this 4th level will be epics that could be broken down further into minimal marketable features or user stories.

Effect mapping has many benefits:

  • The prioritization can be done at the third level. What are the most important business activities to support?
  • This prevents the user stories going in multiple directions and growing in number to the point where they become unmanageable. Relating every feature to a business goal prevents scope creep.
  • The effect map can be used as a road map.
  • Relating all stakeholders, business activities and features to a business goal allows visualizing of all  the assumptions.
  • This last point is very useful for delivery teams directly presented with solutions to develop and who wish to challenge them as it is often possible to test the assumptions.

Specifying collaboratively

Leveraging the wisdom of crowds in heterogeneous groups is only one benefit of ‘Specifying collaboratively‘. It also ensures the team shares a common understanding of the problems and solutions because the further away from the delivery team the requirements are specified, the more transcription steps there is likely to be, the more room for misinterpretation there is. Finally, it paves the way for the development of a common language across all stakeholders, necessary to illustrate specification using examples.

Diverge and merge. To specify collaboratively splits the attendees in heterogeneous groups of 4 or 5 before merging all the ideas. This avoids meetings beinghijacked by a dominant attendee and other attendees may feel more comfortable expressing themselves in a smaller group.

Illustrating specifications using examples

We use examples every day in our life to clarify abstract matters. By definition, examples are concrete. They leave little room for little interpretation and are easily testable if well chosen. This makes them a great mean to communicate expected behaviours. ‘Illustrating specifications using examples‘ allows exploring hedge cases, identifying functional gaps and crucially providing a clear definition of ‘done’. All examples are welcome, the aim being to have the feature fully covered and understood. The attributes of a good example are to be self-explanatory, focus on one functionality only, expressed in domain language, measurable and not a script (a sequence of activities). These examples need next to be refined.

Refining the specifications

Refining the specifications’ is done at the level of the examples and at the level of the set of examples. The examples must be self-explanatory and testable. The set of examples should describe the feature unambiguously but not necessarily cover all cases. Our key examples are in fact what is more commonly called acceptance criteria, acceptance tests or functional tests. Too many examples could compromise their use as live documentation and their automation.

The most popular format to express acceptance criteria is Gherkin(Given, When, Then). Originally created for Cucumber, it is now used by other tools. The syntax is:

  • Given some precondition
  • And some other precondition
  • When some action by the actor
  • And some other action
  • And yet another action
  • Then some testable outcome is achieved
  • And something else we can check happens too

Automate validation without changing the specifications

The set of key examples needs to be automated as tests so they can be run as often as needed and provide feedback as quickly as possible. It would not be realistic and effective to do these tests manually. However they must not be modified while automated as we do not want to lose important information or introduce wrong information during the transcription. It is therefore not possible to use traditional test automation tools such as the xunit family. To ‘automate validation without changing the specifications’, other tools exist that allow describing behaviours in plain English. Cucumber, Concordion and Fitnesse are popular. Tool choice depends mainly on the programming language used in the project and the domain of the project.

Validating the system frequently

Once the validations are automated, the system must be validated as often as possible. By ‘validating the system frequently’, developers and testers get quick feedback. The defects are identified early when they are the cheapest to fix. This is reminiscent of the Toyota/Lean principles: zero quality control. Quality is an inherent part of the whole process, it is built-in, and it is not a separate stage in the process.

Evolving living documentation

Unlike tangible products, software keep evolving and changing even after its initial release, which makes them rather difficult to document. Typically, for software, especially enterprise software, the only source of truth is the code. This results in a consequent bottleneck in knowledge acquisition and difficulties in implementing changes. By ‘evolving living documentation‘ teams practicing specification by example have a source of truth that evolves with the code and is readable and understandable by all team members.

 Evolving  live documentation is one of the most difficult aspects of specification by example but also one of its most valuable outcomes. Matt Wynne, author of the Cucumber book, is currently developing Relish. Relish helps teams publish, browse, search, and organize their Cucumber features on the web.

Whilst aimed at developing the right software and therefore reducing re-work, the seven patterns of specification by example bring valuable side-benefits: live documentation that will facilitate changes and knowledge transfer, a clear definition of ‘done’ and a set of tests that can validate the system at any time. There are also technical benefits that I am going to briefly highlight below but a little bit of semantic first will help.

What are the differences between Specification by example, Behaviour-Driven development (BDD) and Acceptance Testing-Driven Development (ATDD)?

Behaviour-Driven development is the most widely used of these terms. It was coined by Dan North around 2004. While practicing Test Driven Development he started naming his tests by sentences describing the next behaviour in which he was interested. He found it so beneficial,  notably in helping defining what to test, that he started using ‘Behaviour-Driven Development’ instead of “Test-Driven Development” while coaching on the subject. This narrow definition of BDD, as an improvement of TDD by using meaningful sentences to name tests and objects and testing at a higher level is still in use. However BDD has gained a broader meaning for most practitioners including Dan North:”Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing“. With this second definition BDD is almost identical to Specification by example, or it can be seen as its technical perspective.

The  Rspec book, co-authored by Dan North provides an even broader definition: a combination of three practices, Acceptance Test-Driven Planning (ATDP), Test-Driven development (TDD) and Domain-Driven Design (DDD). Acceptance Test-Driven Planning (ATDP) is an extension of Acceptance Test-Driven Development (ATDD). ATDD advocates defining acceptance tests collaboratively before starting coding. ATDP adds that it must be done during the iteration planning so the acceptance tests are taken into consideration while estimating the user stories. Domain driven Design (DDD) is a set of practices and techniques created and/or assembled by Eric Evans, aiming at keeping code, business logic and business reality in line.
This third definition does not show BDD has an improvement on TDD or a replacement for it. However it increases the scope of BDD considerably by including DDD in it. Domain Driven Design has a lot in common with the practices described in this blog, especially in terms of collaboration between stakeholders and development of a domain language but it relies heavily on modelling which is not the case for Specification by Example. On the basis of this definition BDD encompass Specification by example.

The different definitions of BDD make the comparison with Specification by example difficult and these semantic incongruities are certainly not a major concern for the practitioners in their daily activities anyway, despite the irony for this domain to not have an ubiquitous language. Nonetheless there are differences due to their different initial purpose that can be consequent. Gojko Adzic observed patterns in companies delivering the right products, Dan North wanted to improve TTD. As a result BDD has a more technical perspective and Specification by example is not directly linked to TDD like BDD. For specification by example TDD is a very valuable XP practice addressing another issue: quality. In fact Gojko Adzic advises in his book to start by TDD before implementing Specification by example and does not say that it should replace it. This can be a fundamental difference between BDD and Specification by example as explained below.

and Test-Driven Development (TDD)?

In its broad sense TDD means writing a test first, watching it fail, coding to pass the test and refactoring. However TDD is mostly used with a narrower meaning, like in the above definitions, where the tests are unit tests, i.e. they only validate an individual method or class. Therefore under what could appear as trivial semantic concerns underlay the fundamental question of the level of testing/validation, unit or behaviour? In ‘growing Object-Oriented Software, guided by tests‘, Steve Freeman and Nat Pryce explain that both acceptance tests and unit tests are important. Acceptance tests tell us about the external quality of a system (how it meets user expectations) while unit tests tell us about its internal quality (readability, how easy to change…).

They provide this figure to describe the inner and outer feedback loops in TDD (broad meaning). For instance in the case of an acceptance test described using the gherkin syntax, there should be a unit test at each step, given, when and then. By adding acceptance tests on top of unit tests to drive development, Teams focus on features instead of objects, and design from the perspective of user without consequences on quality and the ability to refactor safely at the granular level.

Specification by example and Testing

It is hopefully clear by now that specification by example is not a ‘tester’ activity, at least no more than it is a developer or business activity. Nonetheless, Specification by example validates the developed feature but the set of examples can also be used for regression testing. In, ‘Agile testing, A practical guide for testers and Agile Teams’, Lisa Crispin and Janet Gregory classified the different kind of testing or validation depending on whether they are technology facing or business facing, whether they support the team or critique the product and whether they are automated or manual.  Unit tests are technology facing, supporting the team and fully automated. The acceptance criteria ensued from Specification by example are Business facing, supporting the team and fully automated. However once the development of the corresponding features is completed, the set of automated acceptance criteria can become, in conjunction with the unit tests, a set of regression tests that is technology facing and critiques the product.

According to Gojko Adzic the number of different names for what are very similar practices is a reflection of the amount of research and work put into that field at the moment. Paradoxically it also shows how difficult it is to develop a common ubiquitous domain language. ‘Specification by example’ has the advantage, because of its focus on developing the right product, to not conflict with other Agile practices. In particular  it does not position itself as a replacement for ‘(Unit) Test-Driven development’ or traditional testing activities.


New Birdsong Push Notification Service and v1.8

by Jon Sharratt

Just a quick post before the weekend to formally let you all know that myself and Joe today have released the new Birdsong push notification service.

Push Notification Service

We have released our shiny new service to Windows Azure today (a release on Friday…. naughty).  It has been a low risk release as the notification and live tile functionality as you all know hasn’t been working for a while.

With this in mind we wanted to get it right and have spent the past few weeks concentrating on implementing site streams from the twitter API to ensure we can provide you with almost instant notifications and live tile updates (phone connectivity depending).  I hope you all enjoy the new and improved service.  Development and testing has been an enjoyable challenge for myself, Joe and our test lead Samera.

NOTE: You will need to resave your notification settings for each account in your current Birdsong version (latest is v1.7) to take advantage of the new service.

NOTE: If you enable notifications in your current application favorited tweets and retweets will come through.  When version 1.8 is released these options will be configurable.

Birdsong v1.8 (Coming soon)

In regards to the next version of the Birdsong client we will be enhancing features for notifications to allow you to enable or disable toast notifications for favorites and retweets when they occur.

The final feature we have also added gives you the opportunity to turn on live in-app updates.  This feature will automatically refresh your timelines when you are mentioned or a direct message is sent to you.

As for the technologies we used and how the push notification was redesigned.  I shall leave that for another post…..

Have a great weekend, oh and don’t forget to set your do not disturb settings ;o)


No red nor badger? – Red Badger branding process

by Sari Griffiths

You may have noticed that we’ve recently rebranded.
Here is a brief account of how we did it.

Why rebrand?

The previous Red Badger brand was created when the company was set up by Stu, Dave and Cain. It served us very well, but as we grew, we felt that it no longer represented us and our ambitions as accurately as it did. Also we all had our own ideas of what Red Badger was all about, but there was no simple way to describe them. Working on a new brand would help us see and express ourselves more clearly in a single(ish) voice.

Brand essence workshop

The first workshop we had was about defining a brand essence. It’s basically a few words that describe and sum up the brand. Coming up with the brand essence helps you to focus on what the business is all about.

For example:

  • BMW Ultimate Driving Machine
  • Coke Open Happiness
  • Disney Magical
  • Starbucks Rewarding Everyday Moments
  • Sony Digital Dream Kids

Okay, these are big brands. And we are not trying to be one. But there is a definite benefit in coming up with something like this.

To find one for us, we did a few things.

1. Personality questions – “What would Red Badger be if it’s…”

We sent a questionnaire around the office and to some of our clients to find out how we see ourselves, and how we’re seen. All questions started with “What would Red Badger be…” and asked things like “…if it’s a car?”, “…if it’s a person?” and “…if it’s an everyday object?”. It was fun and a very useful exercise to find out what everyone thinks of us.

2. Looking at Red and Badger

We started the branding exercise by saying “we might not have a badger in our logo, and we might not use red”, so it was important to look at the meaning of both words to see how relevant they could be to our brand. After all it’s our name.

3. Who are our competitors?

We printed out all potential competitors’ website – or the ones we thought were competitors – to see the space they occupy in the industry visually. By the time we got to this stage, we had a good idea who we were and realised most of them were actually not in our space.

At the end of good discussion, we settled with a set of keywords rather than having a snappy brand essence, and we got a tagline we all liked. (Thanks Stu!)

“Experience. Design. Technology. Crafted.”

Look & feel workshop

Having agreed a tagline and a set of keywords, we had another workshop looking at how these can visually manifest themselves.

As ‘craft’ was one of the central themes that connected many of our ideas, we kept coming back to the idea of a ‘workshop’ as a physical space – where we craft and experiment.

We looked at different visual styles for the new identity and fonts as well. As we were on the same page with our branding, this stage went pretty smoothly. Sketches and photographs are in. Furniture makers’ marks are in.

Now all the important thinking had been done. Let the fun of making begin…

The badger

We looked at the identity as we started looking at a new website. Initially we were looking at a more typographical approach – as is common in Furniture makers’ marks – but in the end we settled on our new Penguin-esq badger. We thought it was appropriate to have a character in the end, considering our clients sometimes refer to us as ‘badgers’.

The strong visual style allowed us to have more than one logo format.

We also like the idea of having a stamp made to show ‘badger approved’ quality.

The red

We concluded that if we were going to use any colour, it had to be red. It’d be a bit confusing otherwise, wouldn’t it? So the red is in. We picked a bit brighter red than in the previous logo.

What now?

We are in the middle of applying the new brand everywhere, including the website. In the true workshop spirit, we’ll keep working on it. And have some fun!


Is the BBC Connected Studio programme a good idea?

by David Wynne

We were very pleased to be invited back by the BBC to attend the second BBC Connected StudioCain and Alex had attended the first Connected Studio which had focused on Homepage, Search & Navigation.  Thanks to their efforts we progressed onto the subsequent Build Studio where our team brought their concepts to life and we’ve just announced that we’ve progressed again to the pilot stage.

This time around Sari & I took the short walk from the Red Badger workshop to the new Google Campus in the “the heart of East London’s Tech City”.  It’s so new the new car smell (read: “paint”) hasn’t had time to dissipate.  The focus this time around was Weather and Travel.


Rather than re-tread Cain and Sari’s already expertly trodden diary style accounts, I thought I’d try and take another angle on the day and provide an alternate view.  Given our experience so far, is the BBC Connected Studio programme a good idea?

Are real ideas created in a day?

I have approximately 43.4 ideas a day, most of them don’t make it past my internal monologue to my mouth.  The majority of the rest get shot down when it’s pointed out someone has already done it or actually implementing the idea would be too dangerous and/or against the law.

Coming up with an idea is easy.  Proving that it’s a good one is the hard part.  More to the point, developing the right skills to prove or disprove an idea is something that takes practice and this format is the perfect training ground.

Many people have spent many millions following through with their idea before proving it.  The lean start-up movement is about testing your ideas with your customer cheaply and quickly.  Looking your idea straight in the face and truly asking, is this a good idea or not?  And if it’s not, move on.  The PoC/Concept Lab/Launch 48/lean start-up (whatever you want to call it) is all about failing fast, failing cheaply.  Short cycles of trial and feedback, rather than the traditional secret bunker and big bang approach that’s littered with casualties and lost investment.

Who owns the IP?

The BBC have been pretty open from the start that the initial creative studio is very much an open pitch process.  If  you progress onto the build and pilot stages, these are covered by a mutual confidentially agreement – but you’re still ultimately working on your idea openly alongside you competitors.

In the first creative studio, there was the option to pre-book a closed pitch session for those who were pitching ideas that contained IP they didn’t want to share.  Interestingly at the second creative studio they had decided that all pitches should be open.

On the downside you have to show them yours and risk embarrassment.  On the upside they have to show you theirs and you get to checkout the competition in an open and healthy manner.  It’s fascinating to see what other ideas people are coming up with, and to see the common themes emerge.

We’ve always been pro open and honest, so the Connected Studio process fits the Red Badger ethos rather nicely.

Aren’t you being taken for a ride?

So two of you spend a day working for free, then a team of you spend 2 days working at cost, then another team works for 6-8 weeks after that.  All with the prospect that Auntie could say no thanks at any point.  Aren’t you being taken for a ride?

Anyone who’s been involved in a tendering/pitch/sales process of any kind will know; stuff takes a long time.™  They will also know that in the consulting game you’re basically selling your ability to do stuff better than anyone else.  If at any point your prospective customer doesn’t believe you can do it, doesn’t like you or finds someone else who can do it better and/or cheaper – you lose.

As I’ve said before when discussing concept labs, the idea is not to do things differently, but to distil best practice and fail fast.  In that respect the Connected Studio programme applies the same attitude to the pitch process.  If anything, the prospect that you get instant feedback is fantastic. If our idea really isn’t up to scratch, then put us out of our misery so we can move on to fight another day.  No problem.

Tell me something else

It’s a fresh approach from a huge organisation.  It’s a chance to tell the BBC what you think they should be doing, rather than doing what they ask you to do.

I’ve been involved in a lot of Proof-of-Concept-type projects and whilst they’re nearly always fun and enlightening, the toughest part is to do something positive with the discoveries you make.  The BBC have been quite wise in making a commitment up front to an end goal.

Ultimately the proof will be in the pudding as to whether they follow through on that commitment and whether the results from the programme go on to improve people’s lives.  But if you don’t try, you’ll never know.



XPF to be open sourced

by David Wynne

Way back in 2010 we announced the public beta of a new framework called XPF, a layout framework for XNA.  It enabled WPF/Silverlight style layouts to be created in XNA solving the pain point of doing 2D layouts in XNA.  It was built from the ground up in pure XNA, supported data binding, attached properties etc and came with a bunch of out of the box controls like Button, Border and the always popular Grid.


What happened?

We were working on a project that had a huge amount of 3D and 2D content and as such was the test bed and, if you like, the thing driving the backlog of XPF.  We were also planning to productise XPF and sell licences so that others could use it in their products and we could make a few quid.

Two things happened.  The project we were working on fell by the wayside and Microsoft announced that they would allow you to combine Silverlight & XNA on the next version of Windows Phone 7 OS.  The impetus for XPF was lost and, as is often the case with start-ups, our attentions were focused elsewhere.

Where is XPF now?

The code for XPF is still sat in a private repo on  We really did do a ton of work on it, as you can see from the numerous blogs we wrote as we went.  There are literally hundreds of BDD specs covering every aspect and thousands of lines of code goodness.

We still get a lot of interest in XPF and pretty much decided months ago that there wasn’t the market to really productise it, so would instead turn it over to the open source community.  We didn’t really want to just flip the switch, make it public and slap an open source label on it however – we wanted some form of curation.  After all we’ve put a lot of our time and effort into the codebase.

What’s going to happen?

In February I started chatting to a Jaco & Jonathan in South Africa about what was happening with XPF and to cut a long story short, we’ve got to the point where they have agreed to shepard XPF into the open source arena – with some help from us of course.

Jaco, Jonathan & I have just had our first Skype call together to get the ball rolling and over the next couple of weeks they’re going to get the code base updated and ready to go public.

It would be great to see XPF brought back to life and to provide real benefit to those who’ve shown interest in it over the last couple of years.  We’re not totally sure how the project will pan out and obviously it’s early in our working relationship – but hopefully we’re moving in the right direction and together we can open up XPF to everyone!


Red Badger–A Bizspark Summit Finalist–Top 15 of 16,000.

by Cain Ullah

It’s just over 3 weeks since the BizSpark Summit on 7th June. I’ve been so busy it has taken me this long to write a blog post about it. So here’s a summary.

16,000 Startups

There are 16,000 startups that are part of Bizspark in Europe so we were honoured to be nominated as one of the top 15. There was a really good bunch of talented startups presenting and lots of interesting people. The event as a whole was fantastic (I have written a little about the build up to the event here). There was an incredible amount of organisation that went into the event from the event organisers Forgather, to the input from Microsoft’s European Bizspark representatives spearheaded by Bindi Karia and the coaching from Mike Sigal. It was a busy couple of weeks leading up to the event (I think I must have changed my pitch about 10 times, the last change being on the eve of the event) with a full day of rehearsals (one run through per startup) and final feedback at Microsoft’s Victoria offices on the day before the summit. Drinks and food were put on by Microsoft that evening so that all of the startups and Microsoft Bizspark folk could mingle and get to know each other.

On the day we arrived early at Ravensbourne college (where we were former incubatees) to prepare our stands before the main event kicked off around 9:30. It was actually quite daunting as there was a crowd of approximately 300 people in the auditorium and all presentations were up on a big stage. This was a definite step up for me when it comes to presenting.

David Rowan, Editor of Wired UK expertly moderated the whole day with Dan’l Lewin (Corporate Vice President Emerging Business Development) doing the opening conversations and getting the day started.  I won’t give a running commentary of the day, you can find more info on that here, but I will say that the day was expertly delivered and there were some really interesting keynotes including Bob Dorf, author of the Startup Owner’s Manual. In-between the keynotes were the three sessions for the startups to present with five startups presenting in each session. I was relieved that I was in the first session so that I could do my presentation and then enjoy the rest of the day.

My Experience

Bizspark Summit

As I mentioned in my previous blog we were slightly different to the rest of the startups that were presenting because we didn’t have an actual product to show and the day was very product focussed with a large contingent of VCs in the audience.

So, I had five minutes to introduce who Red Badger were, describe the problem, paint a vision of how our product idea would provide a solution, describe the market, the business model, the competition, the team, and finally a closing message to the VCs. It was a hell of a lot to fit in and despite lots of practice, I ran over as did most of the other startups.

It was a very good experience though. The hardest bit was painting a vision. Quite a few people in the audience (and the judges) didn’t get what our idea was trying to do. It would have been much easier had I been able to show them what we had done. However, when we were in the breakout sessions, we had a lot of interest from people with experience in the industry who completely got our vision. So, overall it was a successful day for Red Badger. I personally have taken a lot out of the day and the whole process. I have learnt a lot from the coaching, taken some good feedback on board and look forward to doing things different when I am next presenting to a large audience like this one.

The other startups

I think one of my favourite things about the whole event was spending time with the other startups. Apart from them obviously being very talented entrepreneurs with some excellent products, there were some great people too. There was a real sense of camaraderie between us over the two days. We were also all very different and although we were effectively competing against each other on the day, in the real world I don’t think there was a single competing product. The highlights for me were autitouch, theappbuilder, fittingreality & paperlit. Go check them out as I expect they’re going to continue doing great things for some time. Autitouch specifically impressed me as on the eve of the rehearsals, they had a pivot with some potentially ground-breaking research results coming through that changed their pitch at the 11th hour. Freena Eijffinger handled the change incredibly well to deliver a faultless presentation.

The future

As for Red Badger, well, we’re hoping we’re going to be around for a long time too. We continue to innovate, building up a solid foundation and providing great products for our clients through Consultancy. Product plans are afoot however, so keep an eye out for us in the future.