Stories, users, and learning
This month I had the pleasure of spending some time with Neil Killick(http://agilemelbourne.neilkillick.com/) and a few others learning all about story slicing.
It was incredible. Yes, I realise, that’s a fairly strong statement, but I don’t think I’ve been in a situation before, where I’ve been able to apply so quickly what I had just learnt.
I’m very fortunate to work for the best company in the world, literally, has been ranked #1 by a whole heap of evaluators around the global. That means, I’ve got the space to try new things, and my colleagues are open to working in different ways.
Within hours of this session, I was able to take what Neil had taught us to work and apply it. Where once I had struggled to know what to do with a story, I feel I can now take it to the mincer and slice it in several ways to make it more feasible for everyone.
The following Monday following the session with Neil, I was sitting down with my team running a sprint planning event. During the session, we considered several “user stories” to take into the sprint. Having Neil’s guidance, I could, within moments, look at a story write it up on a whiteboard and apply Neil’s magical “Seams” approach to story slicing. I could quickly help our team break down our work into manageable chunks. By doing this, we could then focus on conversations about where we would be trying to add value.
Not only could I help our team look at a story from a capability perspective, but when it came to implementing a solution, I was able to slow the team down from jumping behind the first solution that made sense. Thus, slicing the story from a functional and technical perspective. This allowed us to instead, do something Intuit are renowned for; going broad before going narrow.
Following on from reading Eric Ries latest book, The Startup Way, I did some Google hunting for Intuit. They have this approach to ideas. Rather than getting behind a single approach, they spend time thinking up as many possible ways of solving a problem before going deep on just a few. From Neil’s session, I was able to initiate a level of discussion that didn’t end abruptly by everyone getting behind just one option. We took some time to consider alternatives, which in the end actually led to a completely different solution being implemented then was thought of beforehand. This has saved us a least a week of time if not more, as I’m confident, if we hadn’t considered as many options as possible, we would have been a week or more into building a solution, only to realise a better way! We found this better way much sooner, or at least our degree of confidence in the way we are building out the solution now is higher and ultimately more considered.
Inside of learning about functional and technical slicing, Neil taught us a technique he refers to as the Hamburger method. It’s a simple approach to functional and technical slicing. I won’t go into too much detail, as you can experience it first hand by attending a session(), but it’s a great tool for getting your team to hold off on jumping straight into one solution and to consider a multitude of alternatives.
Since this session, I’ve noticed an improved confidence to take a statement or vision that an executive has for their project, and slice it up. This will help our team to start looking at quick ways to deliver value. I have found in the past that getting the backlog into a healthy state has been hard. One of the specific problems I’ve faced is initiating a backlog and getting it to a point of being “ready” for a build. I’m not saying by any means I’m all of a sudden perfect. But the ability to slice has helped take a statement/assumption and show how we might leverage it to give the development team something to look at and work with. This, of course, has meant, we can more quickly establish our priorities and build something. The benefits for me are huge, it means we’ll be at a point sooner rather than later where our team can inspect and adapt what we are building.