Having experienced both Waterfall and Agile methodologies in software development, and having a forever-optimistic outlook, I strongly feel that either extremes are not working. Here's why.
Agile - Concentrating on individuals and interactions, working software, customer collaboration and responding to change has meant that the product has lesser re-usable processes and tools, documentation, well thought out contracts. It's producing more generalists than specialists in the DevOps world. On boarding, training, troubleshooting, compliance, attention to clean architectural patterns and non-functional requirements (Scalability, Availability, Security, Resiliency etc) are becoming a challenge in absence of the processes, tools and documentation.
Waterfall - Concentrating on specialists for requirements gathering, analysis, design, coding, testing and operations resulted in reusable processes and tools, extensive but-too-much often-unused documentation, rigid not-flexible contracts, lesser team collaboration, dictatorship mode of team roles, slower deployment cycles and lesser adoption to change. Was the industry too quick in thinking of the Waterfall's shortcomings and did we concentrate too much on its lack of adaptability?
Simply put, either extremes are not working. With each of these methodologies having pitfalls, is the ideal solution somewhere in between? Here's my proposal: a Waterfallistic-Agile approach to software development to produce a responsive, resilient, elastic, asynchronous/message-driven "reactive" product.
The proposed approach, has the following salient aspects:
Feature board - A program wide feature board that tracks which phase (Requirements/Product Engineering, Architecture/Design, Implementation, Verification/Testing, Deployment) each feature of the product is in.
Specialist roles and deliverables
Requirements role (Input: Business Need; Output: Requirements documented as Epics, and acceptance criteria; Handoff: Architecture/design role; Validations: Previously completed features meet business need?)
Architecture/design role (Input: Requirements; Output: Logical/Physical architecture, system decomposition, Tools & process identification, Message driven/asynchronous design to make a responsive product which meets NFR criteria, contract definition; Handoff: Implementation role; Validations: Review Previously completed features for completeness, quality and NFRs)
Implementation role (Input: Design artifacts, Requirements; Output: Implementation with built in tests, ensuring NFRs met; Handoff: Verification/Test role; Validations: Review previously completed features for completeness, quality and NFRs)
Verification/test role (Input: Implementation, Design artifacts, requirements; Output: Validate comprehensive functionality and ensure responsive system. Validate elasticity for varying load scenarios. Validate resiliency for various failure and chaos scenarios; Handoff: Deployment)
3. Different stages for each feature. Rolling/Continuous deployment.
Have you found success in pure Agile? Are there scenarios where the Waterfallistic-Agile would not work? How would you change the diagram above? Comments are welcome.
Comments