It is the most common scenario! A business problem is handed down to the team. The project manager comes out with project charter explaining the objectives and other details. He determines the project scope, estimated effort, costs and time lines etc. He promises a date by which he’d deliver the solution with a set of features.
Then the Waterfall cycle begins! The teams work meticulously in capturing each requirement in detail, may be using use case, point by point, covering all the scenarios. Then the design team comes and detailing the placement of every field, button, checkbox and pixel and data models etc. Then the army of Developers takes over, write down the code meticulously in the way dictated by designers, implementing each requirement to the best of their understanding to hand over the output their comrades, the Testers. Testers show their mettle in finding bugs and product is ready. And then, finally T-shirts are printed and launch parties celebrated and slowly euphoria dies down. Business gets a chance to use the product. Despite all the confidence inspired, what happened is wrong solution is delivered with right efforts!
What went wrong???
There is a lessons learned meeting, root-cause analysis happens. It concludes that the team delivered the wrong solution because the project was based on unvalidated assumptions. These assumptions were presented as requirements. There is no feedback loop mechanism during the development of the product.Waterfall typically depends on listing the features to the teams which are bundled together and developed as a product.
Instead of providing the teams with list of features, what needs to be done is to present the business problem to the teams and put constraints on the solution. Working on short iterative cycles gives the business the opportunity to look at the product and validate the way in which product is being built.
Building agility into the development life cycle with shorter iterations and continuous feedback loop mechanism mitigates the risk of delivering a wrong product to the customer at the end of a long project gestation period. Despite a lot of buzz around Agile methodology with lot of coaches and availability of literature, many people and organizations struggle to embrace agility properly. One of the reasons is people got comfortable with waterfall and the other is no clarity on certain roles.
Software Engineers whose activity is coding, don't find their role changing. They continue to write the code. For others the roles are not clear. People in roles such as designers, project managers, architects and analysts find their role definition changed. The water fall process provides designers compartmentalized period in which they can focus on their work and draw a lot of satisfaction by providing what they think are optimal design for the application. Suddenly the designer finds the role and space shrunk which leads to dissatisfaction as well as job insecurity. Suddenly you find people screaming, “Oh, this is not the way of working. This cannot be called design.” In agile, the value designers brought into project gets distributed to other roles in the team. One needs to recognize the evolution of the role avoid the temptation to cram the old methods into the new process.
Agile with its orientation towards iterative approach facilitates better coordination and frequent feedback from the customers. Software is developed in iterative and incremental model in rapid cycles. I’d not like to cover the methodology of Agile as such in this post as it is very popular and would limit my discussion to the impact on the teams and development cycle. Here are the Pros and Cons of Agile:
Pros:
Flexibility
Traditional waterfall model dictates that requirements to be defined ahead of design and implementation. The scope is rigid and non-negotiable factor. With Agile methodology, schedule and cost are the major determining factors and it is scope that changes in order to accommodate acceptable business demand.
Immediate Feedback
Presence of business representative ensures that there are suggestions regularly. Agile methodology calls for smaller release cycles, in which the product is always in a ready release state. This ready release state is brought about by continuous feedback from product owners and end users with the development and quality assurance team. Corrections can be immediately passed on to the developers.
Predictability
Fewer Defects make to the end as result of quality assurance testing being done on each cycle. The cycle of develop, build and test cuts down the number of defects and they are caught early on.
Cons:
Documentation Gets Left Behind
Agile’s code-test-build-release cycle does leave one component behind, which is documentation. Due to the fluid nature of Agile, the documentation team needs to follow right behind the curve of the project’s rapidly changing scope. Whether this happens are not is the question.
Daily Meetings take the toll
Daily stand up meetings take the toll due the high pressure created. However, frequency of the meetings is one thing that needs to be decided by the project managers in the interest of the team and project. The team members are expected to have considerable experience expertise and junior members may not always be preferred.
Conclusion
There is no single methodology that can be adopted by all the projects. The classic Waterfall model has its own advantages as well as limitations. Agile methodologies can also be inefficient in large organizations and certain types of projects. So it is up to the Managers concerned to select the right methodology based on the project characteristics.
Whatever said and done, Agile is the current trend and Buzz word. As long as we don’t see the methodology as the end in itself, we can adopt any suitable model and deliver value to the customer. It is worth giving it a try.
Then the Waterfall cycle begins! The teams work meticulously in capturing each requirement in detail, may be using use case, point by point, covering all the scenarios. Then the design team comes and detailing the placement of every field, button, checkbox and pixel and data models etc. Then the army of Developers takes over, write down the code meticulously in the way dictated by designers, implementing each requirement to the best of their understanding to hand over the output their comrades, the Testers. Testers show their mettle in finding bugs and product is ready. And then, finally T-shirts are printed and launch parties celebrated and slowly euphoria dies down. Business gets a chance to use the product. Despite all the confidence inspired, what happened is wrong solution is delivered with right efforts!
What went wrong???
There is a lessons learned meeting, root-cause analysis happens. It concludes that the team delivered the wrong solution because the project was based on unvalidated assumptions. These assumptions were presented as requirements. There is no feedback loop mechanism during the development of the product.Waterfall typically depends on listing the features to the teams which are bundled together and developed as a product.
Instead of providing the teams with list of features, what needs to be done is to present the business problem to the teams and put constraints on the solution. Working on short iterative cycles gives the business the opportunity to look at the product and validate the way in which product is being built.
Software Engineers whose activity is coding, don't find their role changing. They continue to write the code. For others the roles are not clear. People in roles such as designers, project managers, architects and analysts find their role definition changed. The water fall process provides designers compartmentalized period in which they can focus on their work and draw a lot of satisfaction by providing what they think are optimal design for the application. Suddenly the designer finds the role and space shrunk which leads to dissatisfaction as well as job insecurity. Suddenly you find people screaming, “Oh, this is not the way of working. This cannot be called design.” In agile, the value designers brought into project gets distributed to other roles in the team. One needs to recognize the evolution of the role avoid the temptation to cram the old methods into the new process.
Agile with its orientation towards iterative approach facilitates better coordination and frequent feedback from the customers. Software is developed in iterative and incremental model in rapid cycles. I’d not like to cover the methodology of Agile as such in this post as it is very popular and would limit my discussion to the impact on the teams and development cycle. Here are the Pros and Cons of Agile:
Pros:
Flexibility
Traditional waterfall model dictates that requirements to be defined ahead of design and implementation. The scope is rigid and non-negotiable factor. With Agile methodology, schedule and cost are the major determining factors and it is scope that changes in order to accommodate acceptable business demand.
Immediate Feedback
Presence of business representative ensures that there are suggestions regularly. Agile methodology calls for smaller release cycles, in which the product is always in a ready release state. This ready release state is brought about by continuous feedback from product owners and end users with the development and quality assurance team. Corrections can be immediately passed on to the developers.
Predictability
Fewer Defects make to the end as result of quality assurance testing being done on each cycle. The cycle of develop, build and test cuts down the number of defects and they are caught early on.
Cons:
Documentation Gets Left Behind
Agile’s code-test-build-release cycle does leave one component behind, which is documentation. Due to the fluid nature of Agile, the documentation team needs to follow right behind the curve of the project’s rapidly changing scope. Whether this happens are not is the question.
Daily Meetings take the toll
Daily stand up meetings take the toll due the high pressure created. However, frequency of the meetings is one thing that needs to be decided by the project managers in the interest of the team and project. The team members are expected to have considerable experience expertise and junior members may not always be preferred.
Conclusion
There is no single methodology that can be adopted by all the projects. The classic Waterfall model has its own advantages as well as limitations. Agile methodologies can also be inefficient in large organizations and certain types of projects. So it is up to the Managers concerned to select the right methodology based on the project characteristics.
Whatever said and done, Agile is the current trend and Buzz word. As long as we don’t see the methodology as the end in itself, we can adopt any suitable model and deliver value to the customer. It is worth giving it a try.
4 comments:
+ I would like to add that today systems are complex, too many interfaces with lot of up stream/down stream systems. In this increasingly complex scenario we cannot expect to have our old "Project Manager" who used know every aspect of the project to a good extent. Today its impossible for a Project Manager to be even aware of all the complexities involved and they have gone from a Techno-Mgmt role to a Mgmt Only role.
Leaving very little scope for success in Waterfall.
Completely agree !!
Surojit - thanks for bringing out good point. The role of PM from all rounder is evolving due to the emerging changes.
Hello,
The Article on Waterfall vs. Agile is amazing, gives detailed information about it. Thanks for Sharing the information about the difference in waterfall vs Agile Testing For More information check the detail on the Waterfall testing here Software Testing Company
The Article on Mobile testing Services Map is awesome nice pie chart description, thanks for sharing the information about it.Mobile app testing Services and load testing services.
Post a Comment