Gaining insights via conversations

2021-09-26

Introduction

While I was preparing to answer a colleague’s question about how to use Inceptions in specific cases, it made me review and distill my thoughts on Inceptions, as well as delivery, for that matter. I used to be an Inception militant - and even created an open-sourced reference to inceptions here. I still appreciate its tools, but will suggest an alternative way to get the same information, with less structure that Inceptions usually have.

The purpose of inceptions

Inceptions serve two purposes, in my opinion.

Firstly, it’s a tool to allow us, consultants or facilitators, to understand whatever we deem important about the delivery assignment we either committed to or are about to commit to as part of the inception deliverables. This is problematic, as the client is indulging us, and may have done so in the past with other consultants or initiatives, and may be in a state of fatigue and cynicism towards us.

Secondly, it supposedly serves the entire group, us and them, to analyze the state of the business needs as well as the process and technology that support it, current and future. This too is problematic, since we usually do not find ourselves in agile or digital transformation engagements. This implies that the people we collaborate with will not have the answers, nor often-times the interest, in anything out of their immediate scope. Their day-to-day life is to produce software to spec in a chain of hand-offs the depth of which they sometimes are not aware of. It follows, that they lose interest quite quickly as we explore a wider context beyond their immediate deliverables, for which we were brought in to help with.

We often look for shared understanding as a deliverable of an Inceptions. This is dismissible if we have been brought in to help a certain group within a larger organization. They already have that vision, and in this case, our value lies beyond the scope of an Inception, and can manifest as discussions about ways of working, basically agile-with-a-small-a.

An alternative approach

I have tried to lay the case that Inceptions, as we know them, are not fit to be used in situations that are common in our typical engagements. Certainly, if the engagement is with a startup lacking a delivery plan, Inceptions can be useful to define an eventual MVP, which too needs great care in planning, basically a very faint road-map adept to change.

What is left, if we accept the above-mentioned arguments? Assessing two kinds of risk, and working backwards from both. In my opinion, if we follow this new path, it will lead all those involved in the engagement to what we’d usually expect from an Inception, only without the indulgence, with less structure and more active conversations, rather than guided workshops.

Learn about risks, and work backwards from that

The first risk is easily identified, and addresses the product itself. This can be an API to a micro-service, or it can be a full-stack product. The risk assessment in this case can be accomplished with a futurespective, leading to a risk impact/probability map. I’d list the issues mapped in the high/high quadrant on the right-hand side of our delivery plan, and work backwards from there, listing all the dependencies that must be met in order to assure that by the time we get to the right-hand side, those issues would have been resolved. This activity is simple, and builds confidence. The nice thing about this approach (identical to the approach taken for the second kind of risk), is that it results in a graph, allowing many nodes to be mapped as we diverge-converge-diverge on ideas.

The second risk is also easily identified, yet requires more thought regarding the mitigation plan. This involves a discussion about debt at risk. Debt is what we will accrue during the development of the product. Debt at risk signifies the debt that we cannot assure will be repaid. Only when we explain that all debt is at risk till the product is in production and is monitored, will the concept of XP practices will be valued by our sponsor, and only then would we guarantee a shared understanding of both the product’s phases and the ways of working that enable continuous reduction of debt at risk. Debt at risk, once exposed (product in production), transforms itself to either debt (opportunity to pivot) or profit (opportunity to enhance further).

If we lay out both maps on the same page, we’d have two swim lanes, one for the product (futurespective map), and one for development (debt at risk reduction). The latter in support of the former, of course. The further we go to the left in the diagramme, the finer the nodes becomes, and may represent stories, but I’d recommend stopping at the feature level, using other tools to describe stories and tasks.

Conclusion

I would focus on the above-mentioned risks, and use the tools that inceptions have, in order to solve the risks, and move everything from the high/high quadrant to the low/low quadrant. I am hoping that you will get greater engagement using this methodology, rather than using the siloed, structured approach of Inceptions. I think the result would be a higher-fidelity assessment compared with the classic approach.

Do this at the start of each sprint. An IPM on steroids: question everything every two weeks. If I were to do this in a physical room, I’d tear up all the stories below the line, and write them up again, each sprint.

I’ve tried bits of this methodology in three previous projects and it seemed to hold water.