Inception: Getting to rapid alignment on team vision and goals

Inception consists of a series of up to 12 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 influence team decision making.

Note: To the best of my knowledge, credit for the Inception concept should go to Jonathan Rasmussen, who describes it in his book The Agile Samurai: How Agile Masters Deliver Great Software.

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 twelve 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.

References

Diana Larsen & Ainsley Nies, Liftoff (2nd Ed.): Start and Sustain Successfully Agile Teams.

Jonathan Rasmussen, The Agile Samurai: How Agile Masters Deliver Great Software.

If slide decks are your thing, there is an Inception deck available:
https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/