I have heard a lot of people saying a good PM is one who cancels out most of the noise around , so that the team can work smoothly. Like a PM should not only give visibility into the iteration/release on an ongoing basis to the customer, but also take care of ensuring that the work queue is maintained such that there is a smooth stream of work for the release timeline.
In a way he/she is like a noise cancellation headphone, which a developer wears, to concentrate on the code he wants to write, and not worry about anything else. A team should just worry about the stories they have to deliver and the value they wish to provide to their customer and nothing else.
In my view, this is the very first task a new PM should learn to do. The next big task is to actually fix the noise so that the team doesnt need a PM all the time to cut out that noise.
To draw an analogy, if a programmer has to repeat a set of tasks again and again, he will automate that in a shell script. Similarly if a PM finds himself repeatedly doing the same thing, he needs to figure out a process which ensures this happens automatically. An example would be, instead of a PM asking devs every now and then "What is the status of the story?" , create more ownership about that story with the BAs. Let the BA who wrote that story worry about how its being developed and make them collaborate more with developers. The BAs should be eager to see their story being developed by the developers, and that will make sure devs collaborate and show progress to BAs everyday. And the BAs know the story is on track
This not only builds ownership and pride within the team, amongst people who are actually delivering value, but also removed the need for a PM to do a mundane follow up job. If a PM does not think along these lines, it is very hard for that team to be self organized.
In a way he/she is like a noise cancellation headphone, which a developer wears, to concentrate on the code he wants to write, and not worry about anything else. A team should just worry about the stories they have to deliver and the value they wish to provide to their customer and nothing else.
In my view, this is the very first task a new PM should learn to do. The next big task is to actually fix the noise so that the team doesnt need a PM all the time to cut out that noise.
To draw an analogy, if a programmer has to repeat a set of tasks again and again, he will automate that in a shell script. Similarly if a PM finds himself repeatedly doing the same thing, he needs to figure out a process which ensures this happens automatically. An example would be, instead of a PM asking devs every now and then "What is the status of the story?" , create more ownership about that story with the BAs. Let the BA who wrote that story worry about how its being developed and make them collaborate more with developers. The BAs should be eager to see their story being developed by the developers, and that will make sure devs collaborate and show progress to BAs everyday. And the BAs know the story is on track
This not only builds ownership and pride within the team, amongst people who are actually delivering value, but also removed the need for a PM to do a mundane follow up job. If a PM does not think along these lines, it is very hard for that team to be self organized.
No comments:
Post a Comment