This diagram is based on Jeff Patton’s “I’m Glad We All Agree”

Inception: Getting to Rapid Alignment on Team Vision and Goals

Inception consists of a series of up to 11 exercises that help teams rapidly arrive at a shared understanding. For an Inception session to be successful, it is very important for there to be a neutral facilitator present, who acts as a moderator for the conversation, without trying to push team decision making in a particular direction.

Credit for the Inception concept goes to Jonathan Rasmussen, who describes it in his book The Agile Samurai: How Agile Masters Deliver Great Software. Also noteworthy in this context is Jeff Patton’s I’m Glad We All Agree diagram, which captures beautifully the essence of how the same group of people can leave the same meeting with a completely different understanding of what transpired, in the absence of asking clarifying questions.

What’s the purpose of inception?

Particularly when a new product or feature set is being introduced, it can be a challenge to ensure that the team and the stakeholders have a shared understanding of what needs to be built. As Rasmusson says in his book,

Assumption of consensus where none exists is what kills most projects

Rasmusson goes on to say that two of the worst things that can (and often do) happen when teams are just getting started on something are when …

• People fail to ask the right questions
• People don’t have the courage to ask the tough questions

How is inception different from chartering?

For anyone who has facilitated a chartering session (often referred to as Project Chartering or Team Chartering), chartering sessions can be significant undertakings which can last anywhere from a couple of hours to one or more days.

In the hands of an experienced facilitator, chartering sessions are a great tool to have in the toolbox, and can pay big dividends early by helping teams and stakeholders get into alignment on what they are trying to achieve. (See below for a reference to a book on the subject of Chartering by Diana Larsen & Ainsley Nies.)

A significant difference between Chartering and Inception can be session length. I have completed many Inception sessions in less than one hour. (If you’re wondering how that is possible, I have the team complete a subset of the Inception exercises.)

Note: Project Chartering or Team Chartering is NOT the same thing as a Project Charter document, for any proponents of the Project Management Institute that might be reading this post ; )

Desired outcomes

As Rasmusson points out, the primary desired outcome from an inception session is:

• Align on goals, vision, and context for a project/product/feature set so a team can make intelligent decisions while executing

If stakeholders are also present for the conversation, than an additional desired outcome is:

• Give stakeholders the information they need so they can be informed participants as the team iteratively builds the desired product/feature set.

Who attends

Who needs to be present for an inception session depends on the business context. At a minimum:

• The team(s) that would potentially be doing the work
• The Product Manager/Product Owner
• A neutral facilitator (typically an Agile Coach or Scrum Master)

Note: Depending on the context, it is often wise to ensure that customers or other stakeholders are also present.

Inception exercises

Inception consists of up to eleven time-boxed exercises.

Here is the minimalist set of Inception exercises that I often use:

• Why are we here? To state this a bit differently — what is the single most important reason for us to work on this right now? (I would strongly suggest that it’s too early for an Inception session unless and until this question can be answered. Therefore, if you’re going to facilitate an Inception session, reach out to the person(s) who you think can answer this question before you meet, and see whether they can in fact answer it.)
• NOT list. Teams often get bogged down in questions about scope. One way to make the conversation about scope shorter at the outset is to try to agree on what is NOT in scope. Suffice to say, this can be a very revealing and insightful conversation, because it is common for the team and the Product Manager/Product Owner to enter the Inception session with very different ideas about what is not going to be in scope.
• Technical solutions. Depending on how well the team understands what is being asked of them at this early stage, it can be a good idea to have a conversation about what technical approach might be best suited to addressing the business need. As the team’s understanding evolves over time, it’s possible what they originally thought about the technical approach could change, but I find it tends to be helpful to have such a conversation as early as possible.
• What keeps us up at night? The essential aspects of this conversation are to try to surface things that could constitute dependencies and risks, and to capture some initial thoughts on what steps can potentially be taken to minimize the impact of such dependencies and risks.

Additional Inception exercises include:

• The elevator pitch. The basic construct here is to arrive at a brief description that could be used to explain the what, why, and how to somebody who knows nothing about it, typically in 60 seconds or less. The Inception Deck referenced below provides a useful template.
• Product box. This is a popular exercise in training contexts like the Certified Scrum Product Owner (CSPO) course. The idea is to create basic content (images and text) that would go on a box containing the product. (Whether it would ever actually be a shrink-wrapped product is beside the point; the idea is for the team working on it to be able to describe it in a way that would make sense to a prospective buyer/user.)
• Your project community. This conversation focuses on making sure it’s understood who the stakeholders are.
• How big is this? A preliminary conversation where the team tries to arrive at how large an effort this is, in comparison with other work they’ve done.
• Trade-off sliders. A visual technique that helps reinforce the notion that only ONE thing can be fixed. If there is a deadline, then schedule is fixed; and if there is a must-have feature set, then scope is fixed.
• The Team. An initial conversation about who’s on the team. Hopefully all of them are in the room for this conversation ; ).
• The first release. It can also be helpful to talk about which feature(s) could potentially be released the earliest.

Conclusion

For anyone who’s just reading about Inception for the first time, I suggest that you take it for a test drive with a small group of people initially, so that you can get accustomed to the flow of events, what works best for you in terms of facilitation, and which of the activities are least likely to fit your particular context.

I have used Inception in many different team contexts, such as in a team break-out session during a multi-team Release Planning event, when contemplating significant changes to an existing product, or when launching a new product. Another common use case is when starting up a new team, and for this latter situation in particular, I highly recommend the following additional resources for reference:

• Diana Larsen & Ainsley Nies’ book Liftoff (2nd Ed.): Start and Sustain Successfully Agile Teams. This is the definitive guide when it comes to planning team start-up, aka liftoff, activities.
• The Excella Team Launch Guide, a short (2-page) hand-out that serves as a great quick reference which aligns nicely with the Liftoff book.

References

With regard to Inception, here are the reference materials that are likely to be most useful:

• Jonathan Rasmussen’s book, The Agile Samurai: How Agile Masters Deliver Great Software.
• A downloadable Inception deck that Jonathan created:
  https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/