Ceaser Nzuki
Blending agile and waterfall the keys to a successful implementation
INFO 579
The waterfall and the scrum programming improvement models have a few points of interest and drawbacks when contrasted with one another. The waterfall display majors on the advancement procedure by separating it into stages that stream downwards towards the last improvement of the product, much the same as on account of a waterfall; thus the name waterfall development model. The scrum then again, isolates the improvement group into a few little gatherings and each gathering is alloted an errand to achieve.
Traditional approach focuses on the completion of activities rather than on delivery of features. This is another reason why traditional planning fails to lead consistently high value products is because the work described by the plan is not prioritized by its value to the users. This would happen in badly managed waterfall projects, but nothing and no one prevents you to develop a waterfall plan with a properly deliverables-oriented work breakdown structure (WBS) and schedule. When addressing the first activity in an agile project, putting a strong effort in defining an itemized product backlog is a great jumpstart.
I agree with the authors statement ‘ that in the future, projects will use a combination of agile practices, with a traditional approach, usually associated with waterfall projects. This should become the dominant successful methodology, even despite the pressure for quick deliveries and the unstoppable growth of agile philosophy.’ The other aspect of interest in the two models is the flexibility in terms of ability to be easily modified to meet the various customer needs, as well as the error handling mechanisms. Scrum is more flexible as compared to the waterfall model.
In the case of the waterfall model, error handling is done on completion of the development process unlike the scrum which allows errors to be handled as the development continues. This makes the scrum to have less bugs. Also, in case the customer requirements change, the waterfall model has no room for modification to meet the changing needs of the customer. This implies that, a complete redevelopment of the software should be conducted. The scrum allows modifications to meet the customer needs
The difference with waterfall is that a change control procedure may not exist; but then, no hard deadlines and low budget constraints can exist either. Customers have not patience. In today's competitive world, time to market is a key factor for success.They want the speed of agile, combined with the predictability of a thorough and traditional project schedule that eases their anxiety in launching new products and services to an increasingly demanding customer base.
The responsibility of a project team lays efficiently and effectively on a face to face conversation. The new generations express themselves more through social-networking apps such as Snapchat than through emails, let alone long documents, but also they use calm conversation or fruitful constructive dialogue and the continuous conversation that agile requires in the absence of long documents less. An approach that was already used in waterfall projects, and that combined with the product backlog covered before helps this interaction is the use of prototypes.
Young agile teams love to have conversation over prototypes, mockups of what the product owner wants to receive. Young agile project teams are more image-oriented than text-oriented. They are more visual than conversational. Therefore, the project manager has to bring good drawing, sketching, and visual thinking skills into the agile project.
The scrum development model gives room to make changes to the software in future unlike its waterfall counterpart. This ability is referred to as the backward scalability. Even late in the development process, changes to the software in the case of scrum model can still be made making it more. The waterfall model does not support this and in case any changes deem important to the software, then the whole process should be restarted. This functionality makes scrum development model more dynamic as compared to the waterfall model.
Also, although both models allow room for segregation to take place, the scrum development model allows greater room for this. It permits simultaneous development of various modules of the software throughout the development process. When it comes to the implementation stage, the waterfall model is short of making modifications. This is to say that, since all the planning is done at a high level (the initial stages) of the waterfall, the development team and process cannot be further broken down in the implementation of the plan. In case it deems critical, then the whole process has to be repeated.
Another aspect by which we can evaluate the two development models is the documentation and the ease of understanding of the processes. The waterfall method emphasizes a clear documentation of the process that goes hand in hand with the plan. The documentation coupled with the fact that the process is linear makes the waterfall model easier to understand (Colombo et.al, 2012, December). On the other hand, the scrum model overlooks the importance of the documentation as different modules are tackled simultaneously by different groups.
Then the last aspect of comparison is the cost and time. The waterfall model is cheaper to adopt as compared to the scrum. This is majorly because; it employs a single team of developers. However, it is also more time consuming as compared to the scrum. Again, on evaluation of the above discussion, we realize that the additional cost incurred in changing the software to meet the customer needs is higher as compared to the scrum
Recommendations
Collaboration is very much needed regardless of whether you prefer agile or waterfall, or both. Among the tools helping with communication, there are the following formal and informal methods of communication: new tools and methods of communication create additional discipline of managing these channels and understanding that the outcome of this communication good for project.
The more informal communication your teams get to experience the more efficient this communication becomes. Basically if you are at a meeting with 20 people, likely only two or three people efficiently communicate. The rest of the attendees are probably not as efficiently engaged or are checking their Facebook page. With informal communications, the conversation is almost always one on one. You have a chance to listen and talk and exchange ideas quickly and fully.
On classical planning process i would recommend that Incremental planning will let you be more flexible, and spend less work marching toward the final project objective. Increments can be as small as weeks or days as well as large as months or quarters. Finally we should all embrace informal communication and establish a comfortable communication ecosystem within your teams. Collect the communication and make it accessible and shearable. Use tools that work with mobile platforms.
References
Rodov, A. & Teixidó, J. (2016). Blending agile and waterfall: the keys to a successful implementation. Paper presented at PMI® Global Congress 2016—EMEA, Barcelona, Spain. Newtown Square, PA: Project Management Institute.