Note: This article has been published by:
- the IIBA – https://www.iiba.org/business-analysis-blogs/design-thinking-in-a-waterfall-world/
- Modern Analyst – https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5617/Design-Thinking-in-a-Waterfall-World.aspx
- BA Times – https://www.batimes.com/articles/design-thinking-in-a-waterfall-world/
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.
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.
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.
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.
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 empathize 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.
