Inception at Railsware. Part 2

In our previous blog post, we’ve reviewed the Inception as a good way to efficiently start every new project. In this second part, we will go over the Inception process and it’s results in more details.

Introduction

Inception starts with all participants introducing themselves around the table, explaining their role and responsibilities. Needless to say, it is important for all the product stakeholders to have their responsibilities split and well defined. Our recommended approach is using RASCI model.

Demo

After the introduction, client goes into showing a demo of what he currently has and sharing his thoughts on the product. This might be any kind of information exposing the product idea: screens, diagrams, data flow charts, wireframes, etc.

Issues/benefits/risks and goals

Discussion of the future application starts with the consumers’ perspective – who they are, what kind of issues they have and benefits they want to receive – and then moves on to the client’s domain knowledge. Since the client is in the context, maintains the product/idea for quite a while and holds all the data related to it, we have to get all this knowledge from him and really make sure that we understand everything correctly.

Goals

With the team getting deeper into context, we start interviewing client for goals (i.e. business related, etc.) and help him put these goals down on paper in a way consistent for our comprehension.

Roles and workflows

After a bit of a break we move on talking through all the roles, making sure they are consistent and prioritized. The crucial ones are identified and the rest are pushed onto the next development stages. Eventually, for each role we define the workflows it’s supposed to go through and draft the screens of the most critical workflow parts.

Prioritization

The next Inception stage is organizing everything using MoSCoW prioritization method. It helps us arrange client’s domain knowledge in a technical roadmap, that would guide us through all the client’s requirements during the actual development process.

Risks and potential solutions

Finally, with the goals set, we put them on the board and move on to writing down risks on the paper cards (i.e. related to business, process, integration, data, technical aspects, etc.). Each card is then discussed along with the possible solutions of how these risks can be mitigated.

Outcome

As a result of the Inception, both the development team and the client are getting the following documented, clarified and synchronized project details, along with the practical collaboration and more effective communication between both teams:
  1. Business goals and Risks;
  2. Roles/Workflows and critical flow mockups;
  3. Prioritized Weekly Roadmap and Epic user stories;
  4. Client’s knowledge of the development team’s software development specifics.
That’s it! Now, we’d like to initiate a little discussion here: how do you start your projects? have you adopted anything similar to Inception? what other methods do you use to efficiently start working on a product? Share your expertise!