Recently at a ministry of testing meetup I got asked an interesting question. The question was: “How do I start BDD?”
To me this is interesting as it depends on what level your teams are currently at. Visualization is the key to start any kind of agility. So what I would suggest is start there.
What happens to the work? Is there a backlog of cards sitting in some online tracking tool? If so thats a great place to start. Get a big whiteboard and stick it beside the team. Add some columns that represent the work a team does with a user story. We can start simple, the board will probably ready something like: Next, Develop, Test, Ready for Production, Done.
Having the board beside the team will really help show blockers that can get lost in online tools. This allows the team to run a morning standup focusing on the stories as they move through the board. In the standup start with the closest story to done and work through the board. This hammers home the importance of getting work finished instead of starting new work.
After this I think you may see a lot of work in progress (WIP). There will probably be work queuing up in test, and developers working on multiple stories. So this is where we introduce a WIP limit. The Kanban idea of “stop starting start finishing” works really well, and a WIP limit is where you will notice this. The idea behind WIP limits is to encourage team work instead of work being passed off to different people. A good place to start is having a WIP limit set to the number of developers. If there are 4 devs on the team then start with a WIP limit of 4. This means that no other stories can be worked on until the 4 are done. This encourages pairing amongst team members, as the dev is no longer handing over work to a tester, they can work together to test something. This stops a queue of work forming in test, and helps eliminate blockers.
At this point you may be thinking you are not using all the capacity in the team. When a tester is working on a story surely a developer can be working on a new one? Well this leads me to ask what happens when a bug is found in test? Another story is spun up and now the developer has three cards to worry about. This means some fire fighting starts to happen or low priority bugs are deemed not important enough, and we end up going live with bugs.
It may seem counter productive, but less is more. If the developer is only allowed to work on one story at a time then bugs raised will be addressed straight away. It also means we no longer need a bug tracking tool, I have used red sticky notes on the story to show a bug.
So now as a team we can focus on getting stories done instead of starting new work and never getting anything fully finished. Have we done anything too stressful? Not really just visualizing our work and limiting our work in progress. There is probably enough here to start with. I am also aware I never answered the original how to start BDD question. But this is really laying the foundations. In my next blog I will show how easy it is to add BDD on top of what we have done here.
Paul Mccartney understood the value of working as a team in his frog song, “Win or lose, sink or swim….We all stand together”
P.S. This all came from a conversation at Ministry of Testing Dublins last meetup. I highly encourage everyone to check out @ministryoftest and find a meetup in your area.
For all the latest Dublin meetups check here: