Large Batch hand offs : Trapped in Wagile (part 3 of 4)

by | Oct 15, 2014 | Systems Thinking, transformation, Waterfall | 0 comments

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 handoffs.

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:

Fractal Nature:

At portfolio or organization level:

There are many active projects or initiatives, where in a majority of them have minimal or no impact on organization revenue/competitiveness in the current cycle.

At project implementation level:

Many active initiatives are bottle-necked by architecture group that is under high workload yet insists that all projects must submit their design for approval to them.

At task level:

Team members sign up for a few days of work and often do bulk check-ins that result in complicated build and merge issues.

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 complete.

With institutionalized busyness comes 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 up front effort while designing and architecting. In subsequent phases – alternative choices get eliminated because of fear that any changes to requirements/design/architecture will require lengthy and delayed review and approval process and hence are not needed.

Large batch of testing and integration work gets 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 organization. Focus on utilization of people’s primary skill set 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 great wisdom that other’s less able can not attain. It is often that such Product development efforts get stuck within technical group who are perfecting and still not “ready” with master framework that will enable them to accept and develop features to meet business needs.

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 a 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 area of code to be reworked. Working in large batches is favored by optimizers of 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 happen 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 batch of work at hand, people find it easier to optimize for large amount 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 where in 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 root-cause.

These lead to long-term instability and brittle product core.


Delaying feedback and integration aggregates errors into blunders. Fear of small batch incremental development stems from inability to cope with interests of people focused on other important aspects of overall project. While there are many avenues for help and coaches available to show you the way (many publishing 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.




  1. Centralized Control : Trapped in Wagile (Part 4 of 4) – Evolve Agility Inc. - […] of waterfall organizations. In subsequent articles I explained Phase-Gates (part 2) and Large-batch handoffs (part 3). In this article…
  2. Phase Gates : Trapped in Wagile (part 2 of 4) – Evolve Agility Inc. - […] Large batch hand offs : Trapped in Wagile (Part 3 of 4) […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

You May Also Like

The Agile Manifesto Principles Explained

The Agile Manifesto Principles Explained

I started my agile journey twenty years ago. At the time, I was a Java programmer and a UML modeler, and I lucked into working in an XP team. Joining an experienced XP team was uncomfortable at first. The practices were very different from what I was used to. Kent...

The Conflict Escalation Ladder

The Conflict Escalation Ladder

Disagreements are not conflicts. Disagreements are a healthy part of a collaborative dynamic, but conflicts are not. The critical outcome is that people strengthen their relationships as they work through disagreements, whereas the result of the conflict is that...