Agile Unchained: Part 1 - Breaking the Chains!

Prologue: In this tetralogy, I aim to provide a clear perspective that re-establishes–and perhaps reinforces–the value of the Agile Framework (AF) to an audience that may be having trouble applying Agile within their team. Despite AF being around for over two decades (born in 2001 via the Agile Manifesto), there appears to be a persistent obstacle preventing the general population from grasping more than just the fundamentals of AF and its practical application in their respective organizations.

This conundrum becomes even more pronounced for non-technical teams as they embark on their Agile transformation journey. That is to say, the further from tech, the more pronounced these challenges become. Despite these challenges, I still believe AF provides incredible value to teams of all kinds, especially non-technical ones. This and the following articles will delve into the reasons behind the broad application of AF and more. I'll present:

1. What I have observed to be the key obstacles that are preventing Agile adoption,
2. Why I believe it's worth taking on Agile transformation [or some form of Agile],
3. How an organization can go about its journey into the Agile Framework (AF).

Part 1 - Breaking the Chains: Escaping Waterfalls and Embracing the Agile Revolution!

First, let's explore potential reasons why this impediment exists. Based on my experience, I hypothesize three main drivers:

1. A Shift in Thinking: Learning AF requires a distinct paradigm shift, temporarily setting aside our Waterfall mindset to absorb the Agile principles at our core. This cannot be approached through the lens of Waterfall methodology. That’s too definitive of a statement; I have found my brain hurts the most when I try to understand AF in terms of Waterfall. It demands a distinct shift in thinking.?Here is a non-cliché analogy that compares Waterfall and Agile while also highlighting one of the key benefits of Agile:

Consider the human body anatomically. It is a system composed of many subsystems. The famous Aristotle quote applies perfectly, "The whole is greater than the sum of its parts." Remove the respiratory system and the body fails. That is Waterfall Methodology. In Waterfall, the entire project is structured in a way that it is considered a singular deliverable. Remove any part of it, and that part is useless just as the project itself will be. I'm generalizing, but hopefully you're tracking.

Agile, on the other hand, is nothing like the human body. I think of it more as a worm. I remember when I was a kid, we used to believe cutting a worm in half would make two worms. While this is definitely as evil as it is false, it sticks for the sake of my analogy. So let's pretend it's true: cutting a worm in half makes two worms. In Agile, a project is structured in a way that its subparts can be removed, manipulated, or even deprioritized and the project itself will sustain. As a leader in your organization, you can already foresee how your team can benefit greatly by being a worm.

It took me a long time to realize this distinction and if you take anything away, let it be the above. I wouldn't blame you if you stopped reading now. Sleep on it. For the masochists, read on.

Shifting the thinking of an organization is the epitome of change management. And in all change management initiatives, it requires both a deductive and inductive approach; starting with the leadership. To avoid shifting this article into one about change management, I'll cut to the chase: if your leadership does not foundationally comprehend the Agile Framework, then you're doomed. [Ok. That's a bit hyperbolic.] You're in for a very bumpy Agile journey. The amount of bullshitting I have seen surrounding the number of leaders pretending to understand Agile is staggering. In the case of Agile transformation, leaders faking it until they make it has damaging repercussions. Too many leaders are too shameful to admit it. You have to take a moment and extrapolate the implications of this dilemma within an organization. Leaders teach teams, establish processes, and implement processes into workflow tools. Imagine a leader who lacks an understanding of AF that is responsible for architecting their team and systems into an Agile Framework. That's like a Civil Engineer leaving massive structural gaps in a skyscraper. The technical debt is horrendous. What's the solution? Create a safe space, admit your ignorance, break the chain reaction of intellectual insecurity, and fill the gaps.

2. Balancing hybrid approaches: Another layer of complexity tacks on from the fact that most organizations, if not all, need to strike a constantly changing balance between Waterfall and Agile as the transformation progresses. Read that as many times as it takes. The crude reality, at least for me, about the AF is that Waterfall and Agile are more like the yin-yang of project management.

The success of the transformation and the ability to effectively navigate challenges and seize opportunities depend largely on how well an organization monitors and adapts this balance.

Moreover, when organizations are in the midst of Agile transformation, they often face additional challenges associated with updating old Standard Operating Procedures (SOPs) and supporting technologies. This process can and WILL be messy; embrace it (the first Noble Truth of Buddhism) and maybe call in a professional to help. Pro tip: I suggest leveraging AF to facilitate the implementation and manage the complexity. #meta #notfacebookmeta

3. Purists are Evil: It's worth noting that purists focus on how to fill the rest of the half-empty cup, while realists accept that we must work with what we have to forge on. Purists can hinder progress despite their best intentions. It’s also important to recognize the purist within ourselves; the internal tendency can be a bit conniving.

In contrast, realists understand that we must work with the resources at hand to move forward. It almost becomes a philosophical debate. This further emphasizes the importance of balancing hybrid approaches at the individual level. Each individual should recognize that a "one size fits all" solution does not exist. That's why leading an organization is hard, and transforming takes seasoned expertise.

Embracing flexibility and prioritizing customer-centricity must serve as the guiding principle–the north star–for your team, rather than rigidly adhering to a specific framework. This logic is deeply ingrained in the Agile Manifesto.

Let me provide you with a personal example of how I was first introduced to AF:

In my previous role, professionals from various disciplines came together to propose minimally viable solutions to complex business problems. Our goal was to assess whether any of these solutions had potential i.e. traction, adopting an approach similar to throwing spaghetti at a wall to see what sticks. It's a super simple example and it barely scratches the AF surface, but that isn’t the point. The point is to demonstrate and highlight the flexibility that is inherent to the Agile Framework (AF).

To summarize a solution for this third driver, Purists are Evil, I'd say iterate, iterate, iterate.

In the upcoming articles, I will expand on my hypotheses by:

1. Explaining what I find to be The Key Benefits of AF and why it is almost indispensable for every organization to incorporate some aspects of AF into their teams.
2. I am delving deeper into The What and The Why of AF while avoiding the cliché examples that continue to trap everyone from getting beyond the fundamentals.
3. Exploring my suggestions of How to Apply AF and sharing the insights I've gained from widespread pitfalls that lead to failed transformations.

Like all agile practices, this is a work in progress. Please feel free to provide your perspectives and feedback. And, thank you for reading. Bye, for now.