CukeUp! 2015: Call for Papers


After a sold out 2014 conference, CukeUp! returns to London for its fourth iteration. The conference brings together all stakeholders who use BDD for two days of talks and workshops, helping teams to crack complex software problems. We’re on the look out for talks that will inspire and educate others around BDD and it’s wider practices – so if your team is just starting out on the road to BDD, you’ve got some nifty tips to test the untestable or you’ve got a use case on how to bring technical and non technical teams closer together – we want to hear from you.

We are planning for talks to last around 30 minutes, so keep introductions to a minimum and allow time for questions!

To submit an idea for a talk head over to the Call For Papers page. We’re especially keen to hear from people who haven’t spoken at conferences before. If you are worried about presenting alone, feel free to pair with someone on your team. The CukeUp community is very friendly and this is a safe way to dip your toes in the public speaking arena. If you need some help a great place to start is here.

If you have any questions then please contact us at

The CfP will close on January 23rd. All presenters will be contacted the week commencing February 2nd.

Please be sure to read the Skills Matter Code of Conduct. It outlines what we expect from our speakers and guests so that we can continue to provide a fantastic environment to learn and share skills for everyone.

While It’s Compiling: Skills Matter interviews Mary Thorn

While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.


Mary Thorn is a Director of QA at ChannelAdvisor in Morrisville, North Carolina, and she has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques.

We caught up with Mary ahead of her talk at CukeUp! New York City on the 30th September.

In your talk at the upcoming CukeUp! Conference in New York you’ll be looking at the promises of Behaviour-Driven Development (BDD) and Acceptance Test Driven Development (ATDD), namely, greater collaboration between Product Owner & team and focus, along with an increase in the value produced. Without giving too much away, can you give us a quick insight into how you see this working?

I feel that “How to implement BDD?” is the million dollar question. I’ve been successful on four projects and, even though I feel I have a lot more to learn, I want to share my experiences of what’s been successful. BDD can be implemented in Waterfall and Agile processes, with or without automated testing. My experiences have all been in an Agile process with automated testing to back it up, although I have examples from my current job of Waterfall projects who have implemented BDD without automated testing.

The first step in the process for me has been selecting which automation tool to use. Next, I start to introduce the topic of BDD by either a lunch-and-learn or community of practice event. The goal of this step is to start to explain the practice and benefits. My hope is that someone in the room will help me champion this process. A lot of times, the QA team reporting to me are yearning for more collaboration and to be involved in requirements definition, so it is not a hard sell. The biggest pushback typically come from the Product Owners and Business Analysts because they feel that we are adding more work to their plate. In reality we are not, we are adding more upfront work, but less work and rework later in the process.

Next I start to partner and build relationships with the Product Owners, Business Analysts, Functional Analysts, Scrum Master and Development Manager. I encourage them to engage in what we can do as a team to build a better product and make the clients happy. I also start to plant seeds with the QA team to bring up BDD as a retrospective item for the team to try. The next step is running a BDD workshop for the team. Once everyone is trained after the workshop, I encourage the POs or BAs to take just one or two stories out of the next sprint and to take a stab at writing the Gherkins.

After having one-to-two stories with feature files in hand, the PO will hold a grooming session with the entire team (including, PO, Dev and QA) to discuss. The PO will introduce the user story,the GOAL they are trying to accomplish, the acceptance criteria, and the scenarios. Most of the time the scenarios will be 75% of the conversation. During the discussion you will add, remove, and refine the examples as you discuss. At this point the “Whole Team” now owns the feature files and examples, not just the PO or QA. Once everyone agrees on the scope, the team will then estimate the size of the story in points.

Next is sprint planning with the Whole Team. I ask the team to bring the feature files as well as the User Stories to help when breaking stories into tasks. I have found by doing this, estimates are smaller and more accurate as most examples are covered.

Once the sprint starts, Dev and QA review the feature file together one last time to make sure it’s complete. Any additional scenarios at this time should also be reviewed with the whole team. Then developers use TDD to code the scenarios in the feature file. Due to the fact the developers already have the tests from the examples and scenarios they can go ahead and write their equivalent unit tests. The QA automation engineer can start developing in parallel as long as they have discussed with the developer the things that the developer needs to do to make that story “automatable”. The goal is that Dev and QA finish at the same time and that, when all the tests “Go Green”, then the PO can accept that the story is “Done” because all the scenarios and examples pass.

