I am utterly dismayed by the number of so-called Agile teams I meet who are still, after all this time, building software backwards.
What do I mean by that? Let’s defer to the great W. Edwards Deming as he ridiculed the approach of 1970s American manufacturing to quality:
Let’s make toast the American way! I’ll burn it, you scrape it.
What an incredibly wasteful way to make things: Have one team cobble it together, have another team find all the mistakes, then send all the mistakes back to the first team to be fixed. Still, as long as we’re tracking it all with story points on our burn-down chart, and talking about it in our stand-up meetings, we must be Agile, right?
Wrong. A really Agile team would learn how to prevent those mistakes from happening in the first place.
Yet time-after-time, I come across scrum teams with a separate test team working an iteration behind the developers, finding all their mistakes.
Here’s why I think this is such a bad idea:
-
The cost of fixing a defect increases exponentially with time. Defects that fester undetected in the code become harder and harder to remove safely. The longer the defective code is there, the more chance there is that other code will be built on top of it. When the original mistake is rectified, that other code may be broken by the change.
-
The cheapest fix is the one you never had to make. When you write tests up-front, you often spot edge-cases as you write the tests; then you build in support for those edge-cases as you go. If you build software backwards, leaving a team of testers to discover those edge cases, you’ll pay a large penalty for having to go back and introduce the change to existing code.
-
You discover requirements too late. When you practice test-driven development, you prepare for any change to the software by first defining how it should behave when you’re done. If you build software backwards, you may never discover the behaviour you really want until the testers get their hands on it and start asking all those awkward questions. The toast has already been burned.
-
Continuous Delivery will always be a pipe-dream. Many companies, perhaps your competitors, deploy to production several times a day, just minutes after a developer checks in their change. If you have to wait for a separate team of testers to scrape all your burned toast, this will only ever be a pipe-dream for you.
When I talk to people about adopting BDD, the most frequent objection I hear is that it must take longer. This is true, in a sense, because it does take longer for a change to get to the stage where a developer is done with it. If you’re used to burning toast you’ll find this frustrating, because you don’t realise yet that the time and effort you’re putting in to write the tests up-front won’t pay off until later, when you hand the change to your testers and they can’t find anything wrong with it.
To do this takes a leap of faith, so hold your nerve. It will be worth it.
Stop building software backwards: come to BDD Kickstart
If you’d like to hear more about these ideas and learn concrete techniques to make them work in your organisation, I’m teaching a course from March 11-13 in Edinburgh, UK just for you. Click here to find out more.