You can have your cake and eat it, as long as you bake it carefully.
‘We can do this the quick way and pay later, or the thorough way and pay now.’ This seems to be a fundamental dichotomy in software development, between ‘perfectionism’ and ‘pragmatism’, but I do not think it has to be a trade-off at all.
Or how programmers and testers can work together for a happy and fulfilling life.
Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?
Most of my work these days is helping organizations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.
Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of ‘Professional’ or ‘Certified’ (but ironically not both) schools of Scrum training. But it was not always so.
[Adventures With Agile interviewed me recently ahead of teaching a couple of classes with them in June. The original interview is on their blog.]
My first job was playing Star Wars for a living. True story! I had a student internship in 1988 with a games company called Domark. They published the 8-bit versions of movie and board game tie-ins like Star Wars and Trivial Pursuit on home computers like the ZX Spectrum or Commodore 64. If someone called and said they had found a glitch on level 8 of The Empire Strikes Back, I needed to know what they were talking about.
tl;dr: Send us your examples of real world BDD. Read on to find out why.
‘What is BDD?’
‘How can I tell if I’m ‘doing BDD right’? Or wrong? Is there even such a thing?’
‘Where should I start?’
‘Is this or that practise considered part of BDD?’
‘What are the mandatory ‘core’ practises of BDD?’
These and similar questions were the topic of the closing panel at the recent CukeUp conference in London.
A question came up on the BDD list recently, and based on feedback I thought it would be useful to post my answer to a wider audience.
Some software teams get stuck because their business users don’t realize they need to make time to take delivery of features they’ve requested. Over time their User Acceptance Testing backlog increases to the point where the team’s throughput virtually stalls.
I’m having fun in the most unlikely of places. I’m currently working at a Big American Bank. In fact, it’s so big it’s called Bank of America. I recently wrote an article for their internal agile magazine which probably best describes why I think it’s so much fun, and which I’ve reproduced below.
Experienced delivery folks can have surprisingly good instincts for macro-level estimation, as long as we are careful to manage blind spots and cognitive biases. This can be an important tool in early project investment discussions, and can remove roadblocks where people are uncomfortable or unwilling to provide estimates.