Recently my colleague, Theo England, broadcast a question:

We're thinking about running a … half-day class [about BDD] designed for business execs. Tell us the questions we must answer for it to be useful.

We received 60 responses, including some very good questions.

As well as providing valuable input into the design of our upcoming course, BDD for busy people, we felt that we should answer some of the questions in a public forum. This is the first in the series.

“How do I convince Business Partners/Stakeholders/Product Managers that there is extreme value in BDD despite the start-up costs/learning curve?”

This month on the Cucumber Podcast, Seb Rose and Matt Wynne speak to George Dinwiddie, an old friend of the pod and author of a new book "Software Estimation without Guessing".

Next week the BDD community will gather remotely for Cukenfest. This intimate event will inform you about the latest developments and thinking in high-performing BDD teams as well as being a space for you to share your own experiences with like-minded people.

In the build-up to the conference, we spoke to Abby Bangser about what people can expect from her opening keynote, her thoughts on the demands on effective testing and agile ceremonies in remote teams.

Soon the BDD community will gather remotely for Cukenfest, a two-day meeting of the BDD community in which we will hear stories about how we can become better software professionals and stronger teams. It'll also be your opportunity to share your own experiences practising software with peers taking a similar journey.

On of our keynotes this year, Emily Bache, took some time out to speak to us about Approval Testing, the development and ideas in her blog, and her thoughts on how software teams might operate post COVID-19. You can learn more about the conference and Emily's keynote on the CukenFest website.

In the build-up to Cukenfest, we spoke to Rebecca Wirfs-Brock who will give the closing address. We asked Rebecca a few questions about her upcoming keynote and how she came to discover these ideas and become one of the world's most prominent figures in this space.

This month on the Cucumber Podcast, we welcome Diana Larsen, a world-renown author, speaker and co-founder of The Agile Fluency Model.

Previously, we extracted our a simple implementation of the screenplay pattern from some existing Cucumber automation code, turning this:

Given('{word} has created an account', function (name) {
    this.createAccount({ name })
})

…into this:

Given('{actor} has created an account',
    actor => actor.attemptsTo(CreateAccount.forThemselves)
)

We’re going to continue this refactoring, looking at how we can compose granular interactions into tasks that model higher-level concepts in our problem domain.

This month we dig into the financial risks of open-source software. Cucumber's success has led to many of the world's most valuable companies relying on its software for critical parts of their codebase. So what are the financial risks for companies who use OSS tooling every day? And who pays when an OSS tool is no longer looked after? Chairing the conversation is Seb Rose who is joined by his colleague Dermot Canniffee. Answering the questions is Aslak Hellesøy who created Cucumber some 12 years ago.

In the previous post in this series, we explored the need for a new kind of pattern for organising our test automation code.

Now we’re going to work with this little codebase to refactor it towards the Screenplay pattern. By taking the existing code and shifting it, step-by-step, towards the pattern, my hope is that you’ll see how you could do this to your own code, should the fancy take you.

Last week Elisabeth Hendrickson published a blog post called Momentum > Urgency. Please go read it if you haven’t already. In the post she shared a list of observations that she had made when teams achieved a sense of momentum:

• Everyone on the team has a shared understanding of the big picture and what “good” looks like so they don’t burn cycles on unnecessary or non-useful work.
• The team breaks the work into small pieces (a couple days of work at most) that still represent incremental business value (even if not user-facing features).
• The team embraces the technical practices necessary to ensure that the code they deliver does what they intended it to do.
• There’s an engaged and responsive product manager* who is considered part of the team, and who does hands-on acceptance of the work.
• When the work is “accepted,” it’s done. The entire team can stop thinking about it.
• The work, and the status of the work, is visible to everyone.
• The team as a whole has a strong sense of partnership and trust, so the visibility never becomes a mechanism for micromanagement.

Reading the list, I realised that these were very similar to observations that we have made of teams that practiced BDD successfully.