A colleague recently asked me the question: “When do I run an inception?” and I really had to think about it.

We run discovery and inceptions routinely at the start of a new project, and whilst we’ve always had plenty to say about the how, on reflection I wanted to refine when a software inception is needed.  

Should a software project inception be limited to the start of a big new piece of work? Should we extend the rule to every large feature of a project? Each time the team changes? Should we even consider planning in multiple inceptions over the timespan of an engagement? 

I’ve come to the conclusion that the answer to all of the above is yes – to all this and more.

Reasons to run a software inception

In its wider sense, an inception is a set of pre-delivery activities run collaboratively with cross-disciplinary teams. Its purpose is to make sure we have enough information to start delivery with the best possible chance of success. Here are some of the desired outcomes: 

• Gain shared understanding and context
• Identify user needs
• Build relationships, empathy and trust
• Gain alignment on desired outcomes and approaches
• Identify which decisions need to be made when
• Understand and manage risk 
• Build solid foundations so we can hit the ground running with confidence.

When you think of it like this, software project inception work is valuable at numerous points over the course of an engagement’s lifetime. Achieving these outcomes is important whether you’re working on a large multi-year project or a small feature lasting just one day.

An inception by any other name? 

It starts to feel more nuanced when the work to be done gets smaller. But it shouldn’t. Think about it: if you’re starting work on a new feature that will be delivered over a few weeks, it would feel natural to have a short workshop to align on goals and architectural implications. What about when you’re kicking off a new story? A story kick-off might be all that is needed to share context, align and make the decisions needed for the next set of actions.

The point I’m making is that the same principles apply, irrespective.. Call it a kick-off if you like, or even a three amigos session; if it achieves the goals I listed above, it still boils down to a (mini) inception. In a story kick-off you have already built the wider context and relationships so you can focus on the marginal change.  But however marginal the change, it’s always going to be better if those outcomes above get ticked off first, even if it only takes a few seconds.  

We’ve all seen work get pushed back due to misaligned expectations, risks that weren’t identified up front, and knee-jerk responses to uncertainty and complexity. That’s what the software development inception phase is designed to tackle. Essentially, when kicking off any new piece of work – big or small – considering the key outcomes of an inception will help. 

What should an inception look like? 

Well, given my message here, this next part won’t come as a surprise. What activities you undertake on an inception, or even its duration, is very contextual. There is no one-size-fits-all approach. Just as you might give different names to different types of inception depending on the situation, the activities you need to do during a software development inception will vary according to need. 

Whatever it looks like, the goals of an inception remain the same: to share context and create alignment to build a secure foundation that informs every action going forward. 

Like all good systems, size doesn’t matter. And if a question is too complex to answer quickly, an inception might just be the answer.   

If you’d like to understand more about how to use inceptions in your organisation click the link to learn from our Inception Playbook.