PMR
PMR has high visibility hence a PMs personal attention to details presented is a must.
Adequate time must be sought to prepare and present. Unless detail data points are handy
don't schedule it. (Defect slide had data showing closed instead of fixed..last time issues and effort were incorrect).
-Deck should be ready 3 days in advance and should be reviewed.
-An internal peer review and discussion should be done on the data in deck.
-Defects if there in a release should be priortized and fixed at the shortest possible time before starting any new release. A clean code base is a must. Parallel work and planning for merge after 2-3 weeks should best be avoided despite market pressures.
-Duration of Defect Fix for a release should not be more than 2-3 days. You may use whole of the team for it to close it on high priority always. Rest things can wait.
-Keep right team. Individuals who lack proactiveness ..accountability. ..passion ..intelligence should be let go off if effort to improve and bring up above qualities doesn't bear results in a fixed duration.
-PM should be aware of all technical issues faced by team ...details of the issue. Issue Register should be updated by leads daily. Refer it always in scrums or team meetings.
-Spend more time with your best team members sharing growth vision and concerns.
-Career Discussion and mentoring should be formalized.
- If in a team size of > 10, where dev or design or defect fix is happening ..and you don't see emails on issues or lessons learnt....it means discussions are happening in silos in teams and others may miss out..and this will reflect towards end when a release testing shows defects/issues which could have been handled better.
-If your product has defects..and defect fix going on...a PM must spend reviewing STM ..All progress should be reported based on that only. Single source of truth.
-During development, progress should be checked by PM daily using metrics like code commited to svn, testing of nightly build..if team is not mature yet to produce nightly builds...push it hard..don't keep more than 3 weeks to acheive it.. (Developer should check in working code daily. if a function is writen...write its signature first..hardcode its return first..then gradually keep adding the code...use the TDD approach...unit test cases must all fail first..then gradually pass.)
-Avoid merging with huge backlogs. Resolve branch issues for any work at high priority..developer should at no point keep code in local workspace for more than 2 days.While merging..configuration manager should be careful and ensure developer's presence while resolving conflicts in merge.
-Go sequential at times..like code clean ..complete it will all team..then take up other items.
Adequate time must be sought to prepare and present. Unless detail data points are handy
don't schedule it. (Defect slide had data showing closed instead of fixed..last time issues and effort were incorrect).
-Deck should be ready 3 days in advance and should be reviewed.
-An internal peer review and discussion should be done on the data in deck.
-Defects if there in a release should be priortized and fixed at the shortest possible time before starting any new release. A clean code base is a must. Parallel work and planning for merge after 2-3 weeks should best be avoided despite market pressures.
-Duration of Defect Fix for a release should not be more than 2-3 days. You may use whole of the team for it to close it on high priority always. Rest things can wait.
-Keep right team. Individuals who lack proactiveness ..accountability. ..passion ..intelligence should be let go off if effort to improve and bring up above qualities doesn't bear results in a fixed duration.
-PM should be aware of all technical issues faced by team ...details of the issue. Issue Register should be updated by leads daily. Refer it always in scrums or team meetings.
-Spend more time with your best team members sharing growth vision and concerns.
-Career Discussion and mentoring should be formalized.
- If in a team size of > 10, where dev or design or defect fix is happening ..and you don't see emails on issues or lessons learnt....it means discussions are happening in silos in teams and others may miss out..and this will reflect towards end when a release testing shows defects/issues which could have been handled better.
-If your product has defects..and defect fix going on...a PM must spend reviewing STM ..All progress should be reported based on that only. Single source of truth.
-During development, progress should be checked by PM daily using metrics like code commited to svn, testing of nightly build..if team is not mature yet to produce nightly builds...push it hard..don't keep more than 3 weeks to acheive it.. (Developer should check in working code daily. if a function is writen...write its signature first..hardcode its return first..then gradually keep adding the code...use the TDD approach...unit test cases must all fail first..then gradually pass.)
-Avoid merging with huge backlogs. Resolve branch issues for any work at high priority..developer should at no point keep code in local workspace for more than 2 days.While merging..configuration manager should be careful and ensure developer's presence while resolving conflicts in merge.
-Go sequential at times..like code clean ..complete it will all team..then take up other items.
Comments
Post a Comment