Agile, Waterfall, or Hybrid? If you happen to browse job ads and positions nowadays, you will come to realize that the most if not all companies use Agile development methodology. I have always wondered why make it such a prominent factor in the job requirements. It’s just a methodology and it's not like learning a new language. I’m not disputing the benefits of using Agile development but wondering if companies have become slave to a methodology. Agile development lets you build and see products coming to life gradually, instead of working heads down for months fearful that you may not ever see the finished product. It’s also easier with Agile development to take detours, make corrections, ask for feedback, adjust your aim along the way. But some companies still use the Waterfall methodology, and there are good reasons why Waterfall may still make sense today. Most common scenario: a program manager needs to provide and commit to a delivery date for a new product because the CFO, Marketing, or customers, need it to budget expenses, plan the launch, or fund the deployment. For a product or a new major release, how would the PM go by estimating a delivery date of something that is going to take 9, 12 months or longer, by executing the project in 2-week sprints and milestones? If they did commit, they would be just providing an informed guess with no plans to support it, and with a high risk of delivering something different than they had committed to. The Waterfall methodology has been used for years for this reason and forced the program managers to think through at the outset about product design, architecture, frameworks, resources, critical paths, and so forth. These are issues that one cannot think through one sprint at a time and then hope that it will all come together. But there is Waterfall and, what I call, Hybrid Waterfall. The Hybrid Waterfall is what I have used in these exact situations when confronted with a new product, or a major new release that replaced an existing architecture. Under the hybrid methodology, you spend the time to address the architectural issues, scalability, security, and design up front, as if you were under Waterfall. Once you have agreed on the design, architecture, and resources, you create a plan with milestones, and execute using an Agile process to make that product come to life gradually. You can still take corrective actions using this process, involving the customers for feedback along the way, and the risk of missing your deadline is significantly reduced.
When I first started using the hybrid methodology, it was more of a necessity and common sense to do it that way. I needed to have the entire team on the same page first, and because we were in uncharted territory, we proceeded through the implementation phase one small milestone at a time. It worked beautifully, and I still resort to the hybrid methodology occasionally. There are two scenarios when I would recommend Agile development:
So, I would expect most companies to use both methodologies for the above reasons. Comments are closed.
|
Categories
All
Archives
January 2019
|