Slowly but surely, Design Thinking is following Agile and Scrum in a number of poor “implementations.” Initially conceived as a mindset that should help understand the end customer better, it has become a tool for “product” companies to generate requirements for software development vendors, without talking to developers or getting actual feedback from the customer.
It is quite alarming how numerous companies jump onto a “shiny new tool” bandwagon without thinking about the conditions and prerequisites for adopting it within an organization. Usually, management sees the tool as a solution, neglecting the underlying philosophy and mindset that is required to use it properly.
When talking about technical solutions, obvious examples include blockchain and AI. In the domain of organizational improvements, the clear winner is Agile. But in its shadow, a new contender has gained real momentum - Design Thinking.
Dropping out of the “implementation” phase
Although people have significantly misused most software development and product management techniques that have emerged over the past 20-30 years, Design Thinking stands out as the only one that truly covers the end-to-end process, at least in theory. Its primary focus is on discovery, and to validate the things “discovered” from various workshops, it uses Agile principles to put in the hands of end users as quickly as possible. Unfortunately, this critical fact often gets lost in the translation between theory and practice.
Have you ever noticed the variations in the number of steps in different “versions” of Design Thinking? How do some of them have five or six steps? Let’s take a closer look at these “subtle” differences.
Both images indicate that this is a repetitive cycle. But do they? The one on the left is missing the implementation phase. One might argue that “prototyping” includes “implementation.” Usually, it does not. For some, “prototyping” means creating wireframes and asking a focus group for feedback. This is perfectly acceptable in the early stages when the goal is to limit coding expenses.
When an organization decides it is time to code an actual working prototype and test it with end users, it is the first time it receives genuine feedback from end customers. This is where things start falling apart.
Before we go further, let me explain what I mean by product and “product” companies.
-
Product companies have tangible products and generate revenue from end users who purchase them
-
“Product” companies, on the other hand, are usually hired by organizations that want to build a product but lack the internal capacity or knowledge to come up with a product strategy
Although the former can suffer from a silo mentality, the problem is much more pronounced with the latter. In this case, the organization outsources gathering insights and requirements to a “product” company that typically uses Design Thinking and related techniques. Once the requirements are gathered, they are handed over to the software development vendor.
Once the vendor receives requirements, it proceeds with development, testing and delivery. Finally, the solution is placed into production, where it starts generating revenue.
What’s wrong with that?
Agile and Product Management share the common underlying philosophy - the need to implement short feedback loops to quickly evaluate whether we are building the right solution for the right set of customers.
-
Design Thinking techniques should help us find the optimal solution, create a customer journey, and propose a set of features that, we assume, bring the highest possible value
-
Scrum should ensure a cross-functional team and a timeframe (Sprint) in which we evaluate those assumptions
-
DevOps practices should ensure quick deployment time and reduce the risk of production downtime
The problem is that organizations view these as separate phases. “Design Thinking” is done by product managers, designers and business analysts. Afterward, developers implement the solution through the Scrum cycle. Lastly, the organization's “DevOps” team deploys it to production (and yes, I am aware that this is not DevOps, but rather Ops, hence the quotes). In this scenario, analysts, developers and operations are separate entities that hand over the documentation or code to the next one in line.
So, what is the right… or at least a better way?
Similar to Agile, Design Thinking is a broader, more abstract term that envelopes certain principles, practices and values. They are not mutually exclusive, but rather complementary. Design Thinking is a continuous process of creating, implementing and evaluating assumptions while keeping Agile values and principles in mind. Most often, it means using the Scrum framework and cross-functional teams of business analysts, designers, developers, testers, and any other essential roles required for building the solution.
In larger product companies that have internal capabilities, achieving end-to-end coverage with a single team can be challenging, if not impossible. In this case, it is important to remember the guiding principles - improve the feedback loop by defining value streams, aligning the teams working in it, simplifying your architecture and building a tech stack to support the flow of the information, documentation and code with the least friction as possible in the process.
Where there is a handover, there is a (water)fall
Think about how many times you and your team have waited for that documentation, design, or code to be done so you can proceed with your phase. Waiting is one of the biggest wastes in software development, and it can be directly connected to a fall in feature lead time.
Another problem with handover is a fall in clarity. The team handing over the work usually overproduces to give all (and much more) deliverables needed for the next team in the stream. This leads to the overproduction of information, useless features, and most importantly - it shifts the focus from building the right thing to merely “doing your job by specification.” Scrum should have broken the silos between business and development and shift focus towards value creation. Instead, in most cases, it has become a development sweatshop.
Even within organizations that have the capability and the people to build the product, these modern development practices are done in sequence, thus creating the modern waterfall. The credit for this term goes to Jürgen De Smet. While I was already aware of the fact that there is a rift between product and development, he went a step further and elaborated on how companies fall into the trap of creating even more smaller waterfalls, thereby extending feature development lead time.
The broader context
The problem of comprehending the underlying values and the philosophy of Agile or Design Thinking was brilliantly summarized by Kent Beck:
"The things that haven’t changed are the power structures around software development. Until those change, the TDDs of the world and CIs of the world are shadows cast by the power structures. You can’t change the shadow until you change the reality… It’s the human problems that we need progress on if we want to actually make fundamentally lasting change."
When talking about sequencing the product development in phases, he says:
"No successful software has been built that way. That’s exactly the waterfall… There are new words put to it. It does not work for all the reasons it never worked. The fiction is so attractive that people are going to return to it."
The problem is so simple and obvious, yet the need for control and lack of understanding of the complexity that comes from these “power structures” undermine the empirical approach needed in order to create a market-fit product.
So, what can we do?
The key thing to remember is that all participants should collaborate on a daily basis (hence the cross-functional team) and keep the user feedback loops as short as possible.
In practice, if your organization opts to outsource product development, try to find a partner capable of building the entire end-to-end solution without the need for additional contractors. Keep in mind it is still possible that, internally, the partner could also suffer from modern waterfall syndrome. Try to understand how they build the product, how long they expect the lead time for each iteration to be, and how they validate each product iteration.
Stitching back the tear
At Devōt, we are trying to stitch back the tear between the “product” and the “development” by (re)uniting Design Thinking and Agile principles within a single team. This means that developers are included in product discovery workshops and we strive to validate the product features as quickly as possible. Design Thinking isn’t confined to one workshop; rather, it is a continuous process of discovering and validating the most valuable product features. If you want to know more about our approach or have any questions, feel free to reach out to us.
