Agile projects emphasize the early and continuous delivery of valuable software, whose value comes from business objectives and the needs of customers. Lean StartUp product creation helps this by promoting the incremental release of an MVP (Minimum Viable Product) — a simple version of a product that is given to users in order to validate the key business assumptions.
But how do we work out what should be in MVP and start an agile project as quickly as possible?
How do we ensure the team starts creating the product with a shared understanding and an effective plan?
I designed Lean Inception to answer these questions.
Inception, the beginning of an agile project
Naive agile has no up-front work, but in practice we realize we have to do some. For ThoughtWorks, Inception is that "some". Since I joined ThoughtWorks in 2006, I realized all agile projects in the company started in a similar way. The project team would get together for a few weeks, going through many activities prior to starting the delivery work: this was the inception.
The ThoughtWorks inception was primarily developed by Luke Barrett around 2004. Jonathan Rasmusson (author of The Agile Samurai) and Jeff Patton (author of User Story Mapping) both worked at ThoughtWorks for a while, and they described and further developed inception techniques in their books, from which I learned a lot.
Our inceptions vary from project to project, but they usually generate alignment between the business and the technical people, and create an ordered list of user stories with estimates together with a release plan.
And I was very satisfied facilitating these agile inceptions this way until 2011, the year my son was born. The thing is, I was the inception facilitator, but the inception would take from two to four weeks. And I could not stay away from home for more than a week. I had to make the inceptions leaner, somehow make them fit in one week.
I was going on my first trip after my son was born. On a long flight from São Paulo to San Francisco I read the Lean StartUp book from Eric Ries. From it I found the perfect excuse to reduce the inception length, and return home after one week.
Why is it called The Lean Inception?
This new inception style is definitely a shift from the 2006 inception. The team doesn't write and estimate user stories anymore. While experimenting with this new style, the name inception gave everyone the wrong message. I needed a different name.
The new inception style is lean for two reasons:
- the inception duration is shorter, removing everything which was not about the product (such as architecture, project, etc), making it lean
- the end result of the inception is the understanding the MVP, a main concept from the Lean StartUp movement.
Therefore the new inception style had a clear leading name: The Lean Inception.
Why a Lean Inception?
A lean inception is useful when the team needs to iteratively develop an MVP. Although the term is often misunderstood, the central property of an MVP is that it is something we build in order to learn whether it is worthwhile to continue building a product. So we choose features based on testing our assumptions of what is valuable to our users. For this we need to understand who our users are, what activity they do that the product supports and how to measure if they find the product useful.
We've found the workshop to be valuable in two main circumstances.
- Large projects find a lean inception valuable to start quickly and be oriented to work in a lean style. Such a start build early iterations designed to discover and test what features are truly valued by their users.
- Smaller organizations (such as startups) use lean inceptions to take an idea that's been tested by some pre-software MVPs and evolve it into a software product.
This workshop is specifically about understanding an MVP, it doesn't substitute for ideation sessions, customer research, architectural review, or competitive analysis. It's one specific technique that's part of understanding what it takes to build a successful product. Exactly how it fits in with these other activities depends very much on the specific context of your organization and the development effort that you are working on.
The lean inception consists of a series of activities, typically scheduled over the course of a week. I'll explain each activity in the following timetable links:
|Monday||Introduce the inception, kick off, and Write the Product Vision||The product Is – Is not – Does – Does not|
|Tuesday||Describe the Personas||Discover the Features|
|Wednesday||Technical and Business Review||Show the User Journeys|
|Thursday||Display the Features in the Journeys (coming soon)||Sequence the Features (coming soon)|
|Friday||Build the MVP Canvas (coming soon)||Showcase the results of the inception to those interested in the project|
We are publishing this guide in installments, so not all of the activities are published yet. To find out when more installments are published follow
This is an example timetable, please don't treat it as a fixed thing, but let it serve as a good example for how things might flow.
We start the inception with an introduction and kick off, and finish with a showcase. In an ideal world, everyone would be present for the whole inception. However, we usually have people who are very much interested in the direction and result of the inception but aren't able to spend full time on the effort. The minimum necessary is that these stakeholders attend the introduction, kick-off and showcase sessions.
Paulo Caroli is a Principal Consultant with ThoughtWorks, based in Porto Alegre, Brazil. He's been developing software for over twenty years in Brazil, India, USA and Latin America. In 2000, he met Extreme Programming and since then has focused its expertise in processes and practices of Agile & Lean. In addition to “To the point” he is also the author of “Fun Retrospectives; activities and ideas for making agile retrospectives more engaging”
To learn more…
This article summarizes the book "To The Point, a recipe for creating Lean products. " While this article gives you a summary of the workshop and what it contains, the book goes into more depth on how to prepare and run it, It also contains tips and tricks that I've learned from running workshops that will help you make yours a success.
23 March 2017: Published activity Show the User Journeys
22 March 2017: Published activity Technical and Business Review
21 March 2017: Published activity Discover the Features
20 March 2017: Published activity Describe Personas
16 March 2017: Published activity What Product is (and isn't)
15 March 2017: Published overview page and Write the Product Vision