Waterfall Vs Agile

Waterfall has been ‘invented’ decades ago. Based on traditional project management from other industries, the software industry copied the long term planning approach. As in construction, we first build a foundation (architecture), we lay bricks (coding) and then we test and integrate everything.

There are 2 big differences between waterfall and agile:

A. From long term planning to ‘iterations’

In waterfall, we gather all the requirements for the product we are building upfront. A business analyst speaks to stakeholders and gathers all their ideas. He then translates that into software requirements documents. These documents can be very large for big projects as their goal is to capture ‘everything’ that needs to be built in the product. Based on this extensive requirements document (which can take months to complete), the engineers and testers estimate the workload (by reading all the requirements). They come up with a plan to build the product from beginning to end. This includes everything from architecture, designs, coding, to testing and deployment.

Once the estimates are confirmed, a planning is made (which can sometimes span months or even years) with deadlines and milestones. Once the planning is confirmed and the budget approved, the team starts working on the product. First, the architects will design the architeture and make choices that impact the whole lifespan of the project (upfront). Then designers make designs that are used by the developers to create the software code. All this work is done stage-wise. The designers work as a team to finish all the designs and when approved, hand them over to the programmers. Once the programmers finish their coding, the testers test all the code. Once this testing process is done, the product can be integrated and deployed. Any request for change that comes in during the project is parked as a change request and ideally done after the initial project is completed. If it’s done in between, the whole planning needs to be revised, something which is seen as ‘disrupting’.

In agile, we work differently. Instead of planning everything up front, we work in iterations. We describe the requirements for the product on a high level. The business people gather in a room with the development team and discuss all the ideas they have. Requirements are captured in ‘user stories’ (short user-centric descriptions of the user needs). These user stories are written down on sticky notes and prioritized on a backlog. Based on this initial discussion, the team has a high level understanding of what needs to be built. They can roughly estimate the time required to complete the whole project. Using this estimate, a budget can be assigned along with a timebox for the project. Within that timebox, the goal for the team is to build as much ‘value’ as possible.

The team then starts the first iteration (typically 2 weeks for an agile software team). To start, the team discusses in detail with the product owner what they need to do to complete the user stories. At this stage the requirements become ‘detailed’ (so we do make detailed requirements, but only when we are close to the implementation of those requirements). The team executes the iteration and then delivers the user stories to the product owner and stakeholders. Based on what they can see and inspect, the product owner decides on the priorities of his product backlog. This is then the input for the team to decide what they can build in the next iteration. Changing requirements is welcomed, because it means the team is recognizing that the user needs something which was not clear to the team when the project started.

B. From sequential work to cross functional teams.

To make the iterative approach work, teams need to be cross functional. Where waterfall has teams of the same function working together (developers, testers, designers) to make the stages work out; agile has all these functions in the team. Each team has 3-9 developers, a mix of designers, business analysts, coders and testers. This team should be capable to deliver the next increment of the product and we keep the team as stable as possible. Within the team, we have a scrum master to facilitate the work within the team. He is not a project manager or team lead who assigns work; instead, he is a coach who helps the team communicate and collaborate as productively as possible.

Want to know more? Talk to us