I must admit that I’m a fairly rabid agilist. Part of the rationale for that is the pain I’ve experienced in leveraging traditional PM techniques in software projects. Another influence is my experience dealing with traditional leadership and the dysfunction relating to driving projects and teams towards unrealistic goals.

What’s interesting though is a conversation I had with our Scrum Master team the other day. I asked them to act more like “traditional project managers”. To begin to—

be more prescriptive at times with their teams; demanding high quality, excellent software, and adherence to our agile principles
pay close attention to risks – planning, real-time surfacing and guiding team reactions
encourage the teams to improve at an accelerated rate; to set the bar high for improvement
become visible as leaders and spokespersons for their teams; to do a better job of socializing state & progress

I was working with an organization a few weeks ago on a coaching assignment. They’ve been experiencing quite a bit of attrition within their technology teams and the discussion inevitably went to root causes. Several leaders at the client were confused about the drivers behind it.

One of them said that they had sat down with several developers before they left and everything seemed fine. They talked about the developers concerns and tried to address every one. They felt that there were “tuned into” the team and were trusted. They just couldn’t understand why folks were leaving without giving them an earlier warning…and more importantly, a chance to address their concerns.

Here’s another interesting ‘twist’ to the plot.

Agile Training

The Agile Project Manager—Don’t Throw out the PMBOK!

The Agile Project Manager—Listen to your Spider Sense