In most organizations, delivery is done in big batch. Often infrequently and requiring a lot of people to release. In my experience, moving away from this model includes thinking about products instead of products. In this video lesson, we're going to talk about shifting to small batch. At the end of this lesson, you should be able to describe what is meant and how to assess the Minimum Viable Product, explain why it's strategically important to consider moving to small batch projects, and, discuss some advantages and benefits when moving to small batch. In projects, a lot of upfront planning happens to clearly define all the requirements and to test those requirements and plans for one big implementation. In a product model, it is more important to start with defining an MVP. MVP stands for Minimum Viable Product and is defined as a product with enough features to satisfy the initial customers and provide feedback for future development. One of my favorite explanations of MVP comes from the book Lean Enterprise. Most organizations focus on feasible, valuable, usable, delightful, in that order, and tend to try to figure out all of that before they launch a feature. In Lean, the approach is to focus on a little bit of each as the definition of the MVP, so you can move quickly and learn. This also allows the team to focus on how they can break the work down into a smaller delivery. Even delivering components of the MVP into production before the full MVP is ready, and using feature flags to make the feature available once all components are ready. Working in the smaller batch approach gives faster feedback and lowers the risk of deployment and recovery from failure. High-performing organizations slice up products and features into small batches that can be completed in less than a week and released frequently including the use of MVPs. It's also a common myth I've encountered. A lot of stakeholders worry that if they don't get a big release, then they aren't getting everything they wanted. This is why Agile and moving to a product model are so important, so that you can demonstrate to your stakeholders that a product is never done. Even if you start with an MVP and learn, and experiment, you will continue to evolve the product as you learn more. From accelerate, we learn about the evolution of big batch versus small batch. Reducing batch size is another central element of the Lean paradigm. Reducing batch sizes reduces cycle times and variability in flow, accelerates feedback, reduces risk and overhead, improves the efficiency, increases motivation and urgency, and reduces costs and minimize schedule impacts. However, in software, batch size is hard to measure and hard to communicate across contexts as there is no visible inventory. Deployment frequency can be used as a proxy for batch size, because often if you are delivering in small batch, you are delivering more frequently. I have had multiple experiences with this. In cases where my teams were delivering twice per year, the batch size was really large representing months and months of development and testing. Often, the deployment would happen and then we would need a warranty period to deal with all of the issues introduced and trying to isolate the issues and resolve them was very complicated. Once teams move to more frequent releases, it forced us to work in smaller batch sizes which improved feedback and quality. One of my favorite talks from the 2017 DevOps Enterprise Summit was from Jonathan Smart, Head of Development Services for Barclays, a London-based bank that's over 300 years old. In this talk, Jonathan talks about working with teams to break down their work to something that can complete within a day. Most teams and people think that's impossible, but Barclays does that at scale. It's taken time to get to that, but the results show that focusing on small batch is a big contributor to speed devalue. The key to working in small batches is to have work decomposed into features that allow for rapid development instead of complex features developed on branches and released infrequently. This idea can be applied at both the feature and the product level. An MVP is a prototype of a product with just enough features to enable validated learning and the product and its business model. Working in small batches enables short lead times and faster feedback loops. In software organizations, the capability to work and deliver in small batches is especially important, because it allows you to gather feedback quickly using techniques such as AB testing. It's worth noting that an experimental approach to product development is highly correlated with the technical practices of continuous delivery. In the example I shared in an earlier lesson, a team was able to show that they could get cycle time down to 11 days. They did that by picking a very small story and seeing how they could get it through the value stream chain as fast as possible. It often is not important to demonstrate an exact feature when you do this, but even just to push through a one-line code change or even a change to a comment will at least help you see where the bottlenecks are in the flow. Often most organizations especially enterprises see small change is risky. What's interesting is that all of the research shows that small batch is way less risky. Have you been in a situation where you've been held to a frieze window or a restricted change window? As someone who has worked in retail for a long time, we would often have frieze windows during the holidays. However, what ended up happening is that all change was queued up and then post holiday, we would release all of the changes and have incidence. My goal with my teams is to get to a spot where change is safe and we should be able to make a change anytime of any day. Into it made a splash in the DevOps community when they shared that they were pushing frequent changes on Tax Day April 15. In most organizations, pushing change on the most important business day would be completely off limits. However, if the investment is made and the capabilities to make change safe, organization should be able to push change 24/7, 365. I recommend trying this with one to two teams to demonstrate the benefits. Often when I talk to a large group of teams about the concept of small batch and MVP, they get overwhelmed. However, if you can demonstrate the value with a few teams and then scale, I've seen that be quite powerful.
