(2) What we should have done better

1. A more down to earth MVP 🌍

Alex Osterwalder — MVP

At the end of the design phase (which I describe here), when the scrum team just had been created, we were proud of having designed our MVP. But it was far too conceptual to translate it in technical terms.

Out IT Partners were used to receiving specifications, but we had none, and business owners (who knew roughly how the system was working) would jump too fast at a proposed solution. It took us few weeks to set some rules and give the proper specs to IT to work on the MVP:

From the business side, we should have restrained the rules earlier : (i) We would not create a new insurance coverage, as the internal and external process would have taken us minimum 3 months (ii) Itshould be calculated with the same tarification than the other e-commerce products

: (i) We would not create a new insurance coverage, as the internal and external process would have taken us minimum 3 months (ii) Itshould be calculated with the same tarification than the other e-commerce products From the IT side, we should have defined some rules like : (i) The product should not involve backend development. (ii) We should be able to choose whether to display it or not. (iii) It should be recognizable by any mean in the reporting (even if it would take some manual tasks)

👉 If you are not ashamed of your product, then it is not an MVP.

2. Test versus Talk 👀

We spent at least 3 weeks talking how we could build our MVP technically without impacting backends, get the right pricing, and able the display rules correctly.

Instead of making a hypothesis and testing things in a QA environment, we kept arguing on the theory.

👉 Confront ideas to the ground reality is the best way to know if they will work — as well as how and why they wouldn’t. We lost time at the beginning and started the sprint 0 with delay.

3. Monotasking vs multi-tasking ☝️

After a few months, the team was running very well. The company was looking for skilled product owners and I was requested on another project to take care of the redesign of an interface, and the developers were asked to dedicate a bit of their time to another project.

I was unable to deep dive in topics and understand technical issues . I could spend less time with the team, so I cropped on the time we would explain decisions.

. I could spend less time with the team, so I cropped on the time we would explain decisions. The scrum team spent more time switching task and lost in productivity.

👉 Monotasking is the best way to succeed in Agile. If you still have to share your time, then one of the two product must be a priority to avoid the dilemmas in backlog prioritization.

4. Think forward

Agility is often assimilated to emergency. I see it more like a marathon than a sprint, but we were often unable to plan well our events as we were in the run always. If I would have to redo it :

I would dedicate more time to sprint planning . Often, I ended up the week on Friday 7pm and still had to prepare for Monday’s sprint planning session, and thus couldnt get the maximum information we would require to make decisions in session.

. Often, I ended up the week on Friday 7pm and still had to prepare for Monday’s sprint planning session, and thus couldnt get the maximum information we would require to make decisions in session. I would have anticipated the time and capacity needed for iteration. After 3 months live, we realized we hadn’t anticipated this question : how do we let the product live and keep testing without wasting the team’s time ? This is when the project A becomes project B and the team has to deal with 2 products at the same time.

👉 Prepare sprint planning with the team by sending them the backlog so that they can ask you their questions before the session and you can dedicate this time to realy make decisions.