What Type of Project Managers can Easily Adopt Agile?

[Sally]

So I decided to kick off a discussion thread and get your input into
this topic. As I've met and coached several project managers on Agile
"thinking" and practices, I've noticed that different folks grasp
these ideas and principles very quickly and others may need more time
to truly adapt and shift their management style.
What are your thoughts? What are the core personality traits or
existing beliefs that make one person more adaptable to Agile than
another? How can you ensure adoption success with the various type of
personalities?

Please share any personal stories or reflections you may have on the
topic.

Thanks!

-Sally

[Andrew Ochsner]

Well, didn't see any responses so thought I'd add my experiences.  I find that it's pretty much the same whether you're talking about project managers or developers or testers or customers.

There are some people who just get it off the bat.  Either they're willing to learn new things and give it a shot, or it just makes sense to them (Agile is all about doing things that make sense or that people have been doing before, it just packages them all together to support each other).  They just kind of have an attitude that they'll try anything at least once.  I find this especially true of people who either have had big failures in a different process (and are looking for something different), or people who are pretty new to team based software development (new grads etc).

Then there are people who resist.  Either because they don't want to learn new things, or they've had success doing things the way they are (if it ain't broke...), or they've invested a lot of time and effort into the way things are now.  Or, maybe they see their role disappearing or changing significantly.  I see this frequently with project managers and development managers (my distinction is that the project manager owns the project and the development manager owns the people doing the project).  For project managers they sometimes get lost as to what they should be doing or just feel like they're reduced to a tracker role.  Development managers who are more command and control are obviously giving up a lot of control to the team.  That's really just fundamental to Agile though.  My approach is usually to ask for a "willingness to suspend disbelief"  Basically, lets try it for a couple of iterations and we'll have some retrospectives to see how it's going and adjust from there.  Agile is all about on-the-fly adjustments, so lets just give this a shot.  Usually that's all I need.  I can't compel anyone to do it.  Usually it's just one or two people and they don't want to go against the team's desire to be Agile so this gives them just enough to voice their concerns but still get behind the team.  Developers do this too I might add.  Trying to teach someone TDD is really really hard.  In fact, the only successful way I've been able to do it is just to pair w/ the person to show them and then there's this Ah Ha! moment and it sells itself after that.

There's also a 3rd group I've thought of that are probably the most dangerous (it's what I see at the huge company I work for now and the one before that).  Usually they're middle management, esp if the Agile directive is coming from the top.  They'll learn just enough about Agile to know the vocabulary and sounds like they're doing Agile but still end up doing what they want in their command and control style.  Think 4 sprints of Plan, Design, Code, Test.  But they're called sprints.  And "standups" that last 3 hours. 

Anyways, that's been my experience (mostly at large Telco companies).  And as for how you recognize these traits, I really don't know.  I just know it when I see it :-P  I think ultimately you just need to try it out and really pay attention to the feedback you're getting.  Maybe do more frequent retrospectives.  People just react to change in their own ways.  If the new way isn't addressing their concerns, then it's just not going to stick.

Hope this is what you were asking for
Andy O

[Ken]

My observation is that any project manager that want's to learn the
techniques required to lead an Agile project can be successful. This
includes project managers having primarily a "command & control" style
of management. However, a project manager with strengths in
leadership, communications, negotiation, and relationship building
appear to naturally take to Agile disciplines easily and will probably
become effective in a shorter period of time.

[Doug Stewart]

I like what Andy and Ken had to say. I find that folks really want to be
successful in their jobs. They tend to do what works. For many, what
works is a progressive idea, ever changing, ever evolving into newer and
better practices. For many more, what works is what has always worked.
What has kept them employed, kept them getting raises, kept them moving
up in the organization, etc...

The phrase in software development that I most detest is: "If it ain't
broke, don't fix it". The second group of folks above tend to extend
this state of mind into their everyday practices. If I'm a valuable
asset to my company and I've never done agile, then why would I want to
jeopardize my status, my career, my security. Some folks really take
pride in the sets of practices they have developed over the years and
may take offense to being asked/demanded to change those practices.

In this context, I guess I might present the personal value to each
employee be they a vp, director, manager, project lead, engineer,
tester, etc... How exactly will this "agile" thing affect their
professional lives in a positive and sustainable way?

A second piece of dealing that may be very important is to express the
value gained from agile for the company. How will this strengthen our
company? We tend to present this idea to managers and above, but seldom
are the lowbies ever addressed in a way that honors their commitment and
investment in the company they serve.

One last thing. I think the novelty of agile needs to be dropped. It is
important to state agile to folks in terms that speak to it's maturity,
stability, and proven effectiveness. Why is this new agile thingy a good
fit for my company. Agile is not new. XP has been around for over 12
years now, for example.

In short, why should all of us at company X buy-in to this agile
development methodology? Because it values all of you and your company.
How do we get it done? By making some very smart and difficult choices.

Good topic.