Saturday, May 19, 2012

Seema Sonkiya: Difference between Project Manager and Scrum Master:

When we use Scrum agile methodology, scrum master is a valuable role. I met many people who find confusion in the role of Project Manager and Scrum Master, and motivated me to write this article.
Many companies allocate Project manager to play the role of Scrum master as well, while some clearly differentiate the above roles.
Scrum Master is one of core role in Scrum accountable to remove impediments to the ability of project team to achieve sprint goal while project manager is accountable for the all aspect of project i.e. scope, schedule, cost, quality, human resources, communication, risk and procurement.
Project Manager in not a core role in Scrum process, project manager is involved in overall environment set up for the project.
Role of Scrum Master:
·              Scrum Master is the person responsible for the Scrum Process, its correct implementation, and the maximization of its benefits.
·              He/She helps the team turn that backlog into functionality
·              He/ She is responsible for enacting Scrum values and practices
·              His/her main job is to remove impediments
·              He/She fosters team communications
·              He/She improves engineering practices and tools
·              He/ She is responsible for improving productivity of development team
·              He/She organizes and facilitates ‘scrum meetings’
Scrum master owns the block list and mainly responsible to keep development team focused to their main work that is working software.
Scrum master involvement become crucial when project team members acquired and start their work.
1.       During release planning when product owner start to develop product backlog with the help of project team members, scrum master role become crucial for team building as team building is critical during front end of project.
2.       During sprint planning meeting, Scrum master hosts the meeting.
3.       During sprint, scrum master work to focus team members to their core work that involves all of the work which contribute to working software.
4.       Convert impediments to backlog item for structured attention of all parties, uncertainties in blocks are added for risk management section i.e identify ,analyze and risk response planning (this is done with appropriate involvement with project manager and other relevant stakeholders)
5.       Daily scrum meetings are hosted by Scrum Master.
6.       Sprint review meetings are hosted by Scrum Master.
7.       Scrum master continuously track progress through burn chart, which consider estimation of tasks in ideal days.
All the above discussion clearly indicates that Scrum master responsibilities moves around project team, so that they can focus towards their work, while project Manager owns the overall project management processes. Scrum master involved mainly with project team while project manager is involved with all the stakeholders including project team. Scrum master report to project manager
It is recommended that these two roles should not be mixed because:
1.       Scrum master record estimation in ideal days while project manager need estimation in man days for the costing and budgeting.
2.       There is someone who is always available for the project team if project manager is involved with other stakeholders like project sponsor, customer or suppliers especially in critical situations. For example if project manager is involved in giving presentation to the key stakeholders to convey project progress, at the same time some if team members discover serious critical issue which expertise is not available in project team but accessible in other project team then in case of critical deadline (as described in ground rule which shows when to report superiors for having problems) Scrum master serves as next escalation point to the project team and may contact resource manager to get necessary support to resolve critical issue. I would like to give one real example, I was involved in a project as a project manager and project was in second stage of evolution means some new features were going to add after successful launch of site. During deployment of new features some technical problem arose, it was very critical to make site live within agreeable downtime. I was in management meeting and was not available for project team but problem was smoothly resolved due to availability of Scrum Master. He removed impediment successfully with the help of resource manager who gave green signal for the involvement of compatible resources from the other team members. Yes it is true if I was available even then project team is supposed to escalate issue to Scrum master but in that case this issue would rolled up to me to involve resource manager. Direct and easy escalation improves team environment necessary to achieve sprint goal.
3.       Project manager ensures other areas like communication with all of the stakeholders, risks, and procurement besides areas in which Scrum master involves.
4.       Scrum master track progress using burn chart while project manager need EVM calculation to identify variation in cost and budget.

So as a conclusion Scrum master is accountable to achieve sprint goal while project manager is accountable for overall success of project to satisfy all the stakeholders’ needs. Working software is primary deliverable in agile methodology so Scrum master involvement is introduced in scrum process to ensure easy escalation and discovery of issues related to current sprint.
Project manager may act as a Scrum master in small projects but it is recommended not to combine these two roles.
Seema Sonkiya

Tuesday, May 8, 2012

Seema Sonkiya: WBS template

