The Emperor and The Empress Have No Clothes

February 25, 2016 — Posted by Al Shalloway

Doubt is uncomfortable. Certainty is ridiculous. Voltaire

The test of a first-rate intelligence is the ability to hold two opposing ideas in mind at the same time and still retain the ability to function. F. Scott Fitzgerald

There are two things one hears from Agile consultants all the time:

  • No one size fits all
  • Start with a set of practices and evolve into thinking for yourself

Yet, very few live by these maxims. 

No One Size Fits All.                                                  

If no one size fits all, it’s clear we should know when any particular size, or in this case, framework, method, approach, doesn’t work?  In 17+ years being in the Agile community I can’t remember anyone telling me the limits of their favorite approach.

Shu Ha Ri

I actually dislike this metaphor because it caters to the idea that what we’re doing is more art and skill with little science.  However, the intention – that we start by doing and move into understanding and then transcending practices altogether – has been in the Agile space from the beginning.  Unfortunately, virtually all popular approaches take the attitude that you must follow their practices or failure will ensue.  Many even disparage those attempting to go beyond core practices – e.g., Scrum-but, Shallow Kanban.  See Stuck in Shu – Time to Change How to Teach Scrum and The Right Way to Do Scrum-But … for more insights on this.

The Cause of These Disparities – Misunderstanding of Complex Systems

Why are these attitudes so widespread.  There are, of course, the realities that many of our current frameworks/methods/approaches form the basis of many people’s livelihoods (both consultants and practitioners).  As a consultant, having well defined, rigorous solutions that we think work everywhere provide us with a greater population to serve our wares.  As a practitioner, it’s easier to pick up a “proven solution” than to make our own case for a more contextually driven one.  Nice clean solutions are nice to have around, but I am reminded of HL Mencken’s statement - For every complex problem there is an answer that is neat, simple and wrong.

We can gain some insights into what we must do by understanding how we’ve gotten where we are.  I suggest the following are the main “culprits”:

  • People want (I’d go so far as to say “need”) a well-defined solution
  • There is little appreciation for systems thinking
  • People misunderstand the implications of complexity causing them to both think they can only address certain aspects of the development system they are in as well as ignoring the adverse consequences of doing so

I do believe we need to provide a well-defined solution, even (or especially) in a complex system.  However, systems thinking and complexity tells us that we must consider our organization in an holistic manner.  This means that if we ignore aspects of the system that blindedness may come back to haunt us.  This is the crux of the problem.  We can’t deal with the entire system yet any aspect of it we ignore will come back to bite us.  We see this over and over again – see  Framework Tunnel Vision for more.

So what can we do?

When You Resolve Not To Do What You Know Won’t Work You Must Adopt Practices Which May Make You Uncomfortable Doing So.

When you have eliminated the impossible, whatever remains, however, improbable, must be the truth? Sherlock Holmes.

The point is, if we are going to be effective, we can’t do the following:

  • Take a one size fits all approach
  • Ignore aspects of the system we are in
  • Attend to all of the aspects of the system we are in

This may not tell us what to do, but it can tell us the characteristics of what we must do. I would suggest we need a system that:

  • Provides a starting point based on an organization’s context, the laws of software development and an understanding of organizational development
  • Attends to the key aspects of the system (implies one must know what these are, of course)
  • Incorporates double-loop learning to adjust which aspects of the system to look at as things change
  • Provides guidance to achieve the required objectives with a different set of practices

We started talking about such a system a year ago with What Every Framework/Method Should Have.   We have since created such a system.  But you will need to wait for my next blog to introduce it. 

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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