Next week Matt Wynne will run a half-day BDD workshop for business leaders and execs in London. Matt sat down with our co-hosts Adventures with Agile to discuss the challenges of adopting Behaviour-Driven Development in a large organisation. Earlier this week we released a further handful of tickets for this very popular workshop.

This was originally posted on the Adventures with Agile blog.

What do you think are are the biggest challenges that organisations face in software development?

I think the biggest barrier I see right now is the way software development is procured at an executive level. Too many organisations still plan for fixed-budget projects, with a fixed, overly-ambitious scope. When both scope and budget are fixed like this, the promise of agile – a codebase that can continue to evolve with the changing needs of the business – is simply impossible to deliver. The constraints of a fixed deadline and scope force teams into short-term decisions that compromise the quality of their work. Essentially they’re not able to do their jobs properly.

We’re seeing much more success where organisations align funding around product-based teams, with investments made toward more flexible business goals or outcomes. This allows teams to plan for the long-term, working at a sustainable pace in partnership with their business stakeholders to prioritise and continuously deliver the most valuable features to meet those goals.

It takes commitment to make BDD a success in your organisation. You need to invest in people to give them new skills, and you need to invest in codebases.

What has been the industry’s response to BDD?

We’re seeing a “second wave” of agile adoption, where organisations have learned the basic moves of Scrum – daily stand-ups, user stories, story points – but they’re still seeing problems. Problems like a lack of predictability – things usually take longer than they estimated, sometimes quite a lot longer. They’ve noticed that there are often communication problems – developers misunderstanding requirements, for example, or business people being too busy to talk to the developers to a necessary level of depth. There are also quality problems – defects – that are leaking out regularly into production or only being caught by manual testing.

They’re also experiencing a massive load on their testing specialists. They may have started automating some of their tests, but it’s still a huge burden to have to keep regression testing everything every sprint. They can’t keep up!

These are the organisations who are now discovering that they need to up their game, and look to BDD as a solution to these problems.

Why do you think that some leaders/managers or organisation aren’t convinced of the benefits that BDD offers?

I wonder if rather than them being unconvinced of the benefits, it’s more about them fearing the costs. It takes commitment to make BDD a success in your organisation. You need to invest in people to give them new skills, and you need to invest in codebases to pay back sometimes years of accumulated technical debt to make them amenable to test automation. While this is happening, you may need to accept that the pace of delivery will slow down for a while.

The promise is that once you’re through this hump, this period of investment, you’ll be able to deliver valuable features to the business at a much faster pace, indefinitely.

If you’ve experienced this faster pace for yourself, it’s much easier to summon the courage to get everyone through that hump. I completely understand why someone would be skeptical or concerned about making that kind of investment without having seen the evidence with their own eyes.

What impact does BDD have once successfully introduced?

Here’s Jo Wickremasinge, ex Head of Product for BBC Weather talking about exactly that:

Essentially, by shifting testing to the left in your delivery process, you’re reducing the amount of wasted time and effort spent finding, reporting, tracking and fixing defects. We see teams who are shipping features to production faster than ever before and enjoy more collaborative relationships with their business stakeholders as a result.

Fast, reliable tests mean they’re able to use practices like continuous delivery, and testers are freed up to do more interesting exploratory testing leading to even higher quality levels.

How long have you been working with BDD? What inspired you to get involved?

In 2008 I went to the SPA (Software Practice Advancement) conference where I saw a talk by Dan North and Joe Walnes called Awesome Acceptance Testing.

After that talk I was hooked. I was so hungry to be part of this community of people who cared as much as I did about helping business and tech people to really communicate. The trouble was, this community were all using open-source tools and programming languages like Ruby, and I had only ever been a developer on the Microsoft stack.

My wife Anna had just graduated after seven years studying to be an Architect so we decided we could afford for me to quit my well-paid job as a C# contractor and I took a 50% pay-cut to write Ruby for a startup. My new team was one of the first users of the RSpec Story Runner, which became Cucumber. After a year of using the tool I was one of the most experienced people in the community, and I was asked to join the core contributor team. I met some wonderful people like David Chelimsky and Aslak Hellesøy, and the rest is history.

What can leaders/managers expect to learn by attending the 1/2 day workshop with you?

If you’re a decision-maker who is curious about BDD but yet to take the plunge, we’ll give you enough information to make a decision on whether this is the right time for you and your organisation. We won’t pull any punches, and make sure you’re aware of the costs, benefits and the most appropriate contexts where you can really reap the benefits of BDD.

BDD for busy people will take place in London on March 15th. For full details on the half-day workshop, head to the AWA event page.