Continuous Improvement in software production 🔁 Agile - Lean Startup - Scrum / approach, methodology and technique

Useful approach and set of tools for solo entrepreneurs, startups or collaborators teams, and even corporations for their inner innovation teams (intrapreneurship). I proceed to share some learnings and personal reflection from an engineer point of view after reading the book “Lean startup” and about agile and scrum techniques.

In short, the terms I will develop this article about:

• Agile is an approach, it's a spirit, about moving fast and reacting quickly to changes happening around.
• Lean Startup is a methodology for quick improvement and market validation. It represents 'today's possibilities,' an adaptation of past production methodologies (lean manufacturing).
• Scrum, techniques for software development. It involves creating stories and rushing for a couple of weeks to develop the features needed to fulfil the desired or expected functionalities by the end user.

All three terms refer to continuous creation and early market validation, entering in the fast cycle of build-measure- learn or feedback loop. Approaches and methodologies to achieve a goal using continuous improvement.

One of my greatest discoveries through this book: a software startup doesn’t need a software product as an MVP. You can use other platforms or just get some calls that show that your software’s solution is really needed. MVP would be better translated to hypothesis tests, there are many ways to test a hypothesis.

First let’s add some context: what is a startup?

A startup involves much vision and many assumptions to be tested. Many questions in need of an answer. A learning entity, surrounded by uncertainty. So where is the value of a startup? It is not about being original and shaping a product after an idea, it is about validation, i.e. market testing, and learning how to build a sustainable business.

So you have the vision, that’s where you are heading to but: Is the team moving at the right pace to realise the vision? Now we need a (somewhat) structure to proceed or at least a way to measure our improvements, engineering or accountability part. Consistently keep in mind that projections and planning belong to manufacturing, while experimentation belongs to startups.

Engineering aspect: measurements and techniques

How do we measure this early success and market validation?

Measurements

Measurements shouldn't be in absolute terms, for example, new subscribers or web page visitors. It should be in relative terms to measure better the inner improvement of the team along the phases or within the growth, and how their changes affect the customers. Avoid vanity metrics - metrics only useful to show off to investors, efforts dedicated here are efforts not dedicated to build a sustainable business.

About measurements and scalability: to get that hockey stick growth you need to optimise, I thought that was a random moment of product discovery by the market or sort of viral moment in promotion. However it seems to me now that it is a careful measurement and inch by inch improvement on the business parts or features that are attracting customers.

After a measurement you might pivot, a natural step in agile, means testing a new hypothesis for a product, business model, and growth strategy.

Techniques

We just come from the industrialization era, we are taught about mass production and economies of scale. But that’s not how we have to work nowadays, not for software thanks to the velocity of testing and deployment, nor for hardware thanks to 3D printing. In order to find a faster iteration process: use small batches, ship products with small variations.

• Pull (demand side ordering) > Push (supply side offering in advance). Our pull is a hypothesis about the customer, not a straightforward demand.
• Andon - stop the whole production in observance of default or a major disturbing event.
• Minimise waste: “Any extra work we do beyond what is required to learn from customers is a waste”.
• 5 Whys: if something undesired happens, failures or technical faults, ask 5 times why going deeper to uncover the root of a problem.
• For software production follow the Scrum framework: write stories for customers expectations, work prioritisation, develop and validate, evaluate the results.

Adaptive organisations, those which can move at different speeds depending on the matter they are taking care of at that moment. Going fast and without looking to the sides is neither the answer, we should have adaptive process and constant check where problems are originating, use the 5 what and even better as a group session.

For intrapreneurs building a new product and business line: even if scarce, secure resources; independent development authority, fewer approvals; personal stake in the outcome (financial or non-financial). After showing your team value on the market and measure against other possible teams, then be integrated within the larger company’s portfolio.

Personally speaking

By academic studies I am a production engineer, basically optimising machines and humans, by professional experience I am an entrepreneur. Culturally speaking, my German and Swiss immersion maximises planning and my Spanish side maximises flexibility, which helps understanding the dilemma “Just do it entrepreneur vs Analysis paralysis" and overcome this point. Critic to engineering background entrepreneurs: in engineering everything is about anticipation and a product that won’t fail, with a 99,99% reliability, errors are very expensive in industry, for example in case of a product call back. I tend to over-prepare a product searching for perfection, however software errors might be much easier to solve, with immediate deployment of new features or bug fixes to real customers. In general avoid “building quality castles in the sky”.

Unconsciously I applied some of these concepts, however not as structured as the book suggests and my worst mistake is that I kept the trials within friends and family mostly and sought the real market validation too late, when everything was as it should be.