Make Your Waterfall More Agile
March 30, 2015 | Author: PM Hut | Filed under: Agile Project Management
Make Your Waterfall More Agile
By Deepali Bhadade
Lately there has been huge discussions around waterfall vs agile for software development and which is the best way. While the answer to this is very context driven, there are pros and cons for adopting either of them. At times, due to some compelling factors, a project cannot fully adopt agile methods – rather classic waterfall methods seem more suitable. This write-up is focused on highlighting the best practices that waterfall development can adopt to overcome its peculiar challenges.
Adopting Agile practices in Waterfall
Many-a-times, due to compelling reasons like fair requirements clarity, customer’s reluctance for greater involvement in development, less experienced / distributed project team, defined workflows, multiple organizational stakeholder involvement, the predictive waterfall method is preferred for software development project.
This traditional way of developing software has its own advantages such as:
- Easy to understand and follow as it is sequential in nature
- The plan based approach brings discipline and predictability
- Supporting documentation lessens the person dependency
- Established protocols of communication helps in multi-organization stakeholder interaction
- Provides room for learning curve for the less experienced team members
- Risks related to schedule, skill gap, unplanned leaves can be easily absorbed with long delivery cycles
However, there are several challenges or limitations that software developers face while executing projects in waterfall method. Let’s look at some of them and how good practices from the agile world can be adopted to overcome them.
- No working software till late in the cycleChallenge: In the waterfall model, the intermittent deliverables are mostly the documents such as requirements specifications, design document, test plans, code. While reviews and sign-offs are taken for these deliverables, the effectiveness of the reviews and the validity of sign-offs can be questioned. Such documents are typically technical in nature and if the client’s reviewers lack the technical competency, the reviews may not be effective. This leads to unpleasant surprises and gap in the requirements during the User Acceptance Testing (UAT) when the users get to see the working software – which they understand best.
Agile practice to be adopted: Iterative incremental development and prototyping can help resolve the above challenge. While executing the project in waterfall, plan for initial prototypes for effective requirements gathering from the business users. Plan for incremental development with iterations and schedule a user demo of the working increment after every iteration. This will help to surface any requirements gap as early as possible.
- Big bang plan-driven approach tends to resist changes
Challenge: The traditional waterfall model uses big band plan-driven approach for project execution. All project requirements are collected at the beginning – based on which a complete project plan with timelines, budgeting, and resource allocation is prepared. Once such plan is reviewed and baselined, the focus is to stick to the plan and to deliver as per the plan. Any changes to the plan get negative connotation and are not welcomed by the project team. However, in today’s dynamic environment, there could be genuine business changes which the development should be able to easily cater to.
Agile practice to be adopted: Use rolling-wave planning for building the schedule for your waterfall project. Plan near-term activities in detail and park the long term activities at summary level. Put logical milestones in your schedule to have project reviews with the business stakeholders. Any changes due to the requirements, or other environmental factors could be discussed at such milestone meetings. Re-estimate and re-plan as required. This will give flexibility to the development team to handle genuine changes effectively with an open mindset.
- Low customer involvement
Challenge – In waterfall development, the customer is involved mainly during requirement analysis and later during user acceptance testing. Intermittently, there is low involvement up to the status reporting / query resolution. Many-a-times, the customer does not have bandwidth to get involved to a greater extent due to some other work. However, this can cause problems such as lower collaboration, trust on the team’s estimates, higher time for query resolutions, unpleasant gaps during acceptance testing.
Agile practice to be adopted – The communication plan put up for the waterfall project must ensure that the key customer stakeholders are adequately involved in the project. Frequent short scheduled calls for status update, discussing risks/issues as specific agenda items, scheduling demos, doing active walkthroughs of deliverables instead of offline client reviews, using unified communication channels such as video conferencing, webex, live meeting, instant messaging can give the co-location effect to enhance customer collaboration and make them feel more involved.
- Longer release cycles – slower time to market
Challenges – The traditional waterfall model, with its big bang approach of collecting all the requirements at once, designing and building them together and testing, deploying them at once leads to longer delivery cycles. Customers, these days, however are demanding for faster time to market.
Agile practice to be adopted – Use phased-development approach instead of one big bang development. Split the project schedule into smaller releases of 2-3 months with a potentially shippable software as the deliverable after each release. This can help the customer to do partial release if need be.
- Documentation overhead
Challenge – The predictive waterfall model asks for a lot of supporting documentation as deliverables after each project phase. However, this documentation at times could be redundant, effort and time consuming, not appreciated by the team and even by the client at times. Rather, the client may demand for reducing the documentation overhead in the project.
Agile practice to be adopted – Maintain just-enough documents as essential for the projects. Revisit and tailor the processes being followed in the project and ensure there are no redundant documents being created just for the sake of compliance. For example, if the same design team is going to work on the coding, there is no point in developing a low level design document after a high level design document. Appropriately placed in-line code comments often prove the best documents to understand and maintain the code. Revisit project artifact templates to see how they can be made leaner and value adding.
- Two teams approach – Business vs IT
Challenge – In a typical waterfall project, it’s the business team who gives the requirements. After collecting the requirements, it’s the IT team who develops on those requirements. For any unpleasant surprises or gaps during acceptance, there is a classic war between business vs. IT team. The business claims that IT did not fully understand the requirements. IT maintains the stand that business keeps changing the requirements.
Agile practice to be adopted – Staff your waterfall project to have a domain expert or business analyst in the team. If possible, have a representative from the client business team for any real time query resolution, faster decisions and seeing the frequent demos. Enhance the collaboration with the business team by involving them more by doing demos, active walkthroughs. Use latest communication channels to collaborate virtually through video conferencing, webex, live meeting. Use face-to-face conversations wherever possible.
Will adopting these practices convert the waterfall project into an agile project? Not really. It will still be a predictable methodology followed by collecting upfront requirements, putting sequential phased project plan, having a full time project manager doing resource work allocation and monitoring, and controlling project work.
However, by adopting some key practices such as using iterative incremental development, involving the customer more through prototyping/demos, frequent re-planning for accommodating genuine changes, better collaboration with business stakeholders, and maintaining leaner documentation you can enhance the agility of a waterfall project to overcome its old-age challenges, taking the best of both worlds.
Deepali Bhadade has 18+ years of industry experience in IT industry. During which, she worked with clients in USA, and India from different business domains. Deepali is a certified PMP, CSM, Prince2 Foundation & Practitioner and has extensive project management experience.
No comments yet.
Source: Make Your Waterfall More Agile
