Agile Shortfalls and What They Mean for Developers

Yulong Wu

Yulong Wu, Last updated on March 1, 2020

What is the best software development methodology to use? This question is the topic of hot debate during the project implementation stage. However, what you choose depends on many specific factors. To organize the flow of a software development project, there are several methodologies to use. 

Two of the most widely used software development methodologies are Waterfall and Agile. While there are many devoted Waterfall fans out there, Agile has gained its own dedicated following. But Agile doesn’t work for every software project, so keep reading to find out why. 

How Agile Was Born

Agile is newer than the traditional Waterfall method. Unlike Waterfall, Agile is a type of Rapid Application Development or RAD often paired with Scrum. Several years prior to 2001, people were looking for new ways to replace this traditionally-established, unresponsive framework. Several approaches of a new methodology had been invented in the 12 to 18 months before 2001, when Agile debuted. They included the following:

  • Extreme Programming
  • Crystal Methodologies
  • Scrum
  • Adaptive Software Development
  • Feature-Driven Development
  • Dynamic Systems Development Methodology

The hope was to add “agility” to the development process by breaking it up into smaller sections. The goal was to help get new products to the market quickly while gathering consumer feedback during development. Also, it made it easier to try out new features and functionalities before completing the final product. 

On February 13, 2001, at The Lodge at Snowbird Ski Resort in the Wasatch Mountains of Utah, a group of 17 people proposed the principles of Agile software development. Agile methodology, instead of specific ways of doing things, is a set of rules to follow for a flexible, efficient, people-centric software development process.

Reactive Vs. Predictive: A Comparison of Agile and Waterfall Methodologies

First, Let’s talk about the Waterfall method. The normal routine of a Waterfall project has conventionally five stages. It usually goes from planning, building, testing, reviewing and, finally, into deploying. What is important in a Waterfall project is that the team cannot proceed until the current stage is over. 

Also, like a Waterfall, the order is usually from planning to deploying, with no skipping of any steps in the middle. There is no way for anyone to start coding until planning is over, then no one is able to start testing until programming is fully complete. Moreover, if things don’t work out, the current status gets bounced back to the previous stage. 

For example, if there is a problem about a certain function that is impossible to build, the whole team goes back to the planning stage where everyone has to stop everything and return to the conference room.

Most of the steps in Waterfall project management can take a substantial amount of time. Also, the discovery of any problems at each step can send the project back to base 1. If there are a variety of problems, the project must be repeated over and over until it runs out of money. 

Worse yet, by the time the project is finally complete, the end product can be a total misunderstanding of the product owner’s needs. Or, even worse it is rendered useless or obsolete because of changes in technology.

The Waterfall method represents a plan-driven approach. That means it attempts to map out the whole detailed process of the software development in the planning phase. The goal is to make software development more predictable and efficient. Therefore, when changes happen, the Waterfall method won’t be able to react to them without starting the project all over again. 

In this increasingly fast-paced world, the Waterfall method is becoming less and less effective in building software that meets the high demand. The Agile methodology, with its more reactive approach instead of predictive, is set out to thrive on the changes necessary to meet the needs in this ever-evolving world. 

Scrum Vs. Agile Vs. Agile Scrum

We often hear people talking about “Agile” and “Scrum” as if they were two different things. However, we can also hear the term “Agile Scrum” used in many places. So, are they the same or are they different? 

Agile is a framework that aims to foster individual interaction in the software development process and create customer collaboration. Also, it can quickly respond to changes and generate working software. There are 12 principles in the Agile Manifesto that explain in greater details the goals, the mindset and the requirements to practice agile software development.

According to the Agile Manifesto, Agile is just a framework without any specification on how to proceed with software development. However, under the umbrella of the Agile philosophy of software development, Scrum is one of the most common approaches to practice the Agile methodology.

Scrum was developed between the ‘80s and ‘90s with a focus on the management process of software development. In Scrum, the project is divided into manageable chunks, known as Sprints. Sprints are estimated to take under 30 days to be developed into the ship-ready stage. There is also a daily Scrum and burndown chart to ensure communication and monitor progress.

Agile Scrum Software Development: Common Roles, Steps and Procedures

The two specific roles in Agile Scrum software development are as follows:

  1. Product Owner: While this is obviously the person who owns the product, it also represents the user and customer of the end product. They are also the person who sets the direction and identifies the right features to release. 
  2. Scrum Master or Project Manager: The Scrum master sets up the procedure, arranges meetings and makes sure the development process goes smoothly.  

The rest of the team usually consists of executives, developers, testers and customers.

Understanding the Agile Scrum Software Development Process

