Integrating Waterfall and Agile Development: Hybrid Model
10/23/2018
Edit
Waterfall and Agile/Scrum development methodologies are widely used
by all organizations and are individually considered a proven approach
for development. However, challenges arise as these two methodologies
merge and clash. Here are a few key tips to help integrate both
methodologies into your development organization. Let’s first discuss
each methodology and its unique characteristics and assumptions.
The waterfall software development life cycle methodology believes in getting everyone together and involved early in the design process. The design process is longer and iterative as the team steps through the high level requirements, conceptual approach, solutions design, preliminary design and critical design. This assumes little will be left for discovery through the development and testing phases. Generally, waterfall has worked effectively for certain types of products – large, enterprise-wide development efforts where the user is being led through a standardized process.
However, Agile/Scrum is meant for a more volatile world and provides an iterative approach. For example, in the mobile applications space, the landscape is constantly shifting as new phones, new operating systems, and new technology to deliver data compete to get the user to interact in as many ways as possible. Short iterative development allows for an “open” mind for discovery since less time is invested upfront. In this case, discovery involves anything from functional flaws to ineffective user flows to the concept being deemed a bad idea altogether.
The fundamental difference between the two is Agile/Scrum assumes there will be flaws and therefore jumps into the coding to expose these. Therefore the success of the development team is driven on its ability to adapt and react quickly. Waterfall, instead, takes early precautions to mitigate any flaws.
This obviously causes a clash between development teams practicing each of the development methodologies. But certain steps can be taken to show the development team the advantages of the other’s methodology and ideally bring a team together.
5 Tips to integrating agile development groups with waterfall development groups
Trying to introduce agile as iterative waterfall will not work
Some organizations think they can be more “agile” by doing waterfall in smaller iterations. The problem is the timeline is tough to compress when fully vetted artifacts are expected after each round of reviews. There is too much overhead with all of the document creation which detracts from the amount of time left for coding. Agile is about streamlining processes not compressing them.
Development / QA can be iterative while being bookended by design and integration
One transition strategy is to employ agile in the development and QA cycles. Smaller scoped development cycles followed by QA. This way the customer sees the evolution of the application and can comment along the way. The design is properly vetted at the beginning and ample time is allotted for integration at the end.
Watch out for scope creep
A project manager’s challenge in working in a fast-paced “can-do” development team is managing scope creep. Since changes can be implemented quickly, anything and everything seems possible. So the distinction must be made and managed between what is considered a fix versus what is considered a change so that sprints are tight and marching towards the agreed-upon end product.
Play nice with QA
QA is always burdened as a release approaches, their schedule’s usually backed up against a wall. In waterfall, QA expects tight use cases to derive their test cases. So in the agile world, they get code thrown over the wall. That is why in agile teams, sometimes developers rotate into the QA role and become part of the solution from the beginning.
Be mindful of the end user
Since at the end of each sprint a fully functional application is delivered, it is very tempting to release it. This can be very annoying to users if this requires a frequent patch or upgrade. It makes the user wonder whether a polished product is ever in the horizon. If the upgrades are seamless, it may be a hassle to keep up with the new changes. Therefore a published release schedule or roadmap keeps the user in the loop. Major releases semi-annually and/or functional releases quarterly are recommended.
The waterfall software development life cycle methodology believes in getting everyone together and involved early in the design process. The design process is longer and iterative as the team steps through the high level requirements, conceptual approach, solutions design, preliminary design and critical design. This assumes little will be left for discovery through the development and testing phases. Generally, waterfall has worked effectively for certain types of products – large, enterprise-wide development efforts where the user is being led through a standardized process.
However, Agile/Scrum is meant for a more volatile world and provides an iterative approach. For example, in the mobile applications space, the landscape is constantly shifting as new phones, new operating systems, and new technology to deliver data compete to get the user to interact in as many ways as possible. Short iterative development allows for an “open” mind for discovery since less time is invested upfront. In this case, discovery involves anything from functional flaws to ineffective user flows to the concept being deemed a bad idea altogether.
The fundamental difference between the two is Agile/Scrum assumes there will be flaws and therefore jumps into the coding to expose these. Therefore the success of the development team is driven on its ability to adapt and react quickly. Waterfall, instead, takes early precautions to mitigate any flaws.
This obviously causes a clash between development teams practicing each of the development methodologies. But certain steps can be taken to show the development team the advantages of the other’s methodology and ideally bring a team together.
5 Tips to integrating agile development groups with waterfall development groups
Trying to introduce agile as iterative waterfall will not work
Some organizations think they can be more “agile” by doing waterfall in smaller iterations. The problem is the timeline is tough to compress when fully vetted artifacts are expected after each round of reviews. There is too much overhead with all of the document creation which detracts from the amount of time left for coding. Agile is about streamlining processes not compressing them.
Development / QA can be iterative while being bookended by design and integration
One transition strategy is to employ agile in the development and QA cycles. Smaller scoped development cycles followed by QA. This way the customer sees the evolution of the application and can comment along the way. The design is properly vetted at the beginning and ample time is allotted for integration at the end.
Watch out for scope creep
A project manager’s challenge in working in a fast-paced “can-do” development team is managing scope creep. Since changes can be implemented quickly, anything and everything seems possible. So the distinction must be made and managed between what is considered a fix versus what is considered a change so that sprints are tight and marching towards the agreed-upon end product.
Play nice with QA
QA is always burdened as a release approaches, their schedule’s usually backed up against a wall. In waterfall, QA expects tight use cases to derive their test cases. So in the agile world, they get code thrown over the wall. That is why in agile teams, sometimes developers rotate into the QA role and become part of the solution from the beginning.
Be mindful of the end user
Since at the end of each sprint a fully functional application is delivered, it is very tempting to release it. This can be very annoying to users if this requires a frequent patch or upgrade. It makes the user wonder whether a polished product is ever in the horizon. If the upgrades are seamless, it may be a hassle to keep up with the new changes. Therefore a published release schedule or roadmap keeps the user in the loop. Major releases semi-annually and/or functional releases quarterly are recommended.
Xin chào !Tôi là Anh Star kẻ đứng sau website này, tôi viết blog toàn thời gian và kiếm tiền online qua click quảng cáo. Website này lần đầu tiên được thành lập vào năm 2018, hoạt động vào đầu tháng 5 năm 2018 cho đến ngày hôm nay.
