Coaching

An Agile Seat at the Table

An Agile Seat at the Table

There are two aspects I’m noodling on in this article—

  1. Having a Seat at the Table, versus…

  2. Having a real Seat at the Table.

Then,

  1. Being empowered and supported to effect change, versus…

  2. Having real empowerment and support to effect change.

In an agile transformation to an agile mindset and agile ways of working. You might be asking—what’s the difference? Well, I’ll share some stories to explain, but before that, I should explain the role context here? Who am I referring to? Well, it could be anyone tasked with guiding an organizational agile transformation. For example:

  • An Agile change agent;

  • A Director of Agile Transformation;

  • An Enterprise-level Agile Coach;

  • An Agile PMO Director or Leader;

  • Or the Agile Steering Group.

Should be considering the following recommendations.

When to Coach the Problem versus Coaching the Person

When to Coach the Problem versus Coaching the Person

I received the following question from another agile coach the other day…

I'm wondering if you might have a solution for an issue. Within the Agile Coaching Circles, we see a lot of "coaching the problem, not the person." This is regardless of where the circle is located: Europe, Africa, Australia, or North America. We've done the "temperature" exercise, where the more impactful the question, the higher the temperature. However, I'm on the lookout for other exercises to do with groups to help them understand the difference between problem/person. Might you have any ideas? I've got this question in a few different Slack channels and so on, but so far, nothing is coming up.

And here are two resources that help to illustrate the challenge associated with the question—

https://www.youtube.com/watch?v=MYfmo8qvPSA

https://static1.squarespace.com/static/57adc4fa46c3c4f7faf7e4c5/t/5e1f83963315a227f1a0483c/1579123617420/Coach+the+Person%2C+Not+the+Problem+edited.pdf

Here's my reply…

Coaching the Brine

Coaching the Brine

In Prescott’s Pickle Principle, Gerald Weinberg shares the metaphor of cucumbers (people) and the impact that brine (company cultures, systems) can have on them (pickling). The notion is that if you are a change agent you need to be aware of the fact that you (the person, the cucumber) may be pickled by the brine (the culture) before you can effect change on the culture. That you can become “part of the problem”, if you will.

And there’s a bit of subtlety to it in that many of us are unaware (lack the self-awareness) that we’ve been pickled.

I was reminded of the principle just the other day when I read this LinkedIn post by Magnus Hedemark.

Lately, I’ve been thinking of a corollary to the principle.

Sure, as an agile coach, particularly an embedded or internal coach, I can easily become pickled. But what if I actively coach the brine instead of the cucumbers? What if I intentionally spend the majority of my time at the brine level?

Measuring the Effectiveness of Agile Coaching and Coaches

Measuring the Effectiveness of Agile Coaching and Coaches

I’m just now finishing up my agile coaching book and I’ve been thinking about aspects that I may not have adequately covered in it. Measuring agile coaches/coaching and the impact rose to the top of my mind. And as I considered my writing history in this space, it dawned on me that I had never tackled it directly and I began to wonder why?

I think it’s because I don’t like or agree or resonate with the idea of discretely measuring agile coach or coaching performance. Why? No, it’s not because I’m afraid to be measured or held accountable in some way. Mostly, it’s because I don’t think it’s relevant.

The very nature of agile coaching is helping others to experiment, to learn and adapt, to change, and to improve their results. It’s not about measuring the coach. It’s about the performance of who they are coaching that truly counts. That is measuring the individuals, leaders, teams, or organizations that are being coached.

For example, if I’m coaching a Product Team (Chief Product Owner, Product Managers, and Product Owners) in an agile instance do they…

  • Improve the ROI driven across products?

  • Connect more to their clients? Envisioning better?

  • Work more cohesively as a team and are better aligned (horizontally & vertically) across other functions?

  • Are they learning more effectively as a community of practice?

  • Are the leaders operating more as Catalyst leaders? (See Bill Joiner’s work on Leadership Agility)

If these and many other measures are trending positively and improving, then I might be a strong part of that improvement. But while I, as the coach, am part of the system, it’s the system that improves and it’s the system that should be measured.

But I do have a few thoughts on effective measures of the coach that might be separate from the outcomes they are contributing (or not contributing) to.

What Type of Agile Coach are You?

What Type of Agile Coach are You?

Michael de le Maza offered the following metaphor for agile coaches and coaching on LinkedIn the other day

