Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
Viewing entries in
Agile Leadership
I was reading an online HBR article the other day about leadership communication. Here’s the HBR article –
https://hbr.org/2016/03/two-thirds-of-managers-are-uncomfortable-communicating-with-employees
I thought this might be a nice way to RE-explore leadership communication challenges. And a new twist might be some ideas on HOW to improve it.
I came upon a wonderful post entitled The Illusion of Managing People at Nucleus Insights. You can find it here: http://nucleusinsights.com/blog/?p=224
The focus of the article was away from “managing” and more towards “leading, inspiring, and focusing”.
There were three key points made:
They wrapped up the article with the following quote:
This article has been floating around my head for quite a while. It will encompass several themes. The first being, how do we “account for” the time and focus within our agile teams? Second is, how granular do we plan for and monitor the focus of our agile teams? And finally, when planning and forecasting, should we plan at the individual level?
The “we” in these is a bit broad. I would include managers, directors, VP’s, C-level folks, the PMO and Project Managers. Virtually anyone who is tasked with “caring about” a technical team and what, how, and when they do what they do.
Well in this case, it’s not that long ago, but the analogy feels right to me. In this Dinosaur Age, project managers and “all management” for that matter, cared about people and their time. What are some of the aspects of that?
I subscribe to Mike Cohn’s newsletter. As you would expect the value is always high and his posts usually make me think a bit about my own coaching experience and ongoing advice.
In a recent newsletter Mike adopted a position on a manager serving as a ScrumMaster that goes contrary to my experience. Here’s what he had to say:
When I first started doing Scrum, I was what we'd call today the team's ScrumMaster and product owner. But we didn't have those terms back then. And without terms or any clarity on the roles, it was easy for me to make the mistake of being both.
I also did some programming. Oh, and I was also the vice president of the software department, so my team reported to me.
I want to address that last role because common advice in the Scrum community is that a team should never, ever report to their ScrumMaster. That is, I could have been the ScrumMaster or the VP -- but I should not have been both at the same time to the same team.
Do you recall the … Jim Carrey movie called Yes Man? In it he was influenced by a ‘cult’ of sorts that recommended an approach, in order to change our lives, where we have to say YES to everything – every question, every opportunity, and every inquiry.
The point is somewhat captured in the agile posture of “Yes, and…” that many coaches subscribe to.
Lately I’ve been thinking about traditional software leaders who are moving towards agile methods. Typically they take a class or workshop to gain a cursory understanding of agility. Some even take more ‘advanced’ workshops, which are focused towards the leadership shift.
I watch my fair share of TV shows that surround real-world business and projects. I’ve noticed a theme that I want to share to see if you see it the way I do. So here are a few examples:
Fast ‘n Loud is a show on Discovery Channel here in the US. It’s about a garage that takes in “needy” cars and refurbishes them for resale.
The owner of Gas Monkey Garage is Richard Rawlings. In the episodes he generally is scouring the countryside for fixer upper cars that have up-side profit potential.
I’ve often held the perspective that there is no real ‘L’eadership roles within agile teams. The entire notion of a self-directed team in some ways confuses the role that leadership plays within agile contexts.
One of the leadership dynamics, at least from my perspective, is at the agile or Scrum team level. I’ve always observed that leadership is one of the central ingredients to a successful agile adoption. In fact, the larger the scale, the more important it becomes.
That being said, the larger the scale, the more incumbent managers and leaders struggle to figure out the new role they need to play in the shift. And quite often the organization really doesn’t support them (coaching, training, funding) in this effort. It’s sort of left as an exercise for the student; which mostly fails.
I spent about 3-years working at a company called iContact from 2009 – 2012. While there I reported to CTO – Ralph Kasuba.
Ralph was a wonderfully skilled leader and I’ve been reminiscing about him of late. Sure, we still stay in touch, but it’s not the same as working together each day.
Ralph had one “pet peeve” that I’d like to share and it involves interviewing. At the time, iContact was growing quite steadily, so it seemed as if we were always interviewing team members for our technical staff. We went through a period where no one seemed to pass our technical screens.
It was frustrating because the recruiters kept saying they were sending us qualified candidates, but the team-based interviews would just chew them up.
The language we started to use was that we were looking for Unicorn’s and not finding any.
I was sent a request to gather my idea on what Agile Maturity looked like from a column writer. Here’s her request:
Here's my thinking: In 2015, I heard many software pro's talk about "Agile maturity." But you had to listen hard to hear the phrase. Nobody shouted it from the rooftops; it’s not a buzzword, or even a new idea. It was more of a whisper, an aside that came up in the context of other topics: continuous delivery, better business alignment, mobile testing—to name a few. Yet it seems to me that this whisper is crucially important – that a mature Agile practice is the key underpinning for successful software development.
But what exactly does "Agile maturity" mean? It appears to run that gamut from advanced beginner teams flush with their first solid success to those are that doing continuous delivery, with high levels of test automation that entails.
What is your definition? Is your Agile mature? What are you working toward?
A short time ago I was working with an agile coach. He was quite experienced and well known in the agile community. He also held a wide variety of certifications.
We were working together on a project that had, if I were to be honest, quite a few cultural and organizational challenges.
There was one specific individual who always seemed to be the most challenging. My coaching colleague and I were talking about them one day and he was grousing (complaining) about them to me.
