Inception workshops intend to kick-start a new project by getting all the stakeholders on the same page and prepare a rough delivery plan.

In general, the delivery focuses on building a “MVP” (Minimum Viable Product). The MVP should ideally be the minimum viable product that can be released to the end user. They’re usually between 1 to 4 weeks long depending on the kind of inception that works for you - lean or traditional.

My experience with inception workshops

The following is a quick summary of my experiences with inception workshops, ordered chronologically:

• At the very beginning, you need to identify and bring all the stakeholders of the project together for the inception. This is difficult because stakeholders generally have other important business to attend to and finding a time slot that everyone is comfortable with (without clearly understanding why they must spend whole days to discuss something: “just schedule a meeting of two hours instead!”). We had a lot of fun playing appointment tetris with the calendar.
• Once you have everyone in the room, you try to achieve consensus on a broad vision for the project. Usually, you’ll find that some stakeholders are from rival camps (e.g. “business” and “tech”) or meeting each other for the first time. As such, achieving consensus without having a shared context is not a cakewalk.
• The inception facilitator has a tough job. They have to find ways to resolve disagreements and suggest a middle road. In many cases, they have to fill large gaps in crucial artifacts by themselves (like user journeys for example) instead of doing it collaboratively because it is too tiresome to resolve all the disagreements. A lot of these differences of opinion are because of the large number of unknowns - however, you are still expected to deliver something by making a lot of assumptions. These assumptions don’t necessarily hold true in the long run.
• The team then needs to come up with a technical architecture that accounts for all the features and capabilities upfront. Technical teams can have endless discussions about this in the workshop. Keep in mind that there are a lot of unknowns across the board at this point, so we’re effectively discussing about building a castle in the air.
• User journeys are translated into epics and features. These epics and features are sequenced to produce iterations. Bring them together and you have a MVP! Finally we can answer the burning question in everybody’s minds: when can we deliver this MVP? Therein lies the problem: you cannot come up with a high level schedule/cost estimate without slicing these epics and features into user stories and estimating them in the first place. You might end up with tens or hundreds of stories that need to be estimated, and this is not a fun activity. Neither is this useful: the amount of guesswork is just too much to be of any value.
• At the end of the inception, the stakeholders are anticipating a road-map, a timeline of the project that provides them with rough delivery dates. They may even have a sense of entitlement because of all the time and effort that they’ve invested participating in the inception. They are quite disappointed when they’re provided a very “high-level estimate”, and not something more concrete. This is often the case with stakeholders who are not used to agile ways of working.

We can see a pattern emerge from the above observations. Inception workshops end up prioritizing coming up with a plan instead of responding to change. Production of working software is delayed, the key ingredient to promote faster feedback. The intention behind having inceptions are noble; however the execution seems to be flawed. You end up planning a mini-waterfall that would be delivered incrementally.

An alternative

But what if we could apply the same incremental thinking to planning as well? Inceptions are all about discovering products and their delivery. Why can’t we discover a product in an incremental fashion?

In the early days of a software development project, we find that the project delivery is not targeted toward the end user. Instead, the business stakeholders need to use working software to validate their ideas and give them confidence that they are on the right path.

But you need a starting point to build working software. How do you find this starting point if you haven’t conducted an inception workshop yet? Here, the concept of ”steel threads” is useful. A steel thread is defined as the core thread of functionality that runs through your product. For example, in a digital banking app, while the app may have functionalities such as account management, cards, loans etc, the core functionality is the ability to make a transaction. Usually, the business does not have divergent views about the core functionality of a new product. A quick initial meeting with business stakeholders is enough to arrive at this starting point, and this is good enough for us to start building software as well.

Building the steel thread

How do you approach building this software steel thread? Here are some of things that have worked for me:

• Spend some time slicing the functionality into thin and vertical user stories. Again, this would be a quick exercise since you are only working on a single, core feature.
• Setup short sprints (1 week is often doable) that allow you to demo the working software as quickly as possible. Invite all the relevant business stakeholders to the first demo.
• Don’t worry about estimations at this point. Allocate stories to the sprint based on priority.
• Don’t worry about setting up the entire project from commit to production with all the environments and pipelines. Ensure that you have automated a path to a single demo environment instead. A lot of tools available today allow you to do this quickly, for e.g. Heroku Github Integration. This is important since your primary end user is the business stakeholder (or product owner) and you need to get their feedback through demos as quickly as possible.
• Document the process in an evolving wiki, where you can detail the context, add relevant stakeholders and present the architecture of the software.
• Don’t approach the code like it’s a throwaway POC. Write production quality code, with tests, refactoring and continuous integration.
• Showcase your work in the demo, but also discuss the context and thought process behind your approach. Create a space for all the stakeholders to discuss the evolution of the product. Engage them and actively seek their feedback.

The outcome

Usually, it takes a couple or more sprints to deliver the core functionality. However by the time you get there, you will have achieved the following:

• The business stakeholders are now involved and collaborating to provide feedback on working software. They’re excited to see results so quickly, and they appreciate being part of the creative process. As a team member, you now have a platform to connect with the stakeholders and get introduced to new ones who might have been missed before.
• If you’re trying to drive agile practices in your organization, this gives you a gentler ramp to introduce them to these practices as you go through the sprint. With an inception workshop, they are introduced to these concepts too quickly and abruptly.
• Your understanding of the organization’s structure, processes and ways of working matures as you gradually get in touch with people from different parts of the organization. For example, you may have to get in touch with the infrastructure team to provision resources, or to the security team to understand their practices. Often, these teams get left out of the inception workshops.
• Your understanding of the organization’s tech architecture matures. You are now in a position to design the system within the context of the existing architecture.
• You will gain confidence to estimate new stories better, since playing a few stories has given you the relevant context.
• Everyone’s understanding of the domain is now more clear. Business is in a better position to evolve the product in further iterations.

What’s next?

After delivering the core steel thread functionality, there’s a couple of different directions you can take. You can organize an even shorter inception workshop to define the MVP. The workshop would go much smoother this time, and you won’t have as much difficulty coming up with a road-map. A different direction might be to continue iterating on the product using an evolutionary and iterative approach.

As always, I advocate evaluating for yourselves what works best for your context. The alternative approach to inception workshops given above may not work for every setting, but hopefully it gave you some new ideas to think about.