I'm Not Just an Agile Coach!

If you browse through my LinkedIn profile, you'll see more than a dozen roles in the Experience section with the title "Agile Coach". What do I really mean when I use that title for myself?

Four years ago I published an article here on LinkedIn called "What Do I Do as an Agile Coach". In that article I mentioned how anyone can call themselves an Agile Coach and there isn't much we can do about it. That's OK, because I did a similar thing in the mid-2000's, although my background is a little different than many coaches you will encounter today.

And that's what I'd like to convey in this article.

By the time I learned about Extreme Programming (XP) in 2000, I had been developing software professionally for 12 years. I had a good reputation as someone who could deliver solid products pretty much on time. At that point I had a "toolchest" of methods, practices and sometimes even code that I used from contract to contract.

With XP, the values, principles and practices resonated with me immediately. I had already been in situations where several of the XP practices had been used, such as having an onsite Customer who interacted with the team daily, a co-located team sitting together in one space, frequent releases and relative estimation among others. The principles of feedback and embracing change were ones to which I had adhered for years! Later, as I had the opportunity to use XP as the approach with a team, I realized that I was fulfilling one of its key roles - the Coach.

Ron Jeffries was the original team coach while working with the Chrysler Comprehensive Compensation (C3) team at Chrysler in the mid to late 1990's. While he didn't invent XP, he helped the team stay on track with the practices and leveraged his even then considerable experience in software delivery. He, with the help of others, also helped the C3 team adapt over time to practices that worked the best for them in their circumstances - the team members, the technology and the business domain.

On the mailing lists and the original wiki, I interacted with Ron as well as other early XP proponents such as its main inventor, Kent Beck, as well as Ward Cunningham, Martin Fowler, Alistair Cockburn, Jim Highsmith and many others as we explored XP and how it helped teams deliver better software. I cannot thank all of the contributors to those platforms enough for what was essentially a post-grad program in how to deliver software effectively!

At about the same time, the meeting at the Snowbird, Utah ski resort occurred at which the term "Agile Software Development" was coined. It was intended to replace the previous umbrella term of "Lightweight Methods" used to describe the several different but related methods that were created in stark opposition to the standard heavy delivery methods of the time. This roughly coincided with me leaving a contract where those standard heavyweight methods had been used and I was left saying to myself, "There has to be a better way!" Well, XP sure as hell seemed like that way in those days, at least for individual teams!

My toolchest expanded significantly!

After trying XP out with a colleague in 2000 and early 2001, and then successfully introducing XP to a different group in 2001-2002, I saw the possibility of working in Ron's role of XP Coach except in a consulting capacity. I spent a few years honing my skills as a "player/coach" and eventually was able to move into that "pure coach" role in 2006. However, the world had changed a bit by then!

One of Extreme Programming's strengths is also it's biggest weakness - the word "Extreme". Kent Beck chose the term to invoke thoughts of extreme sports and the willingness to take risks for large rewards. While many teams and organizations decided that was great, more were turned off by any notion of risk. After all, good project managers were trained to avoid risk at all costs! The reaction was to sanitize the name by just using the more acceptable term "Agile Software Development". With that change, XP Coach became Agile Coach almost as if it was a simple global search & replace!

By that time as well, I had been turned on to Lean Software Development from Mary & Tom Poppendieck, and by extension the lean underpinnings of all agile methods. This opened my eyes to a whole new world of understanding the flow of work through teams and organizations and how to positively affect it.

I also started to learn much more about team dynamics and especially how to use Retrospectives to help teams identify where they could improve how they work. For this I have Esther Derby and Diana Larsen to thank, since what I learned from their work expanded my toolchest again with some of its most important principles and practices!

As the decade of the '00s came to an end, the questions were no longer just about how to "become agile" but also "How do we scale this across an organization?" Indeed, that question had been around since at least an early 2003 conference I attended. The question of scaling brought with it a whole new set of challenges and more tools for my toolchest!

First and foremost was, "Do you really need to scale?", and how to answer that question. When the answer was "yes", then we needed to decide how to approach that. It was at this point, in 2010 and 2011, that I learned the LeSS approach from Craig Larman, and how to apply it. More tools!

A couple of years later I worked as an internal coach at Shopify, where the "Do you really need to scale?" question was answered with a resounding "No!" In that group we used CI and CD to get multiple features into production on a daily basis and I saw what would become DevOps in practice. Toolchest expansion once again! I should note as well that, when I left there in 2014, there were 22 development teams, none of which was using the exact same process. That, to me, was a strength!

In subsequent years I've been a manager, which taught me even more about team interactions and how to (and sometimes how not to) create an environment in which your team can flourish and deliver great products! I've also worked in many different domains where "production" being down could mean, quite literally, that hundreds of millions of dollars in transactions couldn't be processed! I learned some crossover lean techniques at a large auto company where the team I coached was working with software to optimize an assembly line. There were some counterintuitive practices that, again, were added to my toolchest.

Finally, during the first year of COVID, I attended courses on product management and learned a ton about that aspect of delivering products.

Needless to say, after 35 years in the industry, my toolchest is now pretty big!

Something you'll notice is that I haven't mentioned Scrum to this point, nor have I said anything about certifications. I could have been a Certified ScrumMaster (CSM) after working with Craig Larman and attending his training (which was more of a master class in Lean than a CSM course!), but I chose not to on a matter of principle. I already knew a lot about the use and application of Scrum at that time (2011), but many people who obtain the CSM have only sat through a 2-3 day course and passed a short test which was easy if you listened. The certification is for precisely that - it certifies that the attendees listened in the course, rather than really understood what Scrum is all about. There are exceptions, of course, but they're few and far between in my experience.

Today I encounter many people whose title is also Agile Coach. Many of them are very well versed in team dynamics, are Scrum experts and may even have certifications such as the Certified Scrum Coach or Professional Scrum Coach.

I'm not one of those coaches.

It would be more honest if I were to undo the global search & replace I performed in the mid-2000s and state that I'm an XP Coach. I'm also a Lean Coach. I've coached teams in properly using Kanban. I've also managed and coached teams where we started with pretty much no process at all because our work was highly experimental - we didn't know if it would work, let alone when. I've coached and managed teams that had hard delivery dates to be able to show new work at trade shows.

What you get with me is someone who can tick the standard Agile Coach definition box, but I have so much more to offer. I remarked recently that there was a day a few months ago where I was pairing with college interns on some Typescript code in the morning and had a strategy discussion with the CEO in the afternoon. I can work directly with the testers in a group as well as with the product managers.

People like to talk about their "superpower" these days, and I'd say that mine is exactly that: versatility. That's what helps me work holistically with organizations - I have experience with practices that apply to all levels within a product or project delivery group.

I'm not just an "Agile" Coach!