I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.
Gojko Adzic (@gojkoadzic) spoke about the trouble of aligning strategy and the desired impacts of projects with the implementation of the software.
Palchinsky Principles
He spent some time discussing the Palchinsky principles, from Russian engineer Peter Palchinsky as documented in Tim Harford’s book ‘Adapt’.
The principles, intended to guide the development of innovations, are:
- Variation: We should seek out new ideas and try new things.
- Survivability: We should do things on a scale where failure is survivable. (This is why stories should be small. Not so that we can finish them in an iteration, but because they might be wrong.)
- Selection: We should seek out feedback and learn from mistakes.
Roadmaps that aren’t a map
Gojko observed that a lot of product roadmaps are actually not maps, but just roads. Unlike real maps, there is only one path and they have no options for different ways to arrive somewhere.
He suggested what we really want is not a roadmap but something like a GPS for your software project – a map that helps you change direction when necessary, gives you options and helps you get back on track when you make a wrong turn.
Agile: designed for achieving impact, but do you use it like that?
Many organisations take on Agile with the hope of becoming more productive, but the actual advantage is not to produce faster outcomes but better outcomes.
He asked: Do you really believe you’re doing development as a series of experiments? If so, ask how many stories have you removed from your software after deploying. That is the measure of experimentation.
He said whenever you get a story description where the outcome is about people’s behaviour, e.g. “Some person will do such-and-such”, you should reject it. The person can already do that, just without software. You need to be talking about what will be different from how things are done today.
Measure the impact
He cited the story about “40 shades of blue”, where Marissa Meyer reportedly solved a dispute between a software engineer and a UI designer, who wanted to change a certain hue of blue on Google’s website, by running an experiment with many different shades of blue, apparently showing the UI designer’s choice would have resulted in millions of dollars in lost revenue to Google over a year. (Might be a bit of folk law there. The original NY Times article I found described the experiment but didn’t include the results.)
Why do you need to focus on the goals of your project rather than the software delivery? What if you plan 100 stories, but implementing only the first story (to everyone’s surprise) achieves the goal? Would you continue building the rest of the software?
Impact Mapping
Thought he didn’t talk about Impact Mapping much during the talk, Gojko referred us to ImpactMapping.org at the end, a website containing information about an interesting “strategic planning technique” he’s developed. It comes across a bit like a story map, but with less detail at the story level and more at the strategy levels. The most important difference is that all the features are tied back to:
- the impact they’re intended to create,
- the ultimate goal of the project, and
- the actors who can influence the outcome.
If you’re running a software project or involved in one, I think it’s definitely worth a look.
Want to learn more?
  |
  |
  |
  |
Image credit: ‘Leaf-cutter ants‘ by Geoff Gallice