This is part three of the continuing series of articles. In the first article of this series, I outlined three fundamental characteristics of the waterfall system. In the previous article (part 2), I explained Phase-Gates and the unintended consequences when phase gates encounter Agile transformation efforts. In this article, I will dive into Large Batch hand-offs.
Working in large batches is based on thinking that handling large batch sizes during each phase optimizes:
- Resource (people) utilization
- Quality: By use of people’s primary skill set
- Reduction in rework
- Decisions: through a broad holistic perspective
Expected system behavior
Utilization Focus:
Most people are busy and have ample tasks to do. Often people are already behind and stressed about catching up with their workload.
Despite high utilization, the organization system is struggling to get projects “done”. Management is stressed about active projects that never seem to be completed.
With institutionalized busyness come weekly ‘red-yellow-green’ status meetings. Most participants turn on their zombie state and learn to check up on email under the drone of status updates.
Big Upfront:
Design and architecture for finality as opposed to changeability. This leads to big upfront effort while designing and architecting. In subsequent phases – choices alternative to the initial design, get eliminated by the rule-of-thumb that any changes to requirements/design/architecture will require a lengthy and delayed review and approval process and hence are not needed.
Large batches of testing and integration work get pushed towards the end of the project. Delays during previous phased hand-offs accumulate and get transferred to later phases of product delivery.
Next Generation and Framework projects:
It is common to see “next generation” and “framework” projects creep up in these organizations. Focus on the utilization of people’s primary skill sets has blinding effects on all other senses (including common sense). In these organizations, lack of results is so rampant that leadership and their subjects desperately seek assurance and clamor to work on “cool” projects. These are often labeled “Next Generation” or “framework”, implying some uber-wisdom that others less able cannot attain. It is often such that product development efforts get stuck within technical groups who are perfecting and still not “ready” with a master framework that will enable them to accept and develop features.
Unintended consequences
Decision concentration:
Imagine that on the first of each month one has to decide on their attire for every one of their work days for the rest of the month. Sounds silly! But with large batches, organizations are doing something similar on a much grander scale. With large batch processing, we are effectively concentrating all relevant decisions in a fixed time window. Not allowing for reassessment of product needs in light of new requirements or new design/architecture options.
Defect concentration:
With large batches, not only features but also defects get produced in large batches. An error in design choice or code implementation will be replicated until this area of product is tested or validated. This results in large areas of code or functionality to be reworked. Working in large batches is favored by optimizers of the functional process step (design/code/test) as this allows them to review holistically and make sound choices. But they always fail to account for holistic mistakes that they will also have and in aggregate cause huge expensive blunders. Limiting work in progress allows for learning from small less expensive errors.
Local Optimization:
People tend to optimize for their task/responsibility completion as opposed to working towards team optimization and quality throughput. With large batches of work at hand, people find it easier to optimize for large amounts of design/code/test. This headphone-in-the-zone approach – while maybe ideal for grunt work or isolated tasks – does not suit product development. Non-linear implications abound wherein choices made by one team member disproportionately affects another team member’s options. There is no substitute to collaboratively flowing freely as a team through requirements ~ design ~ code ~ test aspects of product development.
Context Switching:
Large batch hand-offs are desirable on the premise that work handled in large batch sizes allows workers to optimize towards completion.
So when test is testing feature-(N), code is being done for feature-(N+1) and design is being done for feature-(N+2). When an issue is identified by test in feature-(N) others in code and design have to make a context switch from their in-progress feature (N+1) or feature-(N+2) to accommodate this unpredictable request. This often leads to:
- Larger than anticipated inefficiencies
- Faulty assumptions implemented in code for feature-(N+1) that are not yet exposed while testing for feature-(N)
- Quick fixes that do not address the root cause.
These lead to long-term instability and brittle product core.
Summary
Delaying feedback and integration aggregates errors into blunders. Fear of small-batch incremental development stems from an inability to cope with the interests of people focused on other important aspects of the overall project. There are many avenues for help and coaches available to show you the way (many publish practices in open public forums – one quick search engine query away). I have found that when it comes to change, those who are able to move to a better state – CARE! Those who care about others’ interests and overall products always figure out ways to reach out, collaborate, and problem-solve to make small batch sizes a reality in their organization. While the ones who don’t care, make excuses.
