I was talking with a colleague of mine the other day about their experience beginning an agile transformation at a financial firm. Their executive team asked to be informed about agility and they gave him a 3-hour limit to their availability.
They considered this THE opportunity to get all of the leadership in’s and outs about agile so that they could lead the effort effectively.
To be honest, I’ve heard this all before. In fact, I’ve heard these sorts of things for ~20 years from senior leaders, stakeholder’s, and executives—
I need you to fill me in on everything there is to know about Lean, Agile, Scrum, etc. and I only have about an hour.
We’re locked and loaded on an Agile Transformation. Can you give me the executive overview? The executive team and I can only give you two hours.
The most we can give you for agile leadership training is 4-hours. And that’s a lot considering our priorities, so let’s just make the best of it.
If you follow my writing much, you’ve noticed that I often challenge traditional leaders to lean in to their own personal transformation when it comes to agile. At times, I think I’ve been quite hard on them.
I do this from a perspective of deep respect, and personal experience & empathy, and with the hope of inspiring emergent agile leaders.
CAL class discussion
In my last CAL class, we had a detailed discussion on trust. In that class, it was private, so composed entirely of leaders from a singular organization.
I was emphasizing the need for agile leaders to extend trust (freely give, stretch or reach out, give till it hurts) to their team members as they embarked on a new agile transformation. Another way I tried to express it was for them to—
We were in my Agile Moose Herd coaching circle and the question came up about a coaching firm that had come into an organization and said something like…
We want to focus on the future and don’t really want to look backward. It’s all about what’s in front of us. So, everyone, please let’s talk about agile going forward and not about what did (or did not) work in the past.
And the question was—
Was that a fair way to enter an organization as a coach? Basically, to place history off-limits to the discussions?
This made me/us consider the idea of entering an organization (group, tribe, company, system) as a coach or change agent and explore the first few steps you should be taking upon entry?
Here I capture where the discussions landed on an—agile coaching entry strategy with a client embarking on an agile transformation—
To say that I’m a Kim Scott fan is an understatement. I’m truly in love with her work around Radical Candor and her blogging in clarifying and providing stories of RC in action.
She recently published an article entitled—The Emotional Labor of Being the Boss. It was a story around her learnings of the importance of establishing relationships as a leader/boss. The topic was outside the bounds of what she typically shares, but it resonated with me just as strongly.
To give you a sense of it, here’s a snippet—
“Is my job to build a great company,” I asked, “or am I really just some sort of emotional babysitter?”
Leslie, a fiercely opinionated ex-Microsoft executive, could barely contain herself. “This is not babysitting,” she said. “It’s called management, and it is your job!”
Now, every time I feel I have something more “important” to do than listen to people, I remember Leslie’s words: “It is your job!” I’ve used her line on dozens of new managers who’ve come to me after a few weeks in their new role, moaning that they feel like “babysitters” or “shrinks.” We undervalue the emotional labor of being the boss. But this emotional labor is not just part of the job; it’s the key to being a good boss.
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.
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…
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
