We often hear the ongoing debate of Agile versus Waterfall. And while Agile often wins, not every project or company has the product-based model that best fits its method.
What we don’t hear about is the conflict between business and development teams over which method fits their objectives and constraints. Adhering to a fixed budget while working towards shifting goals creates legitimate problems that neither Agile nor Waterfall can fully solve.
Tasked with the incompatible goal of making things people want (product/market fit) on a fixed budget, Fresh Consulting began developing our own practices. Mixing Agile and Waterfall-esque methods, we created design-led development.
Where Waterfall Fails
Waterfall tends to attract executives and senior managers with its lure of delivery on time and on budget and full product/market fit.
In actuality, Waterfall-driven projects are known for being off target, late, and over budget. When poor choices are made early in the Waterfall process, they steer development in the wrong direction, causing expensive and lengthy fixes.
How Agile Adds Up
Agile is not one single method but a collection of practices and principles with iteration at the heart of development. Agile’s value proposition is a little more enlightened than Waterfall’s: it acknowledges that we know our plans will be wrong initially, but through the process will ultimately succeed.
Under the Agile method, process ultimately lags a little bit behind the market. This is because Agile safely responds to the market. A form of vision-driven development would anticipate and build slightly ahead of market needs and hopefully have the market get excited about it rather than the other way around; something that Steve Jobs mastered.
Budget is where Agile gets complicated. It has often been argued that Agile is designed more towards in-house development rather than agency/contract work, and we tend to agree. Getting internal approval on a fixed budget project is difficult; getting approval on a hugely contingent budget can be nearly impossible.
Where Both Agile and Waterfall Fail
During a development project we expect that user requirements will evolve, frameworks get updated, competitors emerge, and, of course, the dreaded “pivot” occurs where everything gets turned upside down at once.
Waterfall is designed to deliver on initial functional requirements, but sometimes those requirements evolve following industry or scope changes. Meanwhile Agile can valiantly go beyond the initial requirements with the same budget, but still requires additional work to achieve the fabled product/market fit.
With in-house projects, this isn’t such a big deal as the product is already delivering on 80%+ of its value promise. There is a designated team in place and the company will continue to invest and work towards a dominant market position.
Agencies following the same method, however, have agreed to a budget and must either complete the project at their own expense or renegotiate with a possibly disgruntled executive. On the one hand, the executive is constrained by needing to adhere to operational budgets and stay competitive. On the other hand, agencies need to present appearingly-competitive costs, knowing a fixed budget has a high probability of causing conflict later. This is where we at Fresh Consulting found ourselves, and why we decided to do things differently–to do things Fresh.
The Fresh Method
At Fresh we embrace an iterative and flexible approach of design-led development, but we also include a plan-driven aspect to gain efficiency and clarity for delivery and budget effectiveness. It ends up being a combination of Agile and Waterfall approaches with three phases:
Phase 1: UX Design with Discovery & Quick Iterations Upfront (Waterfallish/Agile)
During this initial stage, we paint the vision of where we are going; getting feedback at the design level from users and stakeholders through several iterations and quick prototypes. We’re building, testing, and correcting “on paper,” not in the code where every change can have a ripple effect, and that makes a huge difference to overall cost.
We first redefine what product/market fit looks like by focusing on a smaller set of functional requirements essential to the core UX. Then we reduce the growth rate of additional feature requirements via a deeper understanding of iterations, adding flexibility in our plans.
At Fresh, this is a fixed-budget initial design project with users at center stage. For example, 1) user research, 2) personas for user empathy, 3) user stories, 4) story maps, and 5) user testing are often included in the process. This helps us address the 3 elements of the Agile Manifesto early on… without touching code.
Phase 2: First Phase MVP or MQP Development (Agile/Waterfallish)
We often approach this phase hourly so that we can be flexible; however, we still use estimates from the upfront design work and architecture planning to remain accountable to budgets and indicate how changes (that will come) alter some of the upfront timing and costs. We also budget time for changes and iterations to accompany our estimations. This side of our process is more Agile-like but does contain planning elements…
We either focus on a minimum viable product or a minimum quality product that would make customers or stakeholders pleased, but not overwhelmed, all while understanding the development will go in phases.
By designing with iterations and using smaller targets with more knowledge and awareness for a changing scope, we can hit product/market fit earlier and more consistently.
Phase 3: Ongoing Design & Development Work (Agile)
Once a project is complete we continue to iterate with design and development. In order to maintain product/market fit, we rely on a combination of user testing, analytics, and customer feedback. Analytics done well can flag potential issues, but insight and great design, in our experience, come from empathizing with and understanding the user not only in the upfront UX design phase, but also in the ongoing release cycles. This last step is pure Agile as we are in a continuous, feedback-driven development mode, constantly prioritizing changes into new sprints.
Why Design-led Development Works
Good design requires substantial empathy with users and stakeholders, and early iterations help in the discovery process as you work towards a shared vision. Design-led agencies that give good ideas form and function for early customer validation can become more of a consultative partner rather than a vendor because they are more readily bought into the project intellectually and emotionally.
Regardless of the size of your project, design-led development is a strong way to build a product that is closer to budget and on course for continuing product/market fit.
