Celebrating the “GO LIVE” of a major waterfall program may motivate your team to overlook the risks of a large program and commit to an even larger program in the future. A large Gantt chart is developed, possibly even printed out on large format paper and posted on the wall. Features are executed in parallel: requirements in parallel, detail design in parallel, and eventually, integration testing/stabilization also occurs in parallel.
Each functional silo is heavily taxed while it's their turn with the baton, and then they go mostly into waiting mode while other functions do their work. Definition of requirements can chew up multiple weeks – sometimes months. Architecture also adds similar lead times. Then estimating and final project approval. Each phase of the phase-gate process tends to overload the silo who is mostly responsible, creating a wave of “mura,” a Japanese term that means the waste of uneven workload throughout an organization.
The single pass through the Planning, Development, and Release process eliminates feedback that enables learning. Finally, the organization gets close to the release date, and the realization of risks and “wishful thinking” results in a large “kaboom” -- you justify the remaining bugs, extend the calendar, or in my worst experience throw the entire effort out the window. All of these downstream impacts of wishful thinking cause some of us to question the system, and we realize that there must be a better way.
I will claim that everyone who has been in this industry for 10 years or more has had this experience. In fact, many high-level Software Executives have been fired when the missed release results in significant business impact.
In the Scrum Guide, one of the rules is that every team must release a working product every Sprint, and a Sprint needs to be 30 days or less. Most frequently, in practice, a Sprint is two weeks. This rule enforces exercising of the define, prioritize, design, develop, test, integrate, deploy, and release of some functionality in a short timebox.
How does a team accomplish this? With Agile Planning.
An Agile planning process offers a solution to the problem -- incremental delivery of value. Instead of planning and attempting a large delivery, Agile Planning splits a large delivery into small valuable increments and deploys for customer feedback in every increment. This enables adjustments to the plan and allows all the people to deliver the most valuable work at every two-week checkpoint.
To enable incremental delivery, you must learn the industry-recognized patterns of “splitting” or “slicing” large programs into incremental deliverables. I recommend splitting the large program into separate workflows, workflow steps, happy paths, and secondary paths. Each one of those splits has value and can be implemented sequentially, continuously delivering value along the way.
I can offer several case studies that highlight the value of Agile planning processes and incremental delivery.
Today’s largest insurance industry claims processor and partner with all major insurance providers in the US started less than 20 years ago. At the time, across the industry, 60% of claims required manual adjudication. Their value hypothesis statement was “if we can process automatically 90%+ of claims, then we can dominate the insurance industry.” They tested this hypothesis in one small geographic area, with a small set of providers, and focused on a small but representative set of types of medical claims.
After their test, they built an “intelligent” processing engine that proved to be 98% effective at not requiring manual adjudication after hundreds of claims processed. Once they proved their business hypothesis statement, they attracted more funding and expanded incrementally into more geographies, provider networks, and claims codes until they have become the industry-leading claims processor in the country.
A large financial services company had legacy mainframe technology supporting their Order Management System to place “trades” on the NYSE and other exchanges. They recognized it as expensive, not very scalable, and single-vendor dependent. A large program to replicate its features was invested in across multiple years and dozens of senior technologists. As it approached go live, the commit date was pushed out multiple quarters. Eventually, they decided it would never be stable enough to go live and mothballed the effort, which meant finance entered a very large write-off on the books.
Then they began Agile planning. The revised Key Performance Indicator (KPI) became a few production transactions, replacing features, functionality, and replacing mainframe MIPs. Initially, the production transactions were only Buy orders, at the market, a single security, and only one or two transactions per day. These production transactions enabled compliance audits, availability, reliability, stability, and performance audits. The roadmap was changed from feature-centric to address the findings from production experience. Eliassen was brought in to coach these teams, and the initial KPI was met early on and expanded to 500 production transactions per day in a 3-month coaching engagement.
A Fortune 500 Pharmaceutical firm invested in Digital Transformation and entered an evaluation of an industry-leading Lab SaaS application. After six months of false starts and the requisite number of fired project managers, they “pivoted” using principles of Agile Planning.
They divided the large evaluation effort into milestones of “Scientist workflows” and further divided those into small valuable “stories,” in some cases workflow steps, and in other cases exploration or enabler work. After the Go Decision, the implementation phase leveraged the incremental workflow approach. The most popular “out of the box” workflows were planned for implementation first, while those requiring greater integration to other systems were deliberately deferred on the roadmap with the principle of highest value, incremental delivery. Scientists were thrilled to experience lab notebook workflow in Production on the new system just weeks after the implementation phase began. The Scientists realize they have free rein to adjust the plan to implement going forward.
This pattern is the Agile planning process; the KPI is production functionality early, informing the remainder of the plan for adding additional functionality and outcomes on an incremental basis. My primary advice is for people to learn and become comfortable splitting large programs into features, features into stories, and large stories into smaller stories. Prioritize those and celebrate as you deliver incrementally. As you can see from the above case studies, the agile planning process eliminates risk, enables you to pivot or persevere, and delivers business outcomes.