In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

Recap

Phases are are strictly linear sequence 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. Phase gates are intended to validate 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. Next phase funding is determined based on business context and organization readiness to move forward.

Expected System Behavior:

Fractal Nature:

At portfolio or organization level:
A phased-gated approach is undertaken where in typically a steering committee evaluates an ‘initiative’ or ‘project’ and goes through a serialized process such as:

Discovery → Research Product Concepts → Business Case → Test product Concepts → Gather Requirements and then so on until Maintenance.

At project implementation level:
Same pattern repeats itself where in:

Business Requirements → System Requirements → High Level Architecture → Detail Design → Implementation → Test → User verification → Release.

At task level:
This pattern is not as formally observed as in cases above. However you have probably experienced scenarios where a Developer is “waiting” on approval from Architect before he can check-in OR a case where a team member refuses to implement a well understood feature until the product owner writes down “detailed” acceptance criteria.

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 due to schedule slippage of predecessor phase and/or due to lack of readiness of subsequent phase.

People get organized in functional silos. Example, Business Analysts silo, Development silo, Testing silo etc. Each silo is lead by its respective manager who is responsible for meeting quality of phase deliverables and responsible for maximizing “busy-ness” (utilization) of her people.

Unintended Consequences:

Feature filtering:

Phase gates 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, business is allowed to be smart to come up with new ideas during requirements gathering phase, but for all of the rest of the times, these same ideas are considered no good (stupid). This practice leads to selection and elimination of features with out any end user feedback. And also confines understanding of user needs to the short window of time many months ago when steering committee decided on scope.

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 guess work in selecting features for future product releases. Guess-work that is trapped in 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 to the end of the relay race counts as progress. But this perception is false and results in overall portfolio brittleness. During later phase, changes in requirements and/or design requested by dependent project teams are aggressively throttled preventing meaningful progress for dependent initiatives.

Degree of influence of dependent teams is inversely proportional to the “progress” made by co-dependent waterfall team. 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. Often deferring these updates to next scheduled release. Instead short-term fixes are implemented. Mindset of getting-it-right the first time often enforced via governance bodies through exhaustive gating criteria creates disproportionate impact from risk-event 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 fall out from errors detected in later phases. There is a fundamental misunderstanding of problem domain, within software system development (big or small, green or brown) 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-unkonwns space. Resilience to errors is far more important than error proof gating systems.

Hidden loop backs:

When bugs are discovered in testing phase, typically a bug is reported to developers who then have to apply fix. While officially the project is in testing phase, the testers are waiting on developers to apply fix before they can continue further. This hidden loop back drives false perception that downstream phase is taking longer since revisions/corrections to upstream work product 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 loop backs not only mask process bottlenecks but also damage relationships between the silos that are pitted against each other.

Innovation Killers:

Phase gates are innovation killers. Silos and focused functional work straitjackets creativity and rewards bureaucracy. People confined to interaction 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 through conflict constructively.

Summary:

Phase 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 process for processes sake is an example of being stupid on purpose. You would be surprised by how many people feel the organizational straight-jackets that you do. Reach out, collaborate, eliminate unnecessary phase gates. You can iterate on your organizational systems to find your path to success.

Links to ALL posts in this series

Trapped in Wagile (Part 1 of 4) Organizations attempting to transition to Agile demonstrate waterfall characteristics. Understanding these characteristics and learning to observe manifestation of these tendencies in organization systems will help you uncover impediments to Agile transformation.  

 

 

 

phase gates

Phase gates : Trapped in Wagile (Part 2 of 4)

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

 

 

 

large batch size

Large batch hand offs : Trapped in Wagile (Part 3 of 4)

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.

 

 

 

centralized control

Centralized control : Trapped in Wagile (Part 4 of 4)

The purpose of practical management is of controlling organization system to deliver desirable outcomes (goals) and not that of understanding the organization system.