How the Agile Manifesto Has Gotten Us Stuck

February 27, 2018 — Posted by Al Shalloway

There’s an old joke about a person who has too much to drink staggering around under a lamp post. A policeman sees him and asks if he’s ok. The man says, “I’m ok, just looking for my car keys.” So the policeman starts helping him look so he can take the keys away. After a while of not finding them, the policeman asks the man, “Are you sure you dropped them here?” The man replies, “No officer, I dropped them down that alley.” “Then why are we looking here?” “The light is better here.”

Consider this. The Agile Manifesto was written in 2001. 17 years ago! Think about that for a moment. 17 years before that was 1984. Commercial internet service, mobile devices, inexpensive servers and a lot of other things didn’t even exist in 1984. Many people writing software today were toddlers or not even born in 1984. Things changed quickly in those 17 years. And in the next 17 years, from 2001 to 2018, they changed even faster. And it is only getting faster.

Is it even conceivable that something written 17 years ago should be driving us now? Imagine if we tried using 1984 technology in 2001.

Seventeen years is a long time!

So how is the “light better” with the Agile Manifesto? The Agile Manifesto was created by technologies and is focused on technology. Read it and notice the perspective it comes from. It mentions technology 17 times, the customer three times, the business twice (and then only as the business relates to development), and management not at all. When it was applied to an individual team this worked OK. But it is not the right perspective to have anymore.

Today, almost every business idea has software in it. Cars have dozens of computers in them with over 100 million lines of code.

Consider the challenges we hear from virtually every company:

  • We can’t get alignment from business stakeholders.
  • We can’t get management involved.
  • Our requirements aren’t clear.
  • We get conflicting information.
  • People don’t work together well.

The litany goes on and on. Most everyone is having the same problems. How can this be?

Companies are different, but everyone has the same problems. You hear different explanations like “software development is complex,” “Scrum is simple, follow it as it is,” “managers don’t care,” “business people just don’t get it,” and on and on and on.

And who offers these explanations? People on the technology side.

The Agile Manifesto helped… but it’s time to move on

Yes, Agile is good and the Agile Manifesto was a watershed moment that made things better. But it is time – past time – to look afresh. I’ve been saying this since 2012 (when I wrote a blog post, Agile Manifesto: Incredible Success and Time to Move On).

But technology likes to rule. It ruled in the 70s when IT had a stranglehold on all software. And now Agile is keeping technology in charge. It’s become a mantra. But it’s the wrong focus.

The way we practice Agile is like driving in the back seat of a car with the steering wheel facing out the back. Look at our metrics. Almost all of them look backwards. We embrace the lack of predictability as if it’s a law. It is true that we don’t have the ability to predict details but we definitely have the ability to see patterns and make predictions from them. Holding on to unpredictability slows us down while giving us an excuse for our lack of success. We should be recognizing unpredictability as a symptom of problems in our development approaches; instead,, we paper it over as an intrinsic part of software development and we even have a movement to justify why it’s a good thing.

I am writing this for management and leaders, whether on the technology side or the business side. (And by the way, the fact that we have sides is another symptom of the problem.) It is time to wake up, to work with today.

Fortunately, we already have the knowledge of what to do. We just need to start using it.

There are many consultants and practitioners who know what to do but they can be hard to find if you are looking in the “technology” space. They don’t focus on the technology-based perspectives of SAFe, Scrum, LeSS, Nexus, and so on. They don’t like to talk about Agile, because they realize that business folks don’t care about “Agile”. Nor should they! How technology works is not their only area of expertise. The consultants and practitioners to talk to are the ones who will tell you how they will help you achieve value quickly, predictably, sustainably, and with high quality.

Start with Systems Thinking

There is no magic here. You must start with systems thinking. Systems thinking, best described in Peter Senge’s The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge, is something ignored by almost all packaged Agile solutions and by the Agile community.

Three aspects of systems thinking are that 1) systems cause most of the behaviors of the people in them, 2) the parts of a system interact with each other so changing one part will affect others, and 3) you cannot combine components together to get a functioning system. In other words, a series of local optimizations won’t get you a global improvement; in fact you will likely get just the opposite.

Applying systems thinking is not always comfortable because you have to think. There are no easy solutions. But there are solutions. Look for them. Find someone who can help you by working with you and respecting what you know.

A Call to Action

If we want to improve our organizations we must recognize that all organizations are each unique, yet each follows the natural laws of organizational and software development. This means that we can take advantage of what is known without having to either start from the ground up or take on solutions that were designed as one-size fits-all solutions.

The keys steps are:

  1. Consider that your goal with Agile should be “business agility” – the quick realization of business value, predictably, sustainably and with high quality
  2. Drive your adoption as close to where your strategy and initiatives arise
  3. Engage with people who understand this and don’t take a technology centric approach only
  4. Invest in yourselves more than in outside consulting companies since your staff knows more about your business than anyone else

If you want to learn more about our approach at Net Objectives, take a look at or send me a message.

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