The small batches approach

After reading “Lean Startup” and hearing all the stories about experimentation and iterations, I thought about my workflow. Although I see that I apply it in many cases, I have identified a few areas for improvement.

Firstly, I’ll try to explain the idea of small batches, or at least my understanding of it. So, to allow agility during our work, we need to validate our ideas as quickly as possible. In the space where uncertainty is the norm, long cycles of planning, designing, developing, and validating, also known as the “Waterfall” approach, are not particularly effective. In a rapidly changing market, where small startups compete with the giant corporations, we need to use our resources as productively as possible and learn as quickly as possible. As it was mentioned many times in “Lean Startup”, effectively building something that should not be built in the first place is a failure. Sometimes things that seem very logical and obvious are not seen this way by the market, and the customers are not as enthusiastic as we would expect them to be based on our up-front analysis and research. Therefore, small iterations of Build-Measure-Learn could help any company to apply its vision and drive an effective development of the right things. You can stick to the high-level vision of the company, but holding to your assumptions that are proven to be incorrect is a mistake, which you most likely will pay for. Small cycles that provide the right learning at the right time are a great idea, as they enable quick iteration towards the main goal: a successful company.

Looking at the code, we can find many analogies. Frequently, I see a large amount of work that needs to be developed and handed out to customers, such as the UX department or even other developers, who are the API’s primary consumers. Recently, I found myself in a dual role as both producer and consumer of the API. Without thinking, I automatically applied my autopilot, built on experience, to consider delivering interfaces that I would ultimately consume once the underlying layer is complete. It seemed perfectly fine to me at first. I work in a clean architecture model, which allows me to easily develop a data layer, release functionalities one by one in small PRs, and then move to the presentation layer to consume previously prepared use cases. Sounded reasonable to me at first, but it doesn’t comply with the small-batch model. Dividing the work horizontally, as I planned, can cause a lot of trouble down the road. Without validating the whole stack, I can’t be sure the use cases that I created will be something that I will be happy to work with. Although I verified that it works correctly, I haven’t confirmed whether the interface will be easy to integrate with our view models. After some reflection and my latest reading of “Lean Startup,” I decided to pivot my workflow to pure vertical slicing with small batches. I will be creating the entire feature change from top to bottom. Since it involves some refactoring, I will be feature toggling in the end consumer instead of the use cases. This will allow me to test my assumptions straight away and apply the learning to the next feature that I will work with. Working horizontally on it and learning that something was wrong with the assumptions about the convenience of the interfaces during the implementation of the presentation layer would end up in a huge refactor across all the features that were already written, or in acceptance of non-ideal code design. Either way, it is not good, so working out the whole feature end-to-end, one-by-one, will help to recognise the misconceptions early and apply fixes to all of the future work if necessary.

The Build-Measure-Learn cycles and working in small batches, avoiding long queues, gave a competitive advantage to Toyota, which became one of the biggest car makers despite a tough start. I firmly believe it can help build a good company at all levels, from the overall vision to the low-level code implementation, despite the competitive market and the dominance of big companies.