Less is More: Creating Resilient Systems Through Simplicity

Simplicity isn’t something that we install once and forget. It is both a principle and a value. Whenever a change is made, we should ask the question “What is the simplest way this could be done?” This applies at every level, from small coding decisions all the way up to an organization’s structure.

Simplicity is hard. The natural cognitive bias is to add, not take away. Our default approach to improve a product, a system, or an organization is to add something more. Enhance, boost, augment… these all imply that increasing size also increases strength or value. By default, we don’t think about subtracting or simplifying. We don’t notice an opportunity to subtract, and rarely is it the thing that gets rewarded or praised.[1]

Why does this matter? Because complex systems are more likely to break. An excellent example is provided by the financial crisis of 2007/8. The mortgage system had become so complex that no one could understand the whole system [2]. Not even at a high level. Many banks and governments were caught off guard when it turned out that lenders had offered mortgages to people who couldn’t afford them. Worse, the properties often weren’t worth the stated value. Everyone had assumed someone else was doing the due diligence. Most of us don’t have the power to reform global financial systems, but we do all have the ability to simplify some systems.

Here are some examples of where a typical Scrum Team can create simplicity.

Simplicity in Software Development

In software development, we spend more time reading and understanding code than we do writing it. When we rush through the development work and don’t take time to simplify, there is a price. The people who read the code next will spend far more time to understand it, because the person writing didn’t think about simplicity, they just wanted to save 10 minutes.

Worse, complexity in code is a key source of bugs. When we create a complex solution to a technical problem, as the author we may well use it correctly, however, the people that follow in the years after have a weaker understanding of the work. They’re more likely to use it incorrectly, and that’s when defects can creep in.

Code is not the only source of complexity in software team. In modern programming environments, siimple applications often have dozens of direct dependencies. Each of the direct dependencies will have its own dependences, meaning our simple application really has hundreds dependencies.

Simplicity in Product Design

In any product, there is always pressure to add new features. This happens in software development, but also when designing physical products such as cars, and even refrigerators. Additional features often add value, however they come at a cost.

With software, new features add complexity to the user interface and, worse, to the code base. Take a moment to look at your web browser menu and you might see 60+ items. Then open the options/settings and you’ll probably find well over a hundred more choices. When all of these features were added, they seemed clever. But how many get used? Regardess of whether they truly add value to the consumer, they increase the maintenance burden since one small menu item or preference may require 20-30 changes in the code base.

The automotive industry has tons of examples of complexity. These days, cars have automatic rain, parking, and proximity sensors, to name just a few that are now standard. Many of these features add benefit, but they also make the products harder to use and more complicated —and often more costly— to maintain. New cars now have so many features, a dealer will often spend half an hour with a new owner showing them how all the systems work, just so they can drive home safely. (I still don’t understand our rain sensing windshield wipers after 5 years.) Modern sensor-laden cars may be easier and safer to drive, but when you need to replace a bumper or windshield, you pay not just for the parts, but to have the manufacturer recalibrate the sensors.

Meetings

Most teams are blessed (sarcasm) with too many meetings. When team members don’t have a single two-hour block to focus during the week, we know meeting mania has gone too far. Lacking time to do their actual work, some people have resorted to working evenings.

It’s not the the meetings themselves that are the entire problem. They’re a sympton of something deeper:

• Decision-making bottlenecks, or decision by committees
• Coordination overhead - when work is spread across multiple departments
• Information silos
• Process redundancy

Effective organizations audit their meetings on a regular basis, asking questions like: Why does this meeting exist? What is the real problem we need to solve that is causing us to have a meeting?

Not all meetings should be eliminated. Rather, we should always be questioning what meetings tell us about how our systems behave.

In the Scrum process, I frequently need to remind teams that Daily Scrum should replace most other recurring meetings.

Teams and Process

In any kind of work, we encourage people to specialize. In software development that has traditionally been: User Experience; Business Analyst; Programmer and Quality Assurance.

In Marketing groups, this might be: content creator; copy writer; video editor and web developer.

Each additional role creates handoffs, and the handoffs create rules and standards between each role. The rules and standards themselves add complexity. Worse, each handoff increases the likelihood of accidental complexity.

There isn’t a magic wand here, but instead of the default approach to add more people, the Agile approach is to focus on building cross-functional teams and cross-skilling.

When we have multiple teams or groups working on the same product, they have to coordinate their work. All attempts to coordinate will add overheard and increase complexity. This can’t be avoided. The questions should always be, is this the simplest way we can solve this problem? Are we adding the minimum additional overhead? Are we creating additional committees for the sake of making people feel heard?

Less Really is More

Simplicity is at the core of making our organizations resilient. It isn’t a once and done thing, it is making small choices in our work. Consistently looking for all the places, and in all the layers, where we could simplify will improve our resilience.

The next step is to ask how we spread simplicity throughout the whole organization to reduce bureaucratic overhead and strengthen strategy and performance metrics.

Think about it. What is one area in your work where complexity is masking a deeper issue? Then ask, “What if we simplified this?” The answer might surprise you.