Large Batch Hand-Offs: Trapped in Wagile (part 3 of 4)

This is part three of the continuing series of articles. In the first article of this series, I outlined three fundamental characteristics of 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 work load.

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 busy-ness 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 initial design, get eliminated by 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 other’s 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 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 product 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.

Dhaval Panchal is a VP and Enterprise Agile Coach for agile42. He is a Certified Scrum Coach (CSC), Certified Scrum Trainer (CST), and Innovation Games Facilitator with 15 years of experience working in the development and management of products and services in the software industry.

Dhaval began his career as an XP (Extreme Programming) developer. Over the years he discovered his passion to coach, train, and enable organizations towards Agile transformation. His results-oriented, people-centric perspective helps organizations implement Agile, Scrum, Kanban, and Lean techniques to achieve success. He has experience working with startups to Fortune 100 companies, with clients in the telecommunications, business process engineering, shipping, e-discovery, legal, gaming, health insurance, and oil and gas industries.

A sought-after speaker who has presented at international Agile and Scrum conferences since 2008, Dhaval is also an expert facilitator who helps leadership teams make sense of complex situations and drive towards action.

About the Author

This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.