 |
| Long Live Agile |
I recently read a post that claimed Agile and Change Management are “dead,” and it troubled me so much that I feel compelled to speak up.
This blunt accusation misses the mark. Instead, I’d like to reframe this declaration into a more nuanced analysis of why the adoption of Agile frameworks and mindset might falter—and what we can learn from those experiences.
Having had the privilege of working across different organizations—large and small—I’ve been both a participant and an observer of Agile implementations in action. My experiences have ranged from witnessing moments of stunning success (yes, even to the point of tears) to profound struggles where Agile’s potential was obscured by mistrust, misapplication, or misaligned goals.
What makes Agile so powerful is its universality. At its core,
Agile is about embracing change and breaking down complexity
into manageable, actionable steps. The philosophy behind the Agile Manifesto is timeless and revolutionary, challenging us to focus on collaboration, adaptability, and continuous improvement— qualities that transcend industries and organizations, regardless of size.
The Spectrum of Agile Experiences
In Smaller Groups:
Smaller teams, particularly those under 100 people, often find it easier to embrace Agile. Transparency and Adaption — two foundational pillars of Agile—are easier to nurture in close-knit environments. Frameworks like Scrum often flourish here, allowing teams to adopt Agile incrementally as they learn and adapt together.
In Larger Organizations:
Larger organizations, especially those with deeply ingrained Agile cultures, can achieve remarkable results. When Agile is treated as a shared mindset rather than just a process, it becomes a unifying language across teams and departments, enabling complex systems to function with stunning efficiency.
Where Agile Struggles
I’ve seen teams weighed down by an overemphasis on process and documentation, to the point where they stagnate in debates over the simplest of updates, terminology or roles.
Let me share an anecdotal example. My current team continues to work on standardizing project organization in Jira - our chosen devops platform. In one meeting, we aligned on the mapping method we would use to move a set of dev tickets from one project to another, and we moved everything in that meeting.
I was privately amazed, and quite moved. There was no argument, no hair splitting over labeling, or tagging in one project vs. another. There was not overthinking of 'what if' scenarios in moving all the items. One person was not in charge, we were doing it collaboratively. There was no need to include multiple internal stakeholders, multiple times in discussions when they already knew we were moving items, over the course of months, to prepare everyone for the relocation of devops project items: an action that took minutes at most. There were no outlines, or rechecks,
It was just done.
In other teams, and in other organizations, this simple move would have easily taken months. In defense of similar moves I have contributed to or witnessed in other organizations, I do understand that in large enterprises with multiple devops projects across multiple teams, a move like this, may impact many people, and that may have necessitated some additional discussion to strategize and implement the plan to relocate devops tickets.
However, in past experiences like the one above and in many others, it seemed like we were 'practicing' Agile for Agile's sake.
The Elegant Simplicity of Agile
At its core, Agile challenges us to focus on two fundamental truths:
- We need to break things down.
- We need to move things forward.
The different frameworks of Agile, like LeSS, SAFe, or Scrum, are meant to be applications of the Agile philosophy and mindset. In other words, these frameworks should help teams simplify how teams communicate and work together (Transparency in communication and work, Inspection of progress, Adaptation to change).
They offer a base of shared values (Focus, Openness, Respect, Courage, Commitment) to guide work culture, so that teams may deploy often (incrementally), and achieve objectives.
The problem I've observed in the groups where I've seen this application of Agile falter, occured when applications of Agile seemed forced, overly ceremonial (going through the motions), or became means of micro-management rather than growth. In these cases, there were multiple instances where it seemed like 'Transparency' meant exposing 'fault', 'Inspection' meant viewing the negative rather than the whole picture, and Agile values seemed pushed aside in the process.
True incremental delivery moved slower in these situations, because there was a perceived lack of trust, at the core. The result became an emphasis on needing to do for 'me', rather than for 'we' as a whole.
In these scenarios, it may appear, on its surface, that Agile is 'failing', when it is more accurate to say that the adoption of the Agile mindset, its pillars, values, and the chosen framework is faltering. It may be more accurate to note that the core issue: lack of trust, and lack of accountability, must be addressed first before adjusting any application of Agile.
