Nathanial Willis posted this in LinkedIn recently:
I asked Steve Denning for advice on how to successfully lead an agile transformation and here's what he said:
- Get a bullet-proof vest and hockey mask because you're going to get beaten and be shot at! (As he laughed)
- Stop communicating over email - do it face-to-face; preferably in a bar. (No seriously)
- Discover your executive leader’s problem. Find a story of how another company solved that problem and share it.
- Focus on the 20% that want to change. Forget about the folks that don't.
I came across a video the other day that had this catchy title – Radical Candor. I watched it and was intrigued by the talk AND its implication to agile teams, organizational transformations, and sustainable cultures.
Kim Scott was the presenter in the video and she was sharing lessons she’d learned in her leadership journey at Apple and Google. In a nutshell, she was advocating radical candor for leaders in communicating with their direct reports.
The stories she told made me think about my own career and leadership journey. A couple of which I’d like to share with you.
Or The Dynamics of an Agile Transformation Team
I found this great article about a leadership team (SLT) adopting agility WITH their teams.
http://blog.qrious.co.nz/how-to-navigate-with-agile-leadership
It’s relatively short, but powerful because of the perspective. That is, it focuses on the activity of the senior leadership team in an organizational agile transformation.
I often think one of the core challenges for most leaders is that they are stuck in a situation where they’re telling their teams and organizations –
Do what I say, Go Agile, and not what I do
That is, they are not walking their talk. Now don’t get me wrong. It’s usually not a malicious or lazy play. It’s simply that they have more important things to do. Things that require their specific skill set and expertise to lead and get done. So, there is little to no time left for working like or with their agile teams.
Some may think this is ok and that it doesn’t really have an impact on the agile organization. Or the potential agile organization. I actually think it has a very negative effect.
We’ve all heard of the KISS principle. It stands for: keep it simple, stupid.
Well I want to apply it to software development leadership. Particularly those leaders that are in an agile context.
I’ve been hearing a tremendous amount of pushback and whining amongst leaders in agile contexts of late. What you say. How can this be?
Here’s a sampling of the running types of dialogue (complaints, whining, pushback, etc.) that I’m referring to:
- We’ve already committed to customers a release date for a new, highly profitable product by June 1. However, the agile teams keep saying it will take till January. I thought agile would allow us to get more…faster. It’s sounds like every other time when the teams couldn’t seem to meet our demands. Where’s the creativity? Where’s the can-do attitude? Where’s the commitment to hard work? Where’s the agility?
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.
