- 4.1 Goals of Agile Process Maturity
- 4.2 Why Is Agile Process Improvement Important?
- 4.3 Where Do I Start?
- 4.4 Understanding Agile Process Maturity
- 4.5 Applying the Principles
- 4.6 Recognition by the Agile Community
- 4.7 Consensus within the Agile Community
- 4.8 What Agile Process Maturity Is Not
- 4.9 What Does an Immature Agile Process Look Like?
- 4.10 Problems with Agile
- 4.11 Waterfall Pitfalls
- 4.12 The Items on the Right
- 4.13 Agile Coexisting with Non-Agile
- 4.14 IT Governance
- 4.15 ALM and the Agile Principles
- 4.16 Agile as a Repeatable Process
- 4.17 Deming and Quality Management
- 4.18 Agile Maturity in the Enterprise
- 4.19 Continuous Process Improvement
- 4.20 Measuring the ALM
- 4.21 Vendor Management
- 4.22 Hardware Development
- 4.23 Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.11 Waterfall Pitfalls
Agile enthusiasts have long described the many pitfalls and problems inherent in following the waterfall software methodology. In Chapter 14, “Agile in a Non-Agile World,” we will discuss these and other challenges as well, but also acknowledge that there are times when waterfall is the only choice. From the perspective of agile process maturity, we need to understand exactly where waterfall is problematic so that we do not make the same mistakes in our agile or hybrid agile processes.
Waterfall, as envisioned by Winston Royce,9 was iterative in nature. But waterfall fails when you try to define requirements that are not yet understood. Many organizations go through exhaustive planning exercises that are essentially an effort to plan what is not yet known and understood. When creating a plan, you need to identify the things that are not yet well understood as project risks. Risk itself is not inherently bad. Many organizations, including trading firms, actually thrive on risk. It is also essential to create adequate documentation and to keep it updated as necessary. Many organizations spend so much time trying to track requirements and create exhaustive project plans that they leave no time to actually get to software development and have to rush to make project deadlines. This dysfunctional approach can result in defects and significant technical debt.
Mature agile processes take a pragmatic approach to requirements definition and tracking while also establishing enough of a project plan to communicate dates and deliverables to all stakeholders. There are times when documentation is not negotiable, whether your project is using agile or waterfall.
4.11.1 Mired in Process
We often see organizations that are simply mired in their waterfall processes. These groups typically take a very rigid approach to planning and requirements gathering. Although sometimes waterfall makes sense, it is essential to always be pragmatic and avoid getting mired in your own processes. When this happens, we have seen teams where it actually became part of the culture to pretend to be following the process.
4.11.2 Pretending to Follow the Process
One of the most dysfunctional behaviors we often see is organizations that require complete adherence to waterfall processes, which results in team members being forced to pretend to be following these rigid waterfall processes. In these circumstances we find people who feel pressured into creating and following plans even when they really do not have all of the necessary details, or creating requirements specifications that document features that are not yet well understood. If management forces employees to follow waterfall in a rigid and dysfunctional way, then they really have no choice but to smile and pretend to follow the process. The better way is to create mature agile processes that include both the items on the left of the agile manifesto and the items on the right.