Stories, users, and the art of slicing!

Stories, users, and learning

This month I had the pleasure of spending some time with Neil Killick( 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(here), 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. 
Thanks, Neil!

New Horizon

It’s been some time since I’ve had a clear path forward. From March 2017 until the end of August I’ve been working in my first Government position but only in an Acting capacity. The role has been interesting, having a team and in particular not having a project of my own. It has been a big learning experience, working for others rather than a project, offering where I could, some of my insights and prior experience to help. Some have been really appreciative, others not so much. Part of me feels I failed somewhat, for not creating a noticeable legacy. Another part of me feels I set things up so I could transition into my new role, overall I’m still not clear how I’m leaving that position.
My new job is excitedly the best role I’ve ever had, the potential is huge. I’m truly fortunate, I get to step back into the project world, working under an experienced highly accomplished project manager, now program manager, it’s my first project manager role in a truly agile delivery, and needless to say, I’m super pumped.
How can I say we are truly agile? Since mid-June, I have been on the job market, knowing the acting role would come to an end and not knowing that transitioning across to a project management role within Parks Victoria was possible, so I was all over I was, of course, wrong and am indebted to Tim Tunbridge, Neale Tayler and Jen Rebeiro for making it happen. However, I digress, through the process of hunting for a job and discovering yet again “agile” is a hot topic, but still realising from an I.T. project management perspective mostly/largely misunderstood. A number of companies and jobs have talked to an “agile” environment, but probing a little deeper, discovering a traditional culture still prevails when it comes to projects.
In tech projects, a traditional approach would be referred to as a “waterfall” method, Prince2 and PMBOK are renowned methods in this type of delivery. Basically, waterfall lays out the work of a project sequentially(mostly), wherein; scope, time and money are fixed, but consequentially quality is variable. Agile is by-enlarge seen as the way projects should be operated, but when you start to get a feel for whether or not scope is variable, as would be the case in a truly agile project, companies, supervisors, program managers get highly uncomfortable.
Part of me understands that as project delivery goes, you must inform the business on what you will do, but there is a distinction that needs to be made here. Ideally a team would talk about requirements with an asterisk next to it, something along the lines of “we are not able to predict the future, however, from our analysis we believe addressing these organisational problems will return value to the business and we believe we can get X amount of work done in X amount of time. However, as we progress we will learn more and re-assess what we have delivered against our initial thinking and how much we have spent. From here we can make an informed decision on how we progress and even whether the project is still viable.
During my formal education(albeit a one week course, I’m an expert now!!!) on agile project management (DSDM), I was blown away by the concept that during a project, at key releases/milestones, the project control board, would actual re-assess whether it was worth continuing. This can often, at least at first, seem like a negative thing, but it ties back to Pareto’s 80/20 principle. With functional releases of a project you will realise benefits along the lifecycle of the project, but there very well could be a point wherein 80% of the benefits are realised and the remaining 20% is likely to have less of an impact. At this point, it’s potentially worth considering if that money required to deliver the remaining 20% is worth it, or perhaps better utilised re-investing into anther project that might have a greater impact with the same money.
Coming back to my earlier point. We are in an agile world now, wherein scope is variable, time is fixed, cost is fixed and quality is fixed. Other organisations and projects are possibly impeding their success before even beginning by fixing every aspect of a project. Lately, I’ve thought about it like quadratic equations, solving for X, while all your other elements are unknown
Even though based on the elements of the equation, we can assess what X is worth relative to the other we don’t come away with a distinct value. You could say the quality of our answer is compromised as it is dependent on others. A project, I believe must have distinct benefits, independent of others.
I’m not naive to think there will not be challenges ahead, however, at least I know that there is hope to deliver something great without compromising quality. I.T. has an extraordinary poor delivery record, (RE: Standish report “CHOAS), some 16% of all IT projects deliver, all the others fail in some manner. I’m hoping to work hard and diligently to be in that 16%.