“We can’t solve problems by using the same kind of thinking we used when we created them.” – Albert Einstein
I love this quote because it’s a universal adage that applies to any situation where we find ourselves reviewing lessons learned and reflecting, sometimes in agony, at what could’ve gone better.
In my work, I’ve consistently witnessed clients buy into the theory of the Agile methodology but flounder to commit to Agile fundamentals during execution, usually because unfamiliarity with Agile is overwhelming when faced with the allure, comfort, and predictability of waterfall.
So when applying Einstein’s wisdom to recent lessons learned, one stood out prominently: how to truly attain commitment on what it means to execute Agile? This conflict is best highlighted during funding. Stakeholders want to know what they’re getting, by when, and for how much. It’s a fair ask.
But that discussion can turn problematic when commitments interfere with the essence of Agile, which promotes time-boxed, evolving requirements and development. Your goal with time-boxed requirements is to fix your schedule and cost, but keep scope variable. That way you have a reasonable idea (after all, these are still evolving requirements) of what you can achieve in that “box of time” to produce a great product.
You can bridge the traditional project funding model while staying true to Agile.
Convincing stakeholders (who are more comfortable with waterfall) to fund an Agile project is not unusual anymore. It’s the only way to push for more efficient, high-quality development practices. But to be successful, you have to learn to speak their language while telling your own story.
One effective way to convince stakeholders to back an Agile project is to choose a Minimum Viable Product (MVP) and commit to managing expectations throughout development. Here are three steps to get started:
Step 1: Identify a MVP. This provides the mandatory criteria for releasing and launching a product to users.
Step 2: Create epics. Epics are high-level user stories that serve as the guide for subsequent user stories.
Step 3: Estimate epics using a high Fibonacci series (e.g., 20, 40, 60, etc.). The Product Owner and team can then estimate delivery of the MVP, with a good idea of how many sprints that will take.
This process provides stakeholders with an initial product roadmap for project funding. But, in true Agile fashion, retrospectives and other Agile development staples promote dialogue so all parties can frequently evaluate the product roadmap and determine if it needs adjustment.
It may also help to imagine Agile funding in a home renovation metaphor.
As you prepare to work with stakeholders for funding, you might imagine the funding process in terms of something you may be more familiar with, like a home renovation.
Have you ever experienced a major remodel to your home? A homeowner goes in with basic “must haves” such as 4 bedrooms, 2 full baths, double vanity sinks, or even minimum square footage for the addition. They have a pretty good vision of what they want. This is the MVP.
The general contractor discusses with his crew and supplies the homeowner an estimate and timeline for completion. This is the product roadmap. The homeowner now has an estimate of how much the remodel will cost and how long it’s estimated to last. If they’re in agreement, the homeowner provides funding to the contractor to begin work.
Typically, during a remodel, funding is released in phases. As certain stages of the remodel are completed and inspections pass, additional funding is released to the general contractor to begin the next phase of work. This series of events can be similar during an Agile project.
As sprints are completed and demonstrated, the stakeholder’s approval releases funds for the next sprint. This encourages all parties to frequently communicate about what’s necessary to release the product. Most importantly, though, all parties become comfortable with the project timeline’s inherent flexibility because the cadence makes transparency between groups unavoidable.
Recognizing the funding obstacle now will set you up for success later.
No matter how you make sense of the funding transition between waterfall and Agile, it’s important to recognize that it’s a challenge worth overcoming.
Agile adoption and execution is quickly gaining speed, but not without its obstacles. Easing and facilitating the transition from waterfall to Agile by starting with an MVP and communicating expectations throughout the project will not only lessen resistance, but also lead to a happier team. Like a home renovation, transparency between parties means less “big problems” down the line.
“The secret to change is to focus all your energy, not on the fighting the old, but on building the new.” – Socrates