One of the primary dilemmas organizations deal with for each project is “What kind of development methodology should be used?” Unsurprisingly, this topic often generates a heated discussion with equally passionate arguments from both sides. If this isn’t something that your company has worked with in the past, it’s important to get a basic understanding of development methodology in general. In short, this is simply a way to organize work involved in software development. It’s NOT about a specific style of management or a particular technical approach. However, you’ll still hear these terms used interchangeably.
The two fundamental methodologies that are currently the most popular are:
- Waterfall: The name isn’t quite fitting and might be better suited to be named the “traditional” approach.
- Agile: Newer than the Waterfall approach, this particular kind of Rapid Application Development is typically used with Scrum.
These methodologies have been proven to be usable and effective. With years of experience working in software development, we’re confident in our assessments of the pros and cons of each of these methodologies.
The Waterfall Methodology
The Waterfall methodology employs a linear approach to the development of software. When implementing this approach, developers can expect the sequence of steps to appear something like the following:
- Gather requirements
- Unit and code test
- System testing
- User acceptance testing
- Make necessary adjustments
- Create the finalized version
In the truest form of the Waterfall methodology, each of the aforementioned steps represents a specific pace within software development. As a result, one step has to finish before the succeeding step can commence. There are also certain requirements that have to be met before the following stage can begin. For example, customers have to give their approval before the actual design can start.
As with all methodological approaches, there are pros and cons of the Waterfall approach.
Here are the positives of Waterfall:
Customers and developers have the ability to agree on what is to be delivered early on in the process of development. This ensures the planning and designing phases are straightforward.
It’s easier to get an accurate measure of progress since the entire scope of the project is known beforehand. During the entire development process, it’s easier to have several members of the overall team involved in other work simultaneously. For instance, a business analyst can assess and document what still needs to be completed while developers work on various projects. While coding is being completed, testers are able to test different scripts. The customer is only present during status meetings, approvals, and reviews, leaving the rest of the time more flexible.
Since the design is finished early along in the development process, the Waterfall approach is perfect for projects that require the design of several software components to eventually be integrated into external systems.
Lastly, the produced software is easily designed more carefully and completely since there’s a more holistic understanding of the various software deliverables required. This foresight eliminates the possibility of a “piecemeal effect” where several pieces of code have to be added as time goes on.
Now, we’ll take a closer look at some problems we’ve seen with the Waterfall approach:
The requirements’ effectiveness is one area in which the pure Waterfall methodology continuously falls short. One of the hardest parts of software development is gathering and documenting various requirements in a manner that is useful and meaningful to customers. It’s not uncommon for customers to feel overwhelmed by details. Unfortunately for this approach, specific details are required early on in the process. Also, consumers don’t always have the ability to visualize a specific application just by looking at a requirements document. While mockups and wireframes can certainly help, there’s no doubt that the vast majority of end-users have a hard time putting these pieces together along with written requirements to get a better idea of what they’re going to get.
Another possible downside of the Waterfall process is the potential that customers will end up being disappointed with the final software product. Since all deliverables were based on documented requirements, customers might not have an accurate idea of what’s being delivered until it’s finished. At this point, it makes changes significantly harder and more expensive.
The Agile Methodology
As you can guess from the name, the Agile approach is a flexible, team-based methodology. This process stresses the quick delivery of applications through functional components. Instead of establishing strict schedules and tasks, all of the time within the Agile methodology is time-boxed in several phases known as sprints.
Every sprint has a predetermined duration, typically lasting weeks, with a list of deliverables that are set at the beginning of the sprint. The priority of each deliverable is determined by the business value which is initially set by customers. If it’s not possible to complete all of the planned work before the sprint ends, work has to be reprioritized and adjustments are made accordingly moving forward.
As work is being completed, project teams and customers can actively evaluate and review the project through demos and daily builds. The Agile approach relies heavily on customer involvement and input throughout the duration of the project.
Here are some of the major benefits of the Agile methodology:
The customer has frequent and early opportunities to see the work being delivered and to make decisions and changes throughout the development project.
The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
If time to market for a specific application is a greater concern than releasing a full feature set at initial launch, Agile can more quickly produce a basic version of working software that can be built upon in successive iterations.
Development is often more user-focused, likely a result of more and frequent direction from the customer.
And, of course, there are some disadvantages:
The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.
Agile works best when members of the development team are completely dedicated to the project. Since the Agile methodology focuses on frequent prioritization and time-boxed delivery, there’s a possibility that some deliverables won’t be completed in time. As a result, additional sprints might have to be added, increasing the projects initially projected cost. Additionally, the involvement of customers throughout the process often leads to the request for features to be added at several, odd intervals. Once again, this adds to the overall cost of the project and extends its timeline.
It’s easiest to organize and manage the various projects the comprise the typical Agile process when all members are working from the same area. This isn’t always possible, unfortunately, leading teams to rely heavily on collaboration tools such as webcams and conferencing software.
With many different iterations, the Agile methodology leads to many reassessments of the initial scope of the project. Without this consistent refactoring, the overall quality of the project can drastically decrease. Naturally, this issue with the Agile process is much more apparent in larger-scale projects.
Choosing Between Waterfall and Agile
Now that we understand the key differences between the Waterfall and Agile methodologies, how do we decide between the two? First and foremost, companies have to determine their own methods and processes. It’s a slight variation of the Waterfall process. All of our modifications rely on using prototyping when possible in order to engage the customer early on in the process. This strategy greatly helps to boost the team’s overall understanding of what’s required while simultaneously improving communication with the most important component: the customer. Once the application’s initial framework is finished based on the requirements, our team will continue to the developmental phases while staying in touch with the customer just in case any refinements need to be made. With this strategy, we succeed in being iterative without giving up on the architecture of our system.
While it’s true that many companies are starting to adopt different variations of the Agile methodology, there remain many organizations that have yet to make the change. It’s not uncommon for organizations to move into a hybrid approach that takes components from both the Waterfall and Agile processes.
After determining the basic methodology that should be utilized, organizations can start making refinements and specific changes to fit their needs and goals. While there are generalized applications for these methodologies, the merit of each boils down to practicality. At the end of the day, the best method for an organization will depending how well each performs given their goals and skills. That’s why it’s important to test each methodology before deciding which to move ahead with.
curtsy : https://sourceforge.net/