I’ve always been a huge Pink Floyd fan. And Dark Side of the Moon is one of my top 100 favorite albums of all time. And Time is one of my favorite songs on it.
Here’s a snippet from the lyrics that I think serve as a fine entry for this post.
So you run and you run to catch up with the sun but it's sinking
Racing around to come up behind you again.
The sun is the same in a relative way but you're older,
Shorter of breath and one day closer to death.
But I digress…
I’m mature, experienced, or old enough to remember a time when software development was treated as a time-based activity.
You were measured by—
How fast you typed
How many lines of code you wrote (per hour, per day, per project)
How many hours you worked (typing as fast as you could)
How much time you spend (not typing) in meetings, writing documents, etc.
How quickly you could hack-together a design
How many bugs you produced
How many times you had to rework your code
How many breaks (bathroom, lunch, etc.) you took and for how long
I believe the thought at the time was—the more time you spend working, the more value you delivered to the company, the more you earned your pay. The optimization goal in this case was on time and production.
Sounds like a really good model, doesn’t it? And I’m not joking with the above. This was real!
If you’re a basketball fan and know who Allen Iverson is, then you’ll probably remember his infamous rant about “practice”. While he can never be questioned for the effort he put forth in games, he didn’t have a fondness for practice.
Now that doesn’t have much to do with coaching. Yet, I like the reference.
In this article, I did want to explore the notion of practice related to becoming a better coach. Both a professional coach and an agile coach.
A Sidebar
Not that long ago, I had a young woman sit down with me at a coaching clinic at the Scrum Alliance Gathering. She was a Millennial looking for career advice and she was very direct.
Bob, I want to achieve your level of expertise in the agile coaching community and I want to do it in a year. Please tell me how to do that.
Sadly, I don’t think my answer helped her nor was it well received. It was simply that…you can’t. And I wasn’t speaking from a position of ego. But from the position that it’s taken me ~20 years to acquire whatever skills I have in my journey. And I didn’t think that can easily be encapsulated and subsumed overnight or within a year.
A long time ago, in a galaxy far, far away…
I was visiting a client over the course of a 12-18-month period for some agile coaching when I discovered an interesting pattern. It seemed as if every quarter (3-4 months) or so they would reorganize their organization. Sometimes it was an overhaul reorg, with a massive shift for most folks. And other times, it was just a fine-tuning reorg, affecting only a small percentage. But on aggregate, it seemed as if everyone would get a “new boss” at least once a year.
Of course, there were different reasons for each reorg. Here are some of the drivers that were mentioned in passing—
We need to shift from a Project-based organization to more of a Product-based one.
We lack accountability and ownership within our teams. We’re going to shift management around and declare a “Team Lead” for each team.
We’re adopting LeSS (or Spotify, or fill in your agile scaling framework), which recommends flattening management layers within the organization.
We just merged with/we acquired by (Company x) and we need to aggregate our two groups into one unified team.
We’re simply not getting enough done. We wonder if a reorg will help? Shaking things up a bit if you will.
Now that we’ve “gone Agile” we have far too many of this “role” and need to flatten things out a bit.
We’re not happy with the results from the last reorg. Things are still not getting done and we want to further streamline the organization.
Change happens. Shift happens. So, get over it.
All of which gives you a flavor for the very typical rationale for reorgs that I’ve seen across my 20 years of coaching experience.
I saw the following post on LinkedIn from my colleague Maurice “Mo” Hagar –
"Fostering a new mind-set and creating a new culture is no easy feat."
https://www.strategy-business.com/article/Creating-an-agile-mind-set-at-PepsiCo?gko=20fae
Good read. I've done Agile coaching since 2005. Back then it was easy: stand up a Scrum team. Today we're doing business agility, at scale, across the enterprise, and that's not so easy. Because it's no longer about "Agile" and local optimization but about the "business"--mindset / culture and outcomes--as it should be.
There are two kinds of Agilists in the world: 1) those who talk mostly about Agile, and 2) those who talk mostly about the business. Don't mishear me; I'm all for all that "Agile" means. But the most important thing I've learned at IBM, my primary client for the past two years? "Show me results or I'll show you the door."
That sounds harsh but it's how the game of business is played—all professional sports, in fact. And many of us Agilists need to up our game. While we're talking Agile, all the execs hear is "blah blah blah." Because they speak one and only one language: $$$. If you can't go there go home.
You can view it and the replies here - https://www.linkedin.com/posts/mauricehagar_creating-an-agile-mind-set-at-pepsico-activity-6603998919653421056-1Clb
I have just a couple of responses to Maurice’s comment…
I got into a debate with a coaching colleague the other day. Well, debate, disagreement, argument, and other terms could apply. We kept it respectful and, in the end, I believed we agreed to disagree.
I’ll call my colleague, Ken.
We used an analogy as part of our discussion that I’d like to share. Here’s the analogy—
Meniscus vs. TKR?
I’ve got a problem with my knee. I’ve done the web research and self-diagnosed that I have a partially torn meniscus and I want some simple surgery to clean-up my knee and fix the meniscus.
So, I start looking for the best surgeon I could find. The best “knee-person” out there. And I found her. She’s expert at all sorts of knee surgeries from the meniscus to total knee replacements. Having performed thousands of successful surgeries.
I scheduled a visit to explore the surgery. And she runs some tests (X-rays, MRI, etc.) on my knee in advance of our discussion.
I enter the discussion telling the doctor what I need. I even go so far as telling her when to schedule it. As, clearly, I’ve determined what wrong and what to do about it.
She listens patiently but tells me clearly and firmly that I need a total knee replacement. That my knee is irreparable with anything other than that sort of corrective procedure.
I argue with her. And I insist that I simply want the meniscus repaired. I’ve made up my mind AND I want her to do it…
Ask vs. Need
Clearly, in this example the doctor has a decision to make. And I don’t think it’s that hard. The options are:
Our local agile ALN group has an annual tradition of doing lightning talks on the last meeting (November) of the year. The group coordinator kindly asked me if I wanted to participate and, since I was in town, I enthusiastically agreed.
But then the hard part began. I would have 5-minutes to talk about anything I wanted to. But only 5-minutes.
I struggled to figure out what to focus on until the day of the meeting. The pressure was building. And yes, I had a gazillion ideas that I could share, but nothing had risen to the top. Around 2 pm something came to me.
Within the agile community, I’ve seen quite a few examples of folks doing a, how do I say it, Failure Bow. To be frank, I didn’t know what it was all about. Sure, I get the gist of it. But where does it come from? And what are folks trying to represent by doing it? I never quite knew the backstory.
I also discovered that there were also several forms of it. There was the in-person failure bow. For example, a speaker making a mistake in front of their audience would do it.
But I recently received some email from Scrum Alliance folks that had mistakes in them. The senders then did virtual failure bows via follow-up emails. I’ve even seen folks do it via #failurebow in the twitter (and other) streams.
It made me want to explore it a bit deeper. So, I did.
I received a LinkedIn message from an agile consulting firm asking if I’d be interested in an opportunity. The had two levels of agile coaching opportunities available.
They were:
I sat back and I sighed. I’ve never charged rates this low for any coaching I’ve done…ever. I’ve got somewhere between 15-20 years of agile coaching experience from team level to project/program level to enterprise level including leadership coaching.
When I looked at the specification for these roles, the Sr. Agile Coach role had Enterprise level coaching requirements at my level. But from my perspective, the compensation was at a level that would not fairly compensate qualified agile coaches, nor even Scrum Masters.
In other words, they wanted Filet Mignon at Burger King prices. (with all due respect to BK)
Even Sadder
But what makes me even sadder is that there are people “agile coaches” in the world who will happily work for these rates.
Why?
Largely because they’re agile coaches in name only. They gain a bit of experience and then immediately call themselves an “Agile Coach”. For these folks, the compensation makes a whole lot of sense.
However, they’re leading with paper experience and bravado and not real experience. It’s a game of smoke and mirrors and the clients are the ones that lose in that game.
They are commoditizing agile coaching and driving down compensation rates for all of us. And the rate compression also minimizes the value of real-world experience and skill.
I was teaching a class the other day and folks were very distracted. Even though the class had been scheduled for months and everyone seemed committed to it, the following happened:
People were running in and out of class to attend meetings
Many were checking email on their laptops and phones
Several leaders, who were scheduled to attend, totally bailed out
Several “emergencies” came up that needed immediate attention
Believe it or not, this often happens during my classes. And I’m not that bothered by it. Meaning, I try to ignore the interruptions and focus my attention to those who ARE present. And who do want to add more skills and thinking to their practice of agile leadership.
That being said, I’m not writing this article to complain. But instead to make a very clear point…
It’s a CHOICE!
I sometimes think that I’m the only agile coach who supports “management” and “leaders” in agile contexts. And I’ve written quite a few pieces with that perspective. For example –
http://rgalen.com/agile-training-news/2014/11/23/agile-coaches-trainers-have-you-walked-in-the-shoes-of-technical-management
So, I was surprised and delighted when I read this piece from Jason Little – Why Executives Don’t Go to Agile Conferences.
Based on the title, I thought Jason would join a long list of agile thought leaders who take a few swipes at executives. But when I got into it, I realized that he showed far more understanding and empathy than I could have imagined. Here are two quotes from the article…
It astonishes me to see so much information about bad leadership, and how executives don’t care because they can’t spare a day at an Agile conference to explore how to run more effective retrospectives. I don’t think many pundits have a clue how much stress these people have on them, and that executives are people too. Sure, some may behave in a more forward way, which is usually perceived as command-and-control, but from my experience, it’s not the case. They’re just busy.