This is the Agile Scrum software development process in just five steps: 

  1. Creating the User Backlog: The user backlog is a collection of features,known as user stories in Scrum because the features are written from the end user’s perspective, that will make the software great.  
  2. Identifying Which User Stories to Release: The product owners choose which user stories in the user backlog will be included in the product release.
  3. Prioritizing User Stories and Estimate the Workload:The chosen user stories are prioritized and given an estimated workload.
  4. Developing Sprints: User stories are combined to form a sprint. Sprints are short duration milestones that normally take under 30 days to achieve. The end product of each sprint must be a ship-ready deliverable. In each sprint, there will be four stages: plan stage, build stage, test stage and review stage.
  5. Monitoring progress. The Scrum master will have to monitor the progress to see if the team is on the right track. That way, they’ll know if they will finish the project on time. Other ways to keep the team on track and in the know include: 
  • Burndown Chart: A burndown Chart  created at the beginning of the project  lists the remaining workload. Workloads on the burndown chart should head toward zero, although some fluctuations can occur in between each day.
  • Daily Scrum: Daily stand up meetings  for team members to report their progress, identify problems, and communicate with each other.

The Disadvantages of the Agile Methodology

Agile methodology came about because there were many things that the Waterfall methodology couldn’t do. However, that doesn’t make Agile the best at everything. Here are some of the disadvantages to this methodology: 

More Dedication and Time Investment

While focusing more on people and the interactions between people, Agile needs clients to commit more time and energy into the project. Clients can’t just show up once at a specific time to provide their plan and then wait for the project to be complete. 

Because the project development becomes an ongoing process for the client as well, they will have to commit to giving up a portion of their time each month, sometimes each week or even each day, to the project.

Too Much Focus on the Details

Since what makes Agile efficient is short planning and quick reaction to change, sometimes the project may end up with a ton of features without a clear connection between them.  Moreover, some functions are more suited for seeing the big picture in the future, which makes them shine less in the user review phase. This results in a shortsighted project. Also, the bigger projects may be too large for chopping into smaller, more manageable milestones.

A New Concept to Some Clients 

Before Agile, there was already a solid-structured software development process that people had been using for years. Agile is relatively new, so  it may take more effort from the client side, as well. So, it shouldn’t come as a surprise when some clients need some more help in understanding their role in an Agile development project.

Less Predictability and Documentation 

Compared to the Waterfall method, which is more plan-oriented or document-oriented, Agile tends to react when a problem presents itself, rather than predicting the problem. This can leave projects with the Agile approach with much less documentation before the project even starts. 

Some people argue that the key part of documentation in Agile software development is its source code. This property of Agile software development can be much harder for new members to understand. Furthermore, the team can sometimes fall off track because of insufficient details for direction before the project begins.

Tough to Maintain a High Level of Collaboration 

Because Agile separates a project into blocks and assigns tasks to different individuals  at the same time,collaboration can be difficult. Frequent updates and daily Scrums are crucial to the entire team.  

While some still turn to the traditional Waterfall approach, Agile is a viable alternative, thanks to the flexibility at every stage of the project. The Agile Scrum development process works well, but it doesn’t work for every single project. Huge, complicated ones may be too much to break up into manageable Sprints. 

However, the fixed, “all or nothing” approach of Waterfall can make it too cumbersome and time-consuming for a successful project finish. The decision on which to use often is dependent on the size of the project, as well as how much involvement the product owner wants to commit. 

Agile and Waterfall: A Quick Comparison Study

Here is a quick comparison of Agile and Waterfall software development methodologies:

  • Waterfall works best for projects where the requirements are well-defined and have no expected changes. Agile works better when there is a bigger chance of frequent project adjustments.
  • Waterfall is simple to manage yet rigid because of its sequential approach. Agile is more flexible, yet not as defined since it allows changes at any stage. To mitigate that, teams should create a clear roadmap for delivering the finished product to avoid uncertainty during each phase of the project. 
  • In Agile, the project description and each specific step of the project can change often. In Waterfall, they are definite from the start. The requirement of each step must be fulfilled before moving on to the next.
  • With Waterfall, the product owner only has to be involved in the beginning. But, with Agile, they must approve each phase of the project before the development team can move on to the next. 

Conclusion

Will you use Agile, Agile Scrum or Waterfall for your next software development project? While it may depend on your team’s preferences, it also depends on the specifics of the project, such as the size and scope. Be sure to consider all factors in order to make the best choice. 

Did you like this post?

Receive updates delivered to your inbox.

We will never spam you. One email per week with latest updates.

Comments

Leave your comment here

Your email address will not be published. Required fields are marked *