If you’ve heard me speak at any conferences or read my blog over the last few years, you’ll know that I’m really, really into Real Options.
I’m half-tempted to get “Options have value. Options expire,” added to my tattoo. The principles which Chris Matts and Olav Maassen champion have become such guiding forces in my life that many of the decisions I make are only done in order to increase the number of options available to me. Once the whole innate phobia of uncertainty is out of the way, it’s a fantastic way to live life in freedom and with fun.
Real Options are also a phenomenal model for managing risk on software project – and not the only brilliant idea that Chris and Olav have!
So imagine my absolute joy when I saw this in the works – a graphical novel, fun and easy to read and understand, dealing with all kinds of ideas around risk management. The skiing story at the end of the first chapter (downloadable from the link) is the same one that Chris shared with me to help me understand his ideas.
Chris and Olav describe it as “a business graphic novel on managing risk. The book is a culmination of their collaboration on the real options model over the last six years. It provides examples of how to manage a project using the real options model and outlines a simple technique for making better (informed) decisions. It also covers more advanced topics such as information arrival process, game theory, feature injection, paradox of choice and how to deal with uncertainty. While geared towards project managers, the book benefits anyone making decisions in their job or daily life. Chris and Olav focus on making risk management easily understandable as everybody does this every day without being aware of it. ”
I am very confident that this book is going to be ground-breaking. I am so confident that I’ve already laid out £500 of hard-earned cash for a chance to star in the book (sorry, that option has expired). I don’t regard this as charity. This is me doing something small to pay Chris and Olav back for their guidance and help over the last few years, and it’s money they’ve helped me earn anyway. Estimated publishing date is Winter 2012… assuming they manage to raise the funds to kick it off.
If you would like to help these two fantastic people get this novel out of the door and benefit from the same help they’ve given me, please go to the Sponsume site before April 14th and pick an option. You never know – you could be the proud owner of a limited edition of a book that turns out to be as ground-breaking as “The Goal”*.
I often hear things like, “Tell the team what to build, but don’t tell them how to build it.”
Or, “A feature is what you’re building. A story is how you’re going to build it.”
Or, “When you’re doing TDD, don’t worry about the internals of the class. The API is what it does. The internals are how it does it.”
Here’s the thing. When we write code, that’s how we’re creating a story or a feature. It’s also how we’re implementing the architecture. It’s how we’re managing security and providing an audit trail and doing a bunch of other stuff.
And that’s how we’re selling more goods. And how we’re keeping things maintainable for the future. And how we’re preventing data theft. And how we’re correcting our mistakes.
And that’s how we’re staying in business. And how we’ll be able to react in the future. And how we’re able to sleep at night. And how we learn.
- The code is how we deliver a story.
- The story is how we deliver a feature.
- The feature is how we give the users the capability to do something.
- The users’ capabilities are how they deliver a business goal.
- The business goals are how stakeholders implement a vision.
- The vision is an idea of how to make money, save money or protect revenue.
- And we could keep going if we wanted to…
Every goal, no matter how big or small, is the how for someone’s what. (The how and the what may come from the same person, but the interesting stuff happens when they’re different people. Or behave like they are.)
If only life worked by being able to divide a bigger what up into smaller pieces and manage them appropriately, then it would all be fine! Unfortunately the code has to work with other code to deliver its value. The features have to work with other features. The system has to work with other systems, users have to work with other users and the goals of one stakeholder have to align with the goals of another.
This is why we have root cause analysis and the “5 Whys” – because when we can see the higher-level goals and deeper-rooted problems, we can understand better how our own actions fit into them, and what they deliver – for better or worse. This is also true for other domains than software.
It doesn’t really matter much whether we call them features, stories or tasks, as long we appreciate that they’re how we’re delivering to those higher-level whats, and we have a pretty good understanding of the whats and how to test that we’ve achieved them, even (especially!) if the what is a learning or exploratory goal.
Of course, we’ll get the how wrong occasionally and fail to deliver the what. But that’s what feedback, in its many forms, is for.
Another question that people often ask around or to me is, “What’s the difference between Acceptance Test Driven Development and Behavior Driven Development?”
To explain, I’ll go back to the time when I first learnt BDD.
BDD started at a unit or class level
Dan North started doing BDD at a unit or class level, as a replacement for TDD – a mechanism for describing the behaviour of code and providing examples, without using the word “test”, because it turned out that this clarified a lot of the confusion (and I still find it much easier to teach TDD if I avoid the word “test”, whatever I subsequently call it).
It was only when Chris Matts said, “That looks quite a lot like analysis,” that Dan began taking it out to describe the behaviour of whole systems of code.
ATDD practices at the time weren’t all that solid
When I came across BDD (late 2004), I was working on a project which had been driven quite heavily with ATDD – at least to start with.
This project had 160 acceptance tests. They all consisted of lists of text boxes, button clicks, locating more text boxes and repeating until a particular outcome was reached. They were lengthy. They were rigorous. Unfortunately, at some point someone had introduced a dialog box into the flow, disrupting about 30% of these tests. There were another 10% also failing, possibly for similar reasons.
It took a couple of days for two of us to work through them, fixing the tests. We got most of them working, but not enough for anyone to actually care about them. The acceptance tests were making things hard to change.
BDD changed the landscape
Dan has since said that JBehave was “just a thought experiment”, and he didn’t really expect anyone to use it. (That’s good, because it JBehave 1.0 was pretty unusable, at least at a scenario level). It worked as a thought experiment, though, and lots of people started doing ATDD in a very different way – creating examples of how their system worked, and using those examples to explore the scope of their systems as well as the responsibility of their classes. Lots of people started working outside-in, from the UIs through which users experienced the system’s behaviour, to the controllers, the domain models, the utility classes, services, repositories, etc., until they finally had working software that tended to matter more to the stakeholders of the project than software had before.
Dave Chelimsky’s movement over to plain text really helped this movement to take off. When people think of “BDD” they often think of the frameworks which have copied this (Cucumber and JBehave 2.0 amongst them), even though this isn’t the complete story. They have certainly encouraged developers – famous for their introverted natures – to boldly go into the analysis space.
BDD enabled conversation
Whether through frameworks, DSLs or just conversation, the biggest difference between BDD and ATDD was the way in which BDD enabled a common language between users and business stakeholders, because it supports Domain Driven Design’s “ubiquitous language” (forgive the rabbit-in-the-headlights look, it was my first ever video!), and provides its own ubiquitous language for software development – the language of examples and behaviour, rather than tests and acceptance criteria.
The second difference was the reusability of steps. This is something which a lot of BDDers are still struggling with, so we’ve still got a way to go here. (More on steps and business / system capabilities some other time).
BDD doesn’t just stop at scenarios, it goes all the way to the project vision
Finally, Chris Matts introduced Feature Injection, which takes BDD’s patterns all the way into the analysis space.
(I consider Feature Injection and BDD to be children of Deliberate Discovery (even though they preceded it), which is itself a child of Real Options. I summarise Deliberate Discovery as the act of wilfully addressing ignorance. Both Deliberate Discovery and Real Options have implications and uses beyond software development, and I heartily recommend coaches and managers to go read up on them. In fact, everyone who lives a life of any kind of uncertainty should go and read up on them. And if your life is staid and comfortable, maybe it will help you to step into those challenging spaces. Go do it anyway.)
Or at least, this used to be the difference…
So that’s the past. What about now?
Well, most people who do ATDD nowadays use the Given-When-Then template which Chris introduced (shout-out to Gojko Adzic for his work in this space). They use domain language in conversation with the business. They’re interested in discussing what software would actually make a difference, then capturing that and sometimes automating it, with a focus on working out the software which would matter.
I’m guided by Dan’s words to the BDD Google Group, which apply both to TDD and ATDD:
I think you can over-think these things.
I’d like to avoid “BDD is better than TDD because…” or even “BDD is
different from TDD (as originally envisioned) because…”TDD is amazing. Its initial conception was to solve exactly what I’ve been
trying to do with BDD. Originally it was described as variable scope (i.e.
covering both the space of modern day TDD-in-the-small and what the ATDD/SBE
folks are doing in the functional testing space). It’s not the *only* way to
come up with good design, and neither is BDD. They’re just both useful to
have in your back pocket as you go around trying to write decent software to
solve useful problems.
They’re called different things
The difference is that one is called Behaviour Driven Development – and some people find that wording useful – and one (or two) is called (Acceptance) Test Driven Development – and some people find that wording useful in a different way.
And that’s it.
Pascal Van Cauwenberghe has written a great post on estimating business value, tying it into a feature-injection style template. I particularly like the idea of calculating business velocity, and showing value earned over cost on a visible chart.
Even though we know that cost accounting isn’t useful without looking at ROI, many companies still have this focus (how many people have had problems getting hold of sharpies because they’re "too expensive"? Coloured post-its? Free coffee?)
Perhaps by making the return on investment over time apparent to everyone, we can motivate the team, show the value we’re earning and gain the trust of the business at the same time.
As an aside, I remember one client where the deadline was very tight, but nobody wanted to work overtime or weekends. Our PM asked us if there was anything we’d like to have which would help us work more effectively. We asked for – and got – fresh fruit every day. The difference in our work – both the amount and quality – was noticeable! (We already felt very well respected, so I discount the placebo effect here).
It’s amazing how much difference a few pounds of expense can make.
Comments