Kickstart your team on BDD

BDD Kickstart is dead. Long live...

We are coming up to the one year anniversary of the first public BDD Kickstart, and we’ve got some news…

Matt and I have enjoyed running BDD Kickstart over the last year or so. We’ve had hundreds of people go through the course in all, with courses run for the public and privately in-house.

Over the year we’ve grown a team of real expert practitioners who also happen to be fantastic at teaching and mentoring. Seb, Rob, Julien and Steve have been partnering with us to help us run many more courses than we could have done on our own. With Suzan publicising and marketing the courses, we have built up some great momentum: enough to expand our course lineup.

BDD Kickstart’s fundamental philosophy has always been to put you in a room with experts. With the addition of new partners, we’re growing the range of subjects we can offer at that very high quality level. We can offer courses in more than just BDD. So we needed a new name.

Introducing…

Quality matters to us enormously, so we’re growing slowly. We’re focusing on running our existing Continuous Delivery course, and we’re already running in-house Ruby courses. We’re writing a “Hexagonal” course to teach pure OO design principles for modern web applications.

We’d like your feedback please!

We’re actively seeking feedback to help guide us as we grow and expand. Your emails are always welcome, but we’d especially like to speak to you on the phone if:

• You have been on a course with us and you have some feedback or a testimonial
• You’ve been thinking about coming along but haven’t done so yet for specific reasons (location, can’t spare the time, financial, etc)
• You have an idea of a subject you’d like to learn from us that we don’t offer yet

Send us an email with your phone number or Skype handle and we’ll set up a call.

What’s next

We have two public courses available at the moment: we’re teaching our popular BDD Kickstart course in London in December and our Continuous Delivery course in Paris in March. If you’re interested in either of these courses, you can sign up for London now, or email us to express your interest in the Paris course.

It’s an exciting time for Kickstart Academy: we look forward to seeing you at one of our workshops soon!

BDD Kickstart: London and 2013 plans

Fancy an update on BDD Kickstart? Here’s a quick summary of where we got to at the end of last year, and what we have planned for 2013.

BDD Kickstart London, December 4-6, 2012

Matt Wynne and I finished running the inaugural BDD Kickstart event in London at the beginning of last month. People from every different product discipline got together and learnt about Behaviour Driven Development (BDD) principles, and how to apply them to their own projects.

Matt led the first day, covering the BDD onion skin principles at a high level. We discussed business goals, acceptance criteria, scenarios and how all these concepts fit together. BDD is really just great TDD practiced formalised, so getting the definitions right is much of the work. We also explained how code quality is central to whole process, tying it all together.

On the second day, I covered some of the more practical elements of getting running with Cucumber, one of the most widely used BDD tools. We covered the simplest cucumber project ever, to get a feel for how the tool worked. We looked at different ways of writing and implementing scenarios, along with the practical implications. We took people right through the BDD cycle, showing everyone exactly where to switch between acceptance tests and unit tests, and giving plenty of opportunity to practice. At the end of the day, we introduced some specific techniques to help people test web applications.

The third day was a “connection day” - the aim is to help people to apply the concepts they’ve learnt with their real world work, and the problems they face when at their desks as opposed to sitting in a training room. We encouraged people to bring their own software projects on this day so that we could make real progress on their projects. We began by setting goals with the individual groups, and then allowed people to work towards those goals, helping them as needed along the way.

We just love running this course (we have been running a version of it at the BBC for a while now), and it sounds like those who attended enjoyed it too:

"The course was transformative about how I see software development. Only good things to say! :)"

"Really valuable and exercises were great in illustrating the key points."

"Definitely clarified my thoughts around the difference of acceptance criteria / scenarios."

It is so exciting to see how something that started as a few emails between Matt and I last spring has grown and gathered momentum. I can’t wait to see what’s next! For much of this success, we are indebted to the rest of the team: Suzan Bond, our wonderful marketing consultant, and Tracey Rosenburg, who has diligently handled a lot of the admin for us. Thanks guys!

BDD Kickstart in 2013

We have big plans for the new year. Through partnerships with Julien “Cucumber JS” Biezemans and Seb Rose, BDD Kickstart is coming to Brussels in February, and Edinburgh in March. We also plan to come back to London in the spring in late March or early April, and we have a number of other cities on our radar.

We’re also thinking about running some different Kickstart courses this year: we have had enquiries about a course teaching basic Ruby, for example. If you’re interested in a Ruby Kickstart course, please let us know.

If you’d like to join in the fun, then join our mailing list for news and latest course dates.