Pebble agile coaches vs. Diamond agile coaches.

Pebbles are well rounded. Diamonds have facets.

If you go to a restaurant and they have Chinese food and Italian food what would you think? What if they had Opus One and Two-Buck Chuck?

You wouldn't like that restaurant, right?

And yet many agile coaches pride themselves on being well-rounded. They coach Scrum and Kanban teams. They coach executives and individual contributors. They coach flow and culture. They coach marketing teams and software development teams.

These are pebble agile coaches. They are well-rounded.

Diamond agile coaches have facets. They specialize in one or two areas.

Think about the great agile coaches you know.

Are they pebbles or diamonds?

What do you want to be?

Here’s my LinkedIn reply:

Michael, it almost sounds like I have two choices as an agile coach:

Become (or stay) a pebble and say yes to everything. Stay average, stay mediocre, stay "pebbly". That being well-rounded is, in some fashion, bad or not good.
or...
Become a diamond. Shine in a few areas. Be excellent in a few things. Say no to things when I don't have the excellence or brilliance to meet the need.

I wonder if there is a sort of middle ground if you will and not polar or binary opposites? For example, can I become a cabochon? Can I be well-rounded AND shiny/with rounded facets?

I guess I don't view well-roundedness as a coach as being something less attractive. Saying 'yes' to everything, probably not a good idea. But, at least for me, I'm aspiring to be a well-rounded, shiny, cabochon of a coach ;-)

More details…

Agile Coaching Ethics - Front AND Center

Agile Coaching Ethics - Front AND Center

An agile coach, who I’d never met before, reached out to me the other day to have a conversation. She was from India, working in Europe, and had a woeful tale that she shared with me…

It seems as if she had two similar experiences as part of different agile coaching teams. In each case, a lead agile coach (who was male, white, and experienced) misused their authority and positional power when collaborating with her and other female coaches on their teams.

Apparently, those coaches/leaders were…

  • Authoritarian to the point of abusing their positional authority;

  • Intimidating, overpowering, and dismissive to women;

  • And, when confronted with their behavior, they ignored all feedback AND made things worse.

Because of the corporate culture around her, the poor coach felt that there was no place to go for help. So, she simply tolerated it until she found a way to leave the job.

As I said, this repeated itself one more time at another organization.

Agile Coaching versus Professional Coaching

Agile Coaching versus Professional Coaching

I think many in the agile community get confused about the difference between Professional Coaching (as defined by the International Coaching Federation or ICF) and Agile Coaching (as explained within the Agile Coaching Competency Framework or Agile Coaching Growth Wheel).

The clarity problem actually begins because the ICF definitions (certifications, competency models, ethics, etc.) are VERY clearly identified. And, since everything is so clearly defined, the many organizations who have ICF training are consistent in approach as well. There’s great clarity when a singular organization forms around a profession to capture its essence and guide its evolution.

The profession of agile coaching, if I can use that terminology, isn’t nearly as clear. It’s fractured, ill-defined, inconsistently agreed on and composed of organizational factions. The two frameworks I mentioned, while aligned, don’t agree on the standard coaching stances that make up Agile Coaching. Nor do any of the leading certification bodies (Scrum Alliance, iCAgile, Scrum.org, or Scaled Agile Framework). As I said, there is some commonality, but there is no way near the clarity that you gain from ICF in Professional Coaching.

The clarity problem is further exacerbated because I believe Agile Coaching is a superset of Professional Coaching. In other words, Professional Coaching is an activity (or stance) that is practiced while Agile Coaching. But it isn’t the only stance.

Even Agile Coaches are Confused

The 3-R’s of Agile Coaching

The 3-R’s of Agile Coaching

I was reflecting on the craft of agile coaching the other day. As I often do, I was thinking of areas that are important in my coaching competency or my focus.

Sometimes, when I’m reflecting like this, I get way too much information to consider. But this time, something simple and clear came out of my reflection and I thought I’d share it with you. It’s a metaphor I’ll refer to at the 3-R’s of Agile Coaching and my focus on them has been increasing the quality of my coaching. Let’s explore each ‘R’ in turn.

Relationship

I’m continuing to discover that relationship is the center of everything in my coaching. And when I say relationship in this sense, I mean—

  • Relationship with myself;

  • Relationship with my individual clients;

  • Relationship with my client system(s).

