By MALIK GRAVES-PRYOR
Co-Founder and Principal Consultant
"Agile is Dead", "Scrum is a Failure", "The End of Agility". Spend any time reading articles on the Internet regarding agility and/or the methods, mindsets, and frameworks that facilitate it, and you’ve likely come across apocalyptic headlines like these. They pontificate on all the reasons why "agile" has gone wrong ranging from management issues to poor culture to 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 towards 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, etc. 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, however, but instead embraced as part of our personal journey toward greater agility. After all, everyone’s "success iceberg", the shiny object in the distance seemingly reflecting the pristine construct of our unfettered achievements, is in reality littered with setbacks, hard work, failures, and a lot of disappointment under the surface. Reflecting on these foundational moments can empower us individually and as a community just as it does for the people we’re here to help, and should be something that we’re able to openly speak about.
"The Iceberg Illusion" © Sylvia Duckworth (@sylviaduckworth)
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. 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 by the team themselves to live by these suggestions, the DMPO doubled down and instead became more command-and-control, 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 at that time 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 just how deeply impactful they were to him from a motivational perspective.
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, a relationship 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 coaching 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 to understand that agility efforts were not just about the mechanics, but also about empathizing with the motivations both 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, I learned that my efforts were ultimately seen as more of a hindrance than an enabler. From this experience I’ve learned that 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. I’ve learned that 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, etc). 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. ”
So, why should we share these stories of failure? Well, we come from different backgrounds and viewpoints, a richness that collectively 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 how agility and the tenets therein are not just a mindset for the people we serve, but practices and approaches we can, and should, adopt and apply for ourselves.
By sharing these stories, we strip our inevitable failures of their power and instead shift them to what they truly are and should be seen as: the greatest teacher of all. Failure and the willingness to adapt and try again is the foundation upon which true agility is built. 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 outwardly share these experiences, our community will only strengthen in the coming years, and that’s an outcome that benefits us all.