I got into a conversation the other day about the band the Beatles. It generally went along the lines of how much I really didn’t like their music and didn’t believe that many other people do either despite what they claim. The Beatles were a product more in line with today’s mass-produced pop music, and rather overrated.

The Beatles were before my time, but I tend to dislike pop music made even in my time. I can certainly recognize that people consider them revolutionary, I find it hard to agree. I can also recognize that almost everyone will tell you they love the Beatles, but not really know any of the Beatles songs or listen to them at all anymore. I know there are people out there who probably still listen to them, that number is far lower than claimed I think.

Why is that? It’s because the Beatles music wasn’t very good.  People may say they like it, but they don’t. The Beatles maybe had one or two good songs. I have known a grand total of one person in my life that was under 40 that liked the Beatles and seemed to mean it. It was 20 years ago, and she would regularly play Beatles music. It’s how I learned I don’t really like them.

There is a difference between being revolutionary and paving the way and being worth listening to. You like the idea of the Beatles, you just don’t really like them – and probably never bothered to listen to more than one or two of their songs if you are under the age of 40. The music you listen to alone is usually the music you actually like.

What do Agile and the Beatles Have in Common?

There are more people claiming to like Agile than there are people who actually like Agile. I have come to realize over the past four or five  years – partially through writing my blog and partially through work – that this is because Agile is horrible as defined by the 12 principles of the Agile Manifesto and because no one bothers to recognize a goal of being agile (as in nimble or able to adapt to change quickly). People have heard about success in Agile, have no clue what it is but they like success.

I am thinking the only thing of any value in the Agile Manifesto is the four values of the Agile Manifesto and it is still too narrowly focused:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And… Much like the Beatles, I am starting to doubt many claimed Agile fans have read the 12 principles and actually considered what those words said and meant. They are worthless when it comes to any non-software project or product (and not always very agile when you apply them to software projects and products) – yet Agile keeps getting pushed into other areas and they cite the Agile Manifesto when doing this. The Agile Manifesto has a full name – “Manifesto for Agile Software Development.”

The Agile Manifesto is not something to take advice from when making your organization agile. It has also spawned the creation of dozens of processes and tools that force the process and tool above the individual and their interactions. Managers love getting a ready-made process they can drop in that promises them saved money. It doesn’t work that way, unfortunately, and it often makes things worse when you don’t believe it or really like it. You need an Agile you can get behind.

You aren’t really an agile organization just because you have a single Scrum team building your product and adhering strictly to the processes of Scrum. You are ignoring agility for the sake of an Agile process or tool. You are just adopting an Agile process so you can tell people you adopted it – the same way I bought a Beatles CD in the 90s so I could tell people I owned it even though I listened to it once and skipped through all the songs because it was horrible.

Empirical or Just Empty Promises?

I studied scientific approaches to business and organizations in graduate school (Master of Science in Administration as opposed to a Master of Business in Administration). I became a huge fan of human-centered management practices so much so that I studied job satisfaction for my thesis despite a heavy tech-centered undergrad and tech specialization in my graduate work. This is what attracted me to Agile and is a personal interest of mine more than an employment interest. (My early experiences with Agile almost killed any interest I could have had in Agile).

The four values I listed in the prior section seemed to mostly align well with that interest in human-centered management approaches. The 12 principles come in and I am rather torn a bit. I don’t think they align well with the four values.

Then out come the Agile frameworks, peddling their solutions to all of your problems. Mix in some cultish recitation of some slogans and what we end up with is something that has become worse for many of the people forced to work in these situations and none of the problems get solved.

I state frequently that Agile is not Scrum (I know Scrum existed before the Agile Manifesto), but I frequently wonder if Scrum is really agile (flexible and adaptable). It seems more iterative and incremental development with a strong focus on the process rather than on the people. It might explain why most of my Scrum experience I hated and the few times I liked it we focused less on Scrum itself and more on being flexible and adaptive – which meant we dropped parts of Scrum that didn’t work for us. we focused more on being agile (flexible and adaptive) rather than the process of Scrum itself.

This is what brings me around to Complexity Theory and Complexity Leadership Theory. At their core, they are related to Agile and are more agile than most approaches that are called Agile. They are more based on sound scientific ideas rather than strict frameworks designed to make people money through endless certifications (money I have spent in my pursuit to learn more about Agile).

In Conclusion

Agile itself, as defined by the 12 principles and how we have come to practice it, isn’t usually very good. The foundational core is what is important (Complexity Theory: The Most Important Part of Agile) about Agile. It forms the human-centered, empirical, and adaptable guidelines we need and is less about strict process-oriented frameworks.

*A bit of a thought experiment. When you think of Agile, what do you think of? Are you focused on iterative development and the fifteen-minute meetings; maybe even co-located teams and low-tech solutions? Those are all defined processes on how to do things. What happens when the needs of the people interfere with those processes?