Time To Abandon Agile?

March 15, 2016 — Posted by Al Shalloway

It depends on what you mean by Agile. 

Net Objectives has been promoting Agile methods for the 17+ years of its existence.  Although we started by focusing on effective software development using design patterns and object-orientation, it was less than a year that we realized that developing code is not our real problem.  eXtreme Programming, Scrum and the Agile manifesto expanded our view to the entire team level.  This, unfortunately, soon proved to be insufficient for clients wanting to transform more than a few teams.

We shifted from this in 2004 when we started adopting and promoting Lean-Thinking.  Much of the recent success of Scrum-centric Agile methods beyond a mere 3-5 teams has its roots back in the Lean-Scrum approach we were doing in 2004-2007 (see Lean-Agile Software Development: Achieving Enterprise Agility for practices like shared backlogs, redefining Scrum of Scrums and Sprint 0). In the early days Lean provided us insights on how to create new practices when the standard ones didn’t work.  We have since gone well beyond Lean as there are many other areas of knowledge we must pull from to be effective (e.g., Theory of Constraints, Adaptive Management, complexity theory).

Moving forward, out of the familiar tried and true, is something that must be continuously done in order to become and remain effective.  Unfortunately, in my mind, Agile has changed surprisingly little in the last decade and a half.  Many still refer to a 15 year old document to define it.

I am reminded of Bucky Fuller’s comment on this topic from Operating Manual for Spaceship Earth:

"I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences. Only our minds are able to discover the generalized principles operating without exception in each and every special-experience case which if detected and mastered will give knowledgeable advantage in all instances. Because our spontaneous initiative has been frustrated, too often inadvertently, in earliest childhood we do not tend, customarily, to dare to think competently regarding our potentials. We find it socially easier to go on with our narrow, shortsighted specialization's and leave it to others primarily to the politicians to find some way of resolving our common dilemmas."

I am clear that changing the way people work is not an easy task.  Yet, hearing consultants of flawed approaches saying “it’s simple to say just not easy to do” as an excuse for why their approach doesn’t work does not ring true to me.  I am reminded of H L Mencken’s "For every complex problem there is an answer that is clear, simple, and wrong.” Perhaps our simple solutions are simplistic.  The root cause of this is not nefarious.  I believe the challenge is that most people in the Agile community are coming from the wrong mindset. 

In Agile Manifesto: Incredible Success and Time to Move On  I point out that teams are mentioned 17 times, the client 3 times, business twice and management not at all. It is hard to argue that Agile as expressed by its manifesto is anything but a team centric approach. Scrum, often referred to as the standard form of Agile, is actually defined as the team and two roles that interface to the rest of the organization for the team.  Clearly team centric.

One can include Lean practices in Scrum, such as managing WIP, but many, such as defining an explicit workflow, have been frowned upon by Scrum thought leaders.  I had hoped a blend of teams and Lean-flow would arise in Kanban.  Alas, in my mind, the Kanban Method abandoned the baby with the bath water, so to speak, when it focused totally on workflow, saying that the eco-system within which we apply it is orthogonal to the method.  It may be in the method but it isn’t in reality.  Illustrating this is when wind effects were considered to be orthogonal to bridge design about 60 years ago (see this if you don’t get the reference).  Attending to the eco-system is one of the cornerstones of Lean which is why I believe the Kanban Method to be akin to the theory of constraints with Kaizen.

The tragedy is that between eXtreme Programming, Scrum and the Kanban Method, all of the necessary ingredients for an effective team-level approach exist.  Unfortunately, each camp seems to hold onto their ideas more than try to integrate with others.  This is what led us to development Leanban -  the first Lean-based team-level approach that incorporates the practices of Scrum, eXtreme Programming and Kanban as appropriate to the teams using it.

