Waterfall vs. Agile Software Development
Whether you are building a house, launching a new company, or planning a big event, it starts with a vision. As the details become more apparent, the idea begins to shift. Things that were committed to in the beginning feel like they aren’t the right fit any longer, or there are new options that you hadn’t considered. Now what? These concepts are also applicable in software development. As you begin seeing and interacting with software, you begin to envision new features or workflows that bring additional value to your product. Agility becomes critical to building the right “thing” without significant rework and additional cost.
For those not familiar with the software industry, the “Waterfall” methodology has been in existence since the ’70s. This method starts with thorough documentation of the requirements and goals upfront. Once this step is complete, the client is not involved until the end, leaving the final product a surprise. As you can imagine, the Client’s vision in their head often does not line up with the final product because they have not seen it along the way, so the “lost in translation” factor is high. In the early 2000s, industry leaders introduced Agile development to solve the shortcomings of the Waterfall approach.
When comparing the Waterfall and Agile methodologies, one factor stands out – frequent feedback to the project. Feedback is a team effort and comes from the client stakeholders and the development team. It happens every 1 to 2 weeks as the client sees an iteration of completed work and has a chance to react to the demonstrated functionality. Without this feedback, a project is actually just utilizing Waterfall. This facade of utilizing Agile is attempting to patch the waterfall’s functional problems without addressing the root issue.
With every Agile software project we take on, we educate our Clients on how critical it is that every team member understands their roles and responsibilities. This clarity draws boundaries between functions and allows for everyone to continue to move forward quickly. When talking with our Clients about Agile, there are non-negotiables necessary for success, and feedback is at the top of the list.
Agile outlines four values that set it apart from other software development approaches. Let’s look at each of these values and how feedback is critical to living them out.
The Best Laid Plans: Being Agile to Change
No matter how much you think you know about how the end product should look and act, change is inevitable. The choice becomes whether to make the changes during the product’s initial development or resolve them after it is in the market. Without feedback from primary stakeholders and customers, a product gets developed without evaluating how it should be improved to meet the end user’s specific needs. Whether the change would provide a better customer experience, increase usage, or help identify low-value features that could be removed, it takes feedback from the people closest to the implementation for these adjustments to be made along the way. By identifying these change points early in development, costly work and rework are avoided.
The development team’s feedback is also critical in identifying different ways of tackling an issue, designing a feature, or increasing usability. Development teams have seen varying ways to build features. They are closest to know why things are more complex, prone to breaking or creating issues as the system scales. Asking developers to provide options and pros and cons can lead to making the system’s best financial decisions. Some features are worth spending more effort to develop than others. This gives stakeholders the power to decide where to concede and where to push for additional budget.
People, Process, and Technology: Individuals and Interactions
Process and technology are components of good software development; however, people are the critical component of Agile. Meaning, the interactions the development team has with itself, stakeholders, and end-users are more crucial to success than the steps taken or the technology used. A home builder starts with blueprints and an understanding of their Client’s aesthetic preferences for finishes. They may have the best tools and processes in their industry. This initial understanding will undoubtedly deliver a high-quality product once completed; however, if they don’t check in with the Client regarding specific paint colors, changes due to unexpected factors, or potential upgrades, they will miss the mark.
If we adhere only to processes, the end product will not live up to its potential in the absence of interactive feedback sessions. Great software developed in a vacuum can still result in high-quality code that follows best practices while meeting cost and timing constraints but will miss the mark on usability and value.
It’s in the Fine Print: Customer Collaboration
We find that to start on the right path, it is not about spending a lot of time upfront determining every requirement. It is impossible to detail every piece of scope in a contract. So the focus shifts to collaborating with the customer to visualize what could be. The Scrum team’s feedback and the customer help shape the optimal solution, identify complexities, and highlight risk areas.
Suppose the following scope item: a feature that allows a user to set a variable such as a temperature, time, or date. This feature, appearing simple, is vague, open to interpretation, and can be developed in various ways. Attempting to document every single requirement before the team and stakeholders are engaged wastes valuable time. It is better to leave the details up to an engaged scrum team and its stakeholders to work through. Doing so allows the team to elicit feedback quickly and iterate through design instead of spending time working through minutiae details in a contract, only to find out the requirements did not fit the user’s needs, to begin with.
Don’t Take My Word For It: Working Software
Time is money. We all know every hour worked goes to the bottom line. If an excessive amount of time is spent documenting a system’s requirements, that means less time to be spent on development. Two weeks of requirements writing produces little concrete value on a project. However, spending those two weeks developing a feature provides valuable software in the hands of stakeholders that can be part of a feedback loop into improving the final product. Observing working software moves from interpreting words or requirements in a document and brings you front and center to evaluating the end product and giving feedback to ensure it is headed in the right direction.
This philosophy does not mean that documentation isn’t essential. Instead, WHAT to document should be evaluated. Good development teams will ensure the code itself is well documented, allowing other developers to easily walk through the code and follow the purpose and flow within the codebase. Spend time documenting things important to launching the product, communicating to the customer base, and supporting the ongoing software.
Roadmap for Success in Agile Software Development
Timely feedback is critical to successful software development. Success comes when Stakeholders come together with an Agile Team focused on honest interactions, building the right thing, embracing change, and showing progress to allow for timely feedback. It is often challenging to envision what it is in mind and make it a reality. Transparent feedback drives better alignment and clarity. If you find that the development team you are working with is not providing regular feedback, determine how you can improve this to ensure that the final destination is a product to be proud of and customers are excited to utilize.