My first thoughts are to explore the challenge that Gojko Adzic and Christian Hassa set us.
Gojko gave a powerful analogy of a roadmap with many routes, many points of feedback (this bridge is closed, this road is congested etc) with the feedback ideal of GPS turn-by-turn navigation; and contrasted this with deliberately going into a tunnel with no option to emerge except at the initially chosen destination. He felt that too often as software professionals we only give the business the tunnel option, and Christian asked why we have to hit a project crisis to make sensible scope decisions.
The challenge they set is to give the business GPS with turn-by-turn navigation, to generate options, and to seek out feedback, and so give the business the flexibility not to have to be right about the future.
Gojko wondered why people will pay extra for flexibility outside of software (flexible travel tickets, flexible financial products) but as software professionals we are not yet selling flexibility to businesses.
Several anti-patterns came out here:
- All business decisions or scope decided up front, even if agile approaches are adopted within the project (‘waterscrumfall’ and ‘bankan’!)
- Linear thinking, such that a product roadmap is a single destination with a single route to it
- User stories without impact or success criteria, such that they just become requirements in a huge backlog that can’t be prioritised or marked as ‘Not Now’ correctly by the business
Gojko introduced Palchinsky Principles: variation, survivability, selection (see Tim Harford – Adapt: Why Success Always Starts with Failure), showed the similarity with divergent/convergent design thinking, and wondered whether we could instead treat user stories as survivable experiments, on which we actively seek feedback. The aim would be to create options for the business, get feedback, and choose the next direction.
Christian pointed out that the business should be making decisions on business goals, not product scope – each item under discussion should be something a business person cares about. He added that in general this can’t be done well with a list – a good visualisation is needed. Gojko discussed how effective why-who-what-how thinking (impact mapping!) has proved in this area, and Christian discussed story maps.
To sum up, Gojko set the challenge described above, and Christian gave some immediate practical tips for existing projects:
- Any existing project can be reverse-engineered with an Impact Map to start a fresh discussion with the business
- Story Maps may also be useful for prioritising and existing backlog, especially for marking stories as ‘Not Now’
Matt Wynne and Seb Rose also touched on this in their interesting discussion, particularly with regard to who owns scenarios, the level of detail and specific content required for different users, and the quality of feedback that could be achieved. They also suggested that not all business-readable tests need to go through a GUI – we strongly agree – but I’m going to come back to this another time…
The feedback theme continued in David Evans and Brindusa Axon’s talk on user stories.
Bri explained how important it is to invest in stories, but David said how often in his reviews he finds they are inept! David felt the template stinks, and they discussed some alternatives – the aim is to optimise for human understanding, and lead to better conversations. A story is a promise to hold a conversation – if you can’t fit all the details on your card, get a smaller card!
David had a nice discussion of the role of documentation within agile (‘we value working software over comprehensive documentation’) – document the results of conversations – don’t start with documentation – let your documentation capture the important things that have come out of conversations.
He also gave an overview of the life cycle of user stories, and a distinction between stories and specifications in this regard. The story is the scheduling token, and the specification details the effect of the change. They may be joined up when elaborating, but in the longer term we will see a separation. The story is short-lived and gets us to a safely made change, and the specification is eternal and details the behaviour of the system at a point in time, and as such needs curating and nurturing, and this needs investment – with the ideal of a living document.
Finally, some signs that you are getting things right include (amongst other things) collaboration and feedback working effectively at story creation, acceptance, and when deciding what to do next – when you have collective story ownership, collective product ownership, and enjoy planning meetings!
Finally, I’d be very keen to hear what people took away from our talk. Jenny Martin from Sparkle CS, Chris and I spoke about maximising opportunities for feedback, and presented the feedback onion as a way of structuring our thoughts in this area.
These are some of the things I hope people would take away:
- What is most important to us is maximising opportunities for feedback throughout the business – we used the onion to discuss what different types of feedback we might be looking for, and what type of conversations we want to have – if you only get feedback working at the iteration and capability levels then you’re not providing the tools to keep the business on target
- We try to use the best tools for each type of conversation (what we have rather grandly called our collaboration framework)
- We don’t use user stories (we do have jira tickets with plain language titles that serve as process tracking tokens), and instead we really invest in our examples
- Examples have a life cycle – in elaboration this flows from an initial mention in an impact map (as a desired business impact), through a brief description in a dream demo (as the leanest way to get feedback from potential clients), to a fully worked example in the demo steps for a particular iteration showcase (as the best conversation between analysts and developers, and for continuous acceptance)
- We love the idea of Continuous Acceptance – we have shared ownership of examples and the resulting software, and the fortnightly showcase is no longer an acceptance event, and can instead be a chance for conversations with stakeholders outside the immediate team, shaping the next iteration to meet their needs
- Once we have working software, the example is still important – we componentise and consolidate the short-lived iteration confluence pages into executable specifications (x-specs) that are structured for use by people rather than structured for automation, and build these into a living specification, including a master demo, where the example can be used in conversations with stakeholders and clients, and so can input to the overall direction of the business.
We still have a lot we want to do here, but I’m really proud of what we have achieved, particularly in light of Gojko and Christian’s challenge.
I saw this assertion that “people will pay extra for flexibility outside of software (flexible travel tickets, flexible financial products)”. I’m not sure I agree, and I think it has implications on how we perceive flexibility in software development. I travel for a living. I’ve bought hundreds of flights and I have never paid for a flexible fare. It’s usually cheaper to buy a non-refundable ticket and pay a change fee+fare difference later than it is to buy a flexible fare when you might not need to change. Imagine two travellers who had the same needs for flights, sometimes changing, sometimes not. Imagine one of them pays for flexible tickets every time. Imagine the other pays for non-refundable cheapest fare tickets, and then pays the fare difference and penalty on the times he has to change. The second person would probably save money.
Now cast this into software development. You could pay for flexibility up front by engineering processes and methodologies that adapt and handle changes well. Or, you could blow that off and always assume that every story is flawless and will live unchanged forever. My assertion is that somewhere, something costs more to do things in a flexible way. I don’t know if it’s more time spent (deciding, prioritising, revisiting decisions?), more effort spent (adding flexibility to activities that otherwise wouldn’t be flexible?), or maybe even psychological (facing conversations where people might disagree?). I bet there is something that humans perceive as a cost—something they want to avoid—because I don’t think there are a lot of fliers buying flexible fares versus inflexible ones.
My guess is that somehow we perceive it as “costing” more on some axis to have flexibility all the time, instead of just paying for the cost of a change when we’re forced to make a change. I don’t know why it is, but I think fully flexible development teams are as rare as business travellers who always buy fully flexible fares. I don’t think it’s as simple as changing their opinion, though. There must be something deeper that motivates this behaviour.
Anyways, good blog post. I enjoyed it.
Hi Paco, thanks for your comment.
You raise some very good questions – especially about the costs of building in flexibility in advance rather than dealing with change when it arises.
Gojko asked ‘how much would you pay not to have to be right’ – in your case the answer is that you are happy to pay the fare difference and penalty when the situation occurs. But you know you have that option when you book – what if there were no option?
My reading of the session was that we’re not talking about building flexibility into the product but into the project approach – what can we do that allows the business to change the project direction when it needs to – similar to you having the option to change your flight? What feedback can it get during the project so it can find out the diection needs to change?
Great write up, thank you.