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
A while ago, I was talking to my colleague Mary Thorn about the notion of agile “playbooks”. Mary had been working with a client in NYC and had developed a playbook for their agile adoption and practices. From her perspective, developing these sorts of:
Guidelines
Rules
Methods
Standards
Guardrails
Were invaluable for helping a large organization effectively transforming with agile approaches.
During the development and deployment of the playbook, she asked me to share my playbook. And the very question caused me to pause.
I’ve been an agile coach for ~20 ears, so I certainly have the chops. But upon reflection, I realized that I’d never, ever developed a playbook for a client. And I sort of busted Mary’s chops a bit around the idea.
Why you might ask?
I was in one of my Moose Herd (virtual Lean Coffee, coaching group/guild) meetings the other day and one of the folks asked a question about a team member they were coaching. I’ll try my best to capture it—
I have a team that I’m coaching who suffers from lots of WIP and they carry over between 30% and 40% of their stories per sprint. I’ve tried bringing up various ideas to help with this, but the team lead, a very strong character, always disagrees with any of my suggestions/ideas. They simply override me and consider it a non-problem. What coaching ideas do you have to change this?
The Herd group brought up quite a few suggestions, for example:
Better backlog grooming
Smaller stories
Discussion around WIP, Lean, and the importance of getting things done
Impact on forecasting and stakeholder trust
Talking to the persons manager
Perhaps trying Kanban, etc.
Everything we said the coach basically replied: Done that, tried that, didn’t work, give me something else…
Many agile folks have been talking about the dynamics and need for T-shaped skills when it comes to their agile teams. My colleague, Mary Thorn, has been a proponent, coach, and explainer of the notion for many years.
And, Kenny Rubin wrote a short and effective explanation in 2012 that you can find here - https://www.scrumexpert.com/knowledge/t-shaped-skills-and-swarming-make-for-flexible-scrum-and-agile-teams/
But, What about Leadership?
But rarely do we talk about T-shaped skills from leadership (or leadership team) perspective. So, I thought I’d spend a little time exploring what T-shaped leadership skills might look like…
If you know anything about me, you know that I’m a Rush fan. So, this article plays a bit of a homage to the song—Big Wheel. RIP Neal Peart.
This is a relatively short post, but an important one. I want to highlight an initiative that’s been going on for a while by Mark Summers and a bunch of other smart folks to define a model or tool for what solid, robust, and professional Agile Coaching skills look like. They call it the Agile Coaching Growth Wheel.
They’ve established a website called http://whatisagilecoaching.org/ Where you can find a description of the Wheel and other supporting information.
What I like about the tool is the depth and breadth of it. For example, the service-oriented aspects. Or the fact that it contains a consultative or advising component that I think is missing from some other models. Let me explore my previous go-to models before highlighting the differentiators in the Wheel.
I read a post by Scott Dunn that inspired this talk. I’ve known Scott for a while. He’s the principal coach/founder of Rocket Nine Solutions, an agile coaching & training firm. He recently moved from Orange County, CA to Nashville.
Since he’s now closer to me, and since Vaco’s headquarters is in Nashville, I’m hoping to collaborate more with Scott in the future.
But I digress…
The title of Scott’s post is – Your Culture is What’s on Your Walls. In it he talks about observing cultures by physical evidence and gleaning the culture by observation. I agree with his perspective and I liked the personal nature of the story. He also inspired me to extend the idea.
About 10 years ago I was an agile coach at a client organization and I was also acting as a Scrum Master for two teams.
I remember a director coming up to me and asking me, as the Scrum Master of a team with folks who reported to him, how was a specific engineer performing. He explained that he had concerns that the engineer wasn’t pulling his weight and he wanted some specifics to confront him with.
I remember my reaction viscerally to this day…
I got a sick feeling in the pit of my stomach;
I even felt a little weakness in my knees;
I struggled with what to say, knowing that the engineer he was talking about was indeed struggling;
I didn’t know if this was part of my role as a Scrum Master or not;
I wondered how he would take it if I declined to give him feedback;
I worried about the impact my feedback would have on the engineer…
It was a horrible experience because I wasn’t sure what to do. If I gave him the feedback, it would certainly compromise my role within the team. I guessed that it would get out and that I’d never really be trusted again.
AND, I was a part of the Scrum Team, wasn’t I? It would be like becoming a “snitch”. And nobody likes a snitch.
But if I didn’t give him the feedback, would it put me at risk?
In the end, I respectfully declined. I said that he’d have to observe the team in our sprint to sort out how everyone was performing. To my surprise, he accepted that reply. But I left feeling incredibly vulnerable and physically shaking.
