I value project managers and see an on-going need for them within a Lean-Agile context. Admittedly the role of the project manager changes when using an Lean-Agile approach, becoming more of a shepherd and less a military officer. In this, the first post of a new series, I thought I’d revisit my definition of the Agile Project Manager.

My insistence on using the title “Project Manager” in a Lean-Agile context makes me a kind of radical traditionalist. A traditionalist in the sense that I see little reason to change existing role titles and responsibilities; unlike some folk I see a project managers making a positive contribution to Lean-Agile teams. However I’m a radical because I see project managers doing their jobs is a new way – the high level responsibilities are the same but the methods are different.

Sheep, Shepherd and Dog

I like the idea of an Agile Project Manager as a shepherd. The PM rushes around the the edges of the development team a lot and keeps them pointed in the right direction. People who suffer from the Fallacy of Control will fail as Agile Project Managers because the reality is the PM directly controls relatively little of what happens inside the team. But they can, and should, control the direction of travel.

I’ve been using this metaphor for a long time starting in my Agile Comparison of 2002. Amongst other things that post describes in detail what an Agile Project Manager does.

Looking back now, with 12 more years of experience and insight, I would only change one thing. I would remove mention of timeboxes to acknowledge how continuous delivery is changing our industry.

So from my perspective an Agile Project Manager must:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed scope; track progress against the goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

In subsequent posts in my new series on Roles and Responsibilities I’ll explore alternative views on Agile Project Managers, including the possibility that an Agile team does not need a PM at all.