This may all sound harsh – and it is.  And many people will read this wondering what my motivations are.  But don’t wonder, I will tell you.  I want people who are struggling with Agile to start looking at something other than what they are currently looking at.  I’d like them to consider that they are not doing the right thing wrong, but perhaps they are being guided to do the wrong thing entirely. If people look at the wrong things it will be difficult to succeed.  I suggest that that is exactly what many are doing and that this is one of the key reasons there is so much difficulty adopting Agile today.  While doing the right thing may be difficult, having difficulty does not indicate you are doing the right thing.

I sometimes ask people how they would teach a person to drive a car.  Typical answers include talking about the mechanisms of manipulating the vehicle, about what to watch out for, and about the rules of the road.  One could say these are the practices, risks and principles of driving.  But three things are always left out:

  1. how to decide where you want to go (figuring that’s separate from the driving)
  2. what you need to look at when you tell their trainees they need to stay on the road (thinking that’s obvious)
  3. which direction to face in the driver’s seat (another obvious one)

In software development, however, I would suggest that the equivalent of where you are going -  knowing what to build - is more important than the quality of your process in building it.  What you need to look at the direction you are facing, while obvious in the physical world, are much contested and unclear in the software world.

In software, we unfortunately, don’t have the equivalent of what to watch for to be staying on the road.  Waterfall suggests one thing, Scrum another, Kanban Method another, and Lean yet another.  As far as the direction to sit, the Agile community is split between taking a bottom up approach, a top down approach or an holistic one.  Creating software is fundamentally different from physical world product development, but few people discuss the issue. 

Perhaps our troubles with software delivery are more complex than it’s “just not simple to implement.”   Perhaps it’s we’re not attending to where we should go and not looking at the right way to know if we are headed there and looking in the wrong direction to boot.

Now to the title of this blog.  I certainly don’t mean to abandon the intent of Agile – better methods of developing software, better culture, more fun in working, creating sustainable paces, getting more value delivered, improving the world (seriously) and more.  These are all good intentions.  But to meet them I suggest the Agile community will have to shift from the team centric view it began with but has mostly refused to abandon. 

To be candid, I don’t care too much about consultants who have defended their methods in the light of continual challenges.  I do have empathy for those consultants who are trying to help their clients to solve the real issues but having difficulties getting their ear because of the cacophony of the major certifying bodies claiming theirs is the true way.  Although I do believe these very same clients bear a large portion of the responsibility for the challenges they are enduring, I still have empathy for them.  Mostly, however, I want to help the preponderance of practitioners out there who have a sense that something about the line they are being told is wrong.  While having suspicions about the validity of the approaches they are being sold, they unfortunately, do not have enough insight to create better alternatives.

It is for these people that Net Objectives will be rolling out a significant number of webinars and live question and answer sessions in the next several weeks. If you are not on our mailing list, I invite you to register (www.netobjectives.com/register) to learn about them.  Topics will include:

Agile at Scale

  • The Essence of Agility at Scale
  • Using Minimum Business Increments to Drive the Incremental Delivery of Business Value
  • Using SAFe as a Framework and not a Solution
  • Solving the “one size does not fit all” and “people need a specific place to start” dilemma
  • The Program Increment Planning Event
  • Agility for Late Stage Startups


  • Guardrails for Agile Organizations
  • The Next Generation of Team Agile Methods: Leanban
  • Acceptance Test Driven Development

Technical Agility

  • Avoiding Over and Under Design
  • Essential Skills for the Agile Developer

Each week a pre-recorded version of the webinar will be put on our website with a live Q&A session scheduled 2-3 weeks later.  Questions submitted via email will also be answered.

My hope for this effort is that we will create a forum for people to actually discuss the issues of what is important for improved software development.  I used to think I only needed to show someone the way to being more effective.  I have since come to realize it’s even more essential to get people to abandon the myths with which they’ve been seduced. I am hoping this video series with integrated conversations can afford people a way to drop these myths and get on with solving their real problems.

As always, if you can identify with the sentiment of this blog and feel we might be helpful in your efforts, please send a note to alshall AT netobjectives DOT com

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