Agile coaches come from all walks of life, most often from Scrum Master, project manager, and development manager backgrounds. While these coaches can train teams in the various Agile frameworks, only a few have hands-on experience as product leaders with business backgrounds. As a result, they can struggle to build rapport with teams, especially Product Owners and Managers who often find themselves in the difficult position of trying to satisfy stakeholder’s unlimited desires with the real-world capacity of their teams.

I’m a bit different: I come from a business and product management background. Unlike Scrum Masters, project managers, and engineering managers, I’ve spent years incrementally and iteratively developing products hands-on with teams, customers, and business stakeholders. This allows me to build a greater degree of rapport with teams and programs. I’m especially well-suited to train and coach product organizations in Agile frameworks, design thinking, and product strategy.

Consider your tools: how you manage your workflow (sticky notes, Trello, JIRA, etc), your video conferencing software, or your programming languages. Would it be easy to swap one for another? Would it provide much value?

What about your processes? You could adopt some of Scrum’s artifacts or events. You can call your business analysts “Product Owners” and your project managers “Scrum Masters.” You could even adopt cross-team strategies such as the “Scrum of Scrums” or even Scaled Agile Framework’s “PI Planning” to manage cross-team dependencies. Will that create a profound new capability for you?

Adopting new tools and processes is relatively easy. There’s plenty good money for coaches who help teams do this, so it persists. Unfortunately, there’s little value. If only it were so easy.

The promise of Agile—”the ability to create and respond to change… a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment“—doesn’t come from software and meetings. It’s not something you do; it’s something you earn. It comes from maturing the way your organization functions. Yes, your tools and processes will probably change. But so must your structure and culture.

As leaders, we must reconsider our structure and culture. Why should we be content to manage dependencies with a process—like running a three-legged race—when we can eliminate them by patiently developing truly cross-functional people and teams? What is the use of teaching our teams about continuous improvement if we are not willing to continuously improve ourselves as leaders too?

Indeed, this is the heart of Agile’s lesson: creating the environment where everyone can creatively solve the problems together. Teamwork and partnership between leaders and workers isn’t a platitude or empty management slogan; it is the very essence of the successful Agile transformation. This isn’t easy, but it’s necessary: when we only adopt the tools and processes from Agile, it is like a caterpillar trying to glue on paper wings.

Bruce Lee isn’t famous for performing white-belt Kung Fu moves. Jimi Hendrix isn’t celebrated for playing beginning scales on stage. Frida Kahlo’s earliest paintings aren’t hanging in the Louvre. But all three—along with virtually every example we have of human genius—started at the beginning. They had the humility to practice and master the fundamentals, the support they needed to start diverging from the basics at the right time, and the perseverance to transcend even their best teachers.

Agile transformations go the same way. So many transformations fail because teams and leaders aren’t willing to consider a fresh approach with a beginner’s mind. They adapt the frameworks too early. For instance, perhaps they change a Scrum-related process to reflect their current structure, rather than sticking with the process long enough to discover that the structure itself needs to be changed. The opportunity for real transformation—and the resulting benefits—is lost.