When the agilist is the reason agility goes wrong
How often do we as agilists share our own personal growth stories, the times when things fail despite our best efforts, and sometimes in part because of those very efforts?
“Agile is Dead.” “Scrum is a Failure.” “The End of Agility.” Spend any time reading articles on the Internet regarding agility and the methods, mindsets, and frameworks that facilitate it, and you’ve likely come across apocalyptic headlines like these. They pontificate on all the reasons “agile” has gone wrong: management issues, poor culture, bad development practices. However, how often do we hear and read about agility efforts that go awry because of the agilist themselves? As agilists we coach the individuals, teams, and organizations we work with to regularly and transparently reflect upon their successes and failures, and to inspect and adapt with an eye toward their continuous improvement. Rarely, however, do we share our own personal growth stories with others, the times when things fail despite our best efforts, and sometimes perhaps in part because of those very efforts.
Rarely do we share our own personal growth stories with others, the times when things fail despite our best efforts, and sometimes perhaps in part because of those very efforts.
Those of us who coach individuals, teams, and organizations go by many names: Scrum Master, Enterprise Coach, Kanban-ist, Agile Coach, Lean-er, Agilist. Whatever label we reference ourselves by, however far along we are in our journey (whether picking up our first book on agility, bearing the battle scars of many transformations, or something in between), we’ve all lived through moments of doubt, lack of clarity, unexpected and undesirable outcomes, and may even have been “fired” by the very people we’re meant to help.
These moments should not be negatively framed, but instead embraced as part of our personal journey toward greater agility. After all, everyone’s visible success hides setbacks, hard work, failures, and a lot of disappointment under the surface. Reflecting on these foundational moments can strengthen us individually and as a community, just as it does for the people we’re here to help, and should be something we’re able to openly speak about.
In my own history, one of the teams I worked with earlier in my career was comprised of four developers and one developer/manager, who also played the role of the Product Owner (PO). I spent a significant amount of time coaching and encouraging the developer/manager/PO (DMPO) to let go of his command-and-control style, to afford the team more autonomy in decision-making, more input in the stories that were created and deliberated over, and ultimately more collaboration in their daily activities. This shift in approach was made more difficult by the intersecting negative influence of being a manager responsible for the reviews (and bonuses) of others, and simultaneously the Product Owner responsible for setting a direction of what gets prioritized and ultimately completed. As you can imagine, this placed the developers in the unenviable position of “if I don’t do what the manager says, I won’t get a good review” instead of “is this really the right thing to do, and why?” when trying to determine what would come next.
Despite my best efforts and those of the team to live by these suggestions, the DMPO became more command-and-control, not less, tightening his grip. After just a couple of months, he ultimately suggested to his management that his team was “agile enough” and no longer needed a coach, at which point I ceased working with his group.
Afterward I dug deeper and discovered that the DMPO was under significant pressure from senior management to meet certain deadlines. He was also fairly new to his management and PO responsibilities, having only recently been promoted. This added to his daily stress, as well as bringing forth a fear and uncertainty around trying new things. While he had touched on these challenges during our numerous conversations, I did not pick up on how much they were weighing on his motivation.
Due to my own blind spots and lack of experience, I did not spend enough time with him and the team, helping them forge a stronger relationship, a relationship based on trust, where he could see the incremental successes they had achieved together. I was unable to help him develop new and better ways to communicate those incremental successes to his stakeholders and upper management, and to coach him to understand that his success would ultimately arrive by trusting those he managed to build the right products and services. Had I understood his needs, challenges, fears, and concerns, alongside those of leadership, I could have more quickly forged a mutually trustworthy relationship that would have allowed the DMPO to move beyond his hesitation and see me and his team as fully vested partners. I learned through that failure that agility efforts were not just about the mechanics, but also about empathizing with the motivations, subtle and direct, of all those involved, helping facilitate a cultural transition and mindshift toward greater agility.
While mid- and senior-level management voiced support for increased agility, they really regarded it more with curiosity than anything else. They looked to the DMPO for guidance and buy-in while simultaneously pressuring him to meet their deadlines. Because I was too inexperienced to fully understand the DMPO’s underlying motivations and pressures, my efforts were ultimately seen as more of a hindrance than an enabler. The lesson stuck. We as agilists have to be able to flex bottom-up and top-down approaches, simultaneously and at all times, keeping an eye on and understanding the intricate positive and negative motivations and desires of all those involved, the “why” behind their attempts at agility. Understanding the “why” becomes just as important, if not more so, than “what” we’re doing (agile transformation) and “how” we’re doing it (Scrum, Kanban, scaling framework of choice). If we can do this as agilists, reach behind those motivations and truly empathize with and understand the ones we’re here to help, we can support and guide our teams and organizations toward their goals while minimizing their challenges and fears.
Failure and the willingness to adapt and try again is the foundation upon which true agility is built.
There is good reason to share these stories of failure. We come from different backgrounds and viewpoints, a richness that strengthens us all and the work we do for our employers and clients. If we can share that richness, the good and the bad, we can encourage greater transparency about our collective craft, and show how agility and the tenets therein are not only a mindset for the people we serve, but practices we can, and should, adopt for ourselves.
Sharing them strips our failures of their power and lets them be what they should be: our best teacher. Failure and the willingness to adapt and try again is the foundation true agility is built on. True agility is the ability to experiment often, fail, reflect on those failures, and adapt to try again. If we can internalize this for ourselves and share these experiences openly, our community will only strengthen in the coming years. And that benefits us all.
That same lesson shapes how we coach at Natoma: we start with the “why” behind a team’s motivations and pressures, not just the mechanics of what and how, because that is what turns a stalled transformation into steady, adaptable delivery. If you want a clear read on where your own delivery is getting stuck, request your delivery map.