1.1.5 Selecting the Right Approach
A waterfall approach is best aligned to projects that have a clearly defined and complete set of requirements. It is expected that Stakeholders have a clear vision of the project scope; significant changes to scope are not intended after planning is complete. Because the complete product is not delivered until the end, emphasis will be placed on quality while speed of delivery is not a priority. The strict, linear methodology fits a project team and sponsoring organization that requires structure in the team’s day-to-day activities and a detailed project plan for the organization to march towards.
Agile may also be feasible for projects that have a clear scope, where an adaptive approach would be effective in promoting early and frequent delivery; however, agile is also well suited for projects that do not have a clear and detailed vision of what the system should look like, how it should work, or what features need to be included. This lack of clarity upfront leads to changes in Stakeholder priorities and possibly scope as more information becomes known during design and development. An agile approach encourages this type of scope flexibility through progressive elaboration of the needs and wants of the users, making it an ideal approach for these situations.
Another need that an agile approach can help address is rapid and incremental delivery of functionality to users. However, with functioning product increments delivered frequently, speed of decision-making and team action becomes an important factor. Creating and maintaining an environment that supports rapid delivery requires a supportive governance process, as well as project team members that are skilled and can work independently without detailed guidance on what needs to happen next.
Many state organizations may not be ready to fully adopt agile as a project management and/or development approach, but certain agile practices related to the organization and project planning can be leveraged in a traditional waterfall environment. By incorporating adaptive thinking and a user centered design approach, organizations can make incremental changes that can bring about increases to user satisfaction that is a cornerstone of agile values and principles.
One such option is a modular approach where the linear project management and development cycle of waterfall is utilized, but the project scope is broken into sizable pieces or components of the full project scope, as illustrated in Figure 1-1.
This approach provides the project team the familiarity of the waterfall project management lifecycle and development cycle across the entire project, but accelerates the delivery of functionality over several releases. Though use of this modular approach is still a longer cycle than an agile iteration, development time frames will be shorter than traditional waterfall and release of functionality will not be dependent on completion of the entire product or project. Stakeholders will not have to wait until the end to realize some benefits, and the project team will have multiple opportunities to obtain Stakeholder feedback and incorporate lessons learned into each release. Organizations using this approach can be more aggressive over time and have more, shorter releases, to the point where iterations of 4 weeks or less become attainable and there is a natural progression to move towards agile development.
When deciding the degree of which to adopt agile, consider the following questions:
- Is the organization ready and able to change to adaptive ways of thinking and doing?
- Would the culture of the organization support empowerment and decision-making at the team level (instead of the management level)?
- Will project team members: have cross-functional expertise, be dedicated full-time to the effort, and be collocated to allow for more effective communication, prompt decision making, and streamlining of product development?
- What business goals and user needs will be addressed?
- Are the Stakeholders/users willing to collaborate frequently and commit the time?
- Are there well-defined requirements? How likely is it that these requirements will change over the course of the project?
Selecting the Right Approach
Updated: September 22, 2017