A development methodology is the process by which an engineering team will build a given product. Every company approaches the delivery of product requirements in different ways, but most approaches can be classified as either Waterfall or Agile types of methodologies.
The Waterfall methodology is a sequential development process, where progress flows steadily toward the conclusion (like a waterfall) through the phases of a project (i.e., analysis, design, development, testing). This involves fully documenting a project in advance, including the user interface, user stories, and all the features’ variations and outcomes.
The goal of the Waterfall methodology follows the old adage to“measure twice, cut once.” A detailed investigation and full research into a feature is conducted up front, eliminating (most) project risks. With the bulk of the research done in advance, estimates of the time required for each requirement are more accurate, thus providing a more predictable release date.
If nothing changes over the course of the product development, then estimates generated from the Waterfall methodology will result in a predictable release date. However, change is inevitable, and will come in many different forms. For example, you might learn more information about a feature and will need to adjust the requirements, or your team might realize once they begin the build that it is more complicated than initially imagined. These factors will change the delivery dates, and add risk to the project.
In the Waterfall methodology, change is expensive because most of the time and effort has been spent early on in the design and analysis phases. Also, because the team will be so invested in the requirements before the project begins, there may be considerable resistance to change.
In the Waterfall methodology, the role of the product manager is to create the requirements up front. Because the team does all of the research and design in the initial phases, the requirements given must be as complete as possible. As well, the requirements drive the detailed estimates on which the project plan will be based.
The Waterfall methodology is a documentation-heavy approach because it relies on the“measure twice, cut once” theory. To that end, the product manager’s workload is much heavier at the beginning of the project than it is during the actual release. The aim is to ask all pertinent questions in advance to minimize change during the development process, especially since change is relatively expensive.
The nature of the Waterfall methodology insists that each phase be complete and perfected before the start of the next phase. This prevents customers from reviewing and providing feedback on a project before its release. Even if suggestions were solicited, since change is expensive, the team will be less flexible about accepting feedback. Building solutions that have features that are not dependent on each other can help mitigate these issues, although challenges will remain. For example, a wind-powered energy solution may have different components, and by ensuring that each part can work independently, your team can mitigate overall project risk.
If a team were to develop a customer address book using the Waterfall methodology, the order of work would be as follows (timeframes are for demonstration purposes only):
1. Requirements: Product manager creates requirements documents that include the following requirements (in order of priority):
These requirement documents will include detailed requirements, user scenarios and potential layouts for the functionality.
2. Analysis: Engineering team takes these requirements and analyzes them, asking questions as needed. Product manager updates documents as questions are resolved.
3. Design: Engineering team creates a design for functionality, including database design, mock-ups and workflows.
4. Implementation: Engineering team develops functionality and prepares it for testing.
5. Testing: Product team tests entire functionality.
6. Release: The product functionality is released.
TOTAL elapsed time:9 weeks
Note that if any changes to the design occur during this workflow, the project would have to return to the second or third phase and restart the process.
There is much debate about the merits of the two different product development methodologies, Waterfall and Agile. In the end, it is up to your organization to choose the most appropriate system. Review the article, Product development: Agile methodology to form your own opinion of how you would like to manage your development process.
McConnell, S. (2006).Software Estimation: Demystifying the Black Art.Microsoft Press.
“Waterfall vs. Agile Methodology.” 2008. Agile Introduction for Dummies. Retrieved August 13, 2010, from http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/