Agility in Mind recently launched a new version of our Behaviour Driven Development (BDD) workshop. I worked with Ed to deliver the early sessions and develop the course content, and this got me thinking about how we choose the processes and tools that support us. A key part of the BDD workshop is to encourage attendees to think about how BDD might fit into their existing process, but in one session we ran a participant was very sceptical. As a business analyst, the main thing she wanted to get out of the course was to understand the benefit of adopting this new technique over the existing requirements gathering methods used by the company, and early that afternoon she had not heard enough to convince her. She raised with the group the fact that having written her first few scenarios she could not see the value of this technique over their existing requirements documentation.
Questioning the value in a new technique before making a change in the development process is the right thing to do. The question we asked during the discussion was “what problem are you trying to solve by adopting BDD?” In this case, the problem of defining what should be built at the start of a project was adequately met by the existing requirements document, and BDD simply solved this problem in a different way. We then looked at some of the additional capabilities a team needs to bring a successful product or feature to fruition:
- Technical people understanding the business goals
- The business understanding what is possible through technology
- Everyone understands how the existing product is intended to behave
BDD is a tool that is intended to help in these areas in addition to simply “capturing requirements”. Scenarios written collaboratively promote the right conversations and then blend seamlessly with the technology that drives the right thing to be built.
If questioning the value of a new technique can help improve your system, why not apply the same criteria to your existing processes and tools? If your goal is to develop valuable, relevant products then BDD will help significantly in part of the process, but there are many other problems to solve:
Here is something to try now. Draw up a list of all of the capabilities that you think will help you deliver successful products or features in your particular market. For example:
- Identifying opportunities
- Comparing new product ideas to decide what to do first
- Estimating potential revenue generation
- Ordering features to be developed
- Reducing the cost of change through maintainable code and reliable release capability
- Allowing innovative ideas to give rise to valuable new products
Then, on a large sheet of paper or whiteboard create a value stream map of your process from new idea to delivered product:
- Start with a new idea “light bulb” on one side, and a delivered “product box” on the other
- Add in all of the process steps that must be navigated in your organisation for a new product or update to be released
- Annotate with all activities, interactions, tools used, and typical timings. Include anything you have to do, wait for, or have approved. It might end up looking a bit like this:
Finally, evaluate the extent to which each of your processes and tools are helping the individuals in your organisation effect the capabilities you need. Or start with the capabilities you feel are most wanting and assess which part of your process could be improved. Either way, writing down what you need and then visually mapping out your development process is likely to make it clear what you need to do next.