I most actively see it nowadays in the intentionality I have in entering spaces and the meta-skills I bring into play. But I also am more intentional in creating, fostering, and building my ongoing relationships with my clients. This ‘R’ reminder me that the key is being more intentional in how I’m “showing up”.

Extraordinarily Badass Agile Coaching

It’s finally here. What’s here, you might ask?

My new book.

Cool! What’s the title?

Extraordinarily Badass Agile Coaching

The Journey from Beginner to Mastery and Beyond

About the Book

The profession of Agile Coaching is, in a word, confusing. That’s because of a number of factors, including:

  • It gets conflated with Professional Coaching and it’s so much more than that;

  • There isn’t a standard or generally accepted model for what it is and isn’t;

  • Clients don’t understand it, so shared accountability is unbalanced with their coaches;

  • There is specialized nuance around the skills of coaching at the Team, Enterprise or Organizational, Technical, and Leadership levels.

This confusion has created a space where nearly anyone can claim to be an Agile Coach with little experience and narrow skills. Resulting largely in mediocrity and negative impacts for our clients, who by the way, are counting on and paying us for help.

Bob Galen has written Extraordinarily Badass Agile Coaching to help alleviate the confusion. The book centers on the Agile Coaching Growth Wheel as the competency and skill maturity model to baseline your agile coaching skills against. Its core goal is to “raise the bar” as to what true excellence looks like and to help you establish a personal development and growth plan.

Bob intentionally uses the term Badass to create a vision of professionalism, craft, passion, accountability, and expertise that you need to bring to bear in service of your clients if you represent yourself as an “agile coach”.

Being an Extraordinarily Badass Agile Coach isn’t easy, quick, or for the faint of heart. It takes lots of hard work and dedication. It also requires a map to point you in the right direction. Consider this book that maps to coaching badassery, personal growth, and client service.

Sample Chapter

If you’re “on the fence” about whether the book is right for you. I’d recommend reading the Introduction, as it explains the intent, overview, and major themes within the book.

Getting a copy?

If you’re mostly interested in e-copies, I’d recommend purchasing your copies from Leanpub. You get more version flexibility that way AND you’ll be able to receive future updates too.

  • Amazon versions are available here Paperback & Kindle.

  • Leanpub (PDF, EPUB, and MOBI) versions are available here.

Landing Page

Once you get your copy, you’ll want to check out the book’s Support & Repo Page for helpful information and ongoing shares & updates.


Why over Way!

I often see something that I re-post on my blog. Something that I think is thoughtful, compelling, and useful in our agile journeys.  

Some folks influence me more than others. John Cutler is one of those. Here’s one of John’s posts that I just had to share with you. I like it that much…

I continue to encounter agile coaches / transformation coaches who position the Why of "digital transformation" as "agility" or "learning faster" or "a mindset shift". When I ask what the burning business need is for agility, outcome-centricity, product thinking, learning faster, or a mindset shift, they often don't know. When I ask about the existential threats to the business, they don't know, or they respond with something very high level like "innovation".

I ask more questions..."will the business exist in ten years if the status quo remains?" ... "what is the biggest product fail of the last year?" ... "where would learning faster and experimentation have helped?" Not sure. "Would you invest in company stock? Why? Why not?" Not sure. "If things were working, what would you observe?" "Well, more empowered teams". Why? Not sure.

To me, this is putting the Way before the Why. The goal isn't product transformation. The goal is what product transformation will enable!

You have to know the business reality. For example...

"At the moment our commercial business accounts for 60% of revenue, and consumer business accounts for 40%. We're paying more and more to keep that 40%, and despite our efforts, we're losing to upstart fintech companies that know that demographic better, and aren't saddled down by the weight of a commercial business. If we can't figure this out, we'll continue to lose market share, and our share price will plummet. Meanwhile, the commercial side of the business is rife with opportunities to use data science to streamline operations and eek out margin. Supply chain disruption will eventually get us there as policies come up. The three major efforts from last year fell flat with no outcomes. We need to do better in a highly complex environment..."

"And this is how product thinking can help....[here]"

You have to know this stuff like the back of your hand. Listen to every investor call. Know the existential threats to the business. You have to think like a business person and an entrepreneur. Otherwise, you'll find yourself just going through the motions.

The goal isn't agility. It is what agility enables. Same with product thinking, DevOps, rate of learning. Etc.
Why over Way.

I hope found it valuable. Stay agile my friends,

Bob.