testing package. It is even simpler and cleaner, and distinguishes between failed checks and fatal test failures. It doesn’t use exceptions to do this.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.
Josiah Renaudin interviewed me in May 2015 ahead of the STAREAST conference in Orlando. The original interview is online at AgileConnection.
Someone asked me recently for advice about consulting into multiple teams, in particular about how to make the most effective use of a number of short sessions. He will be spending two hours with each team in each visit. This will be an ongoing relationship, with a series of visits made up of these two hour coaching sessions.
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 realise 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’ve been taking a few weeks of semi-vacation in South Africa and I’m in a reflective mood, so please forgive the indulgent tone of this post. I’ve been thinking about what an awesome industry I work in, and some of the people who have been moving it forward over the last few years, at least for me. I wanted to take a moment to appreciate them. If you haven’t come across any of the following topics I encourage you to explore further. At the very least you should be following these folks on Twitter.
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.
The goal of software delivery is to minimise the lead time to business impact. Everything else is detail.
At the end of 2009 I left the world of agile delivery and consulting to join a small team in a trading firm. I was member number three. The team grew to five in the next few weeks. This team was the most insanely effective delivery machine I’ve ever been a part of. A handful of programmers sitting in amongst a handful of traders, producing state-of-the-art trading systems—with all the integration pain (back office, risk management, connecting to electronic exchanges) that involves—in weeks. Not months, weeks. This is, of course, impossible.