January 17, 2012 January 17, 2012 1
Agile has now become mainstream, and there are two dominant approaches for managing projects: Traditional Project Management (TPM) - Best represented by the PMBOK Guide using Earned Value Method EVM) Agile Project Management (APM) Was first used primarily for software projects. Now, it is being used in many other new product and service development areas. January 2012 PMNetwork Magazine 90% of Software PMs that were interviewed said they were using some form of Agile Use of Agile has tripled from December 2008 to May 2011 Most PMs using Agile cite much higher success rates January 17, 2012 2
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. January 17, 2012 3
Scrum XP (Extreme Programming) Lean Crystal DSDM (Dynamic Systems Development Method) FDD (Feature Driven Development) January 17, 2012 4
Most authors of books & articles on Agile say NO! Agiledefines a revolutionary approach to managing projects. It is diametrically opposed to the practices described in TPM! Doug DeCarlo Extreme Project Management If TPM is classical music Agile is jazz If TPM is classical, l Newtonian physics Ail Agile is Quantum Mechanics Cites a quote from a PMP managing pension implementations: I always believed that the project management profession is doing itself a disservice if it doesn't recognize that many, if not most, projects don't follow the guidelines set forth hby PMI's PMBOK Guide. (Other references): Jim Highsmith Agile Project Management: Creating Innovative Products Ken Schwaber Agile Project Management with Scrum January 17, 2012 5
The PMI View Yes, of course, the two approaches are compatible! The PMBOK Guide defines a high level framework of best practices for managing projects in any industry, no matter how simple or how complex. Attaching to this framework, there can be many more specific methodologies and approaches that can be used. Agile Project Management defines such a group of more specific methodologies. From pmi.org FAQ page on the new PMI ACP certification: The PMBOK Guide Fourth Edition contains principles of project management and project management processes. These processes describe what should be done during the management of a project. Agile methodologies are different in that they describe how to do the things that should be done in short, what versus how. January 17, 2012 6
Waterfall Divide the project into a set of sequential phases. Term coined by Winston Royce 1970. (He was really criticizing the Waterfall Method in his article!) January 17, 2012 7
We will organize the phases in a sequential manner (or Waterfall structure.) Conceptual Design Detailed Design Development Unit Testing Integrated Testing Phases October 31, 2011 8
Customer doesn t see the product or application for 1 2 years In that time, their requirements have changed! (The world has kept moving.) It s not until they really get to see and use the product that they understand what they really needed in the first place It s not until they really get to see and use the product that we learn if we understood their requirements properly! Therefore, we often have some of the things we hate the most: Scope Creep, Schedule Delays, Cost Overruns, (Anda newproject Manager!) January 17, 2012 9
We will use an iterative approach: (Iterations or Sprints to build prototypes) The Product Owner defines the Product Backlog From this, an initial subset of the backlog is chosen for the first iteration (Sprint) Very quickly: within an iteration of 2 weeks to 4 weeks we will create an initial prototype (Sprint Backlog) of core features/stories. At the end of each iteration the prototype is reviewed, and the team goes through a review or adaptive process. A backlog is chosen for the next iteration We iteratively keep going through this process of exploring, discovering, and adapting progressively elaborating the prototypes and creating true value for the customer. We let the requirements emerge. January 17, 2012 10
Quickly get feedback from the customer Identify Fast Failures Fil Determine if we did understand the requirements properly Oftentimes, it s not until the customer sees and uses the product that they truly understand what they need (Oftentimes, requirements they thought were essential, they realize are not!) So, we don t waste time on non essential requirements From Doug DeCarlo s book: If a picture is worth a thousand words, a prototype is worth a thousand pictures! January 17, 2012 11
Rolling Wave Planning is often used on projects We should use progressive elaborationelaboration throughout our projects: Look for ways to make continual improvement Rolling wave planning is just one type of progressive elaboration Processes from all five process groups should be iteratively used in all phases. Planning processes will normally occur even at the end of a project! Prototyping is a key tool that is mentioned for collecting requirements. So, Sprints and Agile Iterations could be viewed as instances of using Rolling Wave planning. January 17, 2012 12
Monitor Plan Initiate Close Execute Control January 17, 2012 13
Project Phases & Process Group Relationship. Processes From All Five Process Groups Occur Within Phases! Conceptual Detailed Coding/ Unit Integrated Phases Design Development Testing Testing Process Groups (See pp. 39 43 PMBOK Guide) Five Process Groups comprised of: Initiating Planning Executing Monitoring i i & Controlling Closing Cl i Processes) January 17, 2012 14
Managing Teams Corrective Actions Change Control Systems January 17, 2012 15
Team should be a group of 7 8 co located, cross functional individuals dedicated to the project Team members are empowered, and given freedom and authority for creating the backlog during Team is responsible/accountable for the iteration! ti (Not the PM) PM protects the team during the iteration, prevents interference from senior managers or other stakeholders. January 17, 2012 16
PMI does not have any problem with most aspects of team roles as defined in APM. PMI endorses co location very much PM often is a facilitator or a coach Empowering team members is perfectly appropriate in many situations: This is quite similar to how teams are handled in Theory Y, or Management by Objective structures PMI would say the PM is always accountable though! (Team members shouldhelp help create the WBS, and help create elements of the PM Plan, but the PM is ultimately accountable.) January 17, 2012 17
APM authors are quite critical of the corrective actions that are part of traditional project management Change Control lsystems. They say these are used to try enforce the original baselines, and repress change. This is not their purpose! p They find formal change management and configuration management to be too bureaucratic and repressive This is not an accurate representation of the purpose of monitoring & controlling and change management in the PMI model! PMI understands change is a fact of life. They would say we must plan for it, document it, and track the latest versions of products, deliverables and plans. January 17, 2012 18
Most of the disconnects between APM and the traditional approach appear to be the result of misunderstandings about the PMBOK Guide! (TPM) The PMBOK Guide does approve of iterative phase structures, and rolling wave planning. We could view iterations as a special implementation of Rolling Wave planning The PMBOK Guide does not intend change management and configuration management as a means to repress change and enforce the original baselines The PMBOK Guide has no problem with co located, empowered teams that are given a high degree of authority to achieve the iteration goals. This is just one of many possible models that could be used. January 17, 2012 19
So, is this the end of the story? (Agile just defines a set of specific approaches and methodologies that fit well within the framework of the PMBOK Guide?) No this isn t a complete, fair assessment! The PMBOK Guide does define a formal, prescriptive model for managing projects. The PMBOK Guide is an ANSI standard document that defines a formal standard for project management (e.g. all 42 processes should be used at some point in every project). The PM Plan is a fine grained plan with many components that should be formally approved before beginning execution. The PMBOK Guide strongly endorses EVM, and this requires the three key baselines to be defined in detail at the beginning of the project. For PMI Scope Requirements and the WBS are centered on engineering requirements at the most detailed level. For PMI, the PM is accountable, not the team January 17, 2012 20
There are no baselines, so in APM we cannot use traditional methods of variance analysis defined in the PMBOK Guide Cannot use Earned Value Method (EVM) as traditionally conceived. Some interesting proposals for adapting EVM in Agile have been proposed. There is no consensus on the right way to do it. See see Earned Value and Agile Reporting by Anthony Cabri and Mike Griffiths Quadrus Development Inc. - http://leadinganswers.typepad.com/leading_answers/files/rp2_cabri_griff iths_agile_and_earned_value_reporting.pdf and earned reporting pdf January 17, 2012 21
Classic S Curve Cost Baseline So, on 1/17: CPI = EV/AC = 85,000/110,000 =.77 For every dollar we re spending, we re getting 77 cents of value! Cost $$ $110,000 $$ $100,000 AC PV Budget at Completion (BAC) $180,000 $85,000 EV 10/01/2011 Time 1/17/2012 4/17/2012 January 17, 2012 22
The PMBOK Guide prescriptive p approach is defining a push model for managing projects. For PMI, do the detailed planning up front, and define the three key baselines. Measure your performance using EVM as you go through the project. The PM is accountable for all aspects. Team members help build the WBS and elements of the plan, but the PM is in charge of the plan. For the PMBOK Guide, requirements get translated into technical, engineering specification in work packages. Agile defines a pull model Since the requirements are undefined upfront, and are expected to change, use a pull model. Discover and explore the requirements as we move through the project, or let the requirements emerge Requirements are always defined in terms of what provides customer value We will let the team choose what type of planning must be done, and what level of detail is required. We will use a JIT (Just in Time) approach. January 17, 2012 23
How will the Agile Project Management Approach be integrated? Draft of version 5 of the PMBOK Guide is scheduled to be released on the pmi.org website on Feb. 17. Expected release date for version 5 is December 31, 2012. The PMBOK Guide Fifth Edition, will mention Agile specifically, but is not expected to discuss this methodology in any depth. It will be interesting to see if chapters 1 through 3 have any significant revisions to allow for the different pull (JIT) model indicated by Agile methodologies. I m not expecting that to happen! January 17, 2012 24
Mark Tolbert, PMP Best Practices Training, i LLC http://www.bestpractices pmptraining.com (571) 354 0374 Link to full article on same topic: http://www.bestpractices pmptraining.com/agile project management vs thepmbok guide part ii full article/ January 17, 2012 25