Before we dive into agile project management, it is helpful to look at how complex software projects were managed before it existed. The Waterfall model was popular in the 1970s, however it is now considered 'outdated' for certain projects. Whilst it is still applicable for projects, the theory behind it should be limited in its use. The shortcomings of the Waterfall model initiated the use of Agile methodologies.
Let's start off by looking at the history of project management, and in particular, The Waterfall Model!
Discover the Waterfall Model
Winston W. Royce originally defined the waterfall model in the 1970s. It is a software development approach that moves sequentially through a series of phases.
The waterfall model attempts to complete each phase before going to the next but has built-in feedback loops that allow you to return to a previous one if you discover problems. Thus, progress flows from one stage to the next, just like a waterfall! The process even looks like one. Each phase flows downwards to start the next. In project management, the water that drops to a lower step represents the finished tasks. The task can only go to another phase once it is done.
Get Introduced to The Phases of Waterfall Development
Now that you know how the phases are sequenced, let's look at what should happen in each one:
Requirements analysis - This is when all requirements for the system are gathered. It includes talking to the stakeholders and end-users.
Design - Software architects take the information gathered during the requirements phase and design a structure that supports the needs. Some user interface design may also be carried out during this step.
Implementation - Software developers take all requirements and design documents, and code the solution.
Testing - The internal testing team and the client both test the system. The client should validate that the system performs and behaves as expected. This step is often skipped. In that case, the client tests the system in the maintenance phase.
Maintenance - While using the solution, the client identifies any defects so the system can be adapted as needed.
The diagram below illustrates the waterfall development model phases.
Examine Pros and Cons of the Waterfall Model
Let's examine the advantages and disadvantages of the waterfall model:
Pros
Many design errors are identified and captured early in the project. It means that the relative cost of fixing them is much smaller at this stage than it would be if you had written lots of code and then had to go back to make changes.
Measuring progress is easy as there are well-defined milestones as you move from one phase to another according to an estimated time frame.
Accurate cost estimates can be provided - even for large projects. Toward the end of the design phase, you will know the plan and can, therefore, provide an accurate cost estimate for the entire project.
Cons
Change is difficult with the waterfall model. Let's say that you took two months gathering requirements, spent one month on design, and worked for two weeks on implementation. Then you realize that the requirements are wrong. In that case, you have to go back to the beginning and re-do the requirements analysis phase. This may require considerable administrative overhead and may not be politically possible. The team members may resist the change even if they know the requirements are not fit-for-purpose.
Projects often run late with the waterfall model, and the estimated delivery date is usually not met. This is because, by nature, planning large projects has many unknowns. If you try to plan resources and costs for a nine-month project, then those costs and resource estimates will only be accurate if no requirements or circumstances change over the project duration. That is often not realistic.
The major downside of the waterfall model is that it assumes that you know all the requirements up-front before you write a line of code. There are occasions when you know all of them ahead of time, but you won't for most software development projects. You may think that a certain feature is vital to your target clients or that users will understand the interface you designed. However, until the design is tested and you receive feedback, you cannot know these things for sure.
Discover the Principle of Iterative Development
Although managers loved the waterfall model in the 1970s and 1980s because of its logical flow, a new form of software development called iterative development became popular in the 1990s. Iterative development provides a method to develop a system through repeated cycles that can be revisited and redefined at any project stage.
Here’s a metaphor to describe this:
“Some of the apples may grow from a tree. However, they require time to ripen and continue to grow. Some may fall from the tree before they are ripe, and some may fall and rot and need to be composted.”
When considering the apple tree, it’s true to say that these situations can all coincide. But, similar to a project, the tree continues to adapt and provide different outcomes.
Iterative development is similar; some requirements could lead to some design that would lead to some implementation, all occurring simultaneously or relatively close. Thus, while a team implements a particular subset of the project, requirements could continue on another, and so on.
To compare iterative development to the waterfall model, let’s apply each approach to building a doghouse. In the waterfall method, the team would gather all requirements, make a design, build the house, test it, and then show it to the client. Delivering everything (the finished doghouse) to the client at the end of the project characterizes the waterfall model.
Rather than one delivery, the iterative approach would have several cycles. The client would receive something of value at the end of each cycle. For example, imagine that you broke your doghouse project into three iterations:
Iteration 1: Create a frame outline of the dog house in wood.
Iteration 2: Add the roof and walls to the wooden frame.
Iteration 3: Paint the house and add decorations, including the dog's name above the door.
The value of iterative product development becomes obvious if you look more closely at each iteration. Let's start the first one:
Imagine you've finished the wooden frame and you test it, only to find out that your dog doesn't fit comfortably (or perhaps you've adopted a slightly bigger dog 🐕). Once you put the frame in your small backyard, you will see how much space it takes up and decide that you want a smaller doghouse (but one that the dog still fits in). With iterative development, your team provides a deliverable to the client, who then reacts to what has been delivered.
Imagine that you are happy with the frame, and you move on to the second iteration. You instruct the team to build the walls and roof. Now that the team knows that the size of the frame won't change, they can start with more confidence. Their focus is now on the walls and roof that they will deliver at the end of the phase.
During this process, let's say that the team discovers a problem with the roof. For example, the interior of the doghouse is wet after a night of rain. In that case, the roof is leaky and must be replaced. Or, the team uncovers a different issue: adding the roof increases the width of the doghouse, and the doghouse no longer fits in the backyard. With the iterative method, the issue can be fixed right away.
The third iteration can begin because you know that the shape of the doghouse is good (Iteration 1 feedback), and the walls and roof are acceptable (Iteration 2 feedback). Now you are ready to varnish and paint the wood, treat the roof, add the dog's name, and even a toy bone above the door!
The beauty of the iterative approach is that you learn from each iteration and take that learning to the next. This ability to absorb learning means that you can adapt to misunderstandings, changes of context, or new knowledge in a productive way.
Learn More on The Birth of Agile Software Development
The popularity of iterative software/product development in the 1990s, in turn, motivated a new set of frameworks such as Extreme Programming (XP), Scrum, and Kanban. These new frameworks were iterative but added additional elements. As a result, they became recognized as effective approaches to building software and products that customers loved.
In 2002, some visionaries in the software development field condensed what they had learned into a set of principles called the Agile Manifesto, which brought agile development practices into the world. In the following chapters, we will look at the Agile Manifesto, discuss the principles of agile development, take a quick look at Kanban, and then spend most of the rest of this course looking in-depth at Scrum, one of the more popular frameworks used.
Let’s Recap!
During the 1990s, iterative product development came from frustrations with the waterfall model. In particular, its need to define all requirements up-front and the inability to manage changing requirements. Iterative product development breaks a project into iterations and delivers something of value to the client at the end of each phase.
In the 1990s and 2000s, agile frameworks (all iterative such as Scrum, Kanban, and XP) were built on this principle and are very popular today.
The waterfall method has many pros including identifying errors early and often, accurately measuring costs, and easily measuring and tracking progress.
The waterfall approach also has many cons, including lack of flexibility and adaptability, as well as causing projects to run late.
Now that you know a bit more on Agile methodology, let's discover Agile principles and manifesto in the next chapter!
