Organizations attempting to transition to Agile demonstrate waterfall characteristics – residually or resurgently. Understanding these characteristics and learning to observe manifestation of these tendencies in organization systems will help you uncover impediments to Agile transformation.
After reading this series of articles, you may realize that your organization is still being waterfall but thinks otherwise i.e., Wagile
In this article series I want to explore deeper into the “waterfall” label and lay bare the fundamental characteristics that make up such a system. And subsequently I will dive deeper into each characteristic to highlight expected systemic behaviors and unintended consequences that frankly should no longer be unexpected.
Any software development shop that practices Waterfall, will demonstrate these three fundamental characteristics:
Phase and Gate Approach
“In theory there is no difference between theory and practice. In practice there is.” – Yogi Bera
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.
In theory it is expected that an sound concept can be analyzed and designed. The developers and testers have to just engineer this into system which will be launched under warm summer sun. In practice(reality) people are not sure whether their idea will be the “winner” that they want it to be, analysts and architects are puzzled and pull together a plausible solution. Developers and testers soon realize that the plausible solution is not really possible. So they work late nights to jimmy in one fix after another until the project gets launched too late and for too much. Phase and gate approaches are guaranteed innovation killers.
Large Batch Hand-offs
Champions of a holistic perspective want a detailed understanding of the project. Such understanding drives planning, enables optimization of labor resources, maximizes utilization, and reduces rework.
This paragraph above is more suited to be about a project that uses machines to punch holes in sheet metal. Not about a project that applies human knowledge and skills.
The real challenge is about controlling runaway batch sizes where, despite best intentions organizations attempting to move towards Agile methods are unable to keep and maintain small batch sizes. A system designed to maximize work in progress will resist every attempt at reducing batch sizes.
Complimentary to Phase and Gates, where decisions are concentrated at ‘gates’. With centralized control, decision making authority is also concentrated within selected groups.
Know-how is not know-when. While a centralized control body collects information about the state of a project or portfolio, time laps by. By the time centralized decision making authority makes sense of this information the situation on the ground often shifts. Aggregating dashboard level information accurately, introduces delays flow of relevant information. Only in hindsight do decision makers know when they should have applied their know-how.
Command and control style management often manifests in organizations that have Centralized Control characteristics. In such organizations, decisions are always made by a select few. Organizational gossip is the primary means of getting real information and management lacks awareness of real problems on the ground. Project effort, “TPS reports” (bureaucratic paper work that adds no value) and tasks make little sense to people doing the work and managers consistently feel ill-informed despite many daily, weekly and monthly status updates. Most feel like a piece in a chess-game. Some carry the illusion of more power than others, but each are equally at mercy of the organization system complexity that plays them.
All waterfall organizations are not the same:
Waterfall as implemented in one organization is different from waterfall implemented in another organization. Think of these three characteristics as primary colors in RGB Color Model.Organizations differ in their waterfall-ish-ness due to differences in their emphasis on one characteristic over the other.
The same RGB model analogy is applicable to individuals – reflective of their mindsets. When enough people share similar mindset (knowingly or unknowingly) self-similar patterns get repeated over and over again. That is to say that these tendencies manifest themselves at all levels, from project funding to project release level to how organizations are structured. To draw your attention to these self-similar patterns at levels within organization work system, I will use examples and highlight these under sub-section ‘fractal nature’.
No two waterfall organizations are the same. The three characteristics: Phase & Gates, Large batch and Centralized Control, are emphasized by each organization differently. The degree of emphasis that your organization places on one or more of these characteristics will determine the challenges that it will have to overcome in their agile transformation. In the next series of articles I will dive deeper into each characteristic highlighting the challenges that you should expect. Conversely if you observe the challenges then you can get closer to understanding the legacy mindsets that are impeding your organization’s transformation.
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 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.
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.
The purpose of practical management is of controlling organization system to deliver desirable outcomes (goals) and not that of understanding the organization system.