The Divergent/Convergent Cycle and the Minimum Viable Process

A recurring theme that keeps emerging among many thought leaders in our day is that humans compromise or even sabotage their success by converging prematurely on a choice of direction. In some cases, it is choosing the wrong problem to solve. In other cases, it’s the wrong (or a subpar) solution to whatever they are solving.

In recent years, this has been the explicit premise of the “double diamond” found in the UX Design Strategy Framework (UXDS). In the first diamond, the focus is on choosing the best problem to solve. In the second diamond, they begin to focus on the best solution.

Repeating the Divergence/Convergence Pattern Among Many Thought Leaders

Divergence/Convergence in “The Lean Startup”

A divergent/convergent approach is found in Eric Ries’ Hypothesis Driven “Lean Startup.” Many failures occur because entrepreneurs and developers prematurely conclude that they know what the market or a customer wants or how they respond to a change. By testing a hypothesis and validating the results, we avoid converging on beliefs prematurely. Ries lets evidence drive conclusions.

Divergence/Convergence in the “Solution Set” Method

The “solution set” approach also embodies this divergent/convergent cycle regarding how to solve the problem. In this approach, multi-disciplined teams will groupthink and consider multiple alternative strategies for implementing value. They do these in solution workshops and with experimentation.

The classic example is how to solve accident avoidance in an autonomous vehicle. Should the designers employ lidar, radar, image recognition, lasers, other sensors, or various combinations of two or more of these? The team proposes several experiments, and the first deliverables of their work are knowledge, findings, and insights. It’s premature to shoot for a fully working, accident-avoidance system without such exploration.

Divergence/Convergence in the “Definition of Ready” Portfolio Concept Incubation Process

Taking an isolated play from the SAFe framework playbook, we call a Kanban process wrapped around the “solution set” approach, above, “Definition of Ready.” It ensures that portfolio-level concepts are genuinely ready to build. This technique is especially applicable when used with large value streams comprised of many teams. Properly used, it keeps the teams creatively involved in the divergent/convergent cycle, and “shifts left” contributions of crucial experts.  

Divergence/Convergence in the Outcomes VS Outputs Litmus Test

Joshua Seiden pries apart old ways of thinking by teaching us to focus on Outcomes instead of Outputs in his book by a similar name. In another book, “Sense & Respond,” Joshua and his co-author, Jeff Gothelf, reiterate this principle. They use outcome-based KPIs to help us diverge before we converge. The strong temptation to slip back into an output-oriented preoccupation is mitigated by returning to the outcome-based KPIs. Repeated checks against the KPIs keeps us in check, keeps us from drifting off course.

Divergence/Convergence in Don Reinertsen’s Flow

Don Reinertsen’s “Flow” opens with this quote from Mark Twain:

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

Reinertsen challenges long-standing beliefs from Six Sigma and Goldratt’s Theories of Constraints. With compelling evidence and vivid clarity, he helps us to pry our thinking wider before we continue to converge on dangerous or insufficient thought in matters of product management, variability, utilization, and many other aspects of taking concepts to cash. No matter how much we think we understand a domain, the real innovators help us diverge once again, expand our thinking, and converge on new, impactful insights.

One of the process tools Reinertsen provides to help us not jump prematurely to sub-optimal prioritization conclusions is his “Weighted Shortest Job First” (WSJF) technique.

Divergence/Convergence in Old, Simple, Agile Methods Like XP

One can even see the divergent/convergent principle at work in the simple, two-person practice of Kent Beck’s Extreme Programming (XP) from the 1990s. Working alone, developers tend to retrace the ruts of their thinking, digging themselves ever more deeply into the groove that they saw and thought before. They are blind to flaws and pitfalls in their code. 

Shouldering up and working with a “second pair of eyes” helps the coder diverge from their previous, private mental course to expand their perception and perspective regarding what is right before their own eyes.

Tools, Skills, Facilitation, Integration, and Partnership

ALL these divergent/convergent practices involve other people! 

In the simplest case, above, XP programming, it pushes the single developer approach into a dual-developers technique to expand thinking and perception (divergence), leading to insights and agreements (convergence). UXDS corrals groups to work more effectively together as a team instead of a collection of individuals pushing and pulling in different directions to achieve self-absorbed personal goals, interests, and concerns.

When an entire group or organization needs to expand their thinking, sometimes it takes a bigger wedge to pry their thinking apart. The level of effort and facilitation required to get a group to approach strategic choices and problem-solving tactics in this manner varies. 

The UX Design Strategy Framework (UXDS) tackles a very tough problem. Getting a large group of often over-eager, over-achiever-types to not rush to decisions regarding product direction requires a considerable investment in trust-building, confrontation, corralling, guidance, and facilitation. UXDS facilitators employ an array of powerful tools to help diverse groups collectively think about a problem space surrounding a “persona” (abstract entities representing a segment of their market), empathy maps, journey maps, and other tools. These all serve to PRY OPEN their minds as a group, to help them DIVERGE. Then they CONVERGE on what is the most crucial problem to solve. The next diamond begins the solution discovery phase. Once again, the facilitators guide them to diverge before they converge to design the solution in the most potent way.

According to industry analysts, many findings in these workshops are left on the table or rejected. The solution convergence was at the prototype level without the inputs of enterprise architects, regulatory and compliance and security specialists, or other critical subject matter experts. Where this happens, more expertise must “shift left.” We must include crucial SMEs in the UXDS process to lower the rejection rate of UXDS findings (I.e., other people). 

The Ying and the Yang – Sigh. Frameworks. You Can’t Live Wid ‘Em. You Can’t Live Widout ‘Em. 

Flirting With, Yet Being Wary of, the Unified Field Theory Approach

All the creative work going on trying to create these systems, these workflows, these new processes is excellent. It is an expression of the creative energy we need to gain escape velocity, to join the next generation of value providers. That said, we need to continually zoom out and reflect on where we’re going with it all.

Creating and evolving frameworks is needful. Yet, for the same reasons current frameworks often fail to achieve their stated idealistic intentions, new frameworks will have similar challenges. The value of a new one will prove to be like that of LeSS, SAFe, Nexus, Spotify, or DADs, et al. As is often cited, even Spotify continued to learn and evolve. Spotify no longer uses the so-called “Spotify” process anymore – at least not as codified.

When used as a reference framework to frame concepts and practices, these frameworks can benefit those who study, learn and grow from them. When imposed prescriptively in their entirety by a PMO organization (AKA “the process police”), they often prove to be ill-suited for many pockets of the organization, or the attempt is a tortured mess. All of the principles and values become lost or obscured in all the moving parts, machinery, new defined roles, and new responsibilities, etc. Adoption is always difficult at scale.

Minimum Viable Process

The “Sense & Respond” book calls using a loosely coupled approach to a process framework, “Using Minimum Viable Process.” Do we call this MVPr? ??