Striking the Balance: Waterfall and Agile - Part 4
In part 1 of this blog series, we discussed on how business and application related considerations affect selection of SDLC methodology
In Part 2 of this blog series, we saw impact of agile team execution location as well as what pre requisites are considered while team is formed for execution, paving way for inclination to type of methodology preferred.
In Part 3 of this blog series, we analyzed information on existing situation around organization's current/proposed technologies/ tools repository and automation; it's future investment roadmap. This will help driving out methodology choices.
Coming to the last part of this blog series, we will try to unfold how to balance business portfolios within projects and programs with discipline and control against agility and try to explore whether agile and waterfall are really exclusive approaches and can they share best practices and coexists.?
Today's organizations have complex business portfolios for differentiations based on customer segments in a volatile global business environment. IT has to develop applications to develop, enhance, maintain and grow business features to support business demand.
Following scenarios with context to illustrates how organizations can adopt "agile and waterfall."
Organizations have to continue with waterfall, but gain with adopting appropriate agile practices
• Customer's 'acceptance criteria' can be used to redefine milestone content
• Daily stand-ups can improve day-to-day planning and team status communication
• Retrospectives at each milestone can help inspect and adopt with faster feedback cycle to improve the remaining work according to the principle of 'fail early, fail often, and improve incrementally and continuously'.
• Automated testing can validate requirements for completeness, consistency, traceability, and specifications.
• Demonstration of working software around high-risk areas can replace design reviews, Emphasis on validation over verification and use of simulators for early performance validation can trigger early feedback for the team to inspect and adopt.
• Sharing the benefits achieved either due to automation or continuous improvements or reuse or accelerators with the team enhancing morale and team motivation.
• Customer collaboration and early feedback can resolve risks, issues and impediments in the upcoming project lifecycle.
• Time boxing around meetings (planning, progress, governance) and impediment resolution helps to slice and distribute work which is manageable, triggering early and faster feedback.
Organizations have started agile journey, realized need to optimize using waterfall practices
• Complex nature of knowledge work is involved in SDLC which constraints agile approach light in documentation as team will face issues of non-availability of detailed documentation. This may pose challenges in retaining knowledge (Tacit /explicit) in scenarios like transition handover, attrition or scaling. This can be tackled by managing knowledge through 'just-enough/ fit-for-purpose' documentation using wikis, intranet, blogs, and knowledge repositories.
• When business features are evolving, and release of software will contain large chuck of business functionality due to nature of business, resource constraints, maintaining detailed release plan with baseline iteration activities of architecture and design can throw up a holistic view for stakeholders.
• Release planning with specific iterations can help effective resource planning for key team members with multiple commitments.
• Use of design patterns and architectural solutions rather than simple design can help accommodating evolving business requirements.
• Accommodating milestones based on 'definition of done' for tasks, stories, iterations within release plan help communicate project progress better to all stakeholders.
• Laundry list of release and deployment activities and planning for integration within release plan helps all the teams avoid last minute challenges.
It is important to note that above illustrative scenarios will boost efficient communication and collaboration at program level and tackle challenges owing to the portfolio mix of both agile and waterfall projects.
Organizations have both agile and waterfall work programs having dependency with each other due to many constraints such as technology, shared services, application complexity etc.
• It is expected that during the feasibility studies and SDLC methodology selection phase, management identified and communicated business, technical infrastructure, multivendor dependencies to relevant stakeholders.
• Projects were decided to adopt either waterfall or agile methodology based on various considerations. Management establishes high dependencies within projects.
• To achieve desired business functionality, agile and waterfall teams require the mature team level communication and collaboration.
• Agile projects run with time boxed iterations, will develop faster than waterfall and ready for integration.
• Also, agile teams will run iterations, knowing fully that all the information is not available upfront but it will come through as iteration progress.
• Essentially agile team work with certain assumptions about dependencies and associated risks/ issues and move towards integration.
• Waterfall projects will progress with phase gate approach, touch short of speed in showing end product and will not have many assumptions on the way, but there is no real time feedback on working software entill the end.
• Careful synchronization of agile release planning and program plan with milestones can help all teams succeed.
• Setting of program release team with regular Scrum of Scrums (SoS's)/ SAFe /LSS/Disciplined Agile Delivery through progress meetings can mitigate dependency, integration, velocity, resources risks as all teams can validate these assumptions on a regular basis and take corrective action accordingly.
Organizations have successfully differentiated agile and waterfall work within portfolios which are low / minimally dependent on each other.
• Project and program tracks for waterfall and agile projects can run if they found to be almost independent in business, technical infrastructure, multivendor considerations.
• Both these track can progress with minimum interactions between teams throughout the project/program life cycle.
• The agile team can adjust release plans to align with the waterfall milestones for better integration to ensure portfolio consistency in terms of reporting, governance and metrics monitoring.
It is impractical to select waterfall or agile exclusively as binary. Methodology selection dimensions discussed in this blog series can help organizations to evaluate critically, keeping in mind their long term strategic and tactical business objectives, culture, business environment against risks, complexity and ,constraints of individual projects. Thus, the methodology should be chosen to suit the project, rather than forcing projects to suit the methodology.