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:

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:

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.

Summary:

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.

Engage us for advise and strategy services to chart your transformation journey.