By: Kristen Ardito | September 7, 2022 | PMO & Project Management | Agile Transformation | Change Management
Opening Observations
Why do so many organizations struggle to gain adoption for Agile? Why do so many “transformations” feel like another exhausting exercise that takes teams away from doing “real” work? It shouldn’t be so hard right? I mean, a methodology built on the promise of servant leadership, “just enough” documentation, inspect and adapt and incremental delivery should be a no-brainer right?
I’ve slowly and painfully come to the conclusion that while Agile is a good methodology and certainly better than Waterfall, it isn’t perfect.
Sure, with Agile, the months of lengthy upfront planning - usually done with minimal input from the team, are gone. With Agile, teams no longer need to read volumes of documentation that could easily have been condensed. Done right, Agile teams can deliver incrementally and strike the right balance of delivering quality code, addressing tech debt and work on new feature development. But done wrong, Agile can be used as a shield to protect mediocrity and lead to a lack of predictability in the larger ecosystem.
The Struggle to Scale
I’ve seen plenty of organizations go through Agile transformations only to struggle with longer lead times, issues addressing reliability at scale and burned out teams who can never catch a break. In time, finger pointing and distrust can become rampant.
Before you know it, Scrum-fall or Watered down Agile starts to creep in - in the worst case scenario, a new management team is hired to lay down the law and whip everyone into shape. My experience has shown that this approach may result in short term gains to the long term loss of top talent who won’t work under those circumstances.
Small organizations who experience success when team sizes are small and autonomous must not blame teams when there is a growth in complexity (more people, more code, more processes, more applications, etc.) leading to delays and bottlenecks and increased dependencies.
Organizations that are growing will begin to experience delays due to code complexity that wasn’t the case when there were only a handful of engineers. Infrastructure can become a constraint as loads increase and transactions exponentially multiply. Testing is sometimes left to the very end, which is costly and risky.
Often there is a tension that between product leaders (who would prefer to prioritize new feature development) and engineering leaders (who never get a chance to address mounting tech debt).
This is not the fault of the teams and simply demanding they work longer hours to address these issues without help is only going to lead to burnout. To add insult to injury, as the delays mount, more processes, meetings and demands are often thrown at the teams in an effort to speed things up. And you guessed it, these processes often have the opposite effect.
Intention and Change Management
There is another factor at play that may impact the success of Agile at organizations. The intention of the leaders who are tasked with implementing Agile at any organization matters. Intention is defined as: “a thing intended; an aim or plan”.
What does this mean?
If Agile is implemented by leaders who are looking to hold on to or to gain control over teams, then the framework will be distrusted. I’ve also witnessed leaders hiring outside the organization to implement Agile and everything is done behind closed doors. Teams don’t really understand what is going on and often have no say.
I have witnessed a growing trend of leaders who say they believe in Agile, and even use many of the language from the Agile manifesto, but their actions undermine their words.
This can manifest in misaligned expectations and confusion as teams struggle to understand why they are being asked to meet date driven deadlines, with fixed scope for example.
Another trend I’ve observed: Some technology leaders are so desperate to attract qualified candidates in a competitive job market that they proudly tout their “Agile framework” while privately becoming paranoid that deadlines are not being met, workers are unmotivated and that without being told explicitly to innovate that teams are losing their edge.
I’ve seen this manifest in roadmaps that were so jammed with features and ideas that the leadership and business teams wanted that there was no room for the teams to innovate even if they wanted to! I found myself playing a balancing act between the product and engineering teams and the executive/business teams.
There is a growing realization that in order to bring the spirit of Agile with the need for some planning and reporting, change management techniques should be used to build awareness and support for the framework.
My experience has taught me that even one or two resistant people can undermine a lot of goodwill. It’s important to listen.
Change Management is a growing and endlessly fascinating field of study and I won’t go into the details here, but at a very high level, I want to acknowledge that almost all the organizations I’ve worked with struggled with this. To foster a spirit of inclusiveness, and garner advocates for the change, organizations must prepare for the change. This means cracking open the closed doors a little and inviting individuals into the conversations.
This also means having crisp and concise goals and objectives for the change, as well as a vision for what the change will bring to the organization - BEFORE starting to implement the change.
Why Hybrid Won’t Work
The word Hybrid is used a lot, and has been used for quite some time now, but it doesn’t quite mean anything.
When I hear a leader say “we want a hybrid framework”, I cringe. I know what they are really saying is: “we want Waterfall but can’t afford to say that because we don’t want to freak people out”.
The end goal is to instantiate tools and processes that will force teams to commit to dates, take away parts of their autonomy, and govern by auditing and tracking. Does this work? Yeah, sure, sometimes. But oftentimes it leads to resistance, a build up of resentment and distrust. Over time, this distrust becomes the culture. Whispers of micromanagement become louder and spread. Glass Door reviews start reflecting the pent up frustration.
So what can be done? What are some of the best ways to handle the contradiction of meeting deadlines, and orchestrating the sequencing between dependencies vs. shorter delivery cycles? Is there really such a thing as speed AND quality? Are complexities inherently bad?