I was chatting with some colleagues the other day and the topic of agile maturity came up. Particularly for Technology Leaders who are inquiring about agile approaches.
These could be leaders who are new to agile and want to start the transformation OR leaders who are currently engaged in a transformation and looking for assistance.
The questions were around, how to tell IF:
- Do they truly “get” or understand agility?
- Are they really “ready” for it?
- Are they serious about it?
- Are they a good candidate for a coaching engagement?
- And, are they properly aligned with the principles of the coaching/consulting firm?
Some of the questions focused towards money. In fact, quite a few of them. Questions here were around budgets, the contractual/approval process, and payment terms.
I was almost embarrassed to admit that these are not forefront in my mind when I’m engaging clients. My feeling is that they sort of take care of themselves. What I care more about is how I perceive the Inspection Report - February 2017 client’s answers to the first set of questions AND how do they align with my own principles.
I was writing another blog post about the lack of an agile engagement having a cohesive coaching team and it dawned on me that I’ve never shared what an agile coaching team might look like.
Given that inspiration, I thought I’d spend a few minutes discussing aspects of creating (finding, forming, and building) a great team of coaches for a larger-scale, agile transformation initiative.
Followers
I honestly don’t know where the quote comes from, but I’ve heard that in order for you to become a great leader, you need first to become a great follower. That by following, and putting on the mindset of service, you better understand leadership.
In our last Meta-cast, Josh Anderson and I explored the good and the bad around defining roles and responsibilities in agile contexts.
It’s a mixed bag really that requires some common sense and nuance. I think we landed on the need for them, but caution around the negative effects that they can have IF you’re trying to create a healthy instance of self-directed agile teams.
The Basics
One place to start is looking at the Scrum Guide and how it handles the Scrum roles.
Beyond the basic definitions of the roles, I really like the collaboration advice given BETWEEN the roles. I’ve found that it’s the interplay between the Team, Product Owner, and ScrumMaster that really makes the difference in high-level team performance.
I’d recommend you read (and share) the guidance in the Scrum Guide.
Tanner Wortham is a ScrumMaster and coach who I’ve quoted on this blog before. He recently wrote a blog post entitled: When Can a ScrumMaster Say No which I read with interest.
I’ve been sharing of late around the notion of more prescriptive coaching stances and, at least in my mind, this seeps into the role of ScrumMaster. So I wanted to hear what Tanner had to say.
Here’s a snippet from the article:
[…] Doing away with the sprint review simply ignores the problem. Help the team experiment with new ways to conduct the review but that align with the intent. Over time, they will find their solution. At no point did we have to say no. In fact, we should avoid it. I believe our responsibility is to understand and to guide. Rarely is it to deny.
Even so, I occasionally encountered two situations where I’ll say no as a Scrum Master:
As the instructor walked us through the exercise, he made it clear that “it depends” was not an acceptable answer. I asked if we could say “I don’t know”. And that was unacceptable as well.
It seemed that his only view of a viable answer to leadership was to provide a historical, trended data forecast. To give them as specific a timeframe as possible and lightly couch the risks associated with the estimate.
His primary driver for this position seemed to be that:
If we didn’t give them a specific forecast, they would go to someone (another team, another organization, offshore firm, nearshore firm, outsourced, etc.) that would make a more specific commitment.
I.e., that because we’re afraid of losing the “bid”, we have to provide something to win their confidence and win the work. No matter the level of confidence or runway we have in our historical “velocity-based” data.
I was talking with someone at a conference a few weeks ago and he asked the question:
What do you think about the concept of “Elastic Teams”?
To be honest, I’d never heard teams referred to in that manner, so I had to admit that I didn’t know. I asked, what do you mean by an “Elastic” team? He went on to explain.
He said that these are teams who are formed, dissolved, and reformed around business needs and priorities. For example:
If you had 3-5 teams working on a set of products in your portfolio and the overall business priority changed. Then you could possible shrink each of those teams by 3-4 individuals and assign them to another team (or group of teams) for 2-3 months.
If something else shifted, perhaps something smaller. For example, a customer escalation of a performance problem. Then you might shift members amongst teams to address the situation. In this case, it would hopefully be a shorter-term reassignment, and then things could go back to normal.
I’ve been training and coaching agile teams for more than 15 years. While I’ve seen quite a lot of unique dysfunctions, one of the most prevalent is the overall lack of trust leadership trust in their teams.
There, I said it.
Quite often I use the term “little t” trust so that folks aren’t too offended, because really, nobody wants to admit that they don’t TRUST someone in today’s organizations. At least not out loud and visibly.
But the harsh reality is that most leaders do no trust their teams. And the other, even harsher reality, is that the teams know that they are untrusted.
I just read a truly interesting HBR article that focused on the role of management versus team members themselves in fostering an environment of creativity and innovation.
Most of the discussions today in this space, at least in my experience, are focused towards leadership or management being responsible for innovation. That is – in setting up the environment
Very little of the focus is team ward. In that, the team bears some responsibility for its own behavior, energy, and focus towards innovation.
The HBR article had some survey data that puts “the blame” squarely on both shoulders – that of “management” and the “team” in establishing the right climate.
In my view, that’s the right focus since we all play a part in creating an environment of experimentation, innovation, and creativity.
There is an old, old movie called the Marathon Man with Dustin Hoffman. In it, there is a compelling scene where the evil doer continues to ask Hoffman – “Is it safe?” while giving him a free dental checkup.
You can watch the scene here, if you’re up to it: https://www.youtube.com/watch?v=kzw1_2b-I7A
There seems to be several things that are incredibly difficult for many folks to do.
You see it in general, but it’s particularly interesting in agile contexts. Agile Teams seem to rarely want to:
- Ask for help
- Or say, I don’t know
I’m wondering why?
In my classes I often liken an aspect of the ScrumMaster role to that of a sheepdog. That an important part of their role is protecting the team. Often the direction of this protection is assumed to be outward, for example, insulating the team from external interruptions.
In a recent newsletter (sent on September 22), Mike Cohn discussed this part of the role in more detail. He spoke to two areas of protection:
- From Management Dysfunction (external), and
- From Team Complacency (internal)
The thing that struck me in Mike’s post is the internal protection perspective, ie., protecting the team from “themselves”. It made me think about areas where a ScrumMaster can really help their teams in this area.
Let’s explore some specifics…