After doing this for almost 3 years now, I’ve seen these benefits:

  • Expectations, Goals and Business Value are communicated and challenged and clarified with every story
  • Defined Scope
  • Overlooked Requirements Revealed
  • Tangible Reference Materials
  • Accurate Story and Task Estimations
  • Deliberate Collaboration Between QA/DEV/PO
  • Increased Productivity
  • Decreased Bugs from SIT/UAT/PROD
  • Commitments are met (and often times exceeded!)

With that in mind, what are the main factors that can pose a threat to getting BDD right? Are there any classic pitfalls you see recurring again and again?

My main pitfall I run into time and time again is that the Product Owners don’t think it is their responsibility to write their acceptance criteria in acceptance test format. This role is solely the QA’s responsibility and that it is just putting additional work on their plate. What they don’t understand at the beginning is that the discussion helps to uncover missing requirements and helps the team build it right the first time. I eventually get there, but it’s a pitfall that happens over and over again.

Eric Evans, who coined the phrase ‘Domain-Driven Design’, is speaking as well this year. What do you think are the main connecting threads between DDD and BDD?

I have not worked on a project yet where the DDD concept was used. However, I have kept up with the community and I think I understand the concepts. I still think these two concepts (BDD and DDD) have the same goal which is “creating conversations so that you build the right thing the customer wants the first time”. These are just two different ways to meet that goal.

This isn’t the first time you’ve spoken at CukeUp!, and we’re delighted to have you back after your talk last year. As the conference is built to be as much a social event as a series of talks, during your experience last year were there any conversations you had with speakers and delegates which have shaped your work or ideas over the past year?

They have! I am super excited about the Cucumber Pro tool that is coming out. This is a much needed feature in our open source community and one that I have yearned for the past four years working with Cucumber. I currently have left the company I worked at last year who used Cucumber and now I use it’s sister tool Specflow and I hope I can convince Aslak [Hellesøy] to integrate with it in the future. I might have to request a name change though 🙂

And obviously, you’re returning to a CukeUp! that’s slightly different from last year with the addition of two half-day workshops exploring non-technical applications of BDD. Do you feel there is a wider need for non-technical solutions in BDD at the moment? Essentially, do you feel that automation runs the risk of degrading or avoiding regular and constant communication

Great question, and one that I am all to familiar with. Both companies that I came into that had implemented Cucumber before I got there said they were BDD shops and really were just using it for automation purposes. This tool is great for automation but even better for communication and I do feel we are running a risk of avoiding regular and constant communication. However if implemented correctly, you can put in process steps that avoid this and I hope to discuss that in my talk.

London is blessed with a variety of conferences and meet-ups that support the BDD community. You’re based in North Carolina, is there a strong ‘after-hours’ software community there?

There absolutely is. The ‘Research Triangle Park’ area is one of the fastest growing cities in the US for IT jobs. We have several Agile Meetup groups and Agile Testing and Automation groups. This year I co-chaired our Bi-Annual TISQA testing conference, as well as our first Agile conference, TriAgile.

CukeUp! New York City

Mary will be speaking at this years’ CukeUp! conference Tue, 30th Sep – Wed, 1st Oct at DUMBO Loft, New York City.

She will be joined by a host of leading names from the world of Cucumber including Aslak Hellesøy (creator of Cucumber & co-founder of Cucumber Ltd.), Eric Evans, George Dinwiddie, Paul Rayner and many more!

This two day conference will explore various aspects of BDD in this New York community event. CukeUp! is organised and curated in partnership with Cucumber Limited and also runs annually in London.

Click here to book your ticket now!

This Week at Skills Matter: 28 April – 2 May

Here’s what’s coming up at Skills Matter this week!


Luke Hohmann


We have a fantastic kick off to the week today, with three In The Brain talks from some amazing experts:

Adam Gundry, Haskell Consultant for Well-Typed LLP, will be delivering a talk dedicated to employing Haskell records successfully within large projects. He will explain how he has extended Haskell to overcome common frustrations with records. Adam completed a PhD in 2013 on combining Haskell with dependent types, and is a seriously keen Haskell programmer.

Next up, Luke Hohmann will reveal how his team at The Innovation Games Company have been working with organisations to transform the retrospective process, using collaboration games to maximise the wisdom of the entire organisation and improve enterprise retrospectives to work. Luke is the founder and CEO of The Innovation Games Company, author of three books, and has studied not only data structures and artificial intelligence, but cognitive psychology and organisational behaviour. His playfully diverse background and life experience have uniquely prepared him to design and produce serious games!

