First, a disclaimer: Please understand that this is a context specific process, designed to address current challenges with the “how” of product development. In our shop. At this very moment. What we do might not be for you. These musings are intended to provide information regarding the “how” of our work to external as well as internal audiences. It’s my ambition to dive deeper into each part of the process in future blogposts, and provide thoughts on how we make progress towards our true north. It is my hope that I can provide updates to these pages with a few insights and lessons learned. What worked well, and not so well.
This process is a new design that is meant to provide us with a new baseline for continuous improvement. The process design takes inspiration from a variation of sources, and is designed to address a set of challenges, not adequately handled by earlier process designs that were a mix of rather poorly functioning existing frameworks (Scrum-ish) and Ad Hoc.
Furthermore, the design makes an attempt to encompass the whole value stream from beginning to end and aspires to facilitate improvements of the dual aspects of “building the right thing” and “building the thing right”.
The process has been evolving slowly with various aspects of it having been presented in smaller chunks to all parts of the organization during a time frame of a few months. I have chosen the timing and the pace of these changes most carefully, and most likely I will find reason to get back to you in a future blogpost on the question of “why now?”.
This is a high level description of our process. Please excuse the appearance of a linear approach when the process is most certainly cyclic in nature.
I’ll be discussing these separate steps in blog posts to come, and just to make this post actually say something, I’ll dive right in to the first step below.
It all starts with a value demand. All value is not created equal and so one must be mindful of some important variations. There is for instance both a demand for building something new (we will call this value demand), and fixing something old that is currently broken (we call this failure demand). There is of course value in fixing something that’s broken, but this distinction is rather useful, I think. Now, this broken thing can be severely broken, or just a bit crappy. There’s a difference, and this difference matters. Also, consider the question of who the beneficiaries of the proposed action might be. Is a small tweak that fixes something broken, and improves the experience for 1,7 million of our visitors, equally, more, or less important than a larger delivery of value that benefits a target audience of ten important stakeholders? Well, as the old management consulting mantra goes: “it depends”
In order to sort all this out, someone, somewhere, has to first define the proposed value, and consequently also decide whether or not this value should be focussed upon. Considering the realities of constraints, this means there will always be some value which we choose not to deliver right now, and some which will never be delivered at all.
It follows that the first thing we need to do is have this proposed value described somehow. Otherwise, how would we even know what it is that we are debating? I’ve too often seen groups of people who glance at one-line descriptions of proposed value and fool themselves to think that they:
A) actually have a shared understanding of what that one sentence actually means.
B) can make these critical calls based on just that.
Well, they can’t. So there.
Moving on, we need to have all proposed value assessed in roughly the same way, otherwise, we run the risk of inviting invisible rules and hidden agendas, that will taint the value definition process.
When we come across such “hidden thinking”, it’s in everyones best interest that we implement the old “are you proposing that we make that reasoning a decision rule?”-ploy. This can lead to rather uncomfortable discussions, so I would advise to use this method with caution and respect. Tread lightly.
We have chosen to describe value by creating our own opportunity assessment template, modeled on Marty Cagan’s fine example. We’ve tweaked the template to better suit our specific needs. The template is filled out by the person in the organization who champions the proposed value. When we address failure demand, we aim to do the very same thing, but in this instance the opportunity assessment will be replaced by a very basic simplified A3-report. But we shall leave that aside for now.
These reports end up in the hands of a group of people from various parts of the organization. These people look at the proposed value through the lens of a set of considerations that are important to the organization as a whole. This stab at holistic thinking is intended to be a gateway drug to a genuine systems perspective, slightly nudging the organization towards a deeper understanding of our long term strategic thinking.
We’re using a single impact tool for this, and once everything is filled out we end up with a number that says something about the total impact of the proposed value. As with all tools, you will get out of it that which you put into it. GIGO is in play. The point of the tool then, is not to turn a lever and end up with a number that is unquestionable. It’s the process that matters. The discussions and the thinking.
The thinking that goes on, and all the thoughts expressed by the group, is meant to be visible in the report as it continues it’s travels through the organization, all in the name of clarity and transparency.
Next, we have the people who actually know something about building anything tell us how the proposed impact measures up against effort. Effort is not to be confused with traditional estimation. What we’re talking about here is a really high-level discussion about the current constraints of our system and what sort of effort might be involved in order to make sure the delivery process provides us with the feedback from stakeholders and customers that we need. This is intended to take care of the “feasible” aspect of Cagan’s mantra “usable, valuable, feasible”
In my next blog post we’ll move on to the next step, and spend some time discussing how we choose.