Comparing PMBOK and Agile Project Management Software Development Processes

Transcription

1 Comparing PMBOK and Agile Project Management Software Development Processes P. Fitsilis TEI Larissa Larissa, Greece Abstract- The objective of this article is to compare a generic set of project management processes as defined in Project Management Body of Knowledge (PMBOK) with a number of agile project management processes. PMBOK is developed by Project Management Institute and it is structured around five process groups (initiating, planning, execution, controlling and closure) and nine knowledge areas (integration management, scope management, time management, cost management, quality management, human resource management, communication management, risk management, procurement management). On the other hand, agile software project management is based on the following principles: embrace change, focus on customer value, deliver part of functionality incrementally, collaborate, reflect and learn continuously. The purpose of this comparison is to identify gaps, differences, discrepancies etc. The result is that, agile project management methodologies cannot be considered complete, from the traditional project management point of view, since a number of processes either are missing or not described explicitly. I. INTRODUCTION Traditional software development methodologies grew out of a need to control large development projects, and from the difficulties of estimating and managing these efforts to reliably deliver results. These difficulties are inherited in the nature of software and they were identified from the early years of software system development and unfortunately most of them still remain. Most of the skepticism expressed in the legendary book of Frederic Brooks, The mythical man-month thirty years ago is still valid [1]. Further, today s information technology professionals are under tremendous pressure to deliver quality IT products and services, in order to respond to an always dynamic and fast changing market. As a result, the list of large software projects that have failed is still growing. Robert Charette [2] compiled a list of the most notable fiascoes in the IT industry. Further, he states that most IT experts agree that such failures occur far more often than they should and that the failures are universally unprejudiced. Literature suggests that project organization, stakeholders expectation management, scope creep etc., are always important factors leading to project success, when managed properly [3, 4, 5]. Agile methodologies attempt to overcome these obstacles by changing the approach used to develop software and manage projects. Agile software development attempts to put the software being developed first. Further, agile methods acknowledge that the user requirements change, that we have to respond quickly to the users needs, that there is a need to produce frequent and regular, software releases, etc. The Manifesto for Agile Software Development was released in February 2001 by a group of 17 software process methodologists, who attended a summit meeting to promote a better way of developing software and then formed the Agile Alliance. The Manifesto for Agile Software Development can be found on the Agile Alliance website ( Since then, a number of software development methods subscribed to this approach. The list varies depending on different viewpoints and interpretations, but in general the list includes Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Adaptive Software Development (ASD), Crystal Clear Methodology, etc. Most agile development methods were created within corporations by software process experts as an attempt to improve existing processes. For example, XP was created by Kent Beck during his work on the Chrysler Comprehensive Compensation System payroll project. Kent Beck refined the development method used and the result was published in his book Extreme Programming Explained [6]. Similarly, FDD was initially introduced by Jeff De Luca, in order to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in FDD was influenced by ideas of Peter Coad on object modeling. The description of FDD was first introduced in the book Java Modeling in Color with UML by Peter Coad, Eric Lefebvre and Jeff De Luca in 1999 [7]. A more generic description of FDD decoupled from Java can be found in the book A Practical Guide to Feature- Driven Development [8]. On the other end more traditional project management methodologies rely heavier on processes, linear development cycles and waterfall like software development life cycles. Along with predictability, they inherited a deterministic, reductionist approach that relied on task breakdown, and was predicated on stability stable requirements, analysis and T. Sobh (ed.), Advances in Computer and Information Sciences and Engineering, Springer Science+Business Media B.V. 2008

2 AGILE PROJECT MANAGEMENT SOFTWARE DEVELOPMENT PROCESSES 379 stable design. This rigidity was also marked by a tendency towards slavish process compliance as a means of project control [9]. Project Management Body of Knowledge (PMBOK) developed by Project Management Institute is the best representative of this approach [10]. PMBOK formally defines a total of 44 project processes that describe activities throughout a project s life cycle. These 44 project processes are organized into two axis: into five process groups and into nine knowledge areas that will be described briefly in the following section. Within PMBOK each process is described in terms of inputs (documents, plans, design, other data, etc.), outputs (documents, products) and tools and techniques (mechanisms that are applied to inputs for producing outputs) and without being too specific, it provides guidance to someone that wishes to apply the processes [11]. Similar approaches, process oriented, have been introduced by other international bodies or associations. Among them, worths mentioning International Project Management Association, Competence Baseline (ICB), which describes the necessary competences (technical, behavioral, contextual) for project management [12] and project management body of knowledge as defined by Association for Project Management in UK (APM) ( which again describes 40 necessary for project management competencies. These approaches study project management in a multi facet way and therefore somebody can argue about the definition of a process or if a competence is needed but not about their completeness. Further, most of them are widely known and accepted by professionals and organizations. However, even if agile methods look attractive and their use is achieving promising results there is criticism if they are complete project management methodologies or extended, with some management elements, software lifecycles. Similar studies and discussion can be found to [13, 14] In the next sections, we will briefly present PMBOK along with some of the most known agile methods. Then we will to compare them having as basis for comparison the processes as defined, per knowledge area, in PMBOK. II. PROJECT MANAGEMENT INSTITUTE BODY OF KNOWLEDGE As it was mentioned before, Project Management Body of Knowledge (PMBOK) [10] is defined in terms of process groups and knowledge areas. In this study, we will focus on the knowledge areas, since these areas are offering a more precise idea of what is project management about and at the same time they give the overall picture. The knowledge areas are the following: 1. Project Integration Management describes the processes and activities that integrate different aspects of project management. It consists of the following processes: a. Develop Project Charter, b. Develop Preliminary Project Scope Statement, c. Develop Project Management Plan, d. Direct and Manage Project Execution, e. Monitor and Control Project Work, f. Integrated Change Control, and g. Project Closure. 2. Project Scope Management. It encapsulates processes that are responsible for controlling project scope. It consists of: a. Scope Planning, b. Scope Definition, c. Create Work Breakdown Structure (WBS), d. Scope Verification, and e. Scope Control. 3. Project Time Management, which describes the processes concerning the timely completion of the project. It consists of a. Activity Definition, b. Activity Sequencing, c. Activity Resource Estimating, d. Activity Duration Estimating, e. Schedule Development, and f. Schedule Control. 4. Project Cost Management that includes processes concerning the cost. The processes that are part of this knowledge area are: a. Cost Estimating, b. Cost Budgeting, and c. Cost Control. 5. Project Quality Management describes the processes involved in assuring that the project will satisfy the objectives for which it was undertaken. It consists of: a. Quality Planning, b. Perform Quality Assurance, and c. Perform Quality Control. 6. Project Human Resource Management includes all necessary processes for organizing and managing the project team. It consists of: a. Human Resource Planning, b. Acquire Project Team, c. Develop Project Team, and d. Manage Project Team. 7. Project Communications Management describes the processes concerning communication mechanisms of a project, and relate to the timely and appropriate generation, collection, dissemination, storage and ultimate disposition of project information. It consists of the following processes: a. Communications Planning, b. Information Distribution, c. Performance Reporting, and d. Manage Stakeholders 8. Project Risk Management describes the processes concerned with project-related risk management. It consists of: a. Risk Management Planning,

3 380 FITSILIS b. Risk Identification, c. Qualitative Risk Analysis, d. Quantitative Risk Analysis, e. Risk Response Planning, and f. Risk Monitoring and Control. 9. Project Procurement Management includes all processes that deal with acquiring products and services needed to complete a project. It consists of: a. Plan Purchases and Acquisitions, b. Plan Contracting, c. Request Seller Responses, d. Select Sellers, e. Contract Administration, and f. Contract Closure. III. AGILE PROJECT MANAGEMENT Agile Software Development manifesto objective was to uncover better ways of developing software by doing it and helping others do it (( The principles that it is based are the following: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Obviously, the agile manifesto is not a process oriented approach. As, it was presented in the introduction, there are many software development methods that can be called agile. However, in this work we have selected to include only a few of them as the most representative. The software development methods that were included are: Extreme Programming (XP), Scrum and Feature-Driven Development (FDD). A. extreme Programming (XP) Extreme Programming, or XP, is an agile method that emerged from a project at Chrysler Corporation in the late 1990s. It was devised by Ward Cunningham, Kent Beck, and Ron Jeffries. The method is well documented in a number of books, articles and web sites ( [6, 15, 16, 17]. XP method is based on four values: Communication, which is based on practices such as unit testing, pair programming, task estimation. Simplicity, by always seeking the simplest solution. Feedback, by having concrete knowledge about the current state of system Courage, to admit flaws in the system and take immediate corrective actions Further, XP is based on a number of practices. Some of them are: Planning. The scope of the next release should be defined as soon as possible, by combining business priorities and technical estimates. Small releases. The system has to be up and running by having very short cycles and quick releases. Metaphor. All development is driven by a simple story of how the whole system works. Simple design. Simple solutions are the preferred. Complexity should be removed wherever possible. Testing. Testing is a continuous activity. Pair programming. All programmers are working in pairs. Collective ownership. Anyone can change any code anywhere in the system at any time. Continuous integration. The system is built many times a day, as soon as a task is finished. On-site customer. A representative of the customer organization should be available full-time to the project team to answer questions. B. SCRUM Scrum approach for new product development was first presented by Takeuchi and Nonaka [18] after observing small high performance teams, at various companies. Similar, observations were made as well by other researchers [19, 20]. Scrum is an agile software development process where projects progress via a series of month-long iterations called sprints [21, 22, 23]. Furthermore, a series of scrum sprints, on average 6 to 9, can produce a product release. At the beginning of the project, the project requirements are captured into a list known as the product backlog. Then, at the start of each sprint a sprint planning meeting is held during which the product owner prioritizes over the product backlog and the members of the scrum team define the tasks that they can complete during the coming sprint. For each day of the sprint, there is daily stand-up meeting for discussing project issues, called the daily scrum. Daily scrums help significantly team development and team communication. Further, the members of the daily scrum can quickly decide on any issue requiring further attention. Issues are not debated in the meeting itself, since the meeting should not last more than 15 minutes. At the end of the sprint the team presents the developed functionality at a Sprint Review Meeting. Scrum processes are grouped in three phases [23], the pregame, the game and the post game. Pregame phase includes the following processes: Planning, which includes the definition of a new release based on currently known product backlog, along with an estimate of its schedule and cost. If the system under development is new, planning includes both conceptualization and analysis. Architecture development. Includes the architecture development and the high level design. The game consists of development sprints that produce a new product release. Postgame is the closure of the project, which includes preparation of the releases, producing the final documentation, executing the site acceptance testing and the final product release.

4 AGILE PROJECT MANAGEMENT SOFTWARE DEVELOPMENT PROCESSES 381 C. Feature Driven Development (FDD) Feature Driven Development (FDD) is an iterative and incremental software development process [7, 8]. FDD methodology consists of five steps that are the following: Develop the Overall Model, Build the Feature List, Plan by Subject Area, Design by Feature Set, and Build by Feature. In the first step, of developing the overall model, a high level walkthrough of the scope of the system and of its environment is done. The main purpose is to capture requirements and to develop the initial UML class diagram which describes the entities of the problem domain. The whole work is split and assigned to small teams, consisting of developers and users. These teams are responsible for parts of the whole model and for presenting their models for review and approval. Finally, the proposed models are merged in order to form the domain model. The second step of FDD is to build the feature list. The development team will identify the set of features needed, by decomposing the system functionality into subject areas. Each subject area is composed of business activities that comprise business activity steps (features). Features are granular functions expressed in customer terms. Usually, each feature requires up to two weeks of development. In case, the feature requires more time then this step is decomposed into smaller steps. The third step is to produce the project development plan. Planning by subject area involves planning the project by grouping features to feature sets and subject areas. The grouping is done according to the functionality and the existing dependencies between features. Other factors to take into consideration are: the load across the development team and the complexity of the features to be implemented. As soon as features are grouped and the features to be included in the release are agreed, we have to determine the development sequence, to assign business activities to chief programmers and in doing so, consider which of the key classes are assigned to which developers. When this planning is complete the team would then agree on a schedule of delivery for the subject area and the feature sets together with the project sponsor. The forth step is the Design by Feature Set. The objective in this step us to produce the design of each feature set. The design model includes UML sequence diagrams, refinement of the overall UML class diagram developed in the first step, etc. Finally, the fifth step, Build by feature, involves packaging a smaller batch of features from the feature set decided in step 4 and developing the code for those features and unit testing them. The batch of features is known as a Chief Programmer Work Package (CPWP) and should be selected such that it can be completed by a single feature team in less than 2 weeks. IV. COMPARISON OF PMBOK AND AGILE METHODS In order to compare the presented project management methods we took as basis the PMBOK processes as they are organized per knowledge area. The reasons that contributed to this decision were two: PMBOK is an exhaustive list of good practices, in the form of processes that can be tailored and customized to specific needs. PMBOK is well known and formally documented compared with the presented in this work agile methods. The result of this comparison is presented Table I. PMBOK Project Integration Management Develop Project Charter Develop Preliminary Project Scope Statement Develop Project Management Plan Direct and Manage Project Execution Monitor and Control Project Work Integrated Change Control Close Project TABLE I COMPARISON OF PMBOK AND AGILE METHODS PROCESSES Agile methods XP Scrum FDD Integration of software as soon as possible and as often as possible (mostly related with software code). Collective code ownership Project velocity measurement Verification of management approval and funding during planning phase. Validation of development tools and infrastructure during planning phase. Strong change management procedure with product and sprint backlog. Refinement of system architecture to support changes. Postgame phase. Development of the overall system model.

5 382 FITSILIS PMBOK Project Scope Management Scope Planning, Scope Definition, Create Work Breakdown Structure (WBS), Scope Verification, and Scope Control Project Time Management Activity Definition, Activity Sequencing, Activity Resource Estimating, Activity Duration Estimating, Schedule Development, and Schedule Control Project Cost Management Cost Estimating, Cost Budgeting, and Cost Control project Project Quality Management Quality Planning, Perform Quality Assurance, and Perform Quality Control. Agile methods XP Scrum FDD User Stories Release Planning, Small Releases Release Planning, Iterations planning Not available Emphasize on testing (unit, acceptance) Based on simplicity Use of project standards Project Human Resource Management Human Resource Planning, Personnel rotation to Acquire Project Team, various positions Develop Project Team, and Pair programming Manage Project Team. Good working conditions (no overtime) Project Communications Management Communications Planning, Use of system metaphor Information Distribution, Customer always Performance Reporting, and available Manage Stakeholders Daily meetings Use of project standards Perform domain analysis for building domain model. Development of a comprehensive product backlog list. Development of a comprehensive product sprint backlog. Definition of the functionality that will be included in each release. Selection of the release most appropriate for immediate development. Review of progress for assigned backlog items. Definition of the delivery date and functionality for each release. Monthly iterations Estimation of release cost, during planning phase. Distribution, review and adjustment of the standards with which the product will conform. Design review meeting Sprint planning meeting Sprint review meeting. Daily scrum. Appointment of project team(s) per release. Team participation in sprint meetings. Team participation in daily scrums. Design review meeting Scrum meeting Sprint planning meeting Sprint review meeting Communication of standards to the project team Perform domain analysis for building domain model (step 1). Build Features List, subject areas (step 2). Determine development sequence (step 3). Assign Business Activities to Chief Programmers (step 3). Assign Classes to Developers (step 3). Chief programmer work package. Not available Review meetings (all steps) Code inspection and unit test (step 5) Appoint modeling team (step 1) Appoint feature list team (step 2) Appoint Planning Team (step 3) Appoint Feature Team (step 3) Review meetings (all steps)

6 PMBOK Project Risk Management Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control. AGILE PROJECT MANAGEMENT SOFTWARE DEVELOPMENT PROCESSES 383 Agile methods XP Scrum FDD Create prototype to limit risk Initial assessment of risks during pregame. Risk review during review meetings Not available Project Procurement Management Plan Purchases and Acquisitions, Plan Contracting, Request Seller Responses, Select Sellers, Contract Administration, and Contract Closure. Not available Not available Not available V. CONCLUSION Table I proves that agile methods do not define all facets needed in order to cover all aspects of project management, in the traditional sense. This was partially expected since traditional project management processes are fully defined compared with agile methods that are considered empirical. However, from this study we could conclude the following. Agile methods are giving emphasis in the following knowledge areas: Scope Management, since emphasis is given in managing requirements. Human resource management, since emphasis is given in team work. Quality management, even though not formally defined, use of standards, testing and frequent reviews are promoted. On the other hand, agile methods do not fully address the following knowledge areas: Risk is not managed explicitly, Cost management is not part of the agile methodologies Procurement management is not addressed at all. This implies that connecting agile methods with PMBOK will benefit the software project management community. The next step of this work is the detailed mapping between PMBOK processes and the agile methodologies. REFERENCES [1] F. Brooks Jr., The mythical man-month: essays on software engineering Anniversary ed., Addison Wesley Longman, [2] R. Charette, Why software fails, IEEE Spectrum, September [3] J.S. Reel, Critical success factors in software projects, IEEE Software, 16(3), [4] T. Chow, and D-B. Cao, A Survey Study of Critical Success Factors in Agile Software Projects, The Journal of Systems and Software, doi: /j.jss , in press. [5] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-Hall NJ, [6] K. Beck, Extreme Programming Explained: Embrace Change, Addison- Wesley Professional, [7] P. Coad, E. Lefebvre, and J. De Luca, Java Modeling in Color with UML: Enterprise Components and Process, Prentice Hall, [8] A. Carmichael, and D. Haywood, Better Software Faster, Prentice-Hall NJ, [9] S. Augustine and S. Woodcock, Agile Project Management, CC Pace, Available at [10] PMI Institute, A Guide to the Project Management Body of Knowledge, PMI Standard Committee, [11] U.S. Department of Defense, Extension to: A Guide to the Project Management Body of Knowledge, First Edition, Version 1.0, [12] International Project Management Association, IPMA Competence Baseline, Version 3.0. Van Haren Publishing, [13] M. Sliger, Relating PMBOK Practices to Agile Practices, Available at [14] G. Alleman, PMBOK and agile article, Available at [15] K. Auer, and R. Miller, Extreme Programming Applied: Playing to Win (The XP Series), Addison Wesley - New York, [16] S. W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Wiley and Son, Inc., [17] K. Beck and M. Fowler, Planning Extreme Programming, Addison- Wesley, 200. [18] H. Takeuchi and I. Nonaka, The New New Product Development Game, Harvard Business Review, January-February [19] J. Coplien, Borland Software Craftsmanship: A New Look at Process, Quality and Productivity, Proceedings of the 5th Annual Borland International Conference, June 1994, Orlando, Florida. [20] K. Schwaber, Controlled Chaos: Living on the Edge, American Programmer, April [21] K. Schwaber, Agile Project Management with Scrum, Microsoft Press, [22] L. Rising, and N.S. Janoff, The Scrum Software Development Process for Small Teams, IEEE Software, July-August [23] K. Schwaber, Advanced Development Methods. SCRUM Development. Available at