Lean ≠ Fast in software development

Sometimes people in the tech industry assume that being lean means deliver software fast, even in cases the requirements they provide to the team and engineers are way too obscure.

Delivering fast and cheap, delivering an MVP with buggy security and privacy, delivering half baked solutions, etc. is not lean.

Lean starts from planning which predicts that a product and feature could be developed and released iteratively and in a resource-efficient way. Moreover, each iteration must add value to the product and benefit the customer.

The release of the iteration must provide the stakeholders with additional data and feedback that might adjust the plans of future iterations. This way preventing them from spending time and energy on low-value updates to the product.

To achieve lean the supportive processes of release must be standardized, automatic, and repeatable. The initial setup of these processes takes some time. In the beginning, it slows down the team and sometimes the organization. But that’s for a short period of time.

Eventually, the team will be able to speed up and continuously release an incremental value for the customers by adding small features and fixing issues for the product every day, even multiple times per day.

Lean doesn’t mean fast.

Fast is a side-effect stemming from well-shaped and scoped tasks.

Leans software development means the release of a product is planned and executed in a way that small adjustments to the product are released regularly. This way a large feature is delivered incrementally and efficiently, by optimizing the costs of the stakeholder’s focus, energy, and time.

Writing JS, TS, Vue, #C, and fostering teams to release customer value n-times a day. Creator of billid.app and writer on abrickis.me