Less is More – and Tough

Be it in my personal or professional life, I observe a clear tendency to accumulate stuff: in my daily work with product owners, when it comes to throwing something out of the backlog, or when I first start to work with a client and see the multitude of digital collaboration systems being used.

Perhaps the complexity of the world is due to mankind's obsession with collecting. Some people have made it their profession to fight it: editors warn against convoluted and long sentences and complicated vocabulary. In other professions, fighting complexity is just a pretense: watch out when consultants tell you that simplifying means introducing one more process, interface, or even framework. If you want your organization to become more agile, less often means more. How can you fight to overload yourself, and should you?

Subtractive thinking

At the University of Virginia, a team of researchers got to the bottom of collecting behavior. In an experiment, test subjects were asked to create color patterns with colored tiles: Only 20% came up with the idea of removing tiles to create a pattern, 80% were content with adding them.

I notice something similar when I give workshops in which solutions to problems are sought: Participants prefer to add measures rather than part with something.

In further experiments in the study, it was found that when participants had the opportunity to practice, the rate of subtractive solutions increased. This suggests that although people do not use subtractive solutions by default, they do gradually recognize them as useful.

To help my teams come up with subtractive solutions, as a consultant I try to repeat processes. Take, for example, the Definition of Ready or Definition of Done. The team creates these at the beginning of their work, but periodically I remind them of these definitions and we revise them together.

The Virginia researchers also found that when participants are given additional tasks, the added cognitive load reduces the likelihood that participants will arrive to subtractive solutions.

In practice, this is a paradox: If we have too much to do, we do not reduce the complexity in the process because it does not occur to us to leave something out – even though this would actually save us time. An iterative approach remedies this. As a ScrumMaster, I don't introduce big innovations at once, but rather try out an idea in small steps. In the example of the Definition of Done, I don't present the team with a prefabricated, detailed complete solution, but work out a version together with them, which we review at regular intervals and expand or reduce. I take care not to change too much per iteration, otherwise the empirical basis is missing to see which changes had which effect.

Subtractive solutions are not always useful either

Don't forget the emotional component of subtractions: After all, simply omitting a measure, tool, process step, or entire process may mean that they had no value before. Even if this is the case, such a proposal is usually met with resistance. As a consultant, if I suggest eliminating departments on my very first day with a new client, it will certainly not sit well with the client. Neither is eliminating a long-running system or program because the people involved have already put a lot of work and time into it. That's how I approach reducing:

• Reduce on a small scale: With a product backlog beyond 100 items, reducing certainly makes sense. In keeping with agile thinking, I reduce in small steps in an iterative process. Therefore, not every feedback from the review is incorporated into the backlog. It will come back if it was important. In this way, I make sure that we don't fall prey to a collecting frenzy and that we continuously achieve measurable progress.
• Reduce on a large scale: In transformations that involve restructuring an entire department or company, I don't question everything. What is there used to have a purpose. With simple questions, I try to find out whether what is there is still appropriate and, if necessary, can reduce complexity with the answers given: Which meetings do we absolutely need? Which roles/responsibilities? The answers are then compared with what is already in place.

Say more so that less becomes an option In general, you should question what a new system or new departments are wanted for. What is the need behind it? To get teams and leaders to consider dropping, I ask, "What do we need, what can we do without?" The second part is important if you want to do something about complexity. Dare. Remind people that removing is an option.

Picture by Etienne Girardet, Unsplash