Selecting a new AMS or other management system provides a crash course in technology for many association professionals. But just when you think you have a handle on terms like APIs, data flow diagrams, and SQL, your vendor starts throwing around lingo like “agile development” or “waterfall process.” What the what?
They’re talking about the process used to develop the system or software you just purchased. Both agile and waterfall IT development processes work well – in the right situation.
Key differences in the order of things: agile vs. waterfall
The waterfall development process goes in the traditional order:
- Requirements are gathered from stakeholders.
- The system architecture and overall plan is designed.
- The system is developed and integrated with other systems.
- Testing and acceptance occurs.
- And, finally, the system is rolled out to all users.
You move to the next phase of the process only when the previous phase is completed. That is the key distinctive characteristic of waterfall methodology: once you pass from one phase to the next, you don’t revisit the previous phase again. Period.
The agile development process breaks the project up into short iterative segments called sprints. First, high-level system features and functions – requirements – are determined. System requirements are grouped based on criteria such as priority, cost to deploy, or level of effort. Each group of system requirements (i.e., a login feature) goes through a sprint:
- Requirements are further defined.
- An initial design and prototype is created.
- The project team tests the prototype.
- The process repeats until the team is happy that the system feature set is completed and is ready to be deployed.
You may come across many names for agile or iterative development methodologies: SCRUM, Rapid Application Development, Extreme Programming, and a dozen more. They are all variations of the theme.
Agile and waterfall impacts on IT projects in associations
Both methodologies can be done well or done poorly. Neither is fool proof nor a means to ensure success. But, it’s important to understand what the vendor is really talking about when they refer to “agile” or “waterfall” processes so you understand how your system will be developed and can manage your project – and expectations – accordingly.
The elements of the project are the same for both, but project managers, business analysts, and subject matter experts (i.e., your staff) absolutely need to adjust the order in which they do things based on the development methodology and sequence. Furthermore, the level of effort and time commitment for your staff throughout the process is largely dependent on which methodology is being used.
Agile characteristically works well in collaborative, entrepreneurial cultures for projects where “getting it right” can be molded along the way. Budget is important, but there is some flexibility. Waterfall, on the other hand, tends to work better in environments where process and structure are very much appreciated and careful consideration must be given to time and budget. Since waterfall is a predictable path, once the requirements are known, it’s easier to project the timeline and resources needed.
Keep in mind that when your project involves agile development, the cycles of testing and feedback require a much higher level of staff engagement and communication than the waterfall process. Other association cycles, like dues renewal or meeting preparation, can damage agile projects if timelines aren’t coordinated. On the positive side, the association benefits in the long run from the high level of staff collaboration required.
The “H” word
Sometimes, the students in the class I teach on System Requirements and Analysis at Georgetown University bring up the dreaded “H” word – hybrid. A spirited debate ensues: is there such a thing as a hybrid method?
I’ve yet to be convinced there is such a thing – it’s the Bigfoot of the software world. If a vendor tells you they have a hybrid methodology, it’s okay. They may call it that, but I’ll bet they have some banged-up flavor of agile or something they’ve come up with themselves, but it’s not waterfall if you return to a previous phase at any point. We shouldn’t get stuck on what they call it. The key is: does their methodology work for your organization?
(Okay, I will get stuck on what they call it, but I will keep my red pen holstered when reviewing their proposals.)
“Now you know, and knowing is half the battle.” – G.I. Joe
We’ve only scratched the surface of the agile versus waterfall pros and cons list and their impact on your organization and your system implementation. The first step is to know the key differences between the two methodologies and how they might impact you at a high level. In some projects, we make the development methodology part of the criteria for selecting a product or partner.
Flickr photo by tableatny
