Out at Agile Eastern Europe in Kiev last month, I was privileged to see Bjarte Bogsnes and his talk on “Beyond Budgeting”.
One of the elements that struck me most profoundly was when he separated the concerns inherent in budgeting. He noted that it was used for three things:
- creating targets
- allocation of resources.
The combination of all three, he noted, led to a lot of gaming and anti-patterns. By separating these concerns and addressing them individually, Statoil was able to adopt dynamic, transparent leadership and processes that have allowed them to be innovative at very high levels.
I (and others) see the same problems happening with estimation, which is often used for:
- predicting, and hence gaining the trust of stakeholders
- analysis and understanding of requirements
There are of course different ways to predict (I like probabilistic predictions from past data, as long as it’s in a predictable domain) and to gain the trust of stakeholders (deliver something!). Talking through examples of how a system might work is a great way to understand requirements, and particularly to uncover risk in those requirements. Prioritization is much easier when the risk is uncovered (and the easier it is to estimate, the less likely it is to contain all the discoveries that derail projects!) So estimation is not the only way, and may not be the best way, to do these three things.
Increasingly, I’m coming to see a similar conflation with BDD, which is used for:
- exploring what the system should do
- determining whether the system does what it should do (which is different to whether it’s actually useful)
- reducing the burden on the testers
But increasingly I’m seeing people using BDD as the only way to explore what the system should do, whether the system is correct (let alone useful), and help the testers out.
It’s OK to do traditional testing. It’s OK to knock up a small widget which goes and gets that information from those 3 different places so that the testers don’t have to go searching for it every time (and widgets like this might end up helping with automation too). And it’s OK to talk through what the system should do in whatever language suits you. BDD is just pretty good at those three things, but it isn’t the only way.
These are also three different things that seem to get mixed up together and confused:
And I’m seeing people struggle because BDD isn’t particularly good for things which require monitoring, and any capability which applies to the whole system generally requires monitoring rather than, or at least as well as, testing (code quality and maintainability, security, performance, etc.)
If you’re finding that a process isn’t working for you – be it BDD or anything else – then maybe have a look at what values you’re getting from it; what values others are getting from it; and what other options exist to fill in those gaps.