Last (but certainly not least!) Shashikant Jagtap will tackle Behaviour Driven Design. His talk will show how using Headless browsers like PhantomJS and Zombie, can actually speed up the entire BDD process, making running scenarios easier to maintain and less time consuming.

Shashikant has been working in the Agile BDD environment as Developer in Test for the last few years with massive interest in BDD tools. He has explored BDD tools like Behat & Cucumber and integrated them with open source tools to use in test automation. He last spoke at CukeUp! 2014 in London on Headless BDD & Responsive Test Automation, and we’re delighted to have him back!


We host a performance and predictability special from the London Java Community on Tuesday, where Richard Warburton will be informing attendees why access platforms are important and what kind of speed you can gain with them. He will discuss how you can write simple high level code which works well with these kind of patterns.


Neo4J return with an evening based on graphs from the worlds of gaming and recruitment. Mark Wright and Yan Cui will cover topics from building your own private social network using Neo4J, to overcoming the challenges of modelling and balancing the economy of a large-scale game.

The MEAN Stack User Group join us for the first time to discuss Forms Angular – a simple framework built on top of the MEAN stack that enables you to generate forms super quickly. Mark Chapman will show how he used MEAN stack to build forms-angular while Tamas Piros will walk through how to use geospatial data with MongoDB.


The Functional Londoners will be here for a hands-on session with Michael Newton who will provide expert advice on how to construct and hack providers already out there. This will then leave you with the opportunity to create your own first type provider or hack some of the excellent open source providers that already exist.

Codebar, who are also joining us this week for the first time, will be aiming to make the tech scene more diverse by making the jump into coding just that little bit easier. The night will consist of talks that will answer important questions for beginners, introducing attendees to programming and its importance to the real-life stories and struggles of becoming a software developer.

And finishing off the week, the London Java Community will be back with a talk covering the architecture behind LMAX Exchange. Sam Adams, who leads one of the development teams at LMAX echange, will give an overview of their full architecture – all in plain old Java.

Guest Post: “We don’t ‘do Agile’ – We use a toolkit and not a rulebook”, Jenny Martin & Pete Buckney

This is a guest post from Jenny Martin and Pete Buckney from the Sparkle & Co Made Team. They will be giving an In The Brain Talk on ‘Examples Soup-to-Nuts’ at Skills Matter on 20 March, sharing their approach to Specification by Example, including how they invest in examples, and use them to drive collaboration and feedback at all levels in the business and all stages in the process. You can register for this free talk here.

jenny-martinJenny works as IT Solutions Director for Sparkle Coupon Services and also provides consultancy in collaborative software development approaches. Jenny believes that great leadership is about creating highly participative teams and encouraging shared commitment and responsibility.  Follow Jenny on Twitter @jennyjmar or at

pete-buckneyPete is a founder director of Co Made, and is passionate about using collaborative approaches to build software that changes businesses for the better. Pete also provides coaching and training in BDD tools and approaches. Follow Pete on Twitter @PeteBuckney or at

The Problem

During the past 10 years there has been a massive transformation in Agile software development practices. Many companies are experiencing some pain. They have invested heavily in Agile transformation programmes but are either not availing of the benefits of Agile, or are having difficulty scaling these practices within their organisations.

Why is this happening?

The Rulebook

Photo: Flickr/Amy Allcock

Photo: Flickr/Amy Allcock

Agile tends to suffer if implemented as a rulebook. This may be top-down, where a particular Agile implementation is mandated across an organisation, with training courses and defined procedures. It may also happen bottom-up, where exposure to evangelistic Agile messages may lead individuals to believe there is a One True Way out there that will solve all their problems, or may leave them struggling for the confidence to find out what actually works, due to fear of breaking ‘the rules’ or being classified as ‘not Agile’.

We believe that an effective way of working is best achieved by carrying out the work of trying to deliver value, and reflecting, tuning and adjusting our approach. Blind imposition or adoption of rules removes flexibility to respond to change, and halts the experimentation that leads to greater effectiveness.


In the end, what we’re trying to do is put together people with a need and a capability, and collaborate on evolving something to meet that need. We want to measure how good we are at selecting options, providing opportunities for feedback and delivering the intended value, and how much waste there is along the way.

