Before agile: the ‘waterfall method’
Prior to the introduction of agile software development methods, traditional waterfall methods were the de-facto development process used across the software development industry. Waterfall project development is still used today in many modern industries (albeit with a few changes here and there).
Waterfall project management methods have undergone some revisions and improvement but are considered by many people to be somewhat dated when compared to the more modern agile methods.
Sequential phases
Waterfall methods take their name from the sequential nature of their development cycles. The first phase normally being requirements analysis, followed by design, followed by construction, followed by testing. The final phase marks the end of the project whereby the finished system is deployed and operated by users. When displayed on a chart, the development process very much resembles a waterfall, hence the name.
Because waterfall development is linear, software development naturally followed a ‘layered’ development cycle. One team would do their job before passing the software on to the next team who would layer their respective components onto what had already been built. It often took months and years for the final product to be delivered to clients. Any missing or broken components were only discovered long after the product had been deployed and development closed.
User uncertainty
In the early days of software development, waterfall-based projects were often plagued with delays and budget overruns.
One major factor which contributed to such delays was the false assumption that users knew what they wanted from the system. Making changes to a system to accommodate users’ changing needs was more expensive and time-consuming the later in the project these were implemented, as such many projects were late and over-budget.
That’s not to say though that waterfall methods aren’t still needed. They are used very successfully today on many projects – particularly those where users requirements can be clearly defined, or on projects (such as construction) whereby changes made late in the project are simply unfeasible.
The Agile Manifesto
In the early 90’s, small start-ups without limitless financial backing and time on their hands had to find a way to make software development more fluid and less costly. They slowly began to adopt agile policies into their development methods (although they had yet to be labeled as such).
It was only in 2001 that a small group of luminaries gathered to discuss their knowledge of software development management and create what is called the Agile Manifesto.
The manifesto created a rough guide for future software project development, underlining the principles the authors believed should be held paramount when approaching software development in the modern era.
Agile roles
Contemporary agile approaches vary in scope and complexity. Since the creation of the Agile Manifesto, agile methods have been adapted to suit a wide range of industries each with unique features and challenges. While some (e.g. Scrum) add their own unique roles to the mix, agile methods in general focus their attention on some key roles within the project development process.
Users
Agile project development research always begins with the users in mind. Users help define project goals and needs. They can also help refine a product by providing feedback to developers. By seeking user input throughout the agile development cycle, development teams can ensure that the final product is something users will understand and value.
Product owners
Every project begins with the product owner. Owners are charged with detailing who the target users are, what problems they face, how the product can solve these problems and what criteria success will be measured by.
Product owners work closely with development teams when planning to make sure everyone involved knows exactly what is being asked of them and how best to achieve the project goals.
Developers
Agile development teams operate differently from traditional waterfall development teams. Because agile works in short iterations, and because teams are tasked with developing a working product each iteration, development demands extensive cooperation and foresight. Agile teams must work in unison to complete end-to-end functioning products, as opposed to waterfall product development whereby each stage is completed, reviewed then passed on to the next team.
Agile development teams do not specialize in different disciplines, rather they include members who possess a wide range of skills and abilities. A single agile team may be comprised of designers, analysts, engineers and users.
Why agile works
Agile works because it is flexible and can easily adapt to changing user demands and business requirements. You do not define a rigid development cycle and product specification up front as you do in waterfall projects. If something doesn’t work as intended, or if research reveals a critical oversight, an agile team can quickly adapt the product in later iterations to ensure the final product meets the users’ needs.
Agile works because its guiding principles and values closely mirror contemporary working conditions. Product owners may think they know what users want but can’t be sure until a working product has been delivered and feedback has been gathered. Likewise, development teams may think they have made the perfect product but can’t be sure until they can demonstrate the product to its’ intended audience.
Agile highlights ongoing improvement and creates an environment of continuous learning and adaptation.
Today’s markets demand organizations hold a competitive edge in product development, and this is exactly what agile delivers. If you’d like to know more about what agile can offer you or your business, make sure to see our agile training courses.
