If you ever want to witness a spectacular debate, gather a group of tech pros and ask them a simple question: “Agile or Waterfall?” While many tech pros regard Waterfall methodology as a traditional but outdated method of development, it still has its adherents. Although many organizations have altered Waterfall’s core steps over the years to fit their own unique needs, the methodology generally breaks down as follows:

• Establish Requirements
• Design
• Code
• Test
• Fix Bugs
• Integrate with Technology Stack

Contrast that with Agile, which takes a more flexible approach to customer requirements and the overall development process. Advocates of Agile argue that Waterfall requires too much of the above process to proceed smoothly; if something goes radically wrong in testing and integration, or if the project requirements radically change, the whole project can potentially descend into chaos. Instead, Agile relies on cross-functional teams and adaptive planning, with work proceeding in highly reactive sprints. Advocates of Waterfall, meanwhile, argue that many working groups simply can’t balance flexibility with discipline in a way that allows an Agile-based project to proceed smoothly to completion. (Earlier this year, developer Andy Hunt wrote a widely-circulated blog posting in which he argued for a new system called GROWS, or Growing Real-World Oriented Working Systems, which attempts to iron out some of the biggest issues associated with Agile.) Whether or not the project manager decides on Agile or Waterfall, refining the process of gathering client requirements at the beginning of the project can end up saving a lot of time, money, and stress in the long run. When framing out requirements, there are a few axes to consider:

• Must-Have vs. Like-to-Have
• Current vs. Future

While some developers will argue until they’re blue in the face that single-purpose apps greatly outweigh their multipurpose cousins in efficiency and utility, many clients have an instinctive desire to throw in every possible feature into their software. Obviously such desires aren’t feasible, from either an engineering or a user perspective; and so the first step in any process is to divide off the essential features from the “cool but not strictly necessary” ones. The next axis, current vs. future, is likely to spark an enormous amount of debate. With Waterfall methodology, where requirements are set at the beginning of the process, it’s key to build something that won’t be outdated once it arrives on the market; as a result, developers and clients need to think about what sort of features they’ll want at the end of the process, not at the moment. And prognostication is a difficult task. Agile boasts a bit more flexibility when it comes to dealing with the future, but it’s still subject to some of the same time pressures as any other methodology; as a result, any project manager would do well to seriously think about what sort of app or platform they want at the end of all the iterations, and plan accordingly.