Breaking Batches: How Batching Undermines Agile Software Development
Batching is inversely proportional to quality - the more batching you have, the lesser quality you get.
In the last article, we saw that quality is about creating endless opportunities for feedback and acting on it.
Q ∝ F: Quality is proportional to the quantity of feedback you can get. However, feedback and batching do not align well with each other. Batching automatically delays delivery, which in turn delays feedback, preventing quality!
B ∝ 1/Q: Batching is inversely proportional to quality. The more batching you have, the lesser quality you tend to get. Let's see a few examples of why batching may cause quality issues.
Increased Complexity: Large batches tend to be more complex due to the sheer volume of changes. This complexity can make identifying the root causes of issues harder, leading to more bugs and errors. It also makes the software more challenging to test thoroughly.
Higher Risk of Failure: With more changes packed into each release, the risk of something going wrong increases. If a bug slips through, it can be more catastrophic, potentially affecting more aspects of the software.
Resistance to Change: Large batches can be overwhelming for both users and development teams. Users might resist adopting the new version due to its significant changes, while developers might be hesitant to make further changes, fearing it could add more complexity.
Longer Time to Market: Batching can significantly extend the time it takes for new features or improvements to reach the end-users. This delay can be a disadvantage in a fast-paced market where staying ahead of competitors is crucial.
User Disconnection: When updates are released infrequently, there's a risk of moving away from what users currently need or want. The software might evolve in a direction that's misaligned with user expectations or market trends.
How to decrease batching
Adopt Agile Mindset: Work iteratively, break down work into small pieces, reduce work in progress, and encourage frequent releases.
Implement air-tight Continuous Integration and Deployment (CI/CD): Automate the integration and deployment processes, making it easier and faster to release small changes.
Feature Toggling: Use feature flags to deploy code to production in a controlled manner. This technique allows you to push small changes to production without making them visible to all users until you're ready.
Shift-Left Testing: Release fast does not mean bypassing quality control! Incorporate testing early and often in the development cycle. This practice helps identify and fix issues sooner, reducing the risk associated with large batches.
Break Down Large Features: Instead of delivering a large feature in one go, break it down into smaller, incremental parts that can be developed, tested, and released separately.
Use MVP (Minimum Viable Product) Approach: Focus on releasing the minimal set of features that deliver value to the user, then iterate based on feedback. This approach prevents overloading releases with unnecessary features.
Improve Team Communication: Ensure that all team members are aligned and communicate effectively. Remember, most work waits in queues for other team members to pick it up and do something with it. Cross-functional teams are a great recipe for reducing batching.
Monitor and Optimize Processes: Regularly review and analyze your development and deployment processes. Look for bottlenecks or inefficiencies that lead to work item queues and address them.
Educate and Train Your Team: Ensure that all team members understand the importance of small batches and are trained in the practices and tools that support this approach.
Use Trunk-Based-Development(TBD): paired with the right practices, a branching model like TBD can help you greatly reduce batching.
In a nutshell, shorter delays mean better quality and lesser batching means shorter delays. Still not convinced? In the next article, we can analyze the impact of batching on all DORA metrics.