Can we break free from names and labels? Can we be just be a little more “agile” without the capital "A" ?

This article is sort of a philosophical reflection and if you feel it’s a bit exaggerated, you are right, I’m using exaggeration as a resource to make a point and bring a smile to your face while you read ??

We live in a world where everything that becomes popular and / or fancy gets a name and a fanatic following. As I mentioned in my previous post on DevOps, this is not necessarily a bad thing, but once it gets a name and a following you become a slave to what the name implies (which sometimes can be different depending on the different factions of followers!). Fanatic followers will make sure that, if you dare use the name, it is the way they believe it should use or otherwise "you are not doing it right". In the end, it turns simple and effective concepts into, still effective, but more complex ones.

There may be many examples, but t I'd like to highlight the three I consider happen most of the time …

—  Becoming slave to practices. That is, strict definitions on how a practice should be performed.

—  Becoming slave to labels. That is, acronyms, frameworks, models, etc, resulting in lot to choose from in so little time!

—  Becoming slave to dogma. That is, quasi-religious concepts and following in such a ways that if you don't follow the dogma, you are out, a pariah an ignorant and a plethora of other not-directly spoken adjectives that can be inferred from corrections from the "experts".

This happens in lots of stuff, but today, we'll focus on the dreaded "A" word. That, is, no other than Agile itself.

Before I go further into this, I’d like to say I'm an all-time believer of agile. I even organize my personal life in a pretty much iterative fashion. I've been involved with agile since 2000 or so and had the privilege of meeting some of the gurus in OOPSLA, back in the old days. I even was one of the speakers of the first events on the subject organized in Argentina.

Still, I think something of the mentioned above phenomena is happening with Agile …

—  Becoming slave to practices. The many well know rituals (e.g. daily meeting, sprint planning) arised from one or other methods, but were no way a mandatory part of agile and are not necessarily needed (at least in strict way) to work in a "more agile way".

—  Becoming slave to labels. I often get questions on why something is a Squad, a Tribe or "a Scrum", I see many different things being called an MVP, etc. The fun thing is that most of these labels are quite recent and were not even part of the agile movement a few years ago.

—  Becoming slave to dogma. This is probably the one more predominant in agile settings. Religious calls with the Scrum Guide in hand (or whatever guide your specific cult uses … it may be SAFe, LeSS, etc). How many times have you heard someone claiming "this is not agile" (because it does not follow the dogma the critic believes in).

What's the issue? The concept becomes so overloaded that using it carries a lot of overhead. From "you are not doing it right" to a lot of too strict preconceptions (e.g. to be agile you must flatten your organization). It's like you must ask permission to use the so overloaded concept to the few illuminated ones that "know how to do it well" (and, of course, know all the acronyms and labels!). You become a slave to the name.

So, what if we want to decouple from the "A" word itself? What if we just want to work in a more lightweight, responsive, flexible, collaborative way, without falling into the "A" word that carries so many predefinitions, meanings, implications, and risk from being corrected from an illuminated elite?

So, I say we do a simple exercise, that is, forget the "A" word exists. Say you want to achieve something, like building a product, reaching something, etc. What if you …

—  Don't plan exhaustively. Just setup your “north”, a direction, a broad idea of where you want to get and some limits (e.g. a time and budget limit). From that, you start working iteratively, where each iteration gets you closer to that north, and watching as you approach those “limits” you established. As you approach, your "north" may become clearer and you may even realize you want to change direction. As you approach your “limits”, you may also want to steer direction to get to something closer to your destination which is achievable within the limits.

—  Don't split that "north" in parts, but rather, build incrementally towards your north in each iteration. Build a first version of something that looks like your destination and improve on top of it, making it closer to your north as you iterative. Aim at maximizing feedback and reducing risk with each iteration.

—  Work collaboratively with the parts involved in achieving that north, making explicit to each that you are going in the same direction and the best way to get closer to the destination is to work together. Assemble a team that works this way or otherwise don't do it (a bad team won't get you anywhere, whether you work in iterative, waterfall or anything in the middle). Apply the same reasoning to other parts, such as suppliers, clients, etc.

—  Prioritize what adds value and leave the rest unless there is no other option. What is value? What gets you closer to that north. And remember that as you get closer to your destination, you may realize you need to recalibrate and change direction slightly.

Well, that reminds of the "A" word, right? Yes, but honestly, many of the things mentioned above existed long before the "A" word hit our world and filled our social networks. And the good news is, using the above common-sense practices does not tie you to names, labels, standards, methods and will avoid any "you are not doing it right" type of comment from the elite of illuminated ones.

Why can't it be that simple? Can we just be more agile without a capital "A"?

Of course, this article is an exaggeration purposely done just to illustrate that, many times, we become prisoners of overloaded concepts. We thus, lose our freedom to self-proclaimed “owners” of those concepts, whether they are gurus, professional alliances, or societies, etc. Nobody is the owner of good, common ways sense of working and collective experience gained over decades. It’s good to remember that from time to time!