The agile method is increasingly referenced. Be it in software development or product management, contributing to the appearance that the waterfall is a dying method. It is beneficial to remember, however, that the two methodologies differ in their organization, approaches to projects, and levels of flexibility. These differences make it such that one method may be more effective than the other in certain instances, and vice versa.
In instances where the transition from waterfall to agile is deemed necessary, though, there are specific considerations and steps that should be taken. High amongst the considerations to take in making the transition to agile is what can be expected to result, and what cannot. A result that is important to keep in mind is that transitioning to agile will induce chaos initially, but over time — and with the blueprint to success in mind — increased team confidence towards the executive team, amongst other successes, can be observed.
Waterfall Versus Agile Methodologies
The waterfall method is the more traditional of the two. It consists of a linear approach to product management, in which each of the stages of the product’s development process — analysis, design, implementation, verification, and maintenance — must be completed before moving onto the next stage. There is little room for changes during the development process, making the waterfall method more rigid than the agile method.
The agile method is newer than the waterfall method, and it is more flexible in terms of allowing teams to adapt to changes quickly and continuously throughout product development. Although the agile method incorporates the stages that compose the waterfall method, those stages occur multiple times within any given agile product development project. Product development under the agile method consists of multiple cycles, each with the stages of analysis, design, implementation, verification, and maintenance.
The emphasis of this method is on the rapid delivery of a relatively complete product, such that feedback can be gleaned and used to inform the next cycle. The feedback from each testing stage is used to make changes to the developing product’s components, thereby enhancing the product and increasing its chances of success amongst its intended users or customers. Unlike with the waterfall method, each stage need not be thoroughly completed before moving onto the next stage; changes are made as the product development process progresses.
Selecting the Right Waterfall Project
Given the differences between the two methods, there are certain projects for which the waterfall method is more suitable than the agile method. There are four main project components to consider when deciding whether or not to use the waterfall method, which is technical and business complexity, the business stakeholder, whether or not the project is a web or cloud-based solution, and team size.
Technical and Business Complexity
The waterfall method is more suitable for product development projects that possess lower technical and business complexity. If the product at hand is a technically complex one, then it likely will require copious amounts of user feedback in order to smooth out the details; the waterfall method, in its rigid stages, would not leave much room to test various components on users or to make repeated adjustments to the product. The waterfall method also is not equipped to handle the rapid changes in technology or expectations that arise with technically complex products. The waterfall is also not efficient in the situation of products changing scopes and budgets.
Business Stakeholder Involvement
Waterfall is suitable if the business stakeholders for the product cannot be extensively involved in the product’s development. Under the waterfall method, the stakeholders’ requirements for the product are conveyed at the beginning, and because there is little room for alterations throughout the development process, the stakeholders do not need to be consulted throughout the process. In Agile stakeholder needs to work closely with the team, should be able to make quick decisions
Web or Cloud-Based
The waterfall is more efficient with products that are web-based, as opposed to cloud-based ones. A cloud-based product continuously changes, requiring experienced team members who can address the changes quickly. The users of cloud-based products have different and evolving skills regarding the product, rendering it impossible to assume their knowledge base — an aspect that is pertinent to planning the product development stages under the waterfall method.
I agree that Cloud-based projects, agile is more suited. But we also have lot of web-based projects that use agile, so this point may not fit well. It may more accurate to have a classification as Application Platform/Type and under that says Web or cloud-based Agile and Mainframes/Legacy/Backend driven-Waterfall. Agile is more suited for new development work and not for Maintenance kind of work.
When a development team is large, then the waterfall method may be used. This method works well with large teams because it is plan-driven and the plan for each project is set at the beginning and is well documented. Team members do not need to coordinate as closely as with agile — which is difficult to do with large teams — and team members do not have to be extremely experienced in order to work on a product using the waterfall method. Team members can leave and a new member could replace their work, as they would be able to look through the documents and pick up where the previous team member left off.
Interfaces and Interdependencies
Waterfall may be the best fit if the system that we develop has more than 3 interfacing applications and has a lot of interdependencies with other projects.
Wherever we have a lot of requirements driven by legal/ compliance, the waterfall may be the best fit. The more open-ended nature, less defined aspects and lack of substantial documentation inherent to agile may impose challenges to businesses.
For product development projects that are more suitable for agile than waterfall, then the executive and development teams must make a transition. Though each company’s transition from waterfall to agile will be different, there exist general steps that should be taken by any company making the transition. First, the company should have a transition plan and timeframe, along with training for everyone in the company. One way to approach training is, to begin with, the executives, then once they are well-versed in agile, to train other employees. After training is complete, it is necessary to introduce the new, agile roles within the company, such as the Product Owner and Scrum Master. Once individuals have been trained and roles have been established, it is time to select a pilot project to work on using the agile method. Along with selecting a pilot project, the company must decide upon the team size and sprint durations, and begin introducing daily meetings.
Given the differences between the waterfall and agile methods, it can be expected that working under the agile method will be chaotic at first, as team members have to adjust to the new roles and routines. It cannot be expected that the process will be smooth or without glitches. The process will likely constitute trial and error to some extent. It also cannot be expected that the transition will result in an immediate boost in project success. Some team members might be inclined to want to be told what to do, as they were under the waterfall method, instead of being more self-directed in their work. It might also take time for some individuals to adjust to communicating their work thoroughly to every other team member and to working more collaboratively.
On the positive side, it can be expected that after the initial transition phase, and after some pilot projects have been completed, the teams will adapt to the agile method. The agile method can be expected to provide lower market risk for the product, due to the many iterations, and better visibility to business stakeholders. Given time and effort, the company will be able to realize the full potential of the agile method.
Benefits of Iterations
The agile method is essentially a variation of the iterative development method. Core to iterative development is building a product incrementally, beginning with the features that create a complete, though basic product, and then adding on additional features to create a more advanced and complete product. This system of incrementally building up a product, which is not present in the waterfall method, provides the benefit of allowing improvements to be made on the product throughout its development, as feedback is gleaned from the iterations and is made use of. Incorporating user feedback into the product helps ensure that the final end product will be more successful than if it had not addressed users’ wants and needs.
Another benefit of iterations is that they help to build team confidence towards the executive team. In building the product incrementally and adjusting its components as necessary, teams are provided with the opportunity to relay their findings — from user feedback — to the executive team and make recommendations regarding the product’s components that likely will be implemented. Delivery of each iteration’s product reduces uncertainty and enhances confidence. The executive team provides more authority to the development teams to adjust and build up the product, which increases team confidence with the executives.
One other major advantage of iteration would be allowing the business to adapt to a change in the market rapidly. A new feature that your competitor has, a new technology that is creating a buzz in the market can be quickly adapted by reprioritizing what needs to be delivered in an iteration
The Final Blueprint to Success
The transition to agile should be based on a thorough understanding of whether agile is more suitable than a waterfall for your company and projects. If agile is more suitable for your projects, then the transition to agile begins with the committed decision to do so. Commitment to implementing agile is a key factor in making a successful transition. Though each company’s transition to agile will be different in its details, a successful transition incorporates components of the following blueprint.
Plan and Initiate
Agile transitions should be based on a plan for the transition, including the goals for the initiative. Once a plan is solidified, it is as important to hold agile training for management and trickle the training to other teams.
After the agile plan is in place and training has been completed, the company’s agile transition will be in full swing. The kick-off stage of the blueprint is marked by Release planning, backlog refinement, establishing work policies and roles, tools for ALM( Rally, TFS, Excel) and planning the sprints.
This stage is marked by inspection of the company’s work and dynamics under agile, and making changes accordingly. Feedbacks from the teams as well as management through Agile surveys, Scrum masters community helps to establish best practices & standards across teams ant to identify potential issues. Issues should be addressed and smoothed out, while agile development plans should be solidified for each role.
Reflection of the work from the previous stages should be used to inform changes in the transition to agile. Amongst the improvements that could be made are focusing on improving agile KPIs, improving meetings, and harnessing agile management. Engaging an agile coach would help an organization on strategizing areas of improvement and transitioning to the next level.
The blueprint to agile transitioning is a loose guideline to the process, but it is not a guarantee of quick and smooth success. Ultimately, the success of your company’s transition from waterfall to agile depends upon the strength of your commitment to the transition, the ability to convince team members about agile, and perseverance towards attaining full agile success.