Agile + Waterfall = Hybrid Method; when does it have the right application?


Hybrid Methodology

Recently, I was in doing feasibility and due diligence of a Technology Refresh project. This project would involve rewriting a suite of applications, that are running both in command line batch mode and desktop mode. Driven by the idea of long-term technology risk aversion, better maintenance and support, availability of skills; these applications would involve rewrite from legacy technology to latest Microsoft Framework. This technology refresh, or precisely upgrade would involve no new feature development or existing feature enhancements.

One obvious question that came during this feasibility was – ‘Should this project be executed in Agile Scrum methodology?’. In this post I am going to share my observations and rationale to decision made in answering this question. In my view, the selection of project execution method should not be based on emotion, trend and influences from project stakeholders. In this case also there were a section of people, both from customer and management; who were strongly in favor of following Agile Scrum method of project execution. At the same time there were some people who were in favor of following Waterfall approach.

Let me share some more project insights that would help in making appropriate decision to select right execution methodology –

  1. Customer Adapting to Agile: Customer organization have IT and software development divisions, who are responsible to maintain existing and develop new applications required for business continuity. Organization started moving to adapt Agile methods. There are some projects already running following Scrum method, and slowly more teams are getting engaged and trained to Agile scrums. There is shift and demand to follow Agile from management, as they see benefits to agility in terms of visibility and transparency.
  2. Fixed and Known Requirements: As mentioned above, it is a technology refresh, with no new feature development or enhancements; simply to upgrade retaining the applications feature as-is. However, there are some obsolete and redundant functionality that would need to be trimmed down from the to-be system. Which concludes that the project’s requirements are known and fixed.
  3. Fixed Time and Fixed Budget: The overall efforts required to upgrade the applications could be estimated precisely with greater confidence. The project time and cost would be fixed and accordingly the decision on project budget and time required to involve business users could be predicted with greater accuracy.
  4. Business User Engagement To Inspection: Being existing applications and no new features, business team who are the actual end-users of the applications; will get involved in acceptance testing only when the application is developed completely to test and provide signoffs for production deployment.
  5. Technology & Architecture Complexity: The legacy applications are client-server based architecture. To-be applications are expected to operate in same capacity with moderate degree of scalability. The to-be technology, application architecture and design are not expected to be complex.

Considering Factors To Decide Execution Methodology

Knowing the increasing demand for Agile Scrum method, inherent natures of both execution approach and given project scenario; we can take decision appropriately. I took the listed project insights to next level to validate them in terms of their positive and negative influences on both approaches. Below are some of my findings –

Key factors that favors to adapting Agile Scrum –

  1. Swim with wave, customer has at least basic level of understanding and plan to move to Agile Scrum method of project execution. Further agility would feed-in with more practice and participation.
  2. Following Agile Scrum approach would help is better project visibility, transparency and control for customer.
  3. There would be more opportunities to frequent inspection, reviews and course correction.
  4. It will help to control cost, risk aversion, and prioritized delivery of applications.
  5. By prioritizing the features and removing obsolete features; would help to mange the scope better, and include new feature if needed.

Key factors that favors adapting Waterfall Approach –

  1. Fixed scope and known requirements – so better predictability and scope management. Both parties know what is being developed and will be delivered when project completes.
  2. With no new features and enhancements, it as is technology refresh. Just lift and shift to latest technology with no changes to functionalities.
  3. Waterfall methods need less or not continuous inputs from business team, which means low business involvement during the project life. Having known requirements, business would involve only during acceptance testing and signoffs.
  4. End deliverables remain same on project completion – same business process achieved through same set of applications. Business process is averse to technology, process value-stream and end results are going to remain same in both as-is and to-be applications.
  5. Induct Quality Analysts only when project enters to testing phase, instead of from the beginning of the project. This would help in cost reduction, but the quality still can be maintained with appropriate test executions.

Some key factors that strongly negates the Agile Scrum method:

  1. There is likelihood to falling trap to scrum-falls & practicing non-value adding Agile practices – which are avoided if waterfall approach selected.
  2. The mandate of iterative and incremental development and testing required in all iterations does not add much value here. The iteration-end working software can be only tested but can not be deployed in production; because business can not function until the complete working software with all required features are is deployed in production.
  3. More of less these applications are required for business continuity, are stable and less prone to evolve or change. Which means adding money and time to implement automation for unit test, integration & build; would not have significant return on investment; specially when rolled-out to production.

Then, which execution approach and how to select?

It’s obvious now, with all these explanation we are clear – why we should not use the Hybrid approach – taking best and suitable out of both methods. So we have Hybrid Methodology, combining practices that works best in given scenario; specific to the project requirements and given context. Some strictness and rigidity adapted in waterfall need to be renounced and replaced to augment the flexibility and agility. It’s not necessary that whatever the Hybrid Method and practices that has been recommended in this case; would be necessarily applicable to all scenario – be selective in deciding your Hybrid Methodology.

Selected Hybrid Approach