WBS template I developed is based on high level view of project management, mentioned in my earlier article: http://seema-sonkiya.blogspot.in/2012/05/seema-sonkiya-pmp-project-management.html
Note: WBS is deliverable oriented hierarchical decomposition of project work, so my template only shows deliverables.
1.       Pre Initiation
1.1.    Contract
1.1.1. Seller terms & conditions
1.1.2. Buyer terms & Conditions
1.2.    Business Case
1.3.    SOW
1.4.    Project proposal
2.       Project Initiation:
2.1.    Project Phases identification report (i.e. Project Initiation, Project Environment Set up, Release Planning, Iteration Initiation, Iterations, Iteration Close, Project Close)
2.2.    Understand SOW, Contract and Business case
2.2.1. Alternative analysis
2.2.1.1.              High level requirement, usually refinement of provided SOW
2.3.    High level Risks
2.4.    Summary milestone activities
2.5.    Project Budget
2.5.1.  Analyze contract type
2.5.1.1.              Summary Budget (+-50%, if contract type is not Fixed Price)
2.5.1.2.              Assumption Log
2.6.    Resource pre-assigned
2.7.    Success criteria and Measurable Project Objectives, forms the basis of project & Product quality.
2.8.    Project Approval requirements.
2.9.    List of major deliverables
2.10.Project Manager authorities and responsibilities.
2.11.Stakeholder Analysis
2.11.1.    Stakeholder Register
2.11.2.    Stakeholder management strategy
2.12.Project Kick off meeting MOC
2.13.Register Project
3.       Configuration Management
3.1.    List of CI
3.2.    Change Log report
3.2.1. List of CI in impact analysis
3.2.2. Relationship with incidents or blocks and problems
4.       Project Environment Setup
4.1.    Management Plans (tailored from organization process assets)
4.2.    Communication Plan
4.3.    Detailed Life cycle definition
4.4.    Team directory of acquired team members.
5.       Release Planning
5.1.    Product Backlog
5.1.1.1.              QFD
5.1.1.1.1.                     Core features
5.1.1.1.1.1.   Modules
5.1.1.1.1.1.1.          Sub Modules
5.1.1.1.1.1.1.1.                Stories with estimates +10%, estimated in ideal days as these are discrete efforts (reference of Document) – fitness for Purpose
5.1.1.1.1.1.1.1.1.                       Acceptance criteria may be high level, refined in iterations. – Fitness for Use
5.1.1.1.2.                     Needed Features
5.1.1.1.2.1.   Modules
5.1.1.1.2.1.1.          Sub Modules
5.1.1.1.2.1.1.1.                Stories with estimates +10%, estimated in ideal days as these are discrete efforts (reference of Document) – fitness for Purpose
5.1.1.1.2.1.1.1.1.                       Acceptance criteria may be high level, refined in iterations. – Fitness for Use
5.1.1.1.3.                     Luxury features
5.1.1.1.3.1.   Modules
5.1.1.1.3.1.1.          Sub Modules
5.1.1.1.3.1.1.1.                Stories with estimates +10%, estimated in ideal days as these are discrete efforts (reference of Document) – fitness for Purpose
5.1.1.1.3.1.1.1.1.                       Acceptance criteria may be high level, refined in iterations. – Fitness for Use
5.1.1.2.              Training need document
5.1.1.3.              Process improvement activity log (updated anytime)
6.       Iterations
6.1.1. Iteration Number
6.1.1.1.              Meetings
6.1.1.1.1.                     Sprint Planning meeting
6.1.1.1.1.1.   Sprint Backlog
6.1.1.1.1.1.1.          Selected user stories
6.1.1.1.2.                     Daily Scrum
6.1.1.1.2.1.   Block Lists (updated daily)
6.1.1.1.3.                     Sprint Cancellation (rare)
6.1.1.1.3.1.   Detailed report
6.1.1.1.4.                     Sprint Review
6.1.1.1.4.1.   Sprint retrospective
6.1.1.1.4.2.   Verify Scope
6.1.1.1.4.2.1.          Customer feedback
6.1.1.1.4.3.   Lesson learned
6.1.1.1.5.                     Risk Management Planning meeting
6.1.1.1.5.1.   Risk Management Plan
6.1.1.1.6.                     Risk Audit
6.1.1.1.6.1.   Audit report
6.1.1.1.7.                     Risk assessment/ reassessment and Risk status meeting
6.1.1.1.7.1.   Meeting ID
6.1.1.1.7.1.1.          Risk register
6.1.1.1.7.1.2.          Effectiveness of Risk response report
6.1.1.1.8.                     Quality Plan (for each iteration as scope refined with each iteration)
6.1.1.1.8.1.   Quality metrics
6.1.1.1.8.2.   Quality check lists
6.1.1.1.8.3.   Quality Management Plan
6.1.1.1.9.                     Human Resource (human resource requirement may change with each iteration)
6.1.1.1.9.1.   Project Organization chart
6.1.1.1.9.2.   Team performance assessment
6.1.1.1.9.3.   RACI Chart
6.1.1.1.9.4.   Resource breakdown structure
6.1.1.1.9.5.   Performance appraisal report
6.1.1.1.10.                 Communication Planning (may be updated with each iteration)
6.1.1.1.10.1.                        Communication Plan (updated)
6.1.1.2.              Visual Feedbacks:
6.1.1.2.1.                     Burn down chart
6.1.1.2.1.1.   Earn value report
6.1.1.2.1.2.   Architecture Diagram
6.1.1.2.1.3.   Database
6.1.1.3.              Increments
6.1.1.3.1.                     Shippable functional tested
6.1.1.3.2.                     Story left out report and returned back to product backlog
6.1.1.4.              Design & Construction (interleaved)
6.1.1.4.1.                     Detailed Design Doc(project scope statement, that is greater level of details for the selected stories and in high level for future iterations)
6.1.1.4.2.                     Estimates (-5 to 10%)
6.1.1.4.3.                     Unit tested deliverables
6.1.1.4.4.                     Quality Control measurements
6.1.1.4.5.                     Quality Audit report
6.1.1.5.              Other deliverables
6.1.1.5.1.                     Activity list
6.1.1.5.2.                     Activity attributes
6.1.1.5.3.                     Assumption log
6.1.1.5.4.                     Work performance information (i.e. Cost incurred)
6.1.1.5.5.                     Performance reports including forecasts
7.       Iteration Initiation
7.1.    Stakeholder Analysis
7.1.1. Stakeholder register (updated)
7.1.2. Stakeholder management strategy (updated)
7.1.3.  Analysis of whether project is on track to deliver business benefits
8.       Close Project
8.1.    Financial closure report
8.2.    Feedback
8.3.     Lesson learned
8.4.    Project files achieved
8.5.    Final performance reporting
8.6.    Celebration!!
Seema Sonkiya