FOUR: Developing a “WaterScrumFall” Process
The Challenge: As I shared earlier, management needs a roadmap, a schedule, a vision document, a plan. “But that’s not Agile!” says the Agile team. This is one of the main reasons that many companies either overtly or covertly create a hybrid of Waterfall and Agile. They use Waterfall to clarify the front end to develop a plan, and then allow the development team to take over and use their Agile approach. Once the product is near market release, the team will attempt go back to the plan developed under Waterfall thinking. This often includes applying the launch readiness criteria developed in the front end planning and gets a quick response from management, “Hey… this isn’t what we agreed to!” to which the development team responds, “Hey, it’s Agile.”
While this hybrid process can work, it creates great strain on the organization due to the management team following one process and the development team with different process philosophies, terms and metrics. In Waterfall, once a “plan” is baked and approved, there is an expectation that the plan will be followed and delivered upon, even if the development team is using Agile to execute. Now I’m going to say it, “But that’s not truly Agile,” since Agile requires the plan to be flexible and consistently reprioritized and revised. We see this approach so often that we’ve heard many describe it as, “WaterScrumFall.” It’s really business as usual with a traditional process of defining a complete product up front and then the development team using an internal Agile process to conduct the work break-down process to deliver code. But often the real testing, and real development, doesn’t even start until testing of the expected deliverable starts. This is way too late to leverage the power of “agility” in software development. Let the blame games begin!
The Solution: True Agile requires that management, marketing, operations, and other functions are aligned with the principles of Agile development. Agile evangelists must acknowledge the needs of business leaders and other departments, and these other groups must acknowledge the methods and benefits of Agile. In more concrete terms, product roadmap milestones and market releases developed in the Waterfall model must be aligned completely with Agile sprints and software releases. If the development team is practicing Agile, they must create deliverables that track to the plan and provide early warning of what is really getting completed, and how it reflects on the roadmap. To guide the development team’s iterative approach, the marketing and sales teams must be clear on what customers deem most important and how market dynamics are impacting solution requirements to guide Agile efforts with every Agile “sprint.” Communication of progress and product deliverables must also be spoken in both Agile and business teams. For example, use cases and tasks must be translated to the promised features, and business models must be broken down into user stories. The bottom line – any Agile approach used by the development team must support all business needs and address all stakeholder concerns.