3 main factors for delays on agile projects

30 Mar 2022 | Lean Inception

Lean Inception is an excellent method for aligning teams to build the right product, all in an agile and effective way. With the definition of the Minimum Viable Product (MVP), you and your team are aligned  about how to validate the hypotheses and verify the best direction to follow.

It is worth remembering that, at the time of deciding the MVP, things do not need to be defined in details. This reflects an important characteristic of teams working with Lean StartUp and  Lean Inception: flexibility. The team focus on defining what is to be validated by the MVP. The WHAT (to validate) is more important than the HOW  to build it or the HOW LONG until the product features are perfect. By working with MVP, the team has the autonomy to make adjustments, to simplify things so that they move faster, validating it quickly.

However, even with all this flexibility, being able to build the simplest thing to validate the MVP, many projects delay. The main reasons for this to happen are:

1) Lack of alignment on dates and deliverables

2) Sprint Zero delay

3) Changing people on the team

See below for more details on these three reasons. If any of these are occurring in your organization, get together and align your team soon to fix the problem.

Lack of alignment on dates and deliverables

A big fear of the developers who are going to build a feature is in saying how long it will take. Many teams, when filling out the MVP Canvas,  do not want to estimate the delivery time. I consider this a problem. It is essential to clarify any expectations on this subject.

A clear definition of a MVP expected date will avoid delays in the project and will also align expectation between the entire team. Everyone knows they are pursuing validate the hypotheses via the MVP, and they know how long they have to create the simplest  thing to validate it. There is no confusion between developers and stakeholders. For example, the developer imagining that they have about three months to deliver the MVP (usually with complete features) and the stakeholders already believing that the MVP (to validate the business direction) will be done in a single month.

Sprint Zero delay

The second biggest mistake is related to the delay in getting started. Sprint Zero is a term commonly used to represent the time needed to carry out all the set-up tasks, that is, everything that needs to be done before starting to work effectively on the features of your MVP, all according to your reality, the context in which you are inserted.

In this scenario, many teams consider a Sprint Zero, which takes a week, and, in practice, they are surprised by a very different reality, taking a month, for example, for people to be able to start working on the MVP features.

Changing people on the team

We know that changes are very common in teams and in any organisation. However, it is very important to consider that if this happens during the Lean Inception or a few weeks after it, it will lead to delays in the delivery of your project.

The people who are participating in a Lean Inception and creating the MVP Canvas are the ones who are aligned and will get creative to quickly build the simplest solution to validate the business hypotheses. You should not transfer such responsibility to another person, to another group, typically, people who did not participate in the process from the beginning. It is very hard for someone who was not in the Lean Inception to understand  all the 95 out of 100 things that were talked about and are not to be part of the MVP.

A MVP must be concise and small, therefore, on it, there is probably 5% or less of all the conversations and possibilities discussed during the Lean Inception, the process carried out for deciding and aligning about the MVP. If you were not part of such workshop, you will probably ask yourself about all the other 95 things that are not in the MVP Canvas.

In other cases, the MVP decision is made by one team and another team is responsible for the work. This is also a big mistake. You can share a few generated artefacts, but not all the context and commitment from the original group going through the Lean Inception.

There will be delays, as it will be necessary to carry out a knowledge transfer and/or an on-boarding for new people in order to align everyone again in the construction of the MVP and the product increments..

Need to estimate? The Lean Inception might help you with that

Want to know how to guide the agile project estimation process in a Lean Inception? So, follow these nine steps that will make this process much easier:

1) Create the feature sequencer;

2) Select three features;

3) Describe the tasks of each feature, everything that needs to be done for the delivery with quality in your context;

4) Group tasks by size;

5) Decide the duration for each task size;

6) Calculate the average time;

7) Calculate the capacity of the team;

8) Decide on Sprint Zero duration;

9) Clarify dates and increments.

Therefore, the estimation conversation should, indeed, be a topic brought up and discussed in your Lean Inception. Don’t be afraid to estimate! Don’t be afraid to say what and when you are going to deliver. Do not treat estimation as a forbidden conversation or a radical movement (#NoEstimate), but as something that needs to be taken into account, especially when aligning abotu a period for getting something validated (the simple possible way!). This session is described in details as a chapter on the Lean Inception book.

Did you like this content?

On Caroli.org there are, among other things, various materials related to the topic and many training options. Access our website now and continue your knowledge and learning process.

Paulo Caroli

Paulo Caroli is the author of the best-selling book “Lean Inception: How to Align People and Build the Right Product” (the first on a series of books about Lean Strategy and Delivery). He's also the creator of FunRetrospectives.com , a site and book about retrospectives, futurospectives and team building activities. Caroli writes on this blog frequently. Receive the next post in your email. Sign up here .
MVP philosophy and the Justified True Belief

MVP philosophy and the Justified True Belief

Lately I have been listening and reading about philosophy and I came across a theory that got me thinking about hypothesis driven development, Minimum Viable Product (MVP) and validation. It is accredited to Plato from around 369 BC with the name of Justified True...

read more

Pin It on Pinterest