Why Simple Or Overly Complicated Solutions Often Don't Work Well for Complex Systems

June 13, 2017 — Posted by Al Shalloway

Executive Summary

Lean-Agile transformation consultants tend to provide one of two types of approaches to their clients:

  • Simple solutions (e.g., Scrum, Kanban Method)
  • Complicated solutions (e.g., standard implementations of LeSS, SAFe, DAD)

Both can (and have) worked.  And both have challenges with them.  A common problem with simple solutions is that they often never get to the real problem an organization is facing. For example, Scrum achieves its simplicity by focusing on the product owner and team.  But this may not be where the problem lies.  Simple solutions are also often based on a prescribed framework (e.g., Scrum) that is inflexible in certain areas (e.g., the need for cross-functional teams).

The problem with complicated solutions is that they can overwhelm people.  Then, in an effort to implement them, people take these practices as gospel since they don’t fully understand the principles underneath them.  This leads to inappropriate use of the framework or, after initial success, a degree of stagnation.  The dilemma that neither of these approaches solve is that although people need a simple solution to start, there is no single simple solution that works for everybody.  Making something sophisticated enough to solve everyone’s problem can make it too complicated for many.

Why You Must Start Simple

Gall’s law is a rule of thumb for systems design from Gall’s book Systemantics: How Systems Really Work and How They Fail.  It states:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)

Gall's Law basically reflects the reality of:

  1. It is very unlikely anyone knows what the system should end up being.
  2. Even if they knew the right system to use, it’s complexity would make it hard to adopt
  3. The culture in which the system was being implemented may not be able to accept the degree of change required

The idea of starting with something simple has been held to be synonymous with Agile thinking.  One often hears “start as simple as you can” but forget the other part of that mantra “but not too simple.”   Simple is also not synonymous with flexible.  This conflation has often been ignored.  The Scrum framework is simple.  It could be said to be flexible in that you can add whatever you want to it.  But some of its practices, such as cross-functional teams, planning sprints and the roles of product owner, scrum master and team are core.  You aren't doing Scrum if you don't do these.  Unfortunately, these are often not possible or even desirable in many situations.  

The Kanban Method is simple, and flexible enough to be used anywhere.  That's one of it's advantages.  But used as a mere change method it assumes people will figure out what is needed to expand it.  They often won’t. So both Scrum and Kanban Method have their limitations as a starting point. And both work mostly at the team level. 

What Happens at Scale

If you are at scale, what is simple but sufficient is considerably more than what is needed at the team.  Very often here the issue is more the attitude one’s approach takes. Do we get teams started and then they self-organize via Scrum of Scrums (LeSS)?  Or do we create a framework within which teams can work?  There are two divergent approaches.  LeSS takes the attitude that self-organization is the key.  This ignores the reality that organization wide dynamics are considerably different from team dynamics.  SAFe has two fundamental aspects driving it – an attention the the entire value stream and pushing decisions down as low as they can be.  Both are fairly complicated, however.  Each approach again provides different dangers – missing the real problem or getting so caught up in the adoption that one focuses more on a prescribed solution than on solving one’s real problem.

The Key Is Not Simple Solution But Simple Steps

We must recognize that an holistic solution is required, but that we can only start in a simple manner.  Thus, we want to start with something simple but adjust as we go.  This starting point must be based on where an organization is.  After the simple (again, simple is relative), start, new features, processes, steps, etc., can be added. Eventually, a full-blown system will emerge, but one that is both tailored too and adjusted by the organization using it.  The challenge is that this requires years of experience to manifest.

An example of a simple start may be to:

  • Create visibility
  • Decompose the work to be released into smaller chunks
  • Have conversations with product owners or their equivalent and the development/testing people to develop clear specifications for what is to be built prior to building things

After the basics are implemented and people feel comfortable with learning more, additional steps/practices may be added.  For example, make the aforementioned specifications be written in a testable manner.    

Many people start SAFe in a simple manner by using creating programs and using the program increment planning event as their core process. This is a good start. But it is not clear how to go from this to the next step.  

Many Agilists suggest that after an initial start of following practices people must rely on their own wits to transcend the practices and use principles to drive additional change.  What’s ignored is that principles are not enough – one needs to have experience in applying them.  This is where an experienced person must lead.  Their job is not simple, but rather it’s to keep the changes the organization faces to be as small while being sufficient.

In Summation

Organizations have more than the choice of starting simple with little guidance or starting with a full solution.  They can start simple and take simple steps until they achieve a more complete solution (one never achieves a “complete” solution, there is always more to learn).  This is not truly simple however.  Rather each step of the way is relatively small. But knowing which steps to take requires both a solid understanding of organizational principles as well as the experience to apply them. 

Al Shalloway

CEO, Net Objectives


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban