CTS – Your Technology Partner

Top 5 Reasons the Agile Hybrid Method Works

Written by Jeff Lether on June 1, 2015

1. Waterfall method is risky when your requirements are not static.

The waterfall method of managing IT projects assumes you get all the requirements complete and correct up front, and that requirements don’t change. It also assumes that what you built at the beginning of the project is still correct at the end of the project. Since business users don’t typically participate in project implementation, you don’t really find out if it’s right until the end; when all of the time and money are gone. If there are any gaps, you cannot recover without going over-budget and over-schedule. Besides that, users frequently don’t truly know what they want until they see it.

2. Waterfall method does not handle substantial change well.

Waterfall projects respond to requirements shifting over the course of the project with formal change control. This process typically involves contract amendments, requirements documentation updates, and, potentially, rework of already-developed components. For smaller changes, the process for change control can often be more work than implementing the change itself. For a series of smaller changes, this can lead to death by paper cut.

3. Your CFO hates pure Agile.

Agile development addresses “requirements drift” and “business user confirmation” with smaller, iterative deliveries that involve user acceptance every few weeks. Agile manages scope as a set of smaller functional items in a product backlog, so it is more efficient to make requirements changes and substitutions. However, since Agile does not perform up-front project planning activities, it’s difficult to plan the budget and schedule for an Agile project. Developers love the flexibility and responsiveness of Agile development but for finance executives, it’s more difficult. For them, how long it takes and how much it costs are the two questions that matter most. Agile does not answer either one of these questions until considerable time and money have already been spent.

4. Your Data Center Manager hates pure Agile too.

Another part of Agile development that developers love is the ability to ship the product at any time the team decides the right subset of functionality is now implemented. Production rollout can occur before everything is technically “finished.” This is great for development teams, but a nightmare for Data Center Managers. They are tasked with making sure new software deployments do not introduce problems into existing ones. To do their jobs, they perform a variety of testing on new software deployments to ensure seamless interoperation with existing applications; things like security/penetration testing, load/performance testing, user acceptance regression testing, interoperability testing with other data center applications, and so on. Not to mention, Data Center Managers also need to plan for system backups, server and platform support, patching and maintenance, and network and firewall configuration needed by a solution. To top it all off, they need detailed installation plans and a rollback plan in case the deployment has unintended serious consequences. It all adds up to something that doesn’t fit very well into a “we can ship any day” mentality, and gives Data Center managers fits.

5.  Your business users get worn out by pure Agile.

Initially, the idea that they are more likely to get software that matches their needs and expectations is exciting and motivating to business users. They enthusiastically embrace the role of Product Owner and dutifully participate in project implementation with the development team. Then after a while, the amount of time needed for involvement in pure Agile development becomes difficult to maintain, since they still have their old jobs too. They begin drifting away, stop attending and participating, and lose much of the value from the iterative Agile approach. What began with your business being energized about a new way of working together ends with them avoiding you due to unsustainable demands on their time.

Hybrid Agile

The Agile Hybrid method avoids the challenges that are introduced by the endpoints of Waterfall and pure Agile. This method bookends planning activities and formal acceptance around iterative delivery using Agile sprints.  The planning activities in Hybrid Agile are lighter-weight than Waterfall, because you can finish more detailed design during planning for the individual sprints. The planning activities therefore   do not produce requirements that are too rigid to effectively respond to change during the project. And, since you did perform the high-level planning up-front, the demands on your business user time during implementation are reduced, avoiding fatigue and burnout. Additionally, the up-front planning allows you to deliver credible cost and schedule estimates to executives. Having a formal acceptance period allows business users to verify overall solution correctness with a regression test of the finished system. Finally, because you are performing formal acceptance, Data Center managers don’t face unexpected deployments that aren’t compatible with business continuity policy, but instead have adequate time to perform robust deployment activities.