Thanks to Rob Chatley for the photos used in this article.

How to write a great story

Second in my mini-series of Cucumber videos: a quick introduction on writing a great story.

Note: This approach works best when starting off a brand new feature in the system. When changing existing features, we need to work to keep our preamble up to date. Matt Wynne's blog post shows you how.

If you like what you see, and you'd like to learn more, a quick reminder that Matt and I are running BDD Kickstart in London this coming December: the early bird ends November 4th.

The simplest Cucumber project ever

Cucumber can be really very simple. Here’s a short video to show how you can get started in two minutes flat, using only two files: a simple feature file, and a few lines of ruby to execute it.

If you like what you see, and you'd like to learn more, a quick reminder that Matt Wynne and I are running BDD Kickstart in London this coming December: the early bird ends November 4th.

Extreme YAGNI: How BDD nails your prototyping stage

Sometimes people don’t see the value in the BDD process. They contend that the BDD ceremonies are a waste of time, and get in the way of delivering real features to customers. Others cannot see how to apply BDD to their project, as no-one knowns exactly what the project will look like yet. As they’re only in the prototyping stage, by the time a feature file is written and made executable, it’s already out of date.

I don’t agree with this. If our process is set up right, we can prototype using just as effectively and retain the collaboration benefits that BDD gives us.

You Ain’t Gonna Need It

One of the biggest wins that Test-driven Development (TDD) gives us is the principle of YAGNI - “You Ain’t Gonna Need It”. It’s very tempting when writing code to go off on a tangent and produce a beautiful structured work of art that has zero practical use. TDD stops us doing this by forcing us only to write code that a test requires. Even some experts who don’t practice or encourage TDD often espouse the power of writing the calling code first in order to achieve much the same effect.

BDD gives us the same YAGNI win: but at a level higher than TDD. With the BDD cycle we’re adding thin slices of customer observable behaviour to our systems. If we can only write the code thats directly used by the business, then in theory we should be cutting down on wasteful development time.

However, there’s a snag here. if we’re prototyping, we don’t know whether this feature will make it into the final product. We still need to give feedback to our product team, so we need to build something. If the feature is complex, it might take a while to build it, and the feature might never get used. Why bother going through the process of specifying the feature using BDD and Cucumber features?

Happily, we can take YAGNI a level further to help us out.

Extreme YAGNI

Often in TDD, and especially when teaching it, I will encourage people to take shortcuts that might seem silly in their production code. For example, when writing a simple supermarket checkout class in Javascript, we might start with a test like this:

    var checkout = new Checkout();
    expect(checkout.total()).toEqual(0);

Our test defines our supermarket checkout to have a total of zero on creation. One simple way to make this work would be to define the following class:

    var Checkout = function() {
      this.total = function() {
        return 0;
      };
    }

You might think that’s cheating, and many people define a member variable for total, set it to 0 in the constructor, and miss this step out entirely. There is however an important principle at stake here. The code we have does exactly what the test requires it too. We may not need a local variable to store total at all.

Here’s the secret: we can practice this “extreme YAGNI” at the level of our features, too. If there’s a quick way to make our feature files work, then there’s nothing to stop us taking as many shortcuts as we can to get things working quickly.

For example, if we’re testing the user interface of our system via Cucumber features, one fast way to ensure things are working is to hard code the values in the user interface and not implement the back end behaviour too early. Why not make key pages static in your application, or hard code a few cases so your business gets the rough idea?

Again, you might think that’s cheating, but your features pass, so you’ve delivered what’s been asked for. You’ve spent the time thrashing out the story in a 3 amigos meeting, so you gain the benefits of deliberately discovering your software. You’re giving your colleagues real insight to guide the next set of stories, rather than vague guessing up front. Our UX and design colleagues now have important feedback through a working deployed system very quickly, and quick feedback through working software is a core component of the agile manifesto.

By putting off implementing the whole feature until later, we can use BDD to help us navigate the “chaotic” Cynefin space rather than just the “complicated” space. This in theory makes BDD twice as useful to our business.

Fast, fluid BDD

This all assumes that we have a fast, fluid BDD process, with close collaboration built in. If it takes a week to coordinate everyone for the next feature file, then the temptation is to have a long meeting and go through too many features, without a chance to pause, prototype, deliver and learn from working software. Maybe it’s time to re-organise those desks and sit all the members of your team together, or clean up your remote working practices, or block out time each day for 3 amigo sessions. You’ll be suprised how much small changes speed your team up.