I was chatting with...
Viewing entries in
Agile Leadership
Years ago, I worked for a company called Micrognosis. I shared a little about the company in this post. As I recall, I worked there from the late 1980’s to 1996 or for about 10 years. Over my entire 35+ year career, it was my longest tenured job. And I did a lot of growing there, both in my role and in my self-learning.
When I left Micrognosis, I moved to North Carolina for a software leadership role at Bell & Howell Mail Processing. So not only did I change jobs, but I relocated my family as well. To say the change was a bit scary for me and my family is a bit of an understatement. But we moved and never really looked back.
I realized after about three months at Bell & Howell that I’d stayed in my Micrognosis job for a bit too long. That I’d developed some “blind spots” that I didn’t even know I had.
Let me explain.
I delivered a keynote at the Agile Development + Better Software + DevOps conference put on by TechWell on Wednesday, November 8, 2017 in Orlando.
The feedback I received was wonderful and it seems the talk resonated with quite a few of the attendees.
At some point, I'll get a link to the video of the keynote and I'll share it here. Until then though, here's a link to the slide from the talk.
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.