RSSAmplifier

Blog

Gojko's blog

Gojko Adzic's blog. Specification by Example, Impact Mapping, and more...

gojko.netRSS feed ↗10 posts

Latest posts

In five years, everyone will be a product manager

Here’s a random thought for today: In five years, everyone will be a product manager. And I don’t mean this in the Chef Gusteau “Anyone can cook” sense, but that the typical software product manager role will get squeezed from lots of different sides as other people take on the bulk of the responsibilities now handled by PMs (note “the bulk”, not “all”). This includes domain experts, developers,…

From Bugs to BEAM

It’s never been really clear to me what’s the difference between a bug report and a feature request. Yes, of course, there are clear cases at the extremes, but there is a huge gray zone with a lot of overlap. And it recently dawned on me that clearing up this gray zone actually surfaces some very significant product opportunities. Both bugs and feature requests point to something missing from the…

Mega-workshop facilitation tips

Last week, Specflow and I organised an interactive webinar. For posterity, and anyone crazy enough to do something similar in the future, here’s a quick summary. Read on to learn how we facilitated it, what worked well, what worked badly, and some ideas how to do it better. TLDR summary: we got 500 people to try collaborating over Zoom and Miro. Miro more or less held its ground, but I feel as if…

Nijute: how to solve impossible problems

Our industry is full of oriental phrases and loanwords to describe strategies for wicked problems. From Kanban and Gemba, to Shu-Ha-Ri and Poka-Yoke, a far-east sounding name suddenly seems to bestow authority, and turn an ordinary idea into ancient eastern wisdom. So here’s another one, especially good for problems people say are impossible to solve: Nijute! Although it sounds like some secret…

The Play, the points, and the biggest lie in software

“We delivered twenty points this week!” one of the Zoom squares declared in a proud voice. The rest of the grid in the virtual standup (zoomup?) nodded approvingly. This was apparently a big win for the team. Handing out virtual pats on the back would be a killer feature for videoconferences like this one. Yet the person reporting it was lying through his teeth, and everyone else was just going…

Given-When-Then, tweak and try again

A new enhancement has the potential to significantly expand the reach of Given-When-Then tools, and make them much more inclusive. I’m very excited to see this attempt to improve developer/tester collaboration, and I think anyone using GWT should pay close attention to this experiment. Given-When-Then, without any doubt, won the contest for the most popular BDD example structure. The supporting…

Specification by Example, remotely

One of the best things about Specification by Example is how it allows a group of people to quickly get to shared understanding, and collaboratively discover and define exactly what they need to build. Specification workshops are the most effective when everyone is in the same room and has access to the same information. For better or worse, that’s impossible to do in most countries around the…

Specification by Example, 10 years later

It’s now been ten years since I submitted the final manuscript of Specification by Example to the publisher. In the book, I documented how teams back then used examples to guide analysis, development and testing. During the last two months, I’ve been conducting a survey to discover what’s changed since the book came out. Some findings were encouraging, confirming that the most important problems…

Descaling Agile

Here are the slides, links, books and papers I mentioned in the closing keynote of the Agile Scotland conference in December 2019, on descaling agile. Download slides Parkinson’s Law - article from The Economist New analysis shows problematic boom in higher ed administrators by Jon Marcus, 2014 Official Scrum Guide - current and past versions - from Mitch Lacey’s archive, including the original…

Deliberate side-products

Basic laws of statistics imply that most developers work on average products, supporting usual business workflows, helping the proverbial mill run without too much excitement. Although the right choice for most such products should be to “Choose boring technology” (as Dan McKinley nicely explained), very few teams actually do that. This leads to overcomplicated software that is costly to develop,…