Excerpts

Preface We are dedicated to the use of Agile practices in software development (a.k.a. Agilists), but we didn't start out that way. We began as Project Management Professionals (PMP®) 1 who used more traditional methods in the development of software. Why We Wrote This Book We followed the approaches outlined in the Project Management Institute's A Guide to the Project Management Body of Knowledge--Third Edition ( PMBOK® Guide ) for much of our careers, and in moving to Agile approaches we became more aware of the misconceptions out there surrounding the subject matter of this book--incorrect ideas that we once believed as well. Now as Agile consultants, we continue to hear our clients say that they believe (incorrectly) that if they are to keep their PMP certification and follow the practices outlined in the PMBOK® Guide that they must use a waterfall-like methodology. We also hear the mistaken belief that Agile approaches lack discipline and rigor. And we see the fear and dismay of those who believe that their investment in the Project Management Institute (PMI) may be for naught if they follow the path to agility. It is our goal to dispel these myths in our book and show that the Third Edition of the PMBOK® Guide does in fact support Agile software development methods and that the investment that project managers have made in the PMI and in the practices outlined in the PMBOK® Guide are still solid and appropriate to pursue. It is clear to us that the PMBOK® Guide is methodology-neutral and supports good project management practices regardless of the approach chosen. Although many are already aware of this fact, we find that there are still many who are not. As PMPs who are now Agile enthusiasts, we feel it is important to also dispel the mistaken notion in the Agile community that PMPs cannot be good Agile project managers. We would like to build a bridge between the two, thus the need for this book. Structure and Content of the Book Accordingly, we've put much of the detail concerning this bridging in Part II, where we map the PMBOK® Guide's practices to Agile practices. It is our intent to show project managers that in moving to an Agile methodology, they do not move away from implementing PMI-recommended practices--they simply implement the practices in a different way, making sure that the intent behind these practices remains true. In some chapters you'll find a clear mapping, whereas in others the mapping is more imprecise. This book is intended to be a guide, a way to take the lexicon you are already familiar with and relate it to a new way of developing software. This book will not replace any of the more specific Agile practice books in the market today, and we encourage you to supplement this reading with other books on particular Agile methods (Scrum, XP, Lean, Crystal, and so on). The next several sections provide a quick preview of the book. Part I: An Agile Overview Part I introduces you to the basic terms and concepts of Agile software development. We begin in the first chapter ("What is Agile?") with a look back at the emergence of agile ideas in the history of software development. You may be surprised to learn that even Winston Royce's paper on the waterfall approach recommended an iterative cycle and the involvement of the end user in the whole of the project! From this history we move forward and review the concepts behind the Agile Manifesto and its associated principles, which are the basis of all agile software development frameworks. In Chapter 2, "Mapping from the PMBOK® Guide to Agile," we look at the history of the PMI and its most famous contribution to the practice of project management, the PMBOK® Guide. We'll examine how the PMBOK® Guide project lifecycle phases and project management process groups can be related to the Agile Fractal. And we'll reiterate again that you can be agile and be in keeping with the recommendations outlined in the PMBOK® Guide. Chapter 3, "The Agile Project Lifecycle," describes the agile project lifecycle--from release planning to iteration planning to daily planning--and how demos, reviews, and retrospectives at the end of each iteration allow the team to continually improve. This chapter begins the use of terminology and concepts that we expand on throughout the rest of the book. Part II: The Bridge: Relating PMBOK® Guide Practices to Agile Practices This is the part of the book where we review each of the PMBOK® Guide knowledge areas and discuss what you used to do as a traditional project manager, and what you should consider doing instead as an agile project manager. As the title implies, we are trying to build an explicit bridge between the traditional and the agile, and provide you with guidance on what tasks and activities you should substitute--or keep. As it is in the PMBOK® Guide, the knowledge areas are not in any type of chronological order. In both traditional and agile project management settings, you will find yourself doing most of these activities in parallel. Because there is some overlap in the knowledge areas, you may find some ideas and concepts repeated. We did this intentionally, because we expect many of you to use this part of the book as a reference guide, and may therefore start with any of these chapters in any order. However, to keep the repetition to a minimum, we do use references to other chapters rather than rewrite large sections. The chapters in Part II include the following: Chapter 4: "Integration Management" Chapter 5: "Scope Management" Chapter 6: "Time Management" Chapter 7: "Cost Management" Chapter 8: "Quality Management" Chapter 9: "Human Resources Management" Chapter 10: "Communications Management" Chapter 11: "Risk Management" Chapter 12: "Procurement Management" Part III: Crossing the Bridge to Agile Whereas Part II covers the specific practical activity changes, Part III covers the softer skills of being an agent of change and what this change means for you personally and professionally. Having answered much of the "what" you need to do in Part II, we turn our focus to "how" to make these changes in Part III. From how your role changes, to how you'll work with others who aren't agile, to what to watch out for, we respond to the commonly asked questions of those who are about to cross the bridge. The chapters in Part III complete the main body of the book: Chapter 13: "How Will My Role as a Project Manager Change?" Chapter 14: "How Will I Work with Other Teams Who Aren't Agile?" Chapter 15: "How Can a Project Management Office Support Agile? " Chapter 16: "Selling the Benefits of Agile" Chapter 17: "Common Mistakes" Appendixes We've included two appendixes we hope you will find useful. Appendix A, "Agile Methodologies," runs down a number of the software development methodologies that fall under the Agile umbrella. Appendix B, "Typical Agile Artifacts," includes a look at the typical Agile project "artifacts." Who This Book Is For Although this book is targeted at software project managers who are members of the PMI, anyone who is doing traditional software project management will benefit from seeing agility presented in terminology to which they are accustomed. We will refer to these long-established methodologies as "waterfall," "plan-driven," or "traditional," all of which refer to sequential, phased, noniterative approaches to software development. Final Thoughts We should also make it clear that we are not sanctioned by PMI or any of its representatives. This book is the result of our research, interpretation, and experience. Although we used the Third Edition of the PMBOK® Guide in our studies, we expect that as the PMBOK® Guide goes through further revisions, you will still find the concepts presented here to be relevant. Endnotes 1. "PMP," "PMI," and "PMBOK Guide" are registered marks of Project Management Institute, Inc. (c) Copyright Pearson Education. All rights reserved. Excerpted from The Software Project Manager's Bridge to Agility by Michele Sliger, Stacia Broderick All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.