A lot of people say you can’t be a good software manager without really understanding software development.
But, let's face it, people who understand software development are a dime a dozen in our industry. What we really need are people who understand leadership & management. I mean... you know the drill – when was the last time a software project failed for technical reasons?
And so, it was very cool to hear David Spann share his research on Finding and Developing Agile Leader’s at last week’s ScrumClub.
It’s simply not enough to know the latest agile practices. In order for agile projects to succeed, they need leaders who exhibit agile behaviors and, here’s a hint – being a technical guru ain’t one of them.
Now, I don’t want to mislead – David isn’t saying agile leaders don’t have to know anything about software development. What he is saying is that the success criteria for leading agile teams is dependent on the leader’s beliefs and behaviors. That is, how they think and act is just as - if not more - important than what they know.
Beliefs![]()
David identified 5 underlying beliefs that a successful agile leader should hold.
How many of these do you hold? How many does your manager?
1. A group of well intentioned, skilled people will make a better decision through consensus then I can on my own.
2. Five or more people with a single, clear purpose can (and often do!) change the world.
3. Asking the right questions will always create better outcomes then making a series of well-crafted statements.
4. The leadership role is about creating a great environment in which others can succeed.
5. Trust is the foundational component of any relationship and it must be tended to with care, integrity and humility.
Behaviors
David identified the behaviors that make agile leaders successful and from that came two very interesting observations:
The behaviors that make agile leaders successful are, largely, the same behaviors that make Facilitators successful.
The behaviors that cause agile leaders to fail are, largely, the same behaviors we seek when hiring Project Managers.
Behaviors We Want in our Agile Leaders
Strategic. Agile is very pragmatic, with a strong emphasis on the here & now. YAGNI, defer decisions, no Big Up Front anything. And so, it's interesting to see strategic, "taking a long range approach," as a key success criteria for agile leaders. I think this underscores the importance of having a clear vision for the team to rally around, and the need for our leaders to be thinking ahead to make sure that we're not just moving forward - but moving in the right direction.
Tactical. At the same time, agile is very pragmatic, delivery focused. So our leaders need to emphasize the importance of continuously delivering value by focusing on "short-range, hands-on, practical strategies."
Innovative. We are out there, every day, responding to change, creating things no one has before. Our leaders should be open to new ideas, willing to take risks, and comfortable with agile's level of change.
Excitement. We want our leaders to be passionate! To have excitement and energy and enthusiasm, and to pass that passion on to the team and make it felt by all who come in contact with it.
Communication. Agile is about bringing people together to produce more than they could individually. Those 5 people with a clear purpose out there changing the world. This requires communication, "stating clearly what you want and expect... clearly expressing your thoughts and ideas; maintaining a precise and constant flow of information."
Consensual. Agile teams are about respect. Leaders value their team's ideas and opinions and demonstrate this by using their position to help the team gain consensus on how to proceed rather than just telling them what to do.
Delegation. Agile teams are about trust. Leaders encourage this by enlisting team member's strengths to achieve results and giving the team autonomy to make their own judgments about the best way to meet objectives.
Empathy. Agile leaders empathize with and support their team members.
Behaviors that Hurt Agile Teams
Authority. Leaders who are - and believe others should be - deferential to authority, tend to be liabilities on agile teams. Agile teams need to be continuously on the look out for new and better ways to do things and a great way to kill that that is by saying "nope, we don't allow new ideas unless they come from/are approved by the guy at the top."
Structuring. The Plan-Driven Manager who spends weeks devising the "perfect plan" and the rest of the project aligning everything back to that is in direct opposition to the team's agility. Per the manifesto, agile teams value responding to change over following a plan.
Conservative. If it ain't broke don't fix it, says the conservative leader, while agile says, "what can we do better?"
Technical. While some technical understanding is good, being an expert is not only unnecessary but, as we've all seen, can be detrimental. We need our leaders helping us with communication and vision and supporting us to get the work done, not busy doing it all - or coming up with all the answers - themselves.
When we look for managers in our organizations, what kinds of traits do we look for? Managers should have Authority, right? And, just look at the PMP - you know, the thing that tells us how to manage projects - about 90% of it's Body of Knowledge is around planning, so Structuring must be important too. Conservative? Sure, old white guys in suits, right? ;-) And technical... well, we all know what role the techies get promoted to when they do a good job.
What about YOU: Which beliefs and behaviors do you see in your own agile leaders? What about in yourself?
--
Learn more in David Spann's articles on his research into Agile Management Behaviors:
» Agile Management Behaviors: What to Look For and Develop
» The Facilitative Mind of Agile
New! See Patrick Wilson Welsh's response: Agile Team Lead : Useful New Role?
which takes this idea to the next level, and join in the conversation!







