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?
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?)
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.
No comments:
Post a Comment