Some factors that would bring agility in this scenario –

  1. Improve the project governance model and project structure team appropriately. Team structure and size can vary in different project phases.
  2. Increase the project visibility through frequent checkpoints and progress reporting (weekly), joint reviews (bi-weekly/monthly) and senior management reviews (monthly/quarterly) etc.
  3. Adapting Agile practices like daily standup, retrospective, frequent inspection, course correction and some degree of automation (like integration / build) as required.
  4. More & frequent customer IT (development and/or operations) teams involvement in review, testing & feedbacks.
  5. Prioritize and group applications to plan releases as per business groups preference, availability etc.
  6. Observe diluted phase-gates by having opportunity to correction (even after phase completion/signoffs). Multiple testing phases for customer IT and Business users team as planned for applications.

Conclusion

With the increased adaption to Agile methods, it does not mean that Waterfall method do not work good and not necessarily every projects should be executed in Agile Methods. By being innovative and selective to execution approach before taking the final call as per project under consideration; still Waterfall and Hybrid Approach makes a wise option in terms of cost effectiveness and team efficiency; resulting to overall benefit to both customer and service organizations.

7 thoughts on “Agile + Waterfall = Hybrid Method; when does it have the right application?

  1. How is this a good reason to user Waterfall:
    “Induct Quality Analysts only when project enters to testing phase”

    Quality should be built in from the start, not an afterthought. I don’t find this as a good reason to use Waterfall.

    Like

    1. Hi Joshua,
      I agree with you having QA, i.e Testers from beginning of project is good for achieving quality output. But this point was made, considering the project circumstances such as – fixed budget, phased execution etc. Also there is existing legacy application which developer can reference any time but the comparative testing can be done only when features are completed. During the beginning of the project QA would not have much work or add value unless certain features are completed for system integration testing. I have highlighted the reason for making this statement in subsequent statement – ‘This would help in cost reduction, but the quality still can be maintained with appropriate test executions.’

      Like

  2. I’d want to be taking a step back here and asking: “what’s the value of this to the organisation?”

    I’d also want to debate your assertion that this rewrite will produce an “as-is” product, given that there are “redundant” features that will be slimmed down. This is a brand new product, and as such I’d be encouraging frequent testing throughout the development phase, automated testing (run against both products so that you can demonstrate they work the same way) and constant user interaction.

    While I absolutely agree that some projects are better suited to a Waterfall approach than others (construction, for example), I can think of few genuine cases where it applies to software development, simply because the cost of change on a software development project is so comparatively low.

    Like

    1. Hi Brian, many thanks for your feedback.
      Do you think that knowing value of organisation would really have great impact on making decision on selecting project’s execution methodology?
      By redundant features, I mean; features that were developed and being used long back are no more required now as they are not being used due to changes in business scenario. Only such features need to be trimmed down.
      For business, it’s not the brand new product; because for business users; technology selection or technology upgrade does not make any operational difference; applications features are still same whether it’s legacy or modern technology.
      Definitely, frequent testing is good throughout the development; but in given scenario can’t we delay inducting quality analysts until features are implemented to an extent? We have developers, business analyst in project who are equally responsible to quality of deliverables. And also the existing applications are available for comparative testing; do we really require specialists for testing from day one of project? Waterfall method was and still being used for software development; there many success stories. Agile software development proven good, but all project scenario are not best suited to agile; project like this still can be done in efficient manner without completely using agile framework.

      Like

  3. Hi Vikash, I enjoyed reading your post.
    Based on the context you have described, I would still advocate an Agile approach. The reason for this is that the reasons you have given for doing Waterfall don’t seem to me to be worse with Agile, whereas vice versa is not the case.

    For example: “Fixed scope and known requirements – so better predictability and scope management. Both parties know what is being developed and will be delivered when project completes.” An Agile approach works whether scope is fixed or not and whether requirements are known or not. An Agile approach works anyway. On top of this, an Agile approach would devolve the “how” to the team. So the people actually doing the development work would figure out the best way to implement the requirements. This is an important principle if you want to make sure quality is built in.

    Fast feedback on progress is important for everyone involved, increases engagement and therefore gets better results.

    For me, the days of Waterfall are over, regardless, because the people side of Agile is an important dimension for a happy and healthy team to produce quality products.

    Like

    1. Thanks Haran for detailed feedback and recommendation. The hybrid method suggested in the post do not mention that two methodologies have been attached together to come out with new method. In the post, practices from both Waterfall and Agile have been picked to suite project specific scenario. Any project methodologies are not rigid and do not suggest that they can’t be modified to project specific requirements.
      I agree on the point that Agile method works for fixed scope and known requirements. But this does not mean Waterfall approach do not work for given scenario; rather in my view it would work better. In this project, for both – waterfall and agile approaches; team can still leverage the learnings from one application to find better way to implement the next application; as project has suite of applications to upgrade in new technology. Also, fast feedback from business users after every iteration would not be available in this project as business team would involve in final acceptance testing only when complete application is given with all as-is features.
      I don’t think the days for waterfall is over yet; entire industry has not transitioned to Agile. Shortcoming and pain observed in waterfall given birth to Agile, similarity Agile given birth to DevOps. That does not mean the old methodology were completely wrong. They were good and are still good for given situation and scenario; its we who have to apply the best as per project requirement.

      Like

Leave a reply to Vikash Karuna Cancel reply