Lenses for the three P's (Problems, Plans, Prioritization): Problems (1/3)

I recently realized I am 3 posts away for the first hundred in this blog. It feels somehow a milestone to appreciate. As I wrote here before, I do this mostly for my own sake – it has helped me to sharpen my thinking. OK, I won't deny that's sort of nice that others see value, subscribe and check the posts out.

So I thought of making of the three next posts a series, touching upon lenses I like to use when thinking on what I like to call the three P's: problems, plans and prioritization. I call them lenses because I don't find it useful to be stuck on discussion about labels, origins of concepts, and stuff like that, at least not to lead with that. But also because the idea of lenses gives the right framing: means by which we can see the world so to act coherently in it.

You can make a parallel with models and the famous quote by Geoge Box:

“All models are wrong, some are useful.” Paraphrasing: all lenses are wrong, some are useful.

By 'useful' I mean what can help us to reason, make sense and take actions when it comes to the three P's. One by one – starting with problems today.

Problems: working backwards and managing risks

I know that by using the term 'working backwards' I'm risking to violate my own principle of not putting a label, by alluding to the origin of the concept, since that wording is often associated to Amazon and their ways of working. But being true to the idea next to it: it's a managed risk. It just happen to be the case that the term is generic enough and a simple way to articulate what we are trying to achieve (more so then if I would go, say, with a notion of North Star, with its named framework largely implementing the underlying ideas of working backwards).

Speaking of its underlying idea, working backwards is incredibly intuitive, although not necessarily the way we tend to naturally approach things. Still most people would agree that's a good idea to have at least a sense of direction of where we are headed. And use that to guide what we will focus on work-wise.

I want to be clear on something: I am deliberating using 'problems' here to make a point of all of this being rather broad in nature, while obviously quite often the context in which we will be dealing with those problems is by working on 'products'. But it doesn't have to be necessarily, and perhaps I can use a simple example more oriented towards process improvement to illustrate both the general idea I'm trying to articulate as well as showing its broader application.

In a nutshell, this is how I think about it…

Here with an example of improving a process to deliver value through "team portfolio" deliverables (work items teams make commitment on a quarterly basis*)…

In a more descriptive manner, we figured out that we want to increase our chances to focus on the right things by decreasing time to market (assumption being that we will be often wrong, so the best shot we got is to iterate and learn faster). More precisely, we should at least not take more than the time frame in which we made a commitment on delivering something (in this case, 90 days or a quarter). So logically, what we can use to monitor progress as a lagging indicator is precisely the cycle time (or development lead time, if you want to use a more precise wording) of those items. 

Therefore, the question becomes how can we control things more from a leading perspective? From flow (and its mathematical proof, Little's Law) we know that the amount of things we are doing in parallel will affect the time the item stays in progress until delivery (or cycle time). And on top of that, we can use the very definition of the time frame for which the plans were made to define what is an anomaly, what is unexpected too much variability; in other words, what "bad looks like" (in this case, the definition of aged WIP > 90 days). These then become the levers by which we expect to influence the output measurement (cycle time) which we believe will help us to achieve the actual impact we are after (increase our chances to do the right things by decreasing time to market).

Knowing that, it becomes somewhat obvious what are the things we can do now so to "move the needle", such as: consider properly sizing the deliverables so that they small (enough) while still being valuable; have a mechanism to talk about the items that are already taking too long (or on the way to that).

That nicely takes me to the next insight: managing risks. To make a long story short, this is what I want you to get out of this:

Everything you have not yet started is at best an 'option' (with a potential of value).

Everything you are already working on is a 'liability' (you are already invested on it, but right now is just generating cost with no ability to generate any possible value).

Everything you already finished is now an 'asset' you need to manage (for as long as its useful / valuable, then keep it; if not, don't be afraid to discard and go back to the drawing board).

Once you understand that, you can realize how sometimes we get the focus wrong. Worrying too much for things still in 'option'  (like endless discussion and continuous reprioritization of backlogs). Not spending enough time talking about and acting in ways to transform already started 'liabilities' to see if we got a true 'asset'. Not nearly time enough understanding whether delivered things did become an 'asset'.

That takes us to plans (or planning)... But just next week!

* This published case study at Kanban+ illustrates a practical application.

ByRodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.