Here I discuss some of my thoughts on the Agile Industry in general and suggest that it is not necessarily innovating, but rather Agile has gotten stuck. I will suggest that this is largely due to the overt focus on doing agile whilst not paying enough attention to being agile. Finally, we will see that Agnostic Agile helps to bridge this gap through its twelve principles and its ongoing publication of content.
As we welcome our 1000th member on Agnostic Agile (https://agnosticagile.org), it occurs to us that we’re doing something right. It’s been just less than 18 months since we launched Agnostic Agile. In its initial version, we collected lots of feedback and built that feedback into what we see today – a slightly revised text, the redaction of the word ‘oath’, the migration to a CMS (Content Management System) to enable content delivery and the slow and steady flurry of blog posts and articles, and there is a lot more to come.
How is the Agile Industry Changing?
Still though, the Agile Industry continues on a trajectory of show and tell; you can read a lot of opinions on people and things on social media but the reality is that not much has changed in recent years other than the introduction of a new scaling framework and the acknowledgement from Scrum.org that Kanban is pretty good and we should take it more seriously. In terms of innovation in the Agile Industry, one has to question how much innovation is really needed or is even possible as we continue as an industry (and as practitioners within the industry) to mature while things seem to stay the same. It certainly looks like the Agile Industry rather than innovating, is attempting to quell its own cantankerous dysfunction at least in some places, and this is evident from the long overdue marriage (truce?) of Scrum with Kanban (thanks to Scrum.org) and from the existence of Agnostic Agile itself, which has created a global community of over 1000 people at time of writing. But we’ve all been at the Agile game for around 20 years now give or take, and it feels like we should have come a lot further on.
What has changed over the last few years isn’t the introduction of some glorious new framework purporting to solve the world’s problems, or a new technique for estimation, or a better way to do XYZ, rather the topical needle has shifted to different subjects pertinent to the Agile ethos. To give a quick example, we had a brief bout of neuroscience content from various areas of the Internet, which amounted to the fact we need to focus on the soft stuff and not just the hard stuff – Change Management 101, if only we would listen (but we can’t because of the word ‘management’). Another more obvious example is one of Scaling, not least because Agile is being far and wide adopted by more enterprises and people are figuring out the best way to do Agile at scale with many teams in more complex environments. Of course, that darn culture thing always gets in the way (page 12). The underlying assumption here is that Agile as a framework can be effectively done ‘at scale’, something which even these Manifesto authors have presupposed here and here (ironically the most common and widely used scaling approach was written by a non-Manifesto author). The reality we are seeing on the ground is that whilst you can do Agile at scale successfully, you will lose some of the spirit of Agile, the ‘soft stuff’ that constitutes your ‘being’, at least in part – collaboration, team individualism, empowerment, identity, freedom. Rather than evolving as a small team, you must now evolve in tandem with the whole, and this takes time and conscious effort, the latter of which many organisations that do Agile at scale don’t bother with, and most people just won’t hang around waiting for Godot to show up (unless their names are Vladimir and Estragon) and this goes for Agile Coaches as well as for anybody else. Thus, Agile at scale has become a sharp tool in the enterprise toolbox for getting bigger stuff done quicker, all the while brandishing shiny frameworks and shinier target operating models. I am not arguing that this is a bad thing, it has moved the needle slightly more towards the realms of agility, but sacrifices are made in our proclivity to maintain as much order as we can.
And yet, some things never change. The same questions are being asked time and time again on LinkedIn forums and elsewhere, « what is the best way to… », « how do you… », « what is the best tool to track… » On this last one, our core set of classic Lean metrics are still great (why wouldn’t they be?); throughput, cycle time, lead time. And so we have the same answers over and over, with a bit of passive aggressive framework bashing thrown in whenever we get the chance (oh, bless them!)
So, what can we make of this transmogrification of the Agile Industry?
In my estimation, we have focused too much on frameworks and ways of working, and it is easy to see why if we stop and spend a short amount of time thinking about it. Companies demand results, projects and programs need to get delivered, and Agile has become (mostly) the de-facto standard for delivering product to market, even if your ‘product’ and your ‘market’ are proxy variables for some kind of internal substitution. The response is the Agile framework, and to be fair it isn’t a bad response, but there are too many presuppositions left unattended in order to truly enter the realm of agility, and herein lies the problem. We want to apply (our pet) Agile frameworks within an existing hierarchical and largely homogeneous structure that wants to contain it in a bubble, which means that everything else, especially the status quo, must be maintained. That’s like bringing a cake to a party and eating the whole thing by yourself. This is the enterprise agile mediocracy, and this is exactly where Agile has gotten stuck.
Come-hither, sweet Business Agility
Some Agile professionals see Agile almost the way Keats saw his Grecian Urn. For fun, I challenge you to read the first stanza of that poem and pretend like he is talking about Agile, then you will have a much better appreciation of this point, and of the purest of the pure, should you ever encounter them – what wild ecstasy!
Business Agility among its sweet promises, reminds us that Agile isn’t just about delivery. Even if it is, as a natively human way to work and interact with others it obviously has implications beyond the self, beyond the team, beyond the team of teams, beyond senior management; indeed, Agile as a humanistic way of working must be espoused within the very core of the organisation, it must be the very predication that the organisation is built on in terms of its modus operandi rather than a soluble within a container of containers. But we can and should get deeper than this, lest we succumb to the mistaken understanding that Agile is simply a way to do things better – which is why we’re stuck. Perhaps a more complete way to describe Agile and Business Agility is in the word Being. The oft’ cry of the Agilist is that there is a gargantuan difference between doing Agile and being Agile. Being (capital B) describes your own individual experience, your experience as a person, which is subjective and unique. And it describes your joint experience with others, team members colleagues, etc. So Being is how you feel, your drive, dreams, hopes, desires. It is also manifest in all the daily tyrannies you strive to fight off so that your life can be made better. Being is your many interactions with the world, with nature, with your team and your manager, with the people you work with and the wider organisation that you work in. Being can be influenced by action and inaction; and here we tie it up with what it means to be Agile. Agile is part of your Being, it is a set of practices to the less seasoned, a better way to do things, and it is a powerful invisible force to those who are more practiced, who have come to the realisation that it is a thing that permeates through people and organisation and engages continuously to hamronise ways of thinking with ways of working. We must move the needle on the former in order to affect the latter, and this is precisely why Agile isn’t just about delivery.
Order is where we have a comfortable level of control, where we can work within a framework of knowing how we can coordinate with each other, which gives us a sense of predictability about what we are doing. Chaos is when a key team member decides to quit a few sprints ahead of our first production release. It is when your direct competitor releases that feature to the market when the same feature is on your roadmap for the next quarter. Chaos emerges when you run your organisation’s first big room planning event and a senior manager stands up and decries the debacle because she can’t see the point of it. Unpredictability thrives in chaos.
The taijitu symbol (modern yin-yang) shows a balance between two opposites with a portion of the opposite element in each section. For us, the symbolism is profound; you cannot be ‘completely predictable’ or ‘completely unpredictable’. In our noble endeavor to be predictable – to attain and to hold onto order – there will always be that spot of unpredictability and vice versa. We look to Business Agility to prepare us for dealing with an increasingly unpredictable world where companies are here one minute and gone the next, and to deal with fostering innovation – in a natively human way (because no other way would make sense) – in a chaotic market. Recent and previous examples show that there is awareness en masse within the enterprise to confront the problem of unpredictability, of chaos; maybe it’s not yet enough, but it’s a good start.
Business Agility and indeed Agile, is about order confronting chaos, about knowing how to approach the unpredictable with a sense of the predictable, just as the Yin and the Yang eternally give rise to each other, so then Agile’s dance with unpredictability is eternal, but it is the human endeavor to apply order to chaos that continually drives us, and it is the reason we all keep trying.
Mind, the Gap
The change we seek does not lie in rituals, ceremonies, events, frameworks, roles or responsibilities. These are physical manifestations of the organisational mind. If true, then changing the way that mind thinks will by inference alter its physical manifestations, and this is why Agile is so focused on mindset change, and any Agile training course worth its salt will spend a good deal of time talking about mindset, values and principles. But this too is not enough; combatting the traditional management mindset in the most dysfunctional of environments is difficult to say the least, if not impossible without top-down buy-in and a fundamental remapping of core values, in other words, reprogramming the organisation. This is too much for some to bare and so the path of least resistance is to assimilate into the enterprise agile mediocracy and brandish what practices of Agile you were able to carve off of a framework. You will find no short supply of certificate wielders looking to embark on such a quest.
Agnostic Agile is a movement established to remind us all (us dear practitioners of any flavour) that there is more to Agile than its physical manifestations and of the fact that it is counterproductive that the Agile Community should be driven by framework-based (and therefore guru or camp-based) presuppositions, because doing so is to understand people (who are the most cherished ‘asset’ in the Agile community) by their group identity, which is destructive because it pushes us back towards a tribal direction, when we should instead be collaborating and improving upon each other’s work in a harmonious and constructive way; a positive experience for our Being depends on it.
With this comes Agnostic Agile’s Twelve Principles, each designed to stand on its own or with the others. They are meant to foster and encourage a deeper awareness of the realm of agility, where Agile is Being, where what the Manifesto espouses gains life; agility as a force rather than just as a set of practices. As Agnostic Agile practitioners we may understand that, but how many organisations really know what they’re asking for when they hire you to help them be more agile?
Founder, Agnostic Agile