Teams new to Scrum are often obsessed about story points and velocity. Burndown charts and burnup charts hang from walls to convince both the team and the management of how well they’re doing, and improved velocity seems to be one of the key selling points for Scrum consulting gigs. A nice example of that is the Scrum Shock Therapy page. Using lots of numbers, percentages and impressive increases in velocity, readers are convinced about the advantage of the Shock Therapy approach that lead to a team becoming 400% hyper-productive. Knowing nothing else about that, I’m sure that managers at large would like to have such an improvement in their department, and that many delivery teams would be quite happy to get to that point. On the other hand, consider that the company in question was actually MySpace, once a market leader and now effectively an also-ran social network, far on the path to irrelevance. Would you still like to be them? Continue reading
In Inspired: How To Create Products Customers Love, Marty Cagan has a couple of very strong statements about product managers identifying themselves with their customers:
It can be dangerous for a product manager to have too much domain expertise. I say that because people that have spent a long time building their mastery of one domain often fall into another common product management trap – they believe that they can speak for the target customer, and that they are more like their target customer than they really are.
One of the most common mistakes product teams make is confusing themselves with their customers.
The book has lots of interesting and thought-provoking ideas, but it seemed as few would apply in the context of the product that we’re building at the moment. Cagan promotes a strong separation of project management, product management, delivery and marketing, as well as arguing that product delivery and product discovery have to be separate. His experience managing successful large scale products is beyond doubt, but the team I work with at the moment consists of just three people. Unsurprisingly everyone does everything, and we firmly believe that discovery and delivery are entangled and inseparable. Actually, that makes it more fun for us. We started building the product to satisfy our needs, so we’re genuinely representative of our target customers, or at least I thought so. Continue reading
Here’s a video recording of the keynote from XP2013 – Make Impacts, Not Software. This is a theme I challenged myself to present at plenty of conferences this year and refine and add material for each one. It’s shaping up pretty nicely now, so I’m happy to share this version.
In the previous post I wrote about the key conclusions from the recent meeting on delivering software that makes a big impact. One of the best things about the meeting was that we did set-based design on the conclusions (big thanks to Karl Scotland for suggesting this). While the group I was in focused more on underlying principles, Karl’s group focused on how to get there, practical steps that would allow teams to get the most out of feature injection, impact mapping, user story mapping etc. The conclusions they came up with were also aimed at extracting the essence from all those techniques, and they are an interesting complement to the principles we identified.
(click on the image to download a larger version, feel free to use it in your slides, presentations etc).
The sweet-spot for all the techniques we discussed seems to be enabling these practices, and creating a self-reinforcing loop of better customer understanding and collaboration.
Understand your customer
At the core of delivering software that makes an impact is understanding the customers/stakeholders/users. Before someone blames me for stating the obvious, this isn’t just understanding their needs or desires. In What Customers Want, a book about “Outcome-Driven innovation”, Antony Ulwick warns against focusing too much on what customers are asking for, and instead advises understanding deeply what kind of jobs they want to perform and then offering innovative solutions for improving that work. All the techniques we discussed support a better understanding of users’ work and assumptions.
So to get the most out of all those techniques, leverage this aspect, and use them to understand customers’ assumptions, the work they are trying to perform and the impacts that you want to create as much as you can.
Be comfortable with ambiguity
A common thread for the whole day, as well as one of the key principles that made the final list, was to focus software delivery more on impacts and outcomes than on software features. That means that the actual software that will be delivered is not going to be precisely defined ever – we will keep trying things out until the impacts are there, and we’ll stop when they are achieved. Also, as we’re planning to learn through delivery, we can’t be certain what impacts on users’ work we’ll need to get to the outcome. With such a level of uncertainty and ambiguity about scope, there is not much point in fixing the plans or spending time planning too much. At the same time, there needs to be a good level of transparency, visibility and understanding of the delivery work and plans for everyone to coordinate (and for the clients not to panic). A common thread in all the techniques we discussed is providing a dynamic big-picture view, to prevent a stream-of-consciousness of user stories that don’t achieve anything big and make business people run for the hills.
So to get the most out of all those techniques, leverage this aspect, and make the organisation comfortable with not committing on software features, instead of focusing on making impacts. Provide a clear big picture view connecting all deliverables to business outcomes, show how they help or hinder that, and use those things to monitor and report progress.
Another common thread, linking the techniques we discussed with Design Thinking was facilitating a close collaboration between customers/users/stakeholders and delivery teams to create solutions together. Someone (sorry, forgot who) gave a fantastic example of their organisation where they paired up a technical architect and a product person through the entire hierarchy to make decisions together.
So, to get the most out of all those techniques, engage cross-functional groups, involve customers and delivery experts, and use their shared wisdom of crowds to come up with a good delivery plan.
The fourth common factor for many of the techniques we discussed was that they facilitate organisational learning from delivery, establishing a clear and deliberate feedback loop from the outcomes and impacts of deliverables. In “Impact Mapping”, I wrote about this as a third weel that spins business milestone iterations.
So, to get the most out of all those techniques, focus on learning fast. This is closely related to the third principle we extracted, Teams should decide what to do next based on immediate and direct feedback from the use of their work. The more direct and immediate the feedback, the faster we can learn.
Make an impact
Organisations should focus on delivering outcomes and impacts rather than features was another key principle we set out, and by understanding customer needs, engaging them to help design solutions and learning about what worked, we can focus on making big impacts with our work, not just shipping a stream of consciousness of user stories. Many the techniques we discussed facilitate this. They help us define clear business objectives and create a roadmap that drives towards those business goals.
So to get the most out of all those techniques, don’t use them just to map out features – instead show impacts and outcomes and use those things to guide delivery.
Make it visible
By making assumptions, objectives, impacts and scope visible, those tools allow delivery teams and business users/customers to get a better shared understanding and alignment. This includes the impacts we plan to produce, impacts produced already, roadmaps, plans to learn and learnings so far. Visualisation is a common thread in many techniques we discussed, and it seems to also be a key enabling factor for a shared big picture view.
The visual aspect, as David Sibbett suggested in Visual Meetings, seems to add a lot of IQ to everyone in the room.
So to get the most out of all these tools and ideas, make sure the conclusions are visible.