An attempt to answer "wondering about project managers"

A blog post by Shady "Wondering About Project Managers" triggered me to participate in answering his posted questions.

The first question was: Should PMs know the ask much about technical decisions?
let's first try to see what the PM role involves. there's the perceived and unfortunately deeply rooted notion that a PM is the "bad guy" who:

• doesn't trust the team
• uses command and control
• is usually a dictator
• has to report a "status" every now and then
• wants to have to final word on all decisions (technical or anything else!)
  
• is "ultimately responsible" for success
• and is NOT the one to blame when the project is failing
• what else?

If this is how we think of PMs or if the PMs we are working with are like that, then I would say it does not matter what the best mode of operation is between a PM and the rest of the team. It would not matter whether the PM asks much about technical decision or even impose certain technical decisions. Why it does not matter? because this would be a troubled team in a non-ending stage of "storming"; the ongoing outcome is demotivated team members and eventually a challenged or a failing project or a dissatisfied customer. If I cannot help the team move from "storming" to "norming" and into "performing" then "adjourning (see Software Project Manager's Bridge to Agility , by by Michele Sliger; Stacia Broderick) , then I would run :)

Maybe this did not answer the question; I will give it another shot: if the PM is truly a servant leader, then there will be trust and hence there will be collaboration where everyone can contribute with knowledge and experience towards the vision and goals of the project/product, towards "success". So yes, within a good team, anyone can ask questions technical or not provided that the discussions are properly facilitated and "waste" is eliminated; a performing team.

The second question was: In an agile process, where should PMs stand? What exactly is their Role? Should there be PMs in agile in the first place? Or Should they be replaced by a PO (Product Owner), or -may be- a Scrum Masters?

Now this is an excellent question to shift direction from the old terminology "PM" to the evolving terms of agile "PO", "Scrum Master"or "Agile Team Coach". Here's my attempt to answer that:
We can identify the following roles in an agile team:

hats, and caps

• Product Owner
• Scrum Master/Agile Team Coach
• Developer
• UX designer/developer
• QA/Tester
• Business Analyst
• Architect
  
• PO and Scrum Master/Agile Coach
• PO and CM roles
• Product Manager
• DBA?
• Technical Writer
• Support Engineer
  
• Project Manager (maybe?)

In Agile teams it is not about who can replace who, but I believe it is about who can assume which role(s), and whether the same person can assume more than role or wear multiple hats.
I suggest that the role of PM can be split into 2 different roles PO and Scrum Master/Coach. It would ideal to have a person focusing on role of PO (especially for medium and bigger products) and another playing the SM/Coach role (although this role can be taken by any person who "can" do it plus performing his/her role as developer, tester etc..).

Role of PO is concentrated with Why and What, while that of SM/Coach is about How and When. Yet collaboration, reflection (on process, tools, features) , and trust are ESSENTIAL.


Currently at Santeon , I'm a member of a wonderful team where I carry 2 hats, that of a PO and another of SM. It is not easy though, and I'm learning a lot every day.

More to come ......


Jeff Patton & David Hussman explaining User Stories Mapping at Agile 2009 in Chicago.