We see some recurring patterns of Agile implementation that do not optimise the overall delivery of value:

Development-Team-Centric Approach

Agile often seems to exist only within the development team with practices such as rigorous protection of sprint scope actually preventing interaction and change, and protecting the daily lives of the developers rather than delivering value to the business.

Product Backlogs / User Story Hell / Water-Scrum-Fall

Where we see a large backlog that reads like a list of product features, this is usually a sign of a waterfall project in disguise, even if the stories have been written in a “I want to…” ”so that…” format in an attempt to link them to delivered value.  For example a team may be happily churning through all the items in the pre-ordained backlog without any focus on delivering the highest priority business capability or learning opportunity as early as possible.

Celebrating/Measuring/Optimising the Wrong Thing

This is often linked to a development-team-centric approach. For example, a team may have very accurate burn-down measurements and be improving their velocity every sprint, but may not have focused on the other areas of waste, in particular in the transitions of work in and out of the development team.

In some cases the fundamental impact of what is being delivered is not measured at all and teams get better and better at efficiently delivering features that nobody wants or uses.

Focus on Automation

Automation can deliver amazing value (for example Test-Driven Development approaches can create code of astonishing flexibility) and Continuous Delivery can allow for much earlier feedback, but a focus on automation can be symptomatic of neglect in other areas. To be effective, automation needs to be introduced selectively and at the right time – it’s more important to get conversations working that lead to high quality tests than it is for all tests to be automated.

Tool Focus

We like shiny new tools in IT, but if the process isn’t working or we don’t know what we’re trying to achieve, implementing a tool isn’t going to solve it – it’s more likely to disguise the underlying problems, or at the very best speed up a bad process.

Getting distracted using tools whilst forgetting the underlying principles associated with their use is an anti-pattern. The goal is not to implement the tool or the process, i.e. to ‘do Scrum’ or ‘do Agile’.  The goal is the destination, not the method of transport to reach it.

Back to Basics

Would we be better off putting down the rulebook and getting back to basics? To demonstrate this point, let’s ask ourselves – which team demonstrates greater agility?

Photo: Flickr/Tark Siala

Photo: Flickr/Tark Siala

Team A: Vehemently protect their sprint scope once it has started, despite desperate pleas from the business to include a new requirement.  They have a consistent burndown rate & have been improving their velocity sprint on sprint.  They can now accurately predict how many stories they can deliver in each sprint. Releases have gone smoothly but nobody knows if the features delivered over the last 6 months are offering any real business value or how to measure any value achieved.

Photo: Flickr/donjd2

Photo: Flickr/donjd2

Team B: Don’t know what their velocity is. They have regular prioritisation sessions with the business and frequently change direction in response to changing market pressures. They sometimes don’t achieve all they set out to in a sprint, but have a very clear vision on the business goal they are trying to achieve.  They set up small and  regular releases as experiments to measure the impact of the new business capabilities they are delivering and are ready to take a different route if the road ahead becomes blocked. They have confidence that they can grow a successful business around the products they are delivering.

What if instead of implementing ‘Agile’ we set out to answer these questions:

  • How do we get better at identifying smaller increments of business value to deliver?
  • How do we organise ourselves better around the products and business capabilities we deliver to facilitate a shorter feedback loop?
  • How do we collaborate more effectively?
  • How do we bridge communication gaps between the technical & business teams?
  • How do we get the stakeholders more comfortable with flexible scope?
  • How to we collaborate on requirements ‘just in time’?
  • How do we make our outputs and documentation more valuable and support our new product structure more effectively?
  • How do we prioritise our work so that we know we are spending our efforts in the right direction and can respond to change quickly?

To help us with these challenges and to build something great that makes an impact,  we need more than a single tool or set of instructions.  We need a selection of tools, processes and techniques to choose from as well as the craftsmanship and experience to use them to their greatest effect.

The Toolkit (Here are some things that work for us)

Photo: Flickr/veryuseful

Photo: Flickr/veryuseful

We’re keen to share some of the tools that we find particularly useful, the details of how we use them, and how they help us deliver value.

We keep coming back to Impact Mapping as a superb way to ensure everyone shares the big picture, and then lightening-fast identification of the quickest path to the next piece of value. We also identify items with a focus on what we want to learn next, and the minimum work required to enable this learning.

