Get documents about "Scrum and Project Management at Myriad
Document Sample
Project Management and Scrum – A Side by Side Comparison
by Anne Loeser, October 2006
For decades, software development projects have followed the classic “waterfall” method in which software
development initiatives were carefully analyzed, designed, documented, coded, tested, and ultimately delivered
to the customer – sometimes years after inception. By then, it was not uncommon for business needs to have
changed and for the resulting system to fall short of customers’ expectations. According to the Standish Group,
software development projects have an overall success rate of 34%. In response to this rather disappointing
approach to software development, “Agile” methodologies – which are light on documentation and formality -
began to emerge in the 1990’s. Scrum, which is one of several Agile approaches, was first developed and
presented in 1995 so it is relatively novel when compared with traditional software development processes
which have been used for decades. The purpose of this paper is to compare traditional waterfall project
standards and deliverables with those in Scrum, and to contrast the Project Manager’s role with that of the
Scrum Master.
Traditional Project Management at a Glance:
According to the Project Management Body of Knowledge (PMBOK), a “project” is a temporary endeavor
undertaken to create a unique product or service.”1 Projects are typically divided into phases in order to
provide better control of the project’s progress and deliverables; each phase has a prescribed set of deliverables.
Collectively, the project phases are known as the “Project Lifecycle.”
Project Management is a term encompassing the application of skills, tools, techniques, and knowledge applied
to a project to meet or exceed stakeholder expectations. Project Managers typically oversee the following
aspects of a project:
1. Project Scope, which ensures that all the required work, and only the required work, is planned, defined,
documented, and delivered to the customer’s satisfaction.
2. Project Schedule, the objective of which is timely delivery of the product or service. It entails activity
definition and estimating, and schedule development, monitoring and control.
3. Project Cost, which is intended to ensure that the project is delivered within its approved budget. It includes
cost estimation and expense monitoring.
4. Project Quality, which encompasses quality definition, assurance, and control.
5. Project Communication for information dissemination and collection.
6. Project Risk including risk identification, quantification, avoidance, and mitigation.
7. Project Human Resources Management including but not limited to:
• Organizational Planning – identifying, documenting and assigning project roles, responsibilities and
reporting relationships.
• Staff Acquisition – obtaining human resources for the project.
• Team development – enhancing individual and group skills.
Scrum at a Glance:
Scrum is one of several Agile methods for developing and deploying software, although it may be used for non-
software initiatives whenever people need to work together to achieve a common goal. The primary objective
of Agile development is to deliver value early in the Project Lifecycle based upon customer and market
1
PMI Standards Committee, Project Management Body of Knowledge, Library of Congress Cataloguing-in-Publication data, 1996, page 10
12/6/2006 Page 1
demands. The ability to deliver value early and often, yet readily adapting to change, is considered to be a
major contributor in making Agile Development one of the more rapidly growing trends in technology.
Below is a list of Scrum characteristics in contrast with traditional waterfall attributes:
• A dynamic Product Backlog of prioritized work to be done. Although not specifically mentioned in
traditional project management above, this backlog may be loosely compared with traditional projects or
smaller initiatives that are waiting to become active. Together with the Release Plan, the Product
Backlog is jointly compiled by the busines Product Owner and the Development Team.
• A Release Plan to deliver larger initiatives across multiple Sprints, with the highest priority first. The
Release Plan is similar to the traditional Project Schedule in that it identifies product features and the
corresponding timeframes (possibly phases) in which features will be delivered, albeit at a higher level
than traditional Project Plans. Quality-related features, risks, dependencies, constraints, assumptions
and issues may also be identified and documented as part of the Release Plan, which is generated by the
Product Owner and Development Team.
• A Sprint Planning Meeting in which backlog items are selected for iterations(s) called Sprints (which
are usually 30 days in length). Product Owners and the Development Team finalize features and
identify related tasks to be completed within the Sprint, and provide task estimates as part of planning.
When applicable, the Release Plan will be referred to during the Sprint Planning Meeting. Risks and
issues are also discussed at the Sprint Planning Meeting. The resulting Sprint consists of condensed
Planning, Development, Testing and Release Project Lifecycle tasks and activities.
• A living Sprint Backlog or Sprint Plan of tasks to be done within the Sprint. When tasks are identified
in the Sprint Planning Meeting or during a Sprint, they are entered into the Sprint Backlog. The Sprint
Backlog is related to the Project Scope mentioned above in traditional projects because it encompasses
activities and deliverables that need to be completed within the Sprint. When a particular Sprint is part
of a Release Plan encompassing multiple Sprints, its backlog may be compared to the deliverables
within a traditional project phase. The product Owner and Development Team create the Sprint
Backlog.
• A brief daily Sprint Meeting or Scrum, at which each team member’s progress is disclosed, upcoming
work is described and committed to, and impediments are raised. The Sprint Backlog is updated at the
Sprint Meeting, and business partners are frequently members of the Scrum team. The daily meeting is
the primary formal means of communication among the team, although informal meetings and other
forms of communication throughout the day are encouraged.
• A Demo at which Product Owners (and occasionally developers) demonstrate accomplishments during
the Sprint. Each Sprint should deliver a usable product increment. The Demo has no equivalent in
traditional projects.
• A Retrospective, at which team members reflect about the past sprint and make recommendations about
future improvements or changes. The Retrospective may be loosely compared with Post-
Implementation Reviews in traditional projects.
Scrum is facilitated by a Scrum Master whose primary responsibility is to remove obstacles hindering the team
from delivering the Sprint goal. The Scrum Master is not the leader of the team because the Sprint team is self-
organizing. Instead, the Scrum Master acts as a facilitator for issues resolution and communication, rather than
as a manager controlling the team. The Scrum Master notes and removes obstacles, safeguards the Scrum
process, facilitates collaboration, and acts as a “sheepdog” for the team. Whereas the Project Manager is held
ultimately accountable for traditional projects, the entire Sprint team - including the Scrum Master - shares
responsibility for consummating the Sprint’s objectives.
Relatively little has been written about budget and cost control with respect to Scrum. Some corporations
consider cost to be a factor when considering which features to include in a Sprint. Generally the organization
itself is left to decide who will be in charge of monitoring the budget for a Scrum initiative.
12/6/2006 Page 2
Scrum utilizes an empirical approach. Unlike waterfall methodologies, Scrum accepts that a software initiative
cannot be completely understood or fully defined up-front, and that requirements will change over time.
Scrum’s purpose is to maximize the team's ability to respond in a responsive manner to change, and to produce
a working product increment which is demonstrated to and accepted by the user in every Sprint.
It is obvious that Scrum diverges from the approach to Project Management exemplified in the Project
Management Body of Knowledge (PMBOK) - which has as its goal quality through application of a series of
prescribed processes, documentation, and controls overseen by the Project Manager. In contrast, the Agile
movement espouses that people and their interactions with each other are the key to creating value.
According to the Digital Focus Agile 2006 Market Survey, which incorporates 136 executives across 128
organizations ranging in size from under 25 employees to over 5,000 employees, 46% of mid-size companies
and 12% of large companies are using Agile practices company-wide. In the large company category, 44
percent are using Agile practices on one or more projects.
12/6/2006 Page 3
Project Management Comparison – Traditional and Scrum
The following table provides a side-by-side comparison of Project Management practices and deliverables with
respect to the traditional waterfall approach vs. Scrum.
Project Management Practices and Deliverables: Traditional & Scrum
ITEM TRADITIONAL WATERFALL SCRUM
Processes
Project Planning 5 Levels of Planning:
(Scope, . There is no equivalent of a Vision statement in . Vision (a brief statement specifying direction)
Schedule, waterfall projects, although a corporate Strategic derived by Product Owner
Communication, Directive may be derived to specify direction and
and Human ultimately the projects that support it.
Resources)
. There is no specific equivalent of a Roadmap in . Roadmap (a brief document consisting of 1 year’s
waterfall projects, although companies may generate worth of high level features) created by the Product
their own internal Strategic Plans in support of Owner & Executives
Strategic Directives.
. Once a project has been justified and approved, the . Release Plan to deliver larger initiatives across
PM leads the requirements gathering and time multiple Sprints, compiled by the Product Owner and
estimation effort by holding extensive meetings with Development Team. The effort is usually facilitated
Business Analysts, designers, architects, IT, Product by the Scrum Master.
Owner(s) and key stakeholders. The PM oversees the
creation of documentation-related deliverables such
as Feasibility Studies, Statements of Work,
Communication Plan, Contracts, Requirements
Documents, etc.
. The PM creates the Project Plan to derive a . A Sprint Plan identifying all tasks & estimated task
preliminary project schedule and subsequently hours is created by the Product Owner &
baselines the plan after reviewing it with project team Development Team – not by the Scrum Master. It is
members and management. updated daily by the team at the Scrum meeting once
the Sprint commences. Only estimated hours
outstanding are tracked – actual hours are neither
requested nor recorded.
. The PM meets with the project team periodically . Daily Sprint Meeting or Scrum. (15 min.) which is
(as specified within the Communication Plan) to facilitated by the Scrum Master. This is the main
update the Project Plan with actual hours and revised means of ongoing team communication. The Scrum
estimates, and to discuss risks and/or issues. The PM Master asks each team member what was committed
is chartered with documenting risks and issues and to yesterday, what is being committed to today, and
overseeing their successful closure. if there are any obstacles. The Scrum Master records
obstacles and oversees their removal. The Sprint
Plan is updated with estimated hours outstanding.
. Line Management decides upon project team . Line Management allocates Sprint resources.
resource allocations. The PM may negotiate with Negotiation prior to the beginning of the Sprint may
management at any time for resources if available or may not be possible, depending upon corporate
resources are insufficient to deliver the project scope adaptation of Scrum. Scrum team composition does
within the prescribed schedule. not change during the course of the Sprint.
. The project is usually end date-driven and generally . Project schedule is derived via the Release Plan if
incorporates as many requirements as possible. appropriate. Each Sprint is of fixed duration, and the
highest priority items are delivered in the initial
Sprint(s).
12/6/2006 Page 4
Monitoring . Changes to requirements are typically managed . Only the Sprint team can change features and tasks
Project Change through a Change Control Process overseen by the within a Sprint, and only if jointly agreed by all
Control and Risk Project Manager. Activities include, sizing, and members of the Sprint Team. Otherwise the
– (Scope and obtaining management approval. requested item is added to the Product Backlog.
Risk)
. The Project Manager is responsible for Risk . The team performs risk management activities
Analysis and Contingency Planning, and usually before starting development work. Risk may be
maintains and publishes a Risk Document. discussed during Release, Sprint Planning, and/or
daily Scrum Meetings.
Task Ownership; . The PM creates a Project Plan with tasks, . Team members create, sign up for, and estimate
Actuals/Estimates assignments, and estimated hours. The Project Plan is tasks in lieu of being assigned to tasks by the Scrum
(Schedule and reviewed with the Project Team and baselined once Master. There is no baselining in Scrum.
Human all parties concur. Deviations from the baseline must
Resources) be explained and addressed by the PM.
. The PM periodically updates the Project Plan with . Team members may adjust estimated outstanding
actual hours and new estimates, as well as with hours and add, transfer, or cancel tasks during the
additional tasks based upon team input. daily Sprint Meeting. Actual hours are not tracked –
only hours outstanding.
. The PM acts as a coach and leader for the project . The Scrum Master facilitates the team but typically
team and assists team members in overcoming does not coach or lead team members, who are
obstacles. considered self-managing.
Project Overruns . If the completion date of the project or phase . Scrum promotes a fixed 30 day timeframe for
(Schedule) appears to be in jeopardy, the PM is responsible for deliverables. If it appears that a deliverable(s) may
negotiating one or more of the 5 following items: be delayed, the item(s) will be added to the Product
• Scope (reduction) Backlog and will most likely be carried forward to
• Schedule the next Sprint. The Sprint itself is never extended,
• Cost nor does the Scrum Master negotiate for additional
• Resources resources or time.
• Quality
Project Budget . Typically, a project must provide ROI in order to be . At the beginning of each Sprint, the Product Owner
(Cost) launched, at which point a Project Budget is derived. may be asked how much they want to spend on the
Sprint. Based upon the answer, the team may use
cost as a guideline when selecting an appropriate
amount of work from the Product Backlog to be done
in the Sprint.
. The PM usually manages the Project Budget, which . No mention could be found in Scrum materials
includes resource costs, technical costs, consultancy, regarding Sprint-related budgets. It is assumed that
departmental charge backs (if appropriate), and other each corporation adopts its own practices with
expenses. Potential overruns must be justified and respect to software development costs.
approved, and/or the PM must negotiate adjustments
to the aforementioned 5 items in order to meet
budget.
Project Control – . From the customer’s perspective, quality means on- . In Scrum, quality entails the delivery of a working
(Quality) time system delivery, to spec, and within budget and product increment by the end of the Sprint in
schedule. accordance with the specified feature(s). In cases
where expense is a factor, cost constraints must be
adhered to as well.
. Quality Management Plans and Checklists are often . When applicable, quality-related features may be
used to document and cross-check quality identified in Release and/or Sprint Planning
requirements. Although the PM might not be Meetings, and they are built during the Sprint. As
personally accountable for drafting these, s/he is with any other feature, the entire Sprint team is
responsible for ensuring that quality requirements and accountable for providing the quality feature.
metrics are actualized by the project.
. In waterfall projects, QA personnel typically . In Scrum, QA personnel may be needed for testing
12/6/2006 Page 5
become engaged in the testing phase. in every Sprint, which can create a resource burden
on this group.
Documents
Cost Benefit . A Cost Benefit Analysis (CBA) may be submitted . The author could not locate a CBA equivalent in
Analysis and approved in order for a project to be done. The Scrum.
PM may or may not be chartered with compiling this
document. ROI is typically a key factor with respect
to whether an initiative is approved for development.
Requirements . Related documents include but are not limited to: . In Scrum, there are 3 requirements-related items as
* Feasibility Study described on page 2 of this document:
* Statement of Work
* Project Scope * Product Backlog
*. Requirements Document * Release Plan
* Functional Design * Sprint Backlog/Plan
* Detailed Design
* Test Plans and Test Cases, which are sometimes
done at the Requirements Definition Phase
. The PM is generally chartered with overseeing that . All three items are compiled by the Product Owner
the necessary requirements-related documentation is and Development Team, although the Scrum Master
compiled and approved. may facilitate the meetings.
Change Control . PM is accountable for overseeing that changes to . Once a Sprint is underway, the entire team must
original project scope are documented, submitted, and concur upon a change before it is accepted. Other
approved. changes may be added to the Product Backlog at any
time.
Communication . PM compiles and disseminates a Communictaion . There is no equivalent to the Communication Plan
Plan Plan depricting project communication-related in Scrum.
deliverables (such as Team Meetings and Steering
Committee Status Reports), specifying who will
receive or be involved in them, and how often.
Budget . Generally the PM is accountable for overseeing and . The author could find no mention of Project Budget
Spreadsheet reporting the Project Budget. maintenance with specific respect to Scrum.
Issues Log . The PM is accountable for compiling and updating . Issues/obstacles can be raised at any point, and the
the Issues Log and for overseeing that issues are Scrum Master is responsible for documenting them,
resolved. removing obsacles, and overseeing their closure.
Risk Analysis . The PM is accountable for compiling and updating . Risks are documented by the Product Owner and
the Risk Analysis and Contingency Plan, and for Development Team in the Release Plan. The entire
navigating the team safely through the risks in order Sprint Team is responsible for resolving risks
to deliver the project successfully. throughout the Sprint.
Project Plan . The PM uses the Project Plan to derive the . The Sprint Plan (tasks & hours per Sprint) is
preliminary project schedule. The PM then baselines created by the Product Owner &Dev Team – not by
the schedule and meets periodically with the team to the Scrum Master. It is updated daily by the team
update the Project Plan with actual hours and revised once the Sprint begins. Only estimated hours
estimates/tasks. outstanding are tracked. The Sprint Plan is not
baselined.
Status Reports . The PM generates and delivers Project Status . Scrum does not specifically address project status
Reports as warranted. reports. Scrum is generally light on documentation;
it emphasizes personal interaction which would
normally entail status-related information.
Quality . Quality Management Plans and Checklists are often . When applicable, quality-related features may be
Management used to document and cross-check quality identified in Release and/or Sprint Planning
Plan; Checklists requirements. Although the PM might not be Meetings and built during the Sprint. As with any
personally accountable for drafting these, s/he is other feature, the entire Sprint team is accountable
responsible for ensuring that quality requirements and for providing the tasks and activities to support
metrics are actualized by the project. quality-related items.
Test Plans . Although the PM may not actually write test plans, . Scrum acknowledges that a viable product
the PM is responsible for ensuring that test plans are increment must be delivered and accepted in a
documented and successfully deployed. Sprint. It is up to the Product Owner to determine
and ultimately test for viability within the Sprint.
12/6/2006 Page 6
Post- . The PM is responsible for ensuring that post- . A “stabilizing Sprint” may be planned for in the
Implementation installation support is available to the product Release Plan and executed where appropriate.
Support recipient.
Team Meetings
Steering . For high-visibility, high-risk endeavors, the PM will . The author could find no mention of Steering
Committee Status set up and participate in regularly scheduled Steering Committee Meetings with respect to Scrum.
Meetings Committee Meetings (as per the Communication
Plan) at which the status of the project is discussed.
Team Meetings . As per the Communictaion Plan, the PM will usually . In Scrum, the 15-minute daily Scrum meeting is the
schedule regular team meetings to discuss progress, key vehicle for discussing progress, roadblocks, and
actuals/estimates, issues, and risk. Such meetings upcoming commitments as well as obstacles.
may last an hour or more.
Post- . There is no equivalent to the Sprint Demo in . At the end of each Sprint, a Demo is held at which
Implementation traditional waterfall projects. the product recipient demonstrates the usable product
Review increment created during the Sprint.
. It is common for the PM to hold a Post . A Retrospective is held, at which team members
Implementation Review with the Project Team at the reflect about the past Sprint and make
end of the project in order to document what went recommendations about future improvements or
well and what could be improved upon. changes. The Scrum Master typically hosts the
Retrospective.
Recommendation, Conclusion, and Final Questions:
As can be readily determined from the above, Scrum strongly advocates self-managing teams in which the
Scrum Master acts primarily as a facilitator helping the team solidify its tasks as well as ‘running interference’
regarding any obstacles that may have a negative impact on team productivity. Self-managing teams require
time to evolve; they do not happen overnight. Since Scrum documentation is relatively light on how to prepare
a team to become self-sufficient, it is recommended that formal team-related coaching be provided prior to
implementing Scrum.
For seasoned Project Managers, the transition from leader to facilitator may be a difficult mindset to change,
especially if the transition is fairly sudden. The traditional Project Manager may be compared with the captain
of a ship who is chartered with steering the course, anticipating and overcoming difficulties, and ultimately
safely delivering the cargo and passengers on schedule. In contrast, the Scrum Master acts mainly as an enabler
to the Scrum Team since the entire team is responsible for the outcome of each Sprint. Whereas the Scrum
Master primarily utilizes facilitation skills during the course of a Sprint, facilitation is a subset of the entire skill
set required to be a successful PM. Experience and knowledge regarding requirements definition, time
management, estimating, negotiating, budget oversight, and anticipating risk are all expected of the seasoned
Project Manager. How these attributes may be best leveraged in Scrum - if at all - and to what extent the Scrum
Master is free to tap into them is yet to be determined.
Two final questions to pronder:
1 - Will the definition of Scrum Master evolve over the next decade to incorporate more traditional project
management skills and approaches?
Only time will tell, and the answer may depend upon how Scrum is adapted with regard to a company’s specific
culture.
2 - Will seasoned Project Managers who become Scrum Master find themselves underutilized?
If so, they will probably write a white paper as this author did.
Anne Loeser can be reached at bestbird@hotmail.com.
12/6/2006 Page 7
