The magic of the small batches

Kamil Tałanda
3 min readAug 8, 2021

After reading “Lean Startup” and hearing all the stories about experimentation and small iterations I thought about my workflow. Although I see I apply it in many cases I saw few areas of improvements.

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 the uncertainty is the norm, long cycles of planning, designing, developing and validating aka “Waterfall” is not really effective. In rapidly changing market, where small startups compete with the huge corporations we need to use our resources as productive 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 definitely 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 definitely a mistake, that you most likely will pay for. Small cycles that give us the right learning at the right time and are a great idea to iterate quickly to the main goal which is a successful company.

Going down to the code, we can find many analogies. Really often I see a big chunk of work to be developed at once and handed out to the customers, which could be the UX department or even the developers, which are the consumers of the API. Recently I found myself to be both producer and consumer of the API and by default without thinking, using my autopilot built upon the experience I started thinking of delivering some of the interfaces, that I would end up consuming once the whole under-layer is completed. It seemed perfectly fine to me at first. I work in cleanish architecture model, so I can easily develop data layer, release the functionalities one-by-one in small PRs fashion and once I’m done move to presentation layer and consume previously prepared use cases. Sounded reasonably to me at first but obviously it doesn’t comply with the small batches model. Dividing the work horizontally, as I planned, can cause a lot of troubles down the way. 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. Even though I verified it works correctly I didn’t verify the interface will be easy to integrate with our view models. So after a thought and my latest reading of “Lean Startup” I decided to pivot a bit in my workflow and go for pure vertical slicing with small batches. I will be creating the whole features change from the top to bottom and because it is kinda refactor work, 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 tough start. I strongly believe it can help build a good company at all the levels starting from the overall vision and ending in the low level code implementation despite the competitive market and big companies being the key players in the game.

--

--