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.