What Does the Business Want?

To some, asking the question what the business wants may be a nebulous thing. However, in more than 24 years of consulting and managing more than 50 programs/projects, I have come to the realization that the business wants the following when implementing projects:

1. What they are going to get - what requirements are going to be met, what features the solution provides, and will it meet their needs.
2. When are they going to get it - the business wants commitment to a schedule, along with when features are ready.
3. High quality – they want to have high quality software that is error free.
4. Excellent User Experience – in today’s world this is not a desire, this is a ‘must’. Software applications must be intuitive, logical, and allow the user to perform their job functions in a manner that is easy. Providing a poor user experience will result in poor user adoption and disgruntled employees.
5. To be engaged throughout the project lifecycle – gone are the days when users were engaged in design, and then left until it was time for User Acceptance Testing. Today the business wants to be engaged throughout the lifecycle to help ensure that the system truly meets their needs. They want to be integrated with the project team and interact on a regular basis.
6. How much is it going to cost – businesses are always trying to optimize what they can get for their money and need to plan projects according to a prioritized list of objectives. Project overruns can wreak havoc on planned budgets and can cause emergency planning sessions to reprioritize other projects that had been scheduled.

How Does Waterfall and Agile Meet These Needs?

The issue with Waterfall model and Agile model is that both only meet some of the needs. The below table provides a quick glimpse into where each of these two methodologies meet the needs and where they fall short.

Both Waterfall and Agile models fall short. For enterprises, Hybrid Agile can be the answer.

As you can see from the above table, each methodology has its advantages and disadvantages. Waterfall model has a set schedule and can tell the business what it will get when and how much it will cost. However, pure Agile cannot provide that due to the nature of being agile and continually adding, modifying, and re-prioritizing the backlog list. Therefore, the business cannot be sure when certain functionality will be delivered based on pure Agile if that functionality is not in the current sprint.

For change management, it is much easier to change from the Waterfall to a hybrid model, as the planning is intact.

In a traditional waterfall, users are typically engaged through requirement collection and design, and then leave and come back just in time for UAT. This means that a lot of time is lost where the users could be providing input on the design of the system as it is being built. There is nothing more disheartening than running a Waterfall project, and when the users come back for UAT, they see the system for the first time and say ‘this is not at all what we wanted’. There is too much risk associated with not keeping the users engaged throughout the project. Keeping users engaged is one of the main benefits of Agile. It helps to minimize risk and ensures that the system is designed to meet the user needs.

From a cost estimate perspective, the typical waterfall project does a better job of being able to estimate what the cost will be as the scope is defined and the schedule is set. In a pure Agile project, the team is learning as they go, adding new items to the backlog, and re-prioritizing at the end of each sprint. Most often a circle is used when describing Agile. These circles typically include at least 3 phases (Design, Develop, and Test), and sometimes more. The problem with circles is that there is no end point. This can also be true with pure agile. As long as there are items in the backlog, the project can go on. So theoretically the project can go on forever.

Lastly, with the right QA processes in place, either Waterfall or Agile can be used to help ensure a quality product is developed. With Agile you are more likely to find errors earlier in the process than the traditional Waterfall method.

Hybrid Agile – Best of Both Worlds

So, what if we can get the security associated with Waterfall (scheduling, cost, scope) and the benefits of Agile (user engagement, enhanced customer experience, reduced overhead on documentation)? The answer to this is Hybrid Agile. In Hybrid Agile the planning is done up front during a Discover Phase, which provides the business the answers to the questions of ‘what am I getting, and when am I getting it’. In other words, the scope is defined at a high level, the schedule of what is included in each sprint is set, and the high level design is completed. When using a packaged solution such as SAP’s Customer Experience suite, the system is also set up during this period. Having the system set up allows the project team to move right into the Sprint Phase.

During the Sprint Phase, the functionality is developed/configured based on the project schedule. Using a Hybrid Agile methodology allows us to plan for items that may take longer than a sprint to complete, yet we can work on them according to a schedule. Some examples may be complex interfaces or some custom programs. We can plan and let the business know that those items will be in Sprint 2 but will start work in Sprint 1.

Like the Agile methodology, the users are kept engaged throughout the project. During the Sprint phase they get to see the system and can at times interact with it. Through this they can provide feedback which is used to improve the User Experience. Typically, in the sprint phase, the business team members start talking with their peers about how great the new system will be. This goes a long way toward increasing User Adoption. A part of each sprint includes testing and verifying the changes that have been made. This, along with the Integration and UAT testing helps to ensure a Quality Solution. In an Agile manner, as the design continues to evolve through sprints and testing, the design documentation goes through the typical sign-off process at the end of the project. This provides the team the flexibility to update as changes are made without a Change Request that is needed in most Waterfall type projects. Lastly, during the Implement phase we gather additional feedback as we progress through UAT, and typically gain additional user buy-in, as well as train additional users. Once UAT is complete, we go-live with the application using a big-bang approach. The legacy system is retired, and the users begin using the new system in production mode.

As you can see by the below chart, a Hybrid Agile Methodology fulfills all the business needs.

Wrapping it up

While there is a time and a place for everything, one could argue that if you are thinking of using a Waterfall method you can get the same benefit of scope, schedule and budget from a Hybrid Agile type project. From a pure Agile perspective, you can get the benefits of user engagement, modifying scope (to a degree) as you learn new things, and less overhead from heavy design documentation with reviews. In addition to this, the business gets what they want – to know what they are going to get, when they are going to get it, how much will it cost, and to stay engaged to ensure a solution with a good user experience.

Lastly, from an organizational change management, it is much easier to move an organization from waterfall to a hybrid model, as the planning/scheduling is still in place, including the testing phase. The main change is during the development phase. When I use Hybrid Agile, I also incorporate the use of Daily Stand Up meetings to facilitate communications and to help ensure the issues are addressed early.