Notes from Clive’s presentation:
There has been quite a bit of interesting discussion on Twitter about Roadmaps; what they should include, how they should be structured, how to make them useful for agile teams.
A roadmap shows the direction and the destination. If we think about actual roadmaps, where the metaphorical roadmaps we refer to come from, they show all the possible destinations (towns, cities, etc.) and all the possible routes to get there (roads). Typically, if you wanted to get to a particular destination (achieve an outcome) you would start heading in that direction, but if an obstacle was in your way you’d change route but still be heading in the same overall direction towards the destination. Some routes are faster, some routes are more interesting.
So, a good roadmap (back to our metaphorical roadmaps now) should show the outcome that we want to achieve (destination) and provide some direction of travel as a guide to keep teams moving towards the destination. The direction of travel acts as strategic bumpers to help explain the ‘where to play’ decisions but gives the team enough room to decide on the route for themselves.
Roadmaps that explain the destination and the direction of travel become ‘who & why’ roadmaps rather ‘what & when’ roadmaps. ‘What & when’ roadmaps are misleading and often obscuring because they try to define what the team should build before they’ve started the journey and when they’ll be able to do it. ‘What & when’ roadmaps show uncertainty as a pretend certainty.
So, we should accept that ‘Roadmap’ is an incomplete phrase. We should be clear about it not meaning ‘A roadmap of what to build when’. We should be clear about ‘roadmap’ actually meaning ‘A roadmap of why we’re building and who we’re building it for’. Then roadmaps become about achieving an outcome (getting to the destination) rather than the stops along the way. Then our phrasing can become more specific; ‘A roadmap for achieving x for y’. That could be ‘…achieving product/market fit for our idea’ or ‘…achieving 30% time saving for regular subscribers’.
A colleague asked me a question about a customer query she was dealing with, and went on to explain that it wasn’t our teams customer but that she couldn’t let go of it and wanted to resolve it. It was almost like she felt that she had to explain why she was spending time doing something that ‘isn’t her job’ and that I might criticise her choice.
Her job, just like my job, is to deliver value to our customers. I trust her to use her intelligence to decide what is the best way to do that. I don’t care which organisational silo a customer interacted with initially, if they speak to us we’ll do the best we can to help them. I don’t want us to do things that reinforce those silos and reduce the value we provide for our customers. If we’re the best people to help that customer then we absolutely will accept that responsibility and do everything we can to resolve their query.