Bringing Agile benefits to a waterfall project Visual design simulations

The best of both worlds?

Not every project is a good candidate for Agile software development approaches, and not every organization is interested in undergoing the sort of deep cultural change needed to adopt “pure” Agile. For those trying to realize the benefits of Agile within a waterfall project, simulations may be the answer.

A simulation is a compromise between the purely “paper” reviews of traditional waterfall and the full-on demonstrations of working software that are the hallmark of pure Agile. A simulation gives management a tour of a visual prototype of the application, showing them how various screens look and feel, and allowing them to do a hands-on walkthrough of the process workflow. This helps mitigate the risks of last-minute surprises that can occur with waterfall approaches.

These simulations aren’t full-blown working code. They are merely visual prototypes, and are not hooked up to a database or test environment. However, they do lay out in visual fashion the basic steps the system is performing. In a simulation, for example, after a record is retrieved in a case management system, a worker can see what would happen if the information was approved by the system, or what the next steps would be if there is a problem with the information. While the actual coding for all of the various exceptions is not done for a simulation, this visual walkthrough often gives management enough insight to offer important feedback early—when the project can make course corrections without incurring significant delays or cost impacts.

Simulations can be a marked improvement over the functional specifications and design documentation required for waterfall, which can run upward of thousands of pages and be open to multiple interpretations. It is difficult, if not impossible, to read and absorb 1,000-page design documents and tie them together into a working understanding of how a system will function once developed. In contrast, when walked through a visual simulation, project staff and sponsors are able to ask important probing questions, and they come away with a greater awareness of whether the design is on the right track. Granted—unlike with other, “purer” forms of Agile—building simulations can require a significant documentation effort in itself. But the advantage is that simulations can help to ensure that the product works in accordance with expectations and not merely in conformance to written contractual requirements.

Simulations are significantly more robust than mere wireframes, and they do represent a certain amount of investment. However, they can provide enormous value by reducing the possibility of painful and costly surprises down the line. As an added benefit, simulations can be used to identify gaps in business logic. They provide a way for teams to collaboratively review progress early and throughout the design phase—an approach consistent with Agile development principles.

A recipe for success

While simulations are a useful tool, for them to be effective, both the client and the vendor need to use them within a process that allows for their potential benefits to become reality. When considering incorporating simulations into a waterfall project, here are some tips to keep in mind:

• Use simulations throughout the design phase. Set the up-front expectation that, in addition to the usual “paper” progress reviews featuring Gantt charts and spreadsheets, simulations will be part of the review process at predetermined regular intervals. These events must be participatory and in-depth, not a superficial show-and-tell, and project stakeholders—from senior leaders to front-end users—must provide input.
• Involve product owners. Plan to have product owners highly engaged during design and “test-review” simulations.
• Plan for changes. Since simulations should prompt significant thought and discussion, it is critical to build in cycle time to account for enhancements.
• Control the backlog. As with any project, scope creep is a possibility. To control this, the discipline needed in the initial phases must apply in the later phases as well. Management will likely need to make trade-offs to keep the project scope under control.
• Don’t forget end-to-end performance. Test the simulations in modular fashion, but don’t forget the importance of end-to-end performance. This includes identifying cross-dependencies, integrating with third-party vendors, integrating converted data, and testing across all aspects of the system.
• Simulate the important parts. Stick to simulations for core workflows and high-traffic areas. Remember, 20 percent of the system will typically cover 80 percent of the functionality.
• Build basic business logic. To show how various sections are linked, it is important to have some business logic built into simulations. This enables reviewers to understand how work flows through the system, rather than just seeing it in isolated pockets.
• Don’t throw away the design documents. Rely on traditional specifications and design documentation for nonfunctional requirements and aspects of the system that cannot be simulated, such as business rules, interfaces, and other technical system components. In essence, a simulation’s role is to serve as design documentation for the user interface, the navigation field definition, and the association with the underlying data model.

Some cautions

As with any tool, simulations won’t solve every problem or clarify every gray area. For example, in any waterfall project—with or without simulations—if the specifications and requirements are not well-documented and clearly defined, the project will struggle. While simulations are helpful in allowing users to see the workflow and interact with a visual prototype, it is important to remember that they aren’t full-blown operating software. They will not allow users to test how well the new system connects with data sources, or the effect that volume may have on system performance. The testing life cycle remains critical to validating those aspects of the project and ensuring adherence to written design specifications.

Waterfall with simulations

Since waterfall with simulations is based on waterfall, it has most of waterfall’s advantages: It is both familiar and predictable, and mitigates demands on the client workforce. That said, there are also some key differences, both positive and negative.

The primary advantage of waterfall with simulations over “pure” waterfall is that simulations can provide early confirmation that the project is heading in the right direction. Additionally, the ability to walk through visual demonstrations can allow users and developers to identify additional innovations and improvements not contained in the original specifications. The use of visual prototypes limits late surprises and gives the project a head start on familiarizing users with the system, gaining client executive/sponsor buy-in, and developing training.

On the other hand, while useful, simulations aren’t fully operational, and true end-to-end functionality won’t exist until late in the project. In addition, not all of the work involved in building simulations will directly contribute to the actual software build. While the screen design and some other aspects of a simulation can readily translate elsewhere and be “reused,” some of the effort of building a simulation will go unleveraged.

In essence, a portion of the cost of building simulations can be thought of as an investment in a much more robust form of progress reporting. Simulations are far less subject to differing interpretations than written reports, which is one reason why they are so effective in limiting risks and encouraging more helpful user input. But to reap their benefits, organizations need to allow for flexibility and be prepared to dedicate resources to course corrections and enhancements that arise through the simulation process.