In my previous article, I outlined three fundamental characteristics of waterfall systems. Phase-gates are the most distinguishable characteristic of a waterfall organization.
Recap
Phases are are strictly linear sequences of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential phase is gated to ensure quality of deliverables handed off between silos. Many decisions are concentrated at gating decision points. The Phase-gate approach provides an illusion of control, delaying feedback on product.
For example:
Requirements → Design → Implementation → Verification → Maintenance
Gates or gating criterion accompany typical phase-gates. Gates establish GO/NO-GO decision points during the process and are intended to assert quality of work during each phase so that errors or mistakes are not propagated to downstream phases. Further funding of the next sequence of phases is determined based on business context and organization readiness to move forward.
Expected system behavior
Early phases take longer than anticipated and later phases get squeezed. During each phase, work progresses uni-directionally from one phase station to another.
Uni-directional flow of work requires strong emphasis on getting things right the first time. Changes to requirements or design are never ‘welcome’ and always hard-fought.
Product development experiences unpredictable wait-states caused by schedule slippage of predecessor phases and/or the lack of readiness of the subsequent phase.
People get organized in functional silos, for example Business Analysts silo, Development silo, Testing silo etc. Each silo is led by its respective manager who is responsible for meeting the quality of phase deliverables and for maintaining “busy-ness” of her people.
Unintended consequences
Feature filtering
Phase Gate governance mechanisms concentrate a lot of decisions at gating points. During the early phases of requirements gathering (scoping), many features get filtered out. This is purportedly to limit scope for a release. In other words, the business is allowed to be smart and come up with features in a concentrated period of time marked by requirements or product concept phases. All other times, their needs are considered no good (stupid). This practice leads to selection and elimination of features without any end user feedback. It also confines the understanding of user needs to that time many months ago when steering committee held their “scope” meeting.
As your business context and user needs evolve, so do requirements from a software product. So an idea that may not be appealing at the start may become relevant later. Feature filtering leads to dominance of guesswork in selecting features for future product releases. Guesswork that is trapped in a stale understanding of user needs. No wonder a majority of features in a typical products never get used.
Local Optimization
In waterfall systems, movement through phases towards the end of the relay race counts as progress. But this perception of false progress at the local phase level results in overall portfolio brittleness. During later phases, changes in requirements and/or design requested by dependent project teams are aggressively throttled, preventing meaningful progress for dependent initiatives.
The degree of influence of dependent teams is inversely proportional to the “progress” made by codependent waterfall teams. Such systems lead to global sub-optimization at the cost of local optimization.
Root-cause solutions and Resilience
Late in the development game, technical changes or changes in product requirements are not encouraged and are often deferred to the next scheduled release. Instead, short-term fixes are implemented. The mindset of getting-it-right the first time is often enforced via governance bodies through exhaustive gating criteria, which creates a disproportionate impact from risk when the requirements or design or code was not right. Unfortunately, in a waterfall mindset such events trigger needs for stricter gating controls, further perpetuating exponential fallout from errors detected in later phases. There is a fundamental misunderstanding of the problem domain within software system development (big or small, green or brown), and attempts to make error-proof phase gates and implementing big-brother governance systems will never work. There are known-unkowns and unkown-unkowns. Software products for the most part are exploring in the unkown-unknowns space. Resilience to errors is far more important than error-proof gating systems.
Hidden loopbacks
When bugs are discovered in the testing phase, typically a bug is reported to developers who then have to apply a fix. While officially the project is in the testing phase, the testers are waiting on developers to apply a fix before they can continue further. This hidden loopback drives the false perception that the downstream phase is taking longer, since revisions/corrections to upstream product work is incorporated in downstream phases.
This perception of “being stuck” in a downstream phase because of issues in upstream work creates unwanted pressure on downstream folks (testers). Hidden loopbacks not only mask process bottlenecks but also damage relationships between the silos that are pitted against each other.
Innovation Killers
Phases are innovation killers. Silos and focused functional work straightjackets creativity and rewards bureaucracy. People confined to interact within their functional community will never learn to work with other functional disciplines. Cross-domain understanding and multi-learning are essential to process and product innovation. We improve in areas where we practice. Your organization needs exercise and practice in working with each other. People will not auto-magically “collaborate”. They need to practice this often, again and again and again (up and down, up and down, painting the fence) until they learn to navigate constructively through conflict.
Summary
Phases and gates are explicitly and implicitly pervasive in organization mindsets. A serialized cause and effect mental model is comforting, but never reflective of how work really happens when you get down to it.
Following a process for process’s sake is an example of being stupid on purpose. You would be surprised at how many people feel the organizational straightjackets that you do. Reach out, collaborate, eliminate unnecessary phases and gates. You can iterate on your organizational systems to find your shortest path to project success.
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.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
