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 don’t believe I’ve ever read any guidance around ENTERING a coach. Well, other than “plopping” (parachuting, dropping, etc.) them into a situation and telling them…
Go Coach!
And this is less about how the coach enters, but more about how the organization’s leaders explain things before the coaches engage.
For example, the following questions need to be answered and communicated before the coaches ever enter the engagement—
Have you ever worked with a person who simply never turned off? They’re constantly moving, ideating, suggesting, working on projects, email/texting/slacking all at the same time, etc.?
Also, they’re often talkers. And I mean, hard to get a word in, talkers.
Thoughts like –
Energizer Bunny!
Could I get me some of whatever is helping you do that?
I can’t take it anymore, please sit down!
I’m exhausted just being around you.
My goodness, go take a nap…
Run through your head.
In organizations, these people are often highly regarded. In corporate speak, they get shit done. They’re often the fire-fighters who are “assigned” to problem areas, projects, or difficult tasks. They’re go-getters and doers.
And, to contradict what you might be thinking, I don’t have a problem with these folks. At all.
This post is inspired by one from John Cutler.
I want to take a diversion a bit on John. I was talking about his article at our Agile Moose Herd the other morning. I shared that he is one of the “Top 10” folks in our industry (agile, products, transformation, culture, etc.) that makes me think more deeply with everything he writes. John is a thought-provoker, a leading-edge thinker, and a courageous writer. He often says, what needs to be said, before anyone else is saying it. I truly appreciate his voice!
Now, back to the post. It was fairly short and entitled—Kryptonite and Curiosity.
John started out by exploring common organizational phrases that can be kryptonite in nature. That is, they can trigger a negative response in us. For example—Bring solutions, not problems, was one of them. You get the idea.
I’ve been thinking a lot lately about critical aspects of folks going down an agile transformation. For example, I recently delivered a lightning talk at a local group focused on well-being indicators in agile organizations. I was intentional in not saying the word “metrics” or “maturity” in the talk, as they imply some sort of range or specificity that I didn’t want to imply.
Related to that talk is this post. I wanted to think hard about the most critical leadership patterns (habits, tendencies, attributes) that stand between leaders effectively and personally adopting and supporting an agile mindset. Anf four critical areas came to mind as anti-patterns, horsemen if you will, that need to be avoided…
Perhaps you’ve heard some of these statements from your leadership teams over the years? I certainly have…
Bring me sufficient data to convince me of your idea
I have information you don’t have that is driving my decisions
Don’t think, just do your job
It’s above your pay grade
You don’t have a need to know
I get paid to make these decisions, you don’t
Don’t bring me problems, bring me solutions
You’re either part of the solution or part of the problem…
I was in a conference session a few weeks ago. We were talking about the balance many agile organizations struggle with between investing in—
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…
In a recent blog post by Mike Cohn, he wrote about Establishing a Common Baseline for Story Points. He explores the technique of getting estimators in a room from many teams. Perhaps a pair of individuals per team.
The entire room uses Planning Poker to estimate stories. The focus is on getting all of the folks in the same ballpark when it comes to estimating their stories level of effort.
The idea is not to have everyone become a clone of each other. But to get the story points close enough so that forecasting can be done across the teams. So, consistency without normalization or fixed rules.
Not only do I like this approach, but I’ve also successfully used it with several companies where I’ve coached. Not as an external coach, but as an internal coach. And it works quite well.
I was reading an article from Mike Hall of Agile Velocity entitled The Most Important Question to Answer for Successful Agile Transformations. I’ve known Mike for quite a while and he’s an incredibly practical and skilled agile coach. So, I really wanted to explore the question. Point being…he had me “hooked”.
In the article he talked about how establishing a Business Objective was a crucial first step in any agile transformation effort. I’ll reframe it to be—your Compelling Why.
9 Typical Business Objectives
Mike spoke about Agile Velocity’s, Path to Agility framework having 9 business objectives that they typically try to uncover with their clients:
Employee engagement
Customer satisfaction
Quality
Speed
Predictability
