Agile/DevOps Coach required (if success matters to you)

I’ve been a software developer most of my professional career and an Agile coach for most of the last decade (and a DevOps coach for the last several years). I’ve worked within my own teams and with other teams to accomplish Agile and DevOps transformations. Based on my experiences, if you’re going to be successful at the transformation necessary to adopt these practices, you’re going to need a coach.

My evidence?

• Xtreme Programming has been around since the late 1990s
• The Agile manifesto was signed in 2001
• Scrum has been a documented practice since at least 2002
• Mary and Tom Poppendieck published Implementing Lean Software Development: From Concept to Cash in 2006
• The first Velocity conference was in 2008
• The first DevOpsDays conference was in 2009
• Continuous Delivery was published in 2010
• The Phoenix Project was published almost 4 years ago
• and I won’t bore you with the insane number of search hits and YouTube videos for related terms.

And your teams still won’t pair, won’t write tests before code, don’t even know what BDD stands for, can’t merge to master without a week of finger pointing and bug fixing, and still need a weekend to get through the manual upgrade and deployment steps they documented (that worked at least that one time on that test server). Fear permeates every deployment.

If the existence of high quality content was sufficient, every team would be agile and no one would lose weekends deploying crappy software. While I’ve seen teams invest in training and workshops to get things started, it’s far less common for them to invest in coaching to make it stick. This is one of those in for a penny, in for a pound moments that will define your outcomes.

You are going to need a coach.

Before some of you start throwing things, yes, in some cases, teams coach themselves. I have actually seen it happen (and it is beautiful). And in every case I’m aware of, you can trace it back to one or two folks on the team who had an interest and championed the effort (and did a lot of the early work themselves to prove it worked). The coaches.

What’s more common is sitting in a meeting with two “scrum masters” talking about how they’ve got their daily standup down to just 2 days a week and how they almost never waste time on retrospectives any more. :-(

I could wonk on about how “change is hard” even in small teams, much less in enterprise settings. I’ll settle for sharing this interesting piece from The Learning Consortium that describes an agile assessment of sorts of several companies, including giants like Microsoft and Ericsson and includes this little gem hidden in among the other bits (not to mention the flotilla of speedboats metaphor):

continuous championing and vigilance are seen as necessary

Coaches. That’s what coaches do — they champion your cause, lift you up and keep you on course.

Another link I like on this topic is Execution is a People Problem, not a Strategy Problem from Harvard Business Review. Not only does Peter Bregman specifically call out coaching, he closes with something similar to what I’ve been saying to my teams for years: Strategy execution is not a moment in time. It’s thousands of moments across time. It’s in the little decisions you make each day that affirm your commitment.

Looking at it from another angle, much has been said about the Spotify model for organizational culture. They believe in this coaching thing to the point that it is the third leg of their leadership stool (my metaphor, not theirs, as is the emphasis below):

A squad usually has three people who are the leaders and work together: someone who represents a product (a product owner), a technical lead or chapter lead who represents technology, and an agile coach who represents the process. The leadership principle is used at all levels, so a tribe or alliance will also have three people leading it from a product, technical and process perspective.

I considered a section on how prevalent coaching is in just about any other endeavor outside product development. Google tells me that the average NFL team has a head coach plus 15 assistant coaches and a roster limited to just 53 players. It’s not uncommon to read about business executives having a coach (perhaps in addition to a therapist).

Okay, so I did write a section on it, but at least it was short. Point is, coaching is a norm in situations where success is crucial. And in situations where change needs to be sustained in order to help it stick. Lots of folks have personal trainers (fitness/nutrition coach) or therapists (life coach). Sustaining change and growing through it are hard and few people, much less teams, make it entirely on their own. If it matters, it needs to be maintained.

So why is it so hard to for software development and IT organizations (perhaps any organization) to understand the value of coaching for their teams? It’s not as if the products and services that are created don’t have the potential to create impact. It’s not as if their success isn’t crucial. Is it some (perhaps misguided) assumption that managers are coaches? Unfortunately, I’ve seen that work out less often than teams spontaneously being agile and embracing continuous delivery on their own. Though this book could really help with that.

We need our teams focused on delivering great products continuously while harnessing technologies that are changing as they are building them. History (at least the parts I’ve watched) has shown that they won’t figure out the process changes necessary to do so quickly and with high quality on their own.

Invest in their future. Help them fly. Get them a coach.