In a Lean context, create a system that can evolve over time is a waste or worth in an early stage?

Imagine that you have already validated a possible need for a product and you start to create the first Minimum Viable Product, that's not a Prototype.

Even though you have less risk, you still need to try a lot of stuff. The system will be changing fast and often, and sometimes you need to replace the whole system.

In this context, do you think that investing in the next points is a waste or actually worth to do:

• Continuous Delivery System
• Good practices
• Automated testing
• Monitoring
• Analytics

If you think it's not worth at an early stage, then when you think it's worth?

Comments

[Dĵ ΝιΓΞΗΛψΚ]

in projects where there's no prototype and there's only a vague idea of what the end result will look like, my team (typically) follows this path:

note: we mainly do web apps with a js client and c# rest server.

1. initialize git repos (one for web client and one for api server) with ci/cd pipelines where every commit to master will push out a build to a live staging server. devs only commit working code after they verify the new feature works locally on their machines. team leaders review the PRs to make sure everythings in order before merging to master happens. we use vertical slice architecture so merge conflicts happen extremely rarely. because one dev only ever modifies files inside one feature folder. devs are required to pull from master into their local branches as much as possible while working with their local/feature branches.
2. head dev/ architect manually tests/ tries to break the live staging app and makes sure things are heading in the right direction. if the current state of master is stable he/she pushes a tag in the format of v1.0.0 etc. another cd pipeline picks up this tag and pushes a build to the production server. the mongodb library we use enables us to do automated data migrations so production data gets automatically transformed in to the shape of the latest valid schema.
3. we don't write any automated tests until v1.0 of our production app. as soon as v1 is released we drop everything and start to write integration tests and try to achieve >90% test coverage. we do this as we feel having to write tests drains brain power that we can use to better architect the features we write. and also the requirements/app architecture changes too often until v1 where things are always in a state of flux and having to manage tests is just a waste. we however don't touch our master again until theres a good enough integration test suit.
4. once v1 is out and test suit is done, then we setup monitoring and analytics.

this is not a holly grail for us and we evaluate our processes depending on the project/task at hand. but the above has served us well so far. and the only pattern/ practise we ask every team member to follow religiously is KISS. if they submit PRs with too much complexity they'll be asked to redo that feature simplified if feasible.

[Aleix Morgadas]

Thanks for sharing! :)

I would say you work in a quite complete team, with different roles and people involved, and which each person have their own responsibilities during the development and delivery.

In your scenario, I miss which is the time between you initialize the Git Repository and the first v1.0.0 is released, an average number.

On the other hand, to me it's strange the next point:

as soon as v1 is released we drop everything and start to write integration tests and try to achieve >90% test coverage

If I understood it correctly, you first release (the application is live and with users) and then you start writing test. Once you have both, v1 out and tests, you start adding the monitoring and analytics.

Why not do that during the development? Why not setup the monitoring since the beginning and also add some testing (maybe not a 90% coverage)

[Dĵ ΝιΓΞΗΛψΚ]

trunkbaseddevelopment.com/

[Aleix Morgadas]

IMHO and experience, I have seen that introducing those practices and methodologies at the early beginning really pays off.

It was hard to see the benefits at the early beginning, as an engineer, having as much as automated as possible really helped me deliver faster and with confidence.

Under a context of so much pressure and changing environment, having a backup as a Continuous Delivery System combined with an enough trustful automated testing suite was awesome. We were able to accept more changes and deliver with confidence that the important stuff didn't break too often.