We use Dream Demo Visualisation to map out the specific demo we want to be able to run, including early sketches of the specific examples that will be demonstrated, rather than listing product features. Like Story Mapping, we find this approach helps to identify a quicker route to value.

We love Specification by Example, and the ubiquitous language of Domain Driven Design. We invest in our examples, and maintain the same examples from initial dream demo visualisation, through requirements conversations, into Test-Driven Development, and then consolidate into Living Documentation and Automated Testing.

We use a concept of Continuous Acceptance where BAs, testers and developers will be in close communication as an item is developed, and an item will be accepted within minutes of a commit, rather than later in a sprint cycle. This also means our showcases to stakeholders are not acceptance events, but are themselves opportunities for feedback on the new items and a chance to factor changing priorities from the real world into selecting the next item of value.

Overall, what is most important to us is maximising opportunities for feedback and learning. Our Feedback Onion Model captures our thoughts around which tools and examples are most appropriate to facilitate collaboration at every layer of our business.  We work really hard to ensure we are collaborating on the most important examples in order to get fast feedback on our ideas and assumptions in the real world.  Questions such as ‘Should we pivot or persevere?’ and ‘Can we build a viable business around this?’ are more important to us than ‘Are we doing Agile right?’.

Don’t forget, you can hear more from Jenny & Pete at their In The Brain Talk on ‘Examples Soup-to-Nuts’ at Skills Matter on 20 March.

cukeup-14-800-px-v-300-px (1)

Jenny and Pete are also each presenting at CukeUp! 2014. Jenny is running an interactive workshop on Impact Mapping and Pete is talking about ‘Conversations, Examples and Living Documents’ and sharing some technical tools that support these approaches. Register for your ticket now!

While It’s Compiling: Skills Matter Interviews Matt Wynne

Matt Wynne

While It’s Compiling is a new series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

This week on While It’s Compiling we sat down with CukeUp! programme lead and organiser, Matt Wynne. Matt is a BDD fanatic and is currently working on Cucumber Pro.

1. What’s this year’s theme at CukeUp!?

The theme is “one big happy BDD family”. With the birth of Cucumber Limited this year, we want to host a gathering for all the different BDD tribes – the Specification by Example people, the ATDD people, and the people using tools that aren’t named after a variant of the Cucumis sativus, like the PHP Behat community.

2. What are you exploring at the conference this year?

Personally, I’m interested in challenging the BDD orthodoxy a bit – trying to get some more balance into the debate about when BDD is the right tool for the job. I see some teams who have overused Given / When / Then and that’s what I’ll be talking about. I’m hoping some of our invited speakers will be sharing that kind of experience too.

For me, building software is all about people, working together. There’s also a huge amount of uncertainty involved – if the problem had been solved before, you’d be able to buy something off the shelf. BDD puts those two things together – people working together in the face of uncertainty. It gives us tools to communicate better about what we do and don’t yet understand, and to explore the stuff we don’t understand.

3. What projects are you working on at the moment?

I’m 100% focused on Cucumber Limited. That means working on our flagship product, [Cucumber Pro], as well as starting to market and sell our training, consulting and support services. I’ve been providing training and consulting to Agile and BDD teams for the last few years, but since we launched “the company behind Cucumber” we’ve been inundated with requests to visit people and help them. We haven’t even had a chance to put up our website yet!

Cucumber Pro is a paid-for collaboration platform for BDD teams. Using Cucumber Pro, anyone on the team can read, review and even commit changes back to source control through a tool that feels as accessible as Google Docs. It even supports collaborative editing, the same way as Google Docs does, which works especially well for distributed teams. We’re also working on features that will show results and screenshots, really bringing the living documentation to life.

We want Cucumber to be a sustainable ecosystem, and we expect that the revenue from Cucumber Pro will buy us the time to keep working on the open-source suite of Cucumber tools for the community. It’s an exciting time for Cucumber!

4. If you had one piece of advice for your younger self, what would it be?

Little steps!

5. What would you like to ask the community?

What do you think about us starting Cucumber Limited? Are you excited for us? What would you like us to prioritise?

Are you excited? What would like to see first from Cucumber Limited? Tweet your answers to #whileitscompiling or @skillsmatter 

Matt is the program lead at CukeUp! 2014 and will also be giving a talk, check back at Skills Matter for updates and tickets!  

cuke-up-1000-px-x-300-px (1)