Why we built Jumpstart

“We’re doing the next project right”, Scott said. He approached me in the hall after a particularly contentious client meeting. It had been a rough one. The client had been especially demanding and changed his mind constantly. Every demo meeting nothing was good enough, or what he had asked for. The the small consulting firm we worked for took a bath financially on the project. It was not a great time in my career. I’d recently transitioned out of software engineering and into project management and boy was I getting an education.

Scott wanted to talk to me about this new software tool he’d discovered. It was called Cucumber. He said we could write the customer’s requirements in a structure that Cucumber could then connect to our automated tests. We already had pretty good test-automation discipline for the time, why not connect our tests directly to the customer requirements? If the requirements turned green when the tests pass, and if we could agree on the requirements up front with the customer, it would be a win win for everyone. Off to our side the beleaguered head of QA was listening. Listless but somewhat hopeful, she was tired of feeling responsible for our inability to nail down the customer requirements before we started development. I felt terrible for her, I felt like it was my fault.

Scott went on, “The structure of the requirements was a bit funny but easy to grasp.”

Scott explained, “The requirements go in text files called ‘Feature’ files.”

“Ok, I know what a feature is”, I thought.

“Each feature file is broken up into ‘scenarios’. Each scenario can have several steps just like our tests.”, he continued.

“Ok this isn’t rocket science, we can do this”, I thought.

He went on to explain how each “step” in each scenario began with a keyword that corresponded to the context, action, or the outcome of the scenario, just like our tests.

“Interesting”, I thought.

Aslak Hellesøy, the creator of Cucumber who’d I’d come to know many years later, had curiously chosen the words “Given”, “When”, and “Then” to help distinguish which steps were context, action, or outcome.

“Ok, that’s a little odd because I don’t usually begin sentences with ‘Given’, but English is complex”, I figured.

Scott went on to demonstrate a simple example. He opened up a text editor and typed this into the file.

Then he typed a few more commands in his code editor and ran his code. A browser window popped up, buttons were clicked, and Lucy got her discount at checkout. When the test concluded the text of the scenario was printed on the console in green. The test had passed!

“They call this Behavior Driven Development”, Scott said. They could call it Banana Driven Development for all I cared, it worked!

I knew this would be a game changer for us. If I could just get the clients to agree to the behavior language in these Cucumber scenarios it would save us so many billable hours wasted on re-work and misunderstandings.

Indeed the next project ended up having an equally difficult customer but we sailed through like champs. Every demo/review meeting the team walked in with confidence. Each week the team was prepared with green tests for the scenarios we’d agreed too in the prior week.

I eventually moved on from that consulting firm and began doing various other types of software development coaching. Every where I went the thing that made the most solid impact on teams was understanding the tests and getting agreement from the customer up-front. It wasn’t always a piece of cake and over the years I’ve learned some great techniques that streamline what I like to call the most difficult task in software development: Describing how the software should behave. Such that programmers, testers, and customers all have the same shared understanding.

Years later my coaching practice was doing well and I was teaching a lot of BDD. A mutual colleague introduced me to the Cucumber team and we hit it off. I ran training for them in the US for several years before they were acquired.  In all those years of training I’ve come to learn what works and what doesn’t for teams.

The reality is, the principles of Behavior Driven Development are not that complicated. Anyone can learn them, and we have an especially fun and engaging way of making that happen. It’s not the whole story though. Just like with any good new thing at work, it takes time to fit it into our processes and tools, as well as to form an organizational habit.

This is what prompted me to create Jumpstart. It’s a totally new way to learn BDD, but focused on making it stick. I’d love to tell you more about our unique approach. Set up a call with me below and I’ll give you a demo.