Agile-Waterfall Hybrid Program Execution
Summary
I supported the transition from a completely waterfall Integrated Master Schedule (IMS) into one that blended the strengths from Agile and Waterfall into a hybrid solution. Being completely new to this approach meant that our team had to devise processes (particularly with Earned Value and forecasting) to ensure the program schedule and cost were being tracked accurately. The entire program team (30+ employees) were introduced and tutored on the new process, and now it has been showcased as a potential standard for program execution division-wide.
New Program Execution Method
Typically, for a hardware-centric product development, a waterfall schedule is put together in the beginning of the program. This baselines the program and will execute to that schedule and plan. However, it can turn into a scenario where:
Cross-disciplined teams do not collaborate effectively across assignments
The IMS is not communicated and actions appear to spring out of nowhere
Lack of transparency to team on tasks, goals, and expectations
Lack of flexibility in schedule
Agile helps to bridge and address a lot of these weaknesses a waterfall schedule brings. Agile allows a team or program to divide the work into discrete large tasks and the team devises a plan to meet that task on time and on schedule. This allows the team to own their work and set goal-oriented incremental tasks to get to the overall solution.
The issue arises when a program is tasked per Department of Defense standards, to enforce a strict Earned Value Management System (EVMS) to claim work performed vs. solution. This allows program managers to adequately forecast the remainder of the program based on the work performed. This is where Agile is difficult in terms of claiming work complete.
Therefore, the program leadership team devised a hybrid solution where the program is broken up into a set length of time (increments) where large tasks (dictated by the program managers) had to be completed. Within the set increment, the team was able to use Agile techniques and its flexibility to create smaller tasks to get to a point where the large task can be completed by the increment end date. This team taught this approach to the rest of the program, and also came up with specialized processes to address the following:
How to claim work is performed and complete
How to address when the baseline needs to change
How to forecast with story points linked to program dollars
A simple diagram of waterfall, agile, and hybrid is shown below:
Conclusion
This process, while appearing to be simple in the synopsis above, was actually difficult to devise, communicate and enforce onto the team. There were growing pains, and lessons learned along the way. After a few increments, this process and approach has been documented, and is being communicated to other programs in the division as an option to run a program.