Most of my work these days is helping organisations 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.
Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.
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.
tl;dr: Thank you to some lovely people for translating or graphic recording some of my work.
One of the nicest compliments you can receive as a writer is someone choosing to translate your work to make it available to a new audience. I am enormously grateful to the people who have translated my articles and blog posts over the years, most recently Julia Kadauke, who translated What’s In A Story into German.
However nothing prepared me for the email from Denis Oleynik, CTO of 1service.ru, telling me he had translated no fewer than eight posts and articles into Russian!
[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.
Josiah Renaudin interviewed me in May 2015 ahead of the STAREAST conference in Orlando. The original interview is online at AgileConnection.
I am excited to announce some public dates for my Testing Faster and Software Faster classes. These include the first 2-day classes this year, and the first ever public dates for London.
Software Faster is for people looking beyond Scrum and the other agile methods that have been around since the mid–1990s. These methods can shrink delivery times from years to months, but then what? You want to deliver in weeks, days or even hours. The last two decades have seen amazing technological advances, in languages, tools, techniques, and in the availability of inexpensive, on-demand infrastructure. What use is a two-week planning horizon if you can build, deploy, test and discard several product ideas in a single morning?
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.