vege - Fotolia
Establishing software requirements can be challenging. It is not easy to gain a good understanding of customer requirements, let alone document and maintain those requirements when they change over time.
Agile vs. Waterfall: Projects and software requirements
Agile has proved to be valuable because it helps development teams and stakeholders stay focused on delivering software that satisfies customers' most important requirements as quickly as possible. With Agile and its frequent feedback cycles, development teams and stakeholders can stay focused on the right requirements.
Breaking down Waterfall projects
In contrast, Waterfall projects aim to define all software requirements upfront and document them with such detail that project teams can develop satisfactory software products without change. This approach puts pressure on customers to come up with every requirement they might need before a prototype has been delivered. When software requirements do change, Waterfall projects use change management to adjust the requirements -- often a time-consuming and costly process.
I've seen Waterfall projects that started with a long list of software requirements, but in the end many features were never used. Even worse is when needed functionality is overlooked at the start of the project, and hence isn't in the requirements. Getting the requirements right, and keeping them right during a project, is close to impossible with a Waterfall project.
Zeroing in on the Agile approach
Now let's explore how Agile addresses software requirements differently, and how the Agile techniques help development teams focus on satisfying the right requirements. The Manifesto for Agile Software Development puts working software above comprehensive documentation. Agile frameworks like scrum or XP suggest development teams should deliver software in iterations. Backlogs with user stories are used to manage requirements. At the start of the iteration the team and stakeholders agree upon which requirements will be satisfied with the next delivery. By collaborating in this way, everybody is focused on delivering the most important features.
Agile projects begin with the assumption that you can't get all the requirements right at the start. Continuous improvement is built into Agile projects, both from a product and process perspective. To improve software project requirements, Agile frameworks provide practices such as planning games, backlog grooming sessions and software demos. When Agile is used, requirements are updated continuously as new information and insights become available.
Success factors for focusing on the right software requirements with Agile projects are:
- Frequent interaction between the stakeholders and development teams
- Focusing on the value that a requirement can deliver to customers
- Deploying Agile requirement practices effectively
Agile vs. Waterfall: Both call for frequent, detailed interaction
There has to be frequent and detailed interaction between the team and the stakeholders. It's important to establish trust and build a relationship were people can be open and honest. This eases communication and supports building a common understanding of the right requirements.
For me, value matters more than costs. If you know which requirements will be most valuable, then the costs for developing them often become less of an issue. Understanding the value also motivates people, and helps them focus on continuously selecting and developing the right requirements.
Using an Agile project framework like scrum, XP, SAFe or LeSS doesn't automatically guarantee success. You have to deploy the framework in a way that suits your needs. Pick suitable practices and agree upon your way of working. Don't worry about not having a perfect process at the start; practices such as retrospectives will help you to learn and fine tune things along the way.
Agile vs. Waterfall
For more about the Agile Manifesto check out Jenn Lent's columns on whether the Agile Manifesto is 'anti-planning' and whether or not the Agile Manifesto is still relevant. Another good resource is this excerpt from Agile Foundations by Peter Measey and Radtac.
To learn more about Waterfall:
Agile development myths
Agile best practices
Combining Agile and Waterfall
I want to break up with Waterfall; my company doesn't