Please find below a few notes from a video chat about Lean Inception for a Dev with some of my colleagues form Thoughtworks.
How do devs work out what should be in MVP and start an agile project as quickly as possible?
Making sure there is a lean inception. Do not start working on a project or a feature if there is no alignment between what the business want, what the users need and what is feasible for you — developer — to build as a minimum necessary to fulfil these needs (or validate these hypothesis).
What’s the role as Dev in an inception?
An active participant. A Dev must be on all the lean inception activities.
What are the key-sessions in an inception you should run?
A Dev could be the facilitator for the whole inception (in case the inception has one facilitator), or the dev can be one of the facilitator for some of the specific sessions (in case the inception does not have one single facilitator). The sessions more likely for a Dev to facilitate are: Technical, Business and UX Review, Mapping Features to Journeys, the Features Sequencer and the MVP Canvas (especially the conversation on the block 7 — Cost and Schedule — about non-functional requirements, Sprint 0, MVP effort and the schedule).
Which ones you can leave out – or put to a later date? And why?
Breaking the MVP features into user stories. You can do this in the Sprint 0. In fact, you will have to constantly be doing this as the project progresses. It is not worthy breaking everything into user stories in the very beginning. Things will change anyway. Do break MVP and feature into stories one Sprint (or a few Sprints) before you have to work on the stories. If you use Scrum, you should be refining on the current Sprint what you will be developing on the next Sprint. Breaking a MVP’s feature into user stories should part of the Scrum Refinement meeting scope.
Team Norming: deciding how the team is going to work. You must run a few team norming sessions to align on how the team is going to work. It is easier to align on how the team is going to work after the lean inception. The reason, on the lean inception, the team achieves the alignment on what is the work and when it should be done (at least the MVP). These information — what and when — will make it easier the conversation on how the team will work. For this reason, I prefer to do norming sessions after the Lean inception. I typically schedule these on the Sprint 0.
What are the little things, tricks, and tweaks that keep your project as a Product and not being locked into delivery for the next few years right from the onset?
Do not release a detailed plan prematurely; for example a plan with all the user stories. Instead have a plan based on MVP and its increments (as features to be added).
Then you focus on the MVP. Work on it and report on the MVP features. Do not lock yourself on the user stories or detailed plans on technical tasks or technologies. The key point of a MVP is to help validade a business hypothesis. Things might change. So do not lock yourself into a fixed release plan, which goes into details about what, when and how.
The results of a Lean Inception is very clear about what and when. Even though your are very technical and can do it, do not lock yourself promising the how. Remember: the main goal is to fulfil the business and the user needs, validating the hypothesis, achieving great outcome. Keep your options open.
Think about the overall architecture but do not act on it prematurely. Focus and work on the MVA — the Minimum Viable Architecture — to match the MVP needs and fulfil the product evolution strategy.
What are common anti-patterns we’re still seeing around frequently?
- Inceptions which the result is a large backlog with many user stories, assuming all will go fine, without validating the business hypothesis via MVP. The world is changing too fast and backlogs get outdated really fast. So don’t build a large, fine grained backlog.
- Inceptions with scattered sessions that are not consecutive and non collaborative.
- No clear involvement of UX people and business people.
- Inceptions without a clear agenda and a clear goal.
- Inceptions facilitated by one person who has a direct interest on the end result; for example, a business person that facilitates in a way to get his/her features prioritised.
- Inceptions with shared facilitators, where no one is taking care of its continuity and goal achievement.
- Naming some other type of workshops as an inception. For example: Design Sprint, ideation workshop and Portfolio prioritisation workshop.
Notes from two Devs
Ben Tarenne and Melania Sánchez Blanco , two great developers at Thoughtworks, have prepared an amazing presentation about inceptions. Please find below some very insightful notes about a tech lead perspective on inceptions.
How does it feel as a dev attending an inception?
- It is a very intense week or days, so take breaks
- Energy management is key
- Can be frustrating envisioning so many ideas and afterwards plan to do only a few
- Motivating for the incoming project. I can influence what the team will be doing. Give a sense of product ownership to the team
- Get to know the future stakeholder and your teammates
- Everyone gets context and everyone get aligned
What should you do as a dev in an inception?
- Be inclusive for people with less experience / knowledge
- Help / facilitate / delegate
- Propose and facilitate tech sessions
- Focus on risk mitigation
- Keep in mind delivery and deadlines
- Be aware of team / group dynamics (healthiness, energy)
Any advice for a dev going into her first inception?
- Be patient, everything will make sense at the end of the inception.
- This is the time to challenge everything.
- Do recaps at the beginning of the day about what was done the previous day.
- Ask when needed for clarifications, this is the time to ask about anything that the client shares.
- Try to define high level steps during product sessions, don’t get too technical.
