Transcript Managing a Project Using an Agile Approach and

Managing a Project Using an Agile
Approach and the PMBOK® Guide
Kathy Schwalbe, Ph.D., PMP
November, 2012
[email protected]
www.kathyschwalbe.com
1
Presentation Outline
• What is agile? Why the new interest?
• Scrum basics
• PMI process groups and agile
– Project pre-initiation and initiation
– Planning
– Executing
– Monitoring and controlling
– Closing
• Conclusions
What is Agile?
• Agile means being able to move quickly
and easily. Some people feel that project
management, as they have seen it used,
does not allow people to work quickly or
easily
• Agile today means using a method based
on iterative and incremental development,
in which requirements and solutions
evolve through collaboration; “agile” first
used for software development projects
Agile Manifesto
• In February 2001, a group of 17 people that
called itself the Agile Alliance developed and
agreed on the Manifesto for Agile Software
Development, as follows:
• “We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
–
–
–
–
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”*
*Agile Manifesto, www.agilemanifesto.org.
4
Why the New Interest in Agile?
• People still have difficulty managing projects,
especially those with unclear and changing
requirements
• The Project Management Institute (PMI)
developed a new certification in 2011 called
Agile Certified Practitioner (ACP)
• “The use of agile as an approach to managing projects
has been increasing dramatically over the last several
years. Gartner predicts that by the end of 2012, agile
development methods will be used on 80 percent of all
software development projects. PMI’s research has
shown that the use of agile has tripled from December
2008 to May 2011.” (www.pmi.org)
What is Scrum?
• According to the Scrum Alliance, Scrum is the
leading agile development method for
completing projects with a complex, innovative
scope of work
• The term was coined in 1986 in a Harvard
Business Review study that compared highperforming, cross-functional teams to the
scrum formation used by rugby teams
Scrum Framework
Note: All figures with Cengage Learning 2014 copyright are from my upcoming book,
IT Project Management, 7th edition, out in November 2012.
Scrum Roles
1. Product owner: Responsible for the business value of
the project, decides what work to do and in what order
(documented in the product backlog
2. ScrumMaster: Ensures that the team is productive,
facilitates the daily Scrum
– Has authority over the process but not the people
– Some experts suggest that traditional project managers do not
make great ScrumMasters
3. Scrum team or development team: Cross-functional
team of 5-9 people who organize themselves and the
work to produce the desired results for each sprint. (A
sprint normally lasts 2-4 weeks, during which specific
work must be completed and made ready for review)
8
Scrum Artifacts
• Product backlog: A single list of features
prioritized by business value (about 10 workdays for each item)
• Sprint backlog: The highest-priority items
from the product backlog to be completed
within a sprint. The Scrum team breaks down
the highest-priority items into smaller tasks
that take about 16 hours to complete
• Burndown chart: Shows the cumulative work
remaining in a sprint on a day-by-day basis
9
Scrum Ceremonies
• Daily Scrum: A short meeting for the
development team to share progress and
challenges and plan work for the day
• Sprint reviews: A meeting in which the team
demonstrates to the product owner what it
has completed during the sprint
• Sprint retrospectives: A meeting in which the
team looks for ways to improve the product
and the process based on a review of the
actual performance of the development team
10
Unique Scrum Activities by Process Group
11
Scrum Framework and the Process Groups
12
Project Pre-Initiation and Initiation
• Not different from PMBOK® Guide
– Still create a project charter, stakeholder
register, stakeholder management
strategy, and have a kick-off meeting
• Different
– Determine roles and decide what
functionality to deliver for each release,
how many springs for a release, and how
many releases of software to deliver
13
Planning
• Not different from PMBOK® Guide
– Still create a scope statement and can use
a Gantt chart for the entire project
schedule; other planning similar (risk, etc.)
• Different:
– Descriptions of work are identified in the
product and sprint backlogs, more detailed
work documented in technical stories,
estimate a velocity or capacity for each
sprint; release roadmap often used for
schedule
14
Executing
• Not different from PMBOK® Guide
– Still produce products, lead people, etc.
• Different:
– Produce several releases of software users of the new software might be
confused by getting several iterations of
the product instead of just one
– Communications different because the
project team meets every morning,
physically or virtually
15
Gantt Chart Using Scrum Approach
3 software
releases vs. 1
16
Monitoring and Controlling
• Not different from PMBOK® Guide
– Still check actual work vs. planned work
• Different
– Names of key reviews are the daily Scrum
and the sprint review
– A sprint board is used instead of a tracking
Gantt chart or other tools
– Use a burndown chart vs. earned value
chart
17
Burndown Chart
18
Closing
• Not different from PMBOK® Guide
– Focus is still on acceptance of deliverables
and reflection
• Different:
– The retrospective is similar to a lessons-learned
report, but it focuses on a shorter period of time.
It is intended to answer two fundamental
questions:
• What went well during the last sprint that we should
continue doing?
• What could we do differently to improve the product or
process?
19
Conclusions
• You can still use the 5 process groups described
in the PMBOK® Guide to manage an agile
project while also using unique aspects of Scrum
• The increased interest in agile is based partly on
the hope that it will somehow make project
management easier
• Many books, courses, and consultants are
capitalizing on this “new” approach; seasoned
project managers understand that they have
always had the option of customizing how they
run projects, but that project management is not
easy, even when using agile
20
Questions/Comments?
[email protected]
www.kathyschwalbe.com
21