Managing a Project Using an Agile Approach and the PMBOK® Guide Kathy Schwalbe, Ph.D., PMP November, 2012 schwalbe@augsburg.edu www.kathyschwalbe.com

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.

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 high-performing, 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 Product owner: Responsible for the business value of the project, decides what work to do and in what order (documented in the product backlog 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 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)

Scrum Artifacts Product backlog: A single list of features prioritized by business value (about 10 work-days 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

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

Unique Scrum Activities by Process Group

Scrum Framework and the Process Groups

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

Planning Not different from PMBOK® Guide Different: 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

Executing Not different from PMBOK® Guide Different: 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

Gantt Chart Using Scrum Approach 3 software releases vs. 1

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

Burndown Chart

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?

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

Questions/Comments? schwalbe@augsburg.edu www.kathyschwalbe.com