19 comments:
Great work here! This has been one of the best posts on required/detrimental leadership traits I've read.
One observation is that the term 'agile' could be replaced with 'software'. I think everything you've stated holds true even when you are a software maintenance/project manager using other life cycles or methodologies.
On planning... While 90% of the PMBOK is devoted to planning, I don't think that discounts the information/guidance it provides. Agile should encourage us to plan in ways that ensure the team's effectiveness, and allow the team to respond to change...providing just enough planning when needed. I'm not a PMP or anything, and I do see the PMBOK over/mis-used just for the sake of being project manager-y-ish. Just my $0.02 :)
Thanks again for the great post!
Thank you so much! I of course can't take any credit for the awesome ideas, which are all David Spann's. But that's funny, you may be right about substituting "agile" with "software" -- although don't our waterfall projects still need traditional Structured managers?? ;)
Nice post, Hacker Chick. And it reminds me of Stephen R. Covey on new leadership:
Don't Manage to Methods --
"You don't really manage people -- they manage themselves, using the criteria you have developed together, and if you are emotionally connected to those criteria (truly win-win) then those criteria manage people and you become a servant leader to remove obstacles and facilitate them in whichever way you can"
I especially like that you point out technical expertise as being a non-requirement. Hooray for spreading that awareness!
<span style="">"You don't really manage people -- they manage themselves, using the criteria you have developed together"</span>
Thank you! You are now reminding me of this quote from Rick Brenner:
"<span style="">It also helps to recognize that the status difference between managers and managed is probably exaggerated. It's a holdover from the days when most work was menial, and managers truly did have a rare skill set — they could "read, write and cipher." We can all do that now, but the status differential remains."</span>
Why do we feel these brilliant, creative people in software all need to be managed? I like Stephen Covey's idea much better. Thank you for sharing & for your kind words!
Right on Abby!
I have find this challenging as an agile coach because servant leadership is essential and must be nurtured. But I also see that many agile teams fail to reach their full potential because they don't embrace the "tough" technical agile practices that support deep learning and value delivery - often TDD and pair-programming.
My point is that agile leadership must be sufficiently technical to identify, understand and guide the team through the tough technical stuff if they are to reach their full potential. So I think technical proficiency is important.
The way I like to approach this is to strive for building "leaderful" teams. I first heard this from Deborah Hartmann Preuss. We must actively build leadership within ours team so we have multi-faceted, emergent leadership.
Thanks for the insightful post!
(With apologies for deleting my last comment - I realized it was lots of words without saying much. Try again...)
Thanks so much for commenting, Declan!
I agree learning is so vital. I keep thinking of shu-ha-ri, maybe at ri the team can figure out how best to teach itself & acquire the needed skills, but who will help the team get to ri?
A couple of things occur to me. One is that comment from Rick Brenner I put in my reply to Tobias... it is a rather out dated notion that managers are the ones with all the answers. This just can't be true anymore - it's just too much for one person to know. So then does it make sense that we should look to our leaders/managers as the ones to teach us? Or are they instead the ones that help make learning possible....?
I'm also thinking of Mary Poppendieck's Agile 2009 talk on Deliberate Practice in Software Development (video available here: http://www.infoq.com/presentations/poppendieck-deliberate-practice-in-software-development) and how she said our organizations need to be looking at how we can grow experts in our employees, and gives examples of how, for example, Toyota has an entire career path built up around growing experts that takes years and years for each employee.
Maybe we're being too short sited in thinking our leaders or managers can teach us all of this...?
For obvious reasons I want talk about myself. As for my own agile leaders, the behavior I value most is the ability to quickly jump around perspectives. I think this is the primary enabler for being innovatie. In an agile team you constantly need to interact with many opinions coming from (many) intelligent people.
In order to be able to see the value in an opinion one must be able to quickly jump into the perspective of the individual having this opinion, thus understanding the virtues of the opinion. By all means, this jumping around perspectives is not an easy thing to do.
Hi, Itay,
Thank you! I think that's a really good point you raise. One of the biggest benefits to teams, rather than individuals, is that you can really build on the different skills and perspectives that each person brings to the table. But that doesn't work too well if the leader isn't open to them, is perhaps doing things to discourage or shut them down. On the other hand, how much better would we be if we had leaders that were not only open to new ideas, but encouraging of pulling in the different perspectives.
I like that - thanks for sharing!
Love this, but just one caveat: AFAIK research on the quality of groups workresults is inconclusive (apart from being highly variable due to different fallacies). Much work indicates that the quality most often is less.
"1. A group of well intentioned, skilled people will make a better decision through consensus then I can on my own."
A major benefit of consensus is commit, though.
Hi, mawi,
Thanks for commenting! Apologies for delay - I was out of town and then down with the flu. I'm really curious about the research you mention - do you know of anything freely available on the net that speaks to this? Thanks so much!
<span style="font-family: Times; ">
<p>Great post Abby. One item I would add to the list of behaviors we want, is political will. What I mean by that is the willingness to stand up for the team and take the hits as needed. If a team cannot trust their leader to defend them then they will lose all faith. This also allows for the team to try new things without feeling that they'll be slammed by some manager for "wasting time" when what they are really doing is attempting to improve things or do things better.
</span>
Great read. I think I score well but this gives me some things to look for as an Agile leader for improvement.
Abby - good food for thought. I liked it so much I included in this week's Agile Quick Links: http://www.notesfromatooluser.com/2009/11/quick-agile-links-week-3.html
Thanks, Robert! And yes indeed to political will and allowing the team to try things out. I don't know if you saw, Patrick Wilson Welsh has continued this discussion on his blog: http://patrickwilsonwelsh.com/?p=258 and one of the things he mentions that I really like that I think is related to this is:
"<span style=" color: #ced5dd; line-height: 18px; ">Helps continuously build trust and respect between the team and its stakeholders (in a way that buys more and more freedom to speak up, freedom to experiment, freedom to “fail,” freedom to learn)."</span>
Let's try that once more in a font that doesn't blend into the background:
"Helps continuously build trust and respect between the team and its stakeholders (in a way that buys more and more freedom to speak up, freedom to experiment, freedom to “fail,” freedom to learn)." - Patrick Wilson Welsh
Thank you! And you're right, probably people reading my blog already know this stuff so a little preaching to the choir, right? but +1 for giving people something to think about at least. ;) Thanks for commenting!
w00t! Thanks, Mark :)
Abby,
I had a nice reply but realized too late that by logging in, the form reset. Boo. ;)
Anyhow, I enjoyed your writing but do find it interesting that what started off as literally a couple bullet points (the Manifesto) becomes obsfucated by productized constructions and the emotional connections to those constructions. The manager needs to be a people person more than a technical person. Is this really that surprising? Not to be contentious, but managers manage. A manager who is technically saavy will be more effective not only in managing, but in adding value to endeavours across the organization and maybe even pitching in when required (kind of like Kanban pull).
I would suggest that structuring is not bad - but dictums are. False layers and obstructions to communication are. Structure can be something as loose as a team of really talented devs who develop their own unique rythmn. You can't find that structure in the PMBOK, but its a gorgeous one, and one I wish I could deliver with the wave of a wand. Also, in the real world, the suits want to see a .mpp. They just do. This does not mean you have to get all PMPish about it. You can show phases, iterations, even something abstract like "Iteration N+1" as long as it shows what they are looking for, an estimate to "how long and how much?"
Thanks for this. I did enjoy it.
Best,
Josh
http://www.mittechnical.com/blog
So is pooping. Come on now...
What do YOU think?