Not that long ago, I wrote a blog post that was inspired by Kim Scott, the author of Radical Candor. She had written a very brief note around a leader’s responsibility to receive feedback, as well or better than, they are at giving feedback.
And many leaders, to put it mildly, suck at receiving feedback.
And you want to know another surprise? Most of them are unaware of this blind spot. They think they’re great listeners. But they’re not.
They are simply not self-aware!
Frankly, I’m tired of all of the scaling frameworks. They’re mostly driven by three needs:
Creating revenue for the firms creating them;
From a company or organizational perspective, they’re indicative of lazy, buy agile in-a-box, thinking;
And they feed the “certification happy” nature of our community.
And yes, I too am guilty of falling into the above traps.
I think the introduction of Scrum@Scale has ticked me over the edge and inspired me to write this post. That and reading this article by Neil Perkin, which takes a more reflective view to leveraging useful bits from the various scaling frameworks.
There are individuals who have influenced my professional journey significantly. Sometimes, by working with me directly. Other times, by their writing or position in our software community. And other times, simply as a role model.
I've started a segment on my blog called – My Heroes. I’ll post intermittently, perhaps every 1-2 months. But it serves as a reminder to me to be thoughtful and appreciative of the folks who’ve influenced my growth and skills. And of course, they get none of the credit for my many foibles.
The fifth one up is actually a pair of individuals.
In 1994, close to 25 years ago, Dorothy Graham & Tom Gilb authored a book entitled – Software Inspection. It became the de facto standard guidance for how to conduct artifact and code reviews for software development.
Now that doesn’t mean we “got good” at inspections. No, for decades following the books writing we still basically sucked at it. But it means that we had no good excuses for that. Dorothy and Tom had provided a wonderful recipe that many (most) failed to follow.
My colleague Don MacIntyre invited me to attend and co-teach his Scrum @ Scale Certified Practitioner class in Raleigh, NC last week (September 10-11th, 2018). It was in my hometown so how could I refuse.
It was a 2-day class with ~20 attendees. There was a nice mix of agile and Scrum experience across a spectrum of well-known companies leveraging agile at scale. We even had one gentleman fly in from India for the class.
Don spent most of the time teaching, but I had a few opportunities to teach basic Scrum and contribute to our general coaching conversations. Overall, I think the class went very well.
I have a confession to make. I’ve fallen into a trap and I need to get out of it.
Gosh, Bob, what’s wrong? What is it you might ask?
I’ve been saying: “The Scrum Guide says” way too frequently. It’s almost a daily mantra and I suddenly realized that I need to stop it.
The ScrumMaster role is one of those that is simple and complex at the same time. I often speak in terms of doing agile and being agile, and the ScrumMaster role strongly influences their teams in both of those dimensions. Of course, the latter being much more difficult to manage and get right.
The good news in this space is that there are a few really solid books that explore this important role within Scrum.
It’s funny really. One of the key points of the agile methodologies and the manifesto is heavy collaboration, with the best being face-to-face collaboration. But one of the things I see happening in teams all of the time is, how can I say this delicately, over collaboration.
In other words, the teams, ahem, talk too much. There, I said it And I’m referring to open-ended discussion that takes too long if ever to narrow down towards a decision. Folks seem to be talking to hear themselves talk. Often it’s not everyone, with a few heavy talkers dominating discussions and the rest seemingly along for the ride. So it can be quite unbalanced.
In facilitation terms, there are two types of discussions going on when a team is trying to make a decision. There are divergent conversations, where options and ideas are getting put on the table. This is the brainstorming side of the discussion. And then there are convergent discussions, where the team is narrowing down options in order to make a decision.
A ScrumMaster asked me the other day how they should handle the situation where half their team doesn’t seem to care about the work. They don’t seem to be motivated. They seem to be slacking…a lot. And where two individuals seem to be doing all the work. And they seem to be burning out.
A senior leader in an organization that I’m coaching asked me the following when he found out I would be meeting with his boss. He asked me to tell him that they have too much work to do. That they are being stretched over capacity and that it’s causing delivery, quality and morale problems. In fact, the house of cards is about to fall.
I was training a class at a client the other day and three individuals, not at the same time, asked me to escalate their impediments. One impediment was that their leaders were excessively interrupting the sprints. Creating chaos. Another was that the priorities changed constantly. And the final, small problem, was that the leadership team expected the team to exceed their capacity by 350%. They wanted me to address these (fix it) with their organizational leaders. And, believe it or not, they were all serious.
This is a bit uncomfortable for me to admit, but I have some confessions to make…
I’m a SAFe SPC;
I’ve attended a 2-day Nexus training;
I plan on attending / co-teaching Scrum @ Scale with Don MacIntyre in September;
I’ve studied (I mean studied!) and contrasted DAD and LeSS;
I’ve actively coached SAFe organizations;
I’ve been leveraging simple scaling techniques (Scrum of Scrums, bits of SAFe) for well over a decade.
So, it’s fair to say that “agile scaling” is in my bones, in my DNA, and that I’m fairly experienced. And it’s incredibly easy for me to meet a larger scale client and begin discussing scaling aspects quite early in our coaching relationship.
I have some coaching acquaintances who’ve joined a relatively large firm. They’re tasked with being the internal agile coaches and leading the organization’s agile transformation.
Several times members of the organization’s leadership team have reached out to me to come in and discuss various aspects of high-performance agility. Topics like culture, scaling, and leadership agility was of heavy interest. I think they were simply looking to get an outside, experienced coach to come in and provide insights. Not undermine the internal coaches.
But each time the internal coaching team squashed the inquiry and insisted that they do the session. In fact, in other cases of invitation, they wanted to go over my “talking points” to ensure that I wouldn’t say something that differed with their guidance or perspective. Given that level of scrutiny, I respectfully withdrew any interest.
This is an actual example. But I’ve seen and heard it repeated many times in my own agile journey.