As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall. These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.
We often have some outliers, mostly modern businesses without legacy overloads and whose core business is digital or relies heavily on digital who may have cracked the agility question.
Waterfall is seen by most agile advocates as a relic of a time that had been and that should be forgotten and buried.
Waterfall is expensive, time consuming and unforgiving of errors.
Figure 1 The Unmodified Waterfall Model (Source: Peter Kemp / Paul Smith)
Design thinking, on the other hand may be equally as expensive especially for organizations with legacy burdens switching over to an agile way of work, has picking up errors early built right into its DNA and offers opportunities to succeed quickly or fail fast.
Figure 2 A conceptual view of Design Thinking (source: Interaction-Design.org)
A variation of the plan-do-check management methodology – the decision is easy to reach if one strips down the elements of the methodology into its bare bones fundamentals –design thinking allows the business or the delivery team to involve the customer for whom a product or service is being designed early on in the delivery effort. Design thinking offers up an opportunity to build a product truly needed by the customer and not one that was assumed the customer needs.
The question one ponders then is whether an enterprise or delivery team can only be one or the other? Or be both?
An important point of departure is that agility is a mindset, a mindset written into an organisations’ DNA and not only those of its project delivery teams. Agility does not rest solely on the tools and techniques that an organisation or its teams chooses to work with, rather it relies heavily on the collective agreement between teams and individuals; the capacity to work quickly, to experiment all the time, to learn fast and to be honest with itself all the time.
That said, with an agile mindset, design thinking techniques can be applied within each phase of the waterfall methodology.
For example, in the requirements phase of a waterfall project, the elements of design thinking’s empathise, define and ideate can readily be adopted. A bold team may and should also prototype and test their assumptions and some of the features of their product/service with real customers. Done well, the requirements phase of a waterfall project doesn’t then just end with a signed off requirements specification, but also the knowledge of what the customer truly wants backed with empirical data. And potentially the design and implementation phases have a ton of knowledge of the market to go on with – in essence most of the work in these phases of waterfall delivery would have been completed during the define stage as done as described above.
|
Waterfall Phase
|
Design Thinking Steps
|
|
Requirements – identify and document in acceptable language all the features that a new product/service or an existing product/service now requires to meet business’ objectives
|
Empathise – ask and find out what the customer truly needs.
|
|
Define – agree the customers’ needs with the customers and determine the subset of these that your business or project that is most strategic for the project to delivery
|
|
Ideate – work with actual customers to explore pain points, fixes for theses, and boundaries for these fixes.
May help clarify the true needs of the customer and help separate these from their wants.
|
|
Prototype – create illustrations which can vary between drawings on paper and an interactive mock-up of the product or service
|
|
Test – observe the customers interact with the prototype. Question all assumptions and discard all that are determined to hold no relevance for the
|
Figure 3 A conceptual mapping of waterfall ‘requirements’ phase with steps in design thinking
The actual waterfall phases of design and implementation then just becomes opportunities for refinements of the work done in the requirement phase using design thinking, and for honoring the legacy requirements of phase gates.
|
Waterfall Phase
|
Design Thinking Steps
|
|
Design – identify and document in acceptable language all the features that a new product/service or an existing product/service now requires to meet business’ objectives
|
Empathize – understand customer pain points and overall objectives to delight
|
|
Define – design approaches to take in helping meet the known customer needs
|
|
Ideate – play with multiple ideas of the solution(s)
|
|
Prototype – select with some of the users some of the design ideas that may work
|
|
Test – test the ideas prototyped with actual customers to determine which to concretise and implement
|
Figure 4 A conceptual mapping of waterfall ‘design’ phase with steps in design thinking
The refinement efforts in each of the design and implementation phases could also leverage design thinking. For example, the design phase of waterfall could leverage prototyping and test multiple user experience approaches – building on the work started during requirements. And in the implementation phase will build based on the output from the design phase which has determined with a high degree of accuracy what the customer truly wants.
The test phase of the waterfall delivery effort, may end up being systems’ tests (regression and systems integration tests) and confirmatory usability tests – as actual usability tests would have been completed upfront during requirements and design phases where the team had brought in the real customers to empathise with, define and ideate with, prototype for and tested with.
One can then safely conclude that waterfall can co-exist with design thinking (and really most other agile techniques) if the organisation’s mindset focused on agility and not processes for the sake of processes.
Author: Oluwakorede Asuni
Olu, as he is fondly called by friends and colleagues, leads the business analysis efforts for the mobile financial services business for MTN South Africa. He holds the IIBA CBAP and the PMI PMP credentials. Olu, has had several years of experience helping new and established businesses leverage digital technologies. His research interest spans innovation and society, ethical leadership, new business models for mobile network operators and gamification. He is a volunteer board member of the International Institute of Business Analysis (IIBA) South Africa chapter- since 2018.