The project manager's guide to mastering agile pdf free download

Case Study

This information paper will require students to read Chapter 18 - "Not-So-Successful" Case Studies and answer these questions. Identify the major take aways from from this case study that was different from traditional project management. What concepts did you find in this case study that can be tied back to ideas or concepts within the text, and why do you think the company choose these methods? If you were an agile consultant, what would you recommend to improve the agile adoption? Support your response with concepts from the text. This paper will adhere to the APA writing style. Your paper should be a minimum of the three pages of context. When referencing concepts in the book, provide the pager numbers to support your response.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750–8400, fax (978) 646–8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748–6011, fax (201) 748–6008, or online at www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with the respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for damages arising herefrom.

For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762–2974, outside the United States at (317) 572–3993 or fax (317) 572–4002.

Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.

ISBN: 978-1-118-99104-6 (paperback)–ISBN 978-1-118-99177-0 (epdf)–ISBN 978-1-118-99176-3 (epub)

Printed in the United States of America

www.it-ebooks.info

http://www.copyright.com
http://www.wiley.com/go/permissions
http://booksupport.wiley.com
http://www.wiley.com
http://www.it-ebooks.info/
CONTENTS

PREFACE xiii

ACKNOWLEDGMENTS xix

1 Introduction to Agile Project Management 1

The Chasm in Project Management Philosophies 2

The Evolution of Agile and Waterfall 3

Definition of waterfall 4

Definition of agile 4

Comparison of plan-driven and adaptive approaches 5

The Evolution of the Project Management Profession 7

The early history of project management 7

Transformation of the project management profession 8

What’s driving this change, and why now? 9

Agile Project Management Benefits 11

Summary of Key Points 13

Discussion Topics 14

Part 1 Fundamentals of Agile

2 Agile History and the Agile Manifesto 17

Agile Early History 17

Dr. Winston Royce and the Waterfall model (1970) 18

Early iterative and incremental development methods (early 1970s) 19

Further evolution of iterative and incremental development (mid- to late 1970s) 20

Early agile development methods (1980s and 1990s) 20

Agile Manifesto (2001) 21

Agile Manifesto values 22

Agile Manifesto principles 24

Summary of Key Points 30

Discussion Topics 31

v

www.it-ebooks.info

http://www.it-ebooks.info/
vi CO N T E N T S

3 Scrum Overview 33

Scrum Roles 34

Product owner role 35

Scrum Master role 36

Team role 38

Scrum framework 39

Sprint planning 41

Daily standup 42

Sprint review 42

Sprint retrospective 43

General Scrum/Agile Principles 44

Variability and uncertainty 44

Prediction and adaptation 45

Validated learning 46

Work in progress 47

Progress 48

Performance 49

Scrum Values 51

Commitment and focus 51

Openness 52

Respect 53

Courage 54

Summary of Key Points 55

Discussion Topics 55

4 Agile Planning, Requirements, and Product Backlog 57

Agile Planning Practices 57

Rolling-wave planning 57

Planning strategies 58

Spikes 59

Progressive elaboration 60

Value-based functional decomposition 61

Agile Requirements Practices 61

The role of a business analyst in an agile project 61

“Just barely good enough” 63

Differentiating wants from needs and the “five whys” 63

MoSCoW technique 64

User Personas and Stories 64

User personas 64

User stories 65

Epics 67

Product Backlog 68

What is a product backlog? 68

Product backlog grooming 68

Summary of Key Points 70

Discussion Topics 71

5 Agile Development, Quality, and Testing Practices 73

Agile Software Development Practices 73

Code refactoring 74

Continuous integration 75

Pair programming 75

Test-driven development 76

Extreme programming (XP) 77

Agile Quality Management Practices 78

Key differences in agile quality management practices 78

www.it-ebooks.info

http://www.it-ebooks.info/
CON T E N T S vii

Definition of “done” 78

The role of QA testing in an agile project 79

Agile Testing Practices 80

Concurrent testing 80

Acceptance test driven development 80

Repeatable tests and automated regression testing 81

Value-driven and risk-based testing 81

Summary of Key Points 81

Discussion Topics 83

Part 2 Agile Project Management

6 Time-Boxing, Kanban, and Theory of Constraints 87

The Importance of Flow 89

Time-Boxing 90

Time-boxing advantages 90

Additional time-boxing productivity advantages 90

Kanban Process 91

Push and pull processes 91

What is a Kanban process? 92

Differences between Scrum and Kanban 93

Work-in-process limits in Kanban 94

Kanban boards 95

Theory of Constraints 96

Summary of Key Points 98

Discussion Topics 99

7 Agile Estimation 101

Agile Estimation Overview 101

What’s different about agile estimation? 101

Developing an estimation strategy 103

Management of uncertainty 103

Agile Estimation Practices 104

Levels of estimation 104

What is a story point? 106

How are story points used? 107

What is planning poker? 108

Velocity and Burn-Down/Burn-Up Charts 109

Velocity 109

Burn-down charts 110

Burn-up charts 111

Summary of Key Points 112

Discussion Topics 113

8 Agile Project Management Role 115

Agile Project Management Shifts in Thinking 117

Emphasis on maximizing value versus control 117

Emphasis on empowerment and self-organization 119

Limited emphasis on documentation 120

Managing flow instead of structure 121

Potential Agile Project Management Roles 121

Making agile work at a team level 121

Hybrid agile project role 123

www.it-ebooks.info

http://www.it-ebooks.info/
viii CO N T E N T S

Enterprise-level implementation 124

Using agile concepts in non–agile projects 127

Agile and PMBOK® 127

The difference between explicit and tacit knowledge 127

Relationship to traditional project management functions 129

Summary of Key Points 137

Discussion Topics 138

9 Agile Communications and Tools 139

Agile Communications Practices 139

Information radiators 139

Face-to-face communications 141

Daily standups 142

Distributed teams 142

Agile Project Management Tools 143

Benefits of agile project management tools 144

Characteristics of enterprise- level agile project management tools 145

Summary of Key Points 148

Discussion Topics 149

10 VersionOne Tool Overview 151

Product/Project Planning 151

Product backlog management 153

Manage business initiatives with epics 155

Group your work items by feature groups or themes 155

Deliver according to business goals 156

Release and Sprint Planning 157

Release planning/sprint planning capabilities 158

Sprint detail planning 158

Sprint Tracking 160

Kanban boards 161

Burn-down charts 162

Summary of Key Points 163

Discussion Topics 163

11 Understanding Agile at a Deeper Level 165

Systems Thinking 165

Influence of Total Quality Management (TQM) 167

Cease dependence on inspection 168

Emphasis on the human aspect of quality 170

The need for cross-functional collaboration and transformation 171

Importance of leadership 173

Ongoing continuous improvement 173

Influence of Lean Manufacturing 174

Customer value 177

Map the value stream 177

Pull 178

Flow 182

Respect for people 186

Perfection 187

www.it-ebooks.info

http://www.it-ebooks.info/
CON T E N T S ix

Principles of Product Development Flow 187

Summary of Key Points 189

Discussion Topics 191

Part 3 Making Agile Work for a Business

12 Scaling Agile to an Enterprise Level 195

Enterprise-Level Agile Challenges 196

Differences in practices 196

Reinterpreting agile manifesto values and principles 197

Enterprise-Level Obstacles to Overcome 199

Collaborative and cross-functional approach 199

Organizational commitment 199

Risk and regulatory constraints 200

Enterprise-Level Implementation Considerations 200

Architectural planning and direction 200

Enterprise-level requirements definition and management 201

Release to production 203

Enterprise-Level Management Practices 204

Scrum-of-scrums approach 204

Project/program management approach 207

The role of a project management office (PMO) 207

Project/product portfolio management 209

Summary of Key Points 210

Discussion Topics 211

13 Adapting an Agile Approach to Fit a Business 213

The Impact of Different Business Environments on Agile 213

Product-oriented companies 214

Technology-enabled businesses 215

Project-oriented businesses 215

Hybrid business model 216

Adapting an agile approach to a business 217

Typical Levels of Management 218

Overall business management level 218

Enterprise product/project portfolio management level 221

Product management level 223

Project management level 223

Corporate Culture and Values 224

The importance of corporate culture and values 224

Value disciplines 226

Summary of Key Points 230

Discussion Topics 231

14 Enterprise-Level Agile Transformations 233

Planning an Agile Transformation 233

Define the goals you want to achieve 233

Becoming agile is a journey, not a destination 234

www.it-ebooks.info

http://www.it-ebooks.info/
x CO N T E N T S

Develop a culture that is conducive to agile 235

Manage change 237

Don’t throw the baby out with the bathwater 240

Tools can be very important 241

Adaptive Project Governance Model 242

Executive steering group 244

Project governance group 244

Working group forums 244

Project teams 245

Summary of Key Points 245

Discussion Topics 246

Part 4 Enterprise-Level Agile Frameworks

15 Scaled Agile Framework 251

Team Level 253

Program Level 253

Portfolio Level 253

Program Portfolio Management 254

16 Managed Agile Development Framework 259

Managed Agile Development Overview 260

Macro-level 261

Micro-level 261

Objectives of Managed Agile Development 261

Plan-driven benefits 261

Agile benefits 262

Key differences from a typical waterfall approach 262

Framework Description 264

Project organization and work streams 264

High-level process overview 265

Requirements management approach 270

Project Scheduling Approach 272

Project management approach 273

Communications approach 274

Roles and Responsibilities 275

17 Disciplined Agile Delivery Framework 279

Summary of Enterprise-Level Frameworks 286

Part 5 Case Studies

18 “Not-So-Successful” Case Studies 289

Company A 290

Background 290

The approach 290

What went wrong 290

Overall conclusions 290

www.it-ebooks.info

http://www.it-ebooks.info/
CON T E N T S xi

Company B 292

Background 292

The approach 293

What went wrong 293

Overall conclusions 294

Company C 297

Background 297

The approach 297

What went wrong 297

Overall conclusions 297

19 Case Study—Valpak 303

Background 303

Overview 305

Architectural Kanban 306

Portfolio Kanban 309

Project Management Approach 311

Tools, communication, and reporting 312

Challenges 313

Cultural and organizational challenges 313

Technical challenges 316

Other challenges 316

Key Success Factors 320

Top-down support coupled with bottom-up drive 320

Hiring an independent coach 320

Continued support each and every day 321

Senior management engagement/business ownership 321

Results and Conclusions 322

Lessons Learned 324

Forming projects around teams 324

Planning team capacity and developing a sustainable pace 324

Using sprint reviews and “science fairs” 325

20 Case Study—Harvard Pilgrim Health Care 327

Background 327

Overview 328

Impact of outsourcing and vendor partnering 330

Role of the PMO 331

Project governance 332

Role of tools 334

Project methodology mix 335

Project portfolio management 335

Project Management Approach 336

Project methodology 336

Implementation package development 337

Implementation package refinement 338

Project reporting 338

Contractual relationship with Dell Services 340

Challenges 340

Cultural and organizational challenges 340

Contractual challenges 340

Technical challenges 341

Other challenges 341

www.it-ebooks.info

http://www.it-ebooks.info/
xii CO N T E N T S

Key Success Factors 341

Conclusions 349

Lessons Learned 350

Enormous culture shift 350

Adapting the methodology to fit the business 350

Release management 350

Assigning projects to teams 351

Architectural Design Planning 351

Estimating project schedules 351

QA testing 351

CIO retrospective 352

21 Case Study—General Dynamics UK 355

Background 355

Overview 356

Requirements prioritization and management approach 356

Contract negotiation and payment terms 358

Planning approach 358

Personnel management 359

Communication 359

Management and leadership approach 360

Project Management Approach 360

DSDM overview 361

DSDM principles 362

Challenges 363

Cultural and organizational challenges 363

Contractual challenges 363

Technical challenges 363

Key Success Factors 365

Conclusions 366

Lessons Learned 367

22 Overall Summary 369

Appendices

Appendix A Additional Reading 375

Appendix B Glossary of Terms 377

Appendix C Example Project/Program Charter Template 387

Appendix D Suggested Course Outline 393

Index 399

www.it-ebooks.info

http://www.it-ebooks.info/
PREFACE

THE PROJECT MANAGEMENT PROFESSION is beginning to go through rapid and profound changes due to

the widespread adoption of agile methodologies. Those changes are likely to dramatically change the

role of project managers in many environments as we have known them and raise the bar for the entire

project management profession.

It is not a simple matter of making a binary choice between a totally plan-driven approach and

totally adaptive or agile approach. There are many alternatives between those extremes, and it takes

a lot of skill to adapt an approach to fit the situation. This book is designed to help project managers

with a traditional, plan-driven project management background understand these challenges and

to develop a more adaptive project management approach for blending traditional project manage-

ment with agile principles and practices in the right proportions to fit a given project and business

environment.

Agile is changing the way we think and work in many industries and application areas. The impact today is most obvious in the area of software and information technology, where an agile approach

is essential to deal with the level of uncertainty in a typical software development project; however,

the rapidly changing and competitive business world we live in today is already beginning to rapidly

expand the influence of agile to many other areas.

This is the third book I’ve written on the subject of agile project management. My primary moti-

vation in all of the books I’ve published in this area has been to help close the gap between the tradi-

tional project management and agile communities. Those two areas have essentially been treated as

separate and independent domains of knowledge with a very limited amount of integration between

the two and some new thinking is badly needed to see both of these areas as complementary to each

other rather than competitive.

If I were to publish this book as an entirely separate and independent book from my two previ-

ous books, it would have either been disjoint or there might have been redundancy with the material

in the two previous books. For that reason, I have decided to merge together some information from

my two previous books into this one book to make it much more comprehensive, well-integrated, and

easy to follow. It is designed to be used as a textbook in a graduate-level Agile Project Management

course and includes a suggested course outline and instructional materials to align with the material

in the book.

xiii

www.it-ebooks.info

http://www.it-ebooks.info/
xiv P R E FAC E

THE IMPACT OF AGILE

I believe that agile is having a profound impact on the project management profession and will cause

us to fundamentally rethink many of the well-established notions of what a project manager is over some period of time. My opinion is that:

◾ Those changes will dramatically impact the role of project managers in many environments and perhaps even eliminate the role of some project managers as we have known them.

◾ It will also raise the bar for the entire project management profession, broaden the definition of what we think of as project management, and require project managers to acquire significant new skills and new ways of thinking.

Some people may see that as unsettling and perhaps even threatening; however, it is very clear

that agile is not a fad, is here to stay, and will bring about some significant changes that we can’t

ignore. I believe that it is critical for project managers and the project management profession, as a

whole, to be proactive and anticipate the most likely impact and adapt accordingly. To me, that means

figuring out how to integrate agile and traditional project management principles and practices to

provide one integrated view of what project management is.

Many project managers are wondering what impact this has on their career path and it can be

confusing because the role of a project manager in an agile environment is not defined. This raises a number of questions including:

◾ What is the role for a project manager in an agile project?

◾ Are traditional project management principles and practices in conflict with agile principles and practices?

◾ How does a typical project manager shape his or her career to move in a more agile direction?

Those are the needs and challenges that this book is intended to address. Learning to become

an agile project manager can be a long and difficult journey, and this book is only a small part of that

journey.

LEARNING OBJECTIVES FOR AN AGILE PROJECT MANAGER

The following is a summary of what I believe are the most important steps in the journey toward

becoming an agile project manager (not necessarily in this order):

1. Develop new ways of thinking and begin to see agile principles and practices in a new light as

complementary rather than competitive to traditional project management practices.

2. Gain an understanding of the fundamentals of agile practices and learn the principles behind

the agile practices at a deeper level in order to understand why they make sense and how they

can be adapted as necessary to fit a given situation.

www.it-ebooks.info

http://www.it-ebooks.info/
P R E FAC E xv

3. Learn how to go beyond the traditional notion of plan-driven project management and develop

an adaptive approach to project management that blends both agile and traditional project man-

agement principles and practices in the right proportions to fit a given project and business

environment.

4. Understand the potential roles that an agile project manager can play and begin to reshape

project management skills around those roles.

5. Learn some of the challenges of scaling agile to an enterprise level and develop experience in applying these concepts in large, complex, enterprise-level environments.

HOW THIS BOOK IS ORGANIZED

Agile project management is an art that will take time for anyone to develop and master. There’s a

concept from martial arts called shu-ha-ri that is very appropriate here. It outlines the stages of pro- ficiency someone goes through to develop mastery of martial arts techniques. The same concept can

be applied to agile project management:

◾ “Shu”: In the “shu” stage, the student learns to do things more-or-less mechanically, “by the book,” without significantly deviating from the accepted rules and practices and without improvising any

new techniques. This stage is equivalent to a new inexperienced project manager following PMBOK

or other accepted practices “by the book” without necessarily adapting those practices to fit the

situation.

◾ “Ha”: In the “ha” stage, the student begins to understand the principles at a deeper level and learns how to improvise and break free from rigidly accepted practices, but it’s important to

go through the “shu” stage and gain mastery of the foundational principles before you start

improvising—improvisation without knowledge is just amateurish experimentation.

◾ “Ri”: Finally, in the “ri” stage, the student gets to the highest level of mastery and is able to develop his/her own principles and practices as necessary.

Many project managers may think that they are already at a very high level of mastery based on

their knowledge of PMBOK and other well-accepted traditional project management practices, but

agile changes that dramatically and raises the bar significantly.

The way the book is organized follows the shu-ha-ri approach to learning:

◾ The initial sections of the book start out with a very basic understanding of the “mechanics” of agile and learning how to do it “by the book.” That is equivalent to the “shu” level of training.

◾ The book will go deeper into the principles behind agile and why they make sense. It is essential to understand the principles at a deeper level before moving on to the “ha” level and know how to

customize an approach to fit a given situation.

◾ The final goal is to move to the master level or “ri” level where you will learn to go beyond current ways of implementing both agile and plan-driven approaches and learn how to blend them together

www.it-ebooks.info

http://www.it-ebooks.info/
xvi P R E FAC E

as needed to fit a given project and business environment. That goal is somewhat beyond the scope

of this book and will only come from actual practice in implementing these ideas in real world situ-

ations; however, it is hoped that the information in this book and the case studies that are included

will help project managers move rapidly in that direction.

Part 1 – Fundamentals of agile The first step in learning to become an agile project manager is to learn the fundamentals of agile,

which includes not only the mechanics of how an agile project based on Scrum works, but also under-

standing the principles behind it at a deeper level so that you can go beyond just implementing it by

the book.

Part 2 – agile project management Agile is causing us to broaden our vision of what a project manager is and that will have a dramatic impact on the potential roles that a project manager can play in an agile project. In fact, the role of a

project manager at a team level in a typical agile/Scrum project is undefined. That will cause us to

rethink many of the things we have taken for granted about project management for a long time to

develop a broader vision of what an agile project manager is.

Part 3 – Making agile work for a business There are many precedents for successful implementation of agile principles and practices at a

project team level; however, extending the agile principles and practices to large-scale enterprise

implementations and integrating with a business environment can be very difficult and introduces a

number of new challenges, which include:

◾ Large, complex projects that are commonly found at an enterprise level may require some reinter- pretation and adaptation of agile principles and practices as well as blending those principles and

practices with traditional, plan-driven principles and practices in the right proportions.

◾ Integrating agile principles and practices with higher levels of management typically found at an enterprise level, such as project portfolio management and overall business management can be

difficult. However, if an agile implementation is limited to a development process only and does not

address integration with these higher-level processes it is not likely to be effective and may result in

failure.

◾ This section of the book is intended to address these topics and provide an understanding of the key considerations that need to be addressed for scaling an agile approach to an enterprise level, inte-

grating it with a business environment, and planning and implementing an enterprise-level agile

transformation.

www.it-ebooks.info

http://www.it-ebooks.info/
P R E FAC E xvii

Part 4 – Enterprise-level agile frameworks Putting together a complete, top-to-bottom, enterprise-level agile solution can be a very challenging

task, especially when some of the pieces are not designed to fit together. To simplify the design of

an enterprise-level agile implementation, it is useful to have some predefined frameworks that can

be modified to fit a given business environment, rather than having to start from scratch to design

an overall management approach. Three frameworks are discussed in this section: the Scaled Agile

Framework (SAFe) (Dean Leffingwell), Managed Agile Development framework (Chuck Cobb), and the

Disciplined Agile Delivery framework (Scott Ambler).

Part 5 – Case studies In any book of this nature, it’s always useful to go beyond theory and concepts and show how com-

panies have actually put these ideas into practice in the real world. Of course, there is no canned

approach that works for all companies—each of these case studies is different and shows how a differ-

ent approach may be needed in different situations. It also includes a chapter on “Not-So-Successful”

case studies, which shows some of the problems that can develop in an agile implementation.

Part 6 – Appendices The appendices to the book include additional supplementary information:

◾ Additional Reading List

◾ Glossary of Terms

◾ Example Project/Program Charter

◾ Suggested Course Outline for a graduate-level course to accompany this book

www.it-ebooks.info

http://www.it-ebooks.info/
www.it-ebooks.info

http://www.it-ebooks.info/
ACKNOWLEDGMENTS

I USED A VERY AGILE APPROACH for writing this book as well as my previous books. It was a team

effort of a number of people who worked with me collaboratively as the book was being written to

provide feedback and inputs. I particularly want to thank the following people for their contributions

to the book:

◾ Erik Gottesman, director general management at Sapient—Erik is a significant thought leader in this area. He played a huge role in helping me develop my two previous books on agile project manage-

ment and provided some good advice and input on this book as well.

◾ Dr. Michael Hurst, PMO director at Harvard Pilgrim Health Care—Michael has played a significant role in providing input and advice for both this book and my last book and he also played a key role in

providing a case study on Harvard Pilgrim Health Care that is included in this book.

◾ Andrew Bone, IT program/PMO director—Andrew did a thorough review of the entire book, provided a number of good comments and inputs, and also sponsored a presentation on the book with the Long

Island, New York, PMI Chapter.

◾ Liza Wood, senior production manager at Warner Bros. Games—Liza also did a thorough review of the entire book on behalf of the PMI Agile Community of Practice and provided a very large number

of excellent comments.

◾ Several companies generously shared case studies with the results of successful agile implementations:

◾ Michael Hurst, director PMO, Harvard Pilgrim Health Care—Michael and Harvard Pilgrim shared the results of a very large and successful enterprise-level agile transformation effort of more than

200 projects.

◾ Stephanie Stewart, director of agile leadership at Valpak—Stephanie and Valpak shared the results of an enterprise-level implementation of the Scaled Agile Framework at Valpak.

◾ Nigel Edwards, program manager at General Dynamics, UK—Nigel shared the results of a very large and complex, agile fixed price government contracting effort.

xix

www.it-ebooks.info

http://www.it-ebooks.info/
xx AC K NOW L E D GM E N T S

I would like to also thank the following individuals who took the time to review an early draft of

this book and provided very helpful feedback, comments, and suggestions:

Tanvir Ahmed, PMP, CSM,PSM Sr. consultant—Agile process

improvement and implementation

Philadelphia Water

Department

Gopi Aitham, PMP, CSM, ITIL, SSGB Learner, educator, & entrepreneur

Chris Chan Supervising consultant, enterprise

agile coach

Object Consulting

David G Peterson, PMP Consultant

Czeslaw Szubert, PMP Program manager AMD

Kevin Wegryn, PMP, PfMP Vice president

www.it-ebooks.info

http://www.it-ebooks.info/
1 Introduction to AgileProject Management OVER THE PAST 10 TO 15 YEARS, there has been a rapid and dramatic adoption of agile methodologies:

1. Project Management Institute (PMI)® studies concluded that from 2008 to 2013, the use of

agile practices tripled.1

2. According to a 2013 survey conducted by VersionOne:2

◾ 88% of the respondents say that their organizations are practicing agile development, up from 84% in 2012 and 80% in 2011.

◾ Over half of the respondents (52%) are using agile software to manage the majority of their projects.

◾ 88% say that they are at least “knowledgeable” about agile software development techniques, up 7% from the previous year.

3. This trend has been going on for some time. As early as 2007, a Forrester survey reported:3

◾ “26% are already using agile and an additional 42% are aware.” ◾ “Adoption of agile increased 56% from 17% in 2006, to 26% in 2007.” ◾ “Awareness increased 45% from 29% in 2006, to 42% in 2007.”

These statistics indicate that agile is not a fad, it is having a significant impact on the way

projects are managed, and it’s definitely here to stay. This trend has a significant impact on the career

direction of project managers who have come from a traditional, plan-driven project management

background since there is no formal role for a project manager at the team level in an agile project.

1“Agile Project Management,” Project Management Institute, 2014, http://learning.pmi.org/course-detail.php?id= 2563 2“2013 State of Agile(TM) Survey,” VersionOne, Inc., 2014, http://stateofagile.versionone.com/ 3Rally Blogs, “Agile Adoption Rates—So What and Why Do I Care?” posted by Ryan Martens, March 6, 2008, www.rallydev.com/community/agile-blog/agile-adoption-rates-%E2%80%93-so-what-and-why-do-i-care.

1

www.it-ebooks.info

http://learning.pmi.org/course-detail.php?id=2563
http://stateofagile.versionone.com
http://www.rallydev.com/community/agile-blog/agile-adoption-rates-%E2%80%93-so-what-and-why-do-i-care
http://www.it-ebooks.info/
2 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

THE CHASM IN PROJECT MANAGEMENT PHILOSOPHIES

In spite of this rapid and sustained proliferation of agile, there is still a fairly large chasm between the

agile and traditional project management communities:

◾ There has been only a limited amount of progress on developing a more integrated approach to project management that embraces both agile and traditional plan-driven project management

principles and practices.

◾ Many people seem to see agile and project management principles and practices as competitive approaches that are in conflict with each other, and they are essentially treated as two separate and

independent domains of knowledge.

◾ Considerable polarization between these two communities is based in some part on myths, stereotypes, and misconceptions about what agile and project management is.

A major goal of this book is to help project managers understand the impact of agile on the

project management profession and to broaden and expand their project management skills as

needed to develop a more integrated approach to adapt to this new environment.

This isn’t just a matter of getting another certification—it can require a major shift in thinking

for many traditional project managers that will take time and experience to develop. PMI has created

a new PMI-ACP® (Agile Certified Practitioner) certification, which has been very successful and is a

great step in the right direction—but it doesn’t go far enough, in my opinion. It doesn’t test whether

a project manager knows how to blend agile and traditional project management principles and prac-

tices in the right proportions to fit a given situation, and that is the real challenge that many project

managers face.

A lot of the polarization that exists between the agile and traditional project management com-

munities is rooted in some well-established stereotypes of what a project manager is that are based on how typical projects have been managed in the past. The role of a project manager has been so

strongly associated with someone who plans and manages projects using traditional, plan-driven

project management approaches that many people can’t conceive of any other image of a project

manager. It’s time to develop a new vision of what an agile project manager is that goes beyond all of those traditional stereotypes and fully integrates agile within the overall portfolio of project management principles and practices.

It feels very similar to an evolution that took place when I worked in the quality management pro-

fession in the early 1990s. Up until that time, the primary emphasis in quality management had been

on quality control, and inspection, and the image of a quality manager was heavily based on that role:

◾ The predominant quality management approach was based on final inspection of products prior to shipping them to the customer and rejecting any that didn’t meet quality standards. It’s easy to

see how that approach was inefficient, because it resulted in a lot of unnecessary rework to cor-

rect problems after the fact, and it also wasn’t that effective because any inspection approach is

based on sampling, and it is impractical to do a 100% sample. For that reason, it can result in

mediocre quality.

www.it-ebooks.info

http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 3

◾ A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects and build quality into the

inherent design of the products. That didn’t mean that the prior emphasis on quality control and

inspection was obsolete and eliminated; it was just not the only way to manage quality and wasn’t the most effective approach in all situations.

That was a gut-wrenching change for many in the quality management profession—instead

of being in control of quality and being the gatekeeper with the inspection process, a good quality

manager needed to become more of a coach and a consultant to influence others to build quality into

the way they did their work. This changed the nature of the work dramatically for many in the quality

management profession and eliminated a number of traditional quality management roles that were

based on the old quality control and inspection approach. The similarity to the changes going on in

the project management profession should be apparent:

◾ To be successful in more uncertain environments, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project and integrate quality

into the process rather than relying on final acceptance testing at the end of the project to validate

the product that is being produced.

◾ They also need to give up some of the control that has become associated with the project man- agement profession—in some cases, they may need to become more of a coach and a consultant

to influence others rather than being in absolute control of a project.

This can dramatically change the role of a project manager. In some situations, the role of a

project manager as we’ve known it may no longer exist. For example, at a team level in an agile

project, you probably won’t find anyone with a title of project manager because the project manage- ment functions have been absorbed into other roles and are done very differently. That doesn’t mean

that project management is no longer important, but it may cause us to dramatically rethink what project management is in a much broader context than the way we might have thought about it in

the past.

THE EVOLUTION OF AGILE AND WATERFALL

You will often hear people make a comparison between agile and waterfall. Many of those discussions

are polarized and position them as competitive approaches. Here’s an example:4

According to the 2012 CHAOS report, Agile succeeds three times more often than Water-

fall. Because the use of Agile methodologies helps companies work more efficiently and

deliver winning results, Agile adoption is constantly increasing.

4“Agile Adoption Statistics 2012,” One Desk, May 16, 2013, http://community.spiceworks.com/topic/337418-agile- adoption-statistics-2012.

www.it-ebooks.info

http://community.spiceworks.com/topic/337418-agile-adoption-statistics-2012
http://community.spiceworks.com/topic/337418-agile-adoption-statistics-2012
http://community.spiceworks.com/topic/337418-agile-adoption-statistics-2012
http://www.it-ebooks.info/
4 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

While that statement is generally true, it’s an oversimplification. There are at least two problems

with that kind of statement: a

1. It makes it sound like there are only two binary, mutually exclusive choices, agile and waterfall.

2. The meaning of the words agile and waterfall are typically not well-defined and are used very loosely.

For those reasons, I prefer to avoid comparing agile to waterfall because it tends to be a very

polarized discussion—I prefer to take a more objective approach that is based on a comparison

between a plan-driven and an adaptive approach to project management. So let’s first define both

agile and waterfall, and then compare the two approaches.

Definition of waterfall The word waterfall actually has a very specific meaning, but that’s often not how the word is really used:

The waterfall model is a popular version of the systems development life cycle model for

software engineering. Often considered the classic approach to the systems development

life cycle, the waterfall model describes a development method that is linear and sequen-

tial. Waterfall development has distinct goals for each phase of development. Imagine

a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of

the cliff and has begun its journey down the side of the mountain, it cannot turn back. It

is the same with waterfall development. Once a phase of development is completed, the

development proceeds to the next phase and there is no turning back.5

Another aspect to the waterfall model is that it is plan-driven; it attempts to define and document

detailed requirements and a plan for the entire project prior to starting the project. When someone

makes a statement comparing waterfall to agile, the word waterfall is often used very loosely to refer to any kind of plan-driven methodology, and that’s not really a very accurate and meaningful comparison.

In some other comparisons like this, the word waterfall refers to a general style of project manage- ment that obsessively emphasizes predictability and control over agility, and that’s just bad project

management.

Definition of agile The meaning of the word agile in this kind of comparison is also somewhat elusive because it has taken on some very strong connotations in actual usage. At a project level, at least in the

5Margaret Rouse, “Waterfall Model,” TechTarget, February 2007, http://searchsoftwarequality.techtarget.com/ definition/waterfall-model.

www.it-ebooks.info

http://searchsoftwarequality.techtarget.com/definition/waterfall-model
http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 5

United States, the word agile has taken on a specific connotation associated with using the Scrum methodology on software development projects:

Scrum is an agile software development model based on multiple small teams work-

ing in an intensive and interdependent manner. The term is named for the scrum (or

scrummage) formation in rugby, which is used to restart the game after an event that

causes play to stop, such as an infringement. Scrum employs real-time decision-making

processes based on actual events and information.6

That definition has evolved over recent years as Scrum has become somewhat of a de-facto stan-

dard for agile projects; however, the original definition of agile conceived in the Manifesto for Agile Software Development, published in 2001, was much broader than that. Better known as the Agile Manifesto, it laid out some simple and general principles and values that can apply to any kind of

project (not just software development) (See Chapter 2).

Comparison of plan-driven and adaptive approaches Traditional, plan-driven project management is a style of project management that is applied to

projects where the requirements and plan for completing the project can be defined to some extent

prior to implementing the project. However, plan-driven is a relative term, and you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all.

In contrast, an adaptive style of project management starts the implementation of a project with

a less well-defined plan of how the project will be implemented and recognizes that the requirements

and plan for the project are expected to evolve as the project progresses. Adaptive is also a relative term; you won’t find many projects that have no plan whatsoever of how the project will be done.

The important point is that the terms plan-driven and adaptive are relative—they are not discrete, binary, mutually exclusive alternatives. They should imply a continuous range of approaches with

different levels of upfront planning.

Saying “Agile is better than waterfall,” is like saying, “A car is better than a boat.” Agile and

waterfall are different kinds of methodologies designed for different kinds of projects. The problem

is not so much that waterfall or agile are inherently good or bad; the problem comes about when

those methodologies are misused and people try to use a single methodology (whatever it might be)

for all projects. Using a “one size fits all” strategy to applying either waterfall (plan-driven) or agile

(adaptive) approaches to all projects is not likely to yield optimum results.

In my opinion, being able to objectively understand the difference between a plan-driven

approach and a more adaptive approach—as well as the principles behind those approaches at a

6Margaret Rouse, “Scrum,” TechTarget, February 2007, http://searchsoftwarequality.techtarget.com/definition/ Scrum.

www.it-ebooks.info

http://searchsoftwarequality.techtarget.com/definition/Scrum
http://www.it-ebooks.info/
6 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

deeper level—is probably one of the most important skills an agile project manager needs to have.

An agile project manager needs to recognize the following:

◾ There is a broad range of alternative approaches between being plan-driven and being adaptive. The agile project manager must choose the right level of upfront planning to be applied to a

project, based on the level of uncertainty and other factors in the project.

◾ It takes some skill to make the right choice. There is nothing inherently wrong with either of those approaches (adaptive or plan-driven). The problem comes about when people try

to force-fit a project into one of these approaches rather than selecting and tailoring the

approach to fit the project. For example, if I were to set out to try to find a cure for cancer and

I attempted to apply a highly plan-driven approach to that project, the results would probably

be dismal.

The important point is that a heavily plan-driven approach (what some loosely refer to as water- fall) is not the only way to successfully manage a project. In many projects, a good approach is to use an adaptive approach to start the design effort without fully-defined and detailed requirements and

perhaps prototype something quickly. Then user feedback can be added to further refine the design as

the project progresses. With a more adaptive approach:

◾ The elements of the approach are much more concurrent than sequential. Instead of doing the entire design and then turning it over to quality assurance (QA) for testing, the design is done

in small chunks called iterations or sprints that are typically two to four weeks long. During that time, developers and testers work collaboratively to design and test the software during each

sprint.

◾ The customer also provides detailed inputs on the design during each sprint. The customer accepts the results of each sprint at the end of each two- to four-week period rather than waiting for user

acceptance testing (UAT) at the end of the project. That has the advantage of finding and resolving

any problems quickly and early in the project.

One primary advantage of a more adaptive approach is that the project startup is accelerated

because less time is spent upfront in attempting to define detailed requirements. In addition, engag-

ing the user more directly in the design process is more likely to produce an outcome that provides

the necessary business value and really meets the user needs.

An adaptive approach maximizes the business value to the customer because the customer is

directly engaged with the design team as the project progresses, but it is worse for predictability and

control because the customer can make changes as the project progresses. In an agile project, change

is the norm rather than the exception. However, this is not an “all-or-nothing” proposition to have

total control or no control at all. There are many ways to achieve the right balance of control versus

agility. For example, prior to the start of a project, the high-level requirements might be defined and

stabilized, and then only the more detailed requirements need to be further elaborated as the project

progresses.

www.it-ebooks.info

http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 7

THE EVOLUTION OF THE PROJECT MANAGEMENT PROFESSION

Many of the techniques associated with project management that are in use today haven’t changed

significantly since the 1950s and 1960s. I believe that we are on the verge of a major transformation

of the project management profession that will cause us to redefine project management in a much

broader context that includes both agile and traditional, plan-driven project management.

The early history of project management In order to understand this transition and to put it in perspective, it is useful to understand how the

project management profession has evolved over the years and how we got to where we are today.

Project management has been practiced for many years in one way or another—I’m sure that there

was some kind of “project management” approach for building the great pyramids of Egypt or the

Great Wall of China or other similar large efforts many years ago, but it probably wasn’t even thought

of as project management in those days. They didn’t have Gantt charts and Pert charts and other

sophisticated project planning and management tools, because those things weren’t even invented

until the twentieth century.

The Industrial Revolution created the need for a more disciplined approach to project manage-

ment, and a well-defined body of knowledge associated with project management began to evolve:

In the late 19th century, in the United States, large-scale government projects were the

impetus for making important decisions that became the basis for project management

methodology such as the transcontinental railroad, which began construction in the

1860s. Suddenly, business leaders found themselves faced with the daunting task of

organizing the manual labor of thousands of workers and the processing and assembly of

unprecedented quantities of raw material.

Near the turn of the century, Frederick Taylor began his detailed studies of work.

He applied scientific reasoning to work by showing that labor can be analyzed and

improved by focusing on its elementary parts that introduced the concept of working more

efficiently, rather than working harder and longer.

Taylor’s associate, Henry Gantt, studied in great detail the order of operations in work

and is most famous for developing the Gantt [c]hart in the 1910s.7

World War II brought about the need for more large-scale project management for organizing

very large projects like the Manhattan project; however, it wasn’t until the 1950s and 1960s, that it

became apparent that a much more well-defined body of knowledge and a disciplined approach were

7PM Hut, “History of Project Management,” The Project Management Hut, June 6, 2011, http://www.pmhut.com/ history-of-project-management.

www.it-ebooks.info

http://www.pmhut.com/history-of-project-management
http://www.it-ebooks.info/
8 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

needed to successfully manage some of the large and complex projects that were evolving at that

time, which led to the following:

◾ The Program Evaluation and Review Technique or PERT was developed by Booz-Allen & Hamilton as part of the US Navy’s (in conjunction with the Lockheed Corporation)

Polaris missile submarine program.”

◾ The Critical Path Method (CPM) was developed in a joint venture between DuPont Corporation and Remington Rand Corporation for managing plant maintenance

projects.

◾ The Project Management Institute (PMI) was founded in 1969.8

Many people probably assume that the project management profession is now reaching a stage of

maturity and stabilizing, but I believe that we have only seen the beginning, and project management,

as we’ve known it, will continue to grow in entirely new directions.

Transformation of the project management profession Sometimes we get so immersed in day-to-day activities that we don’t take time to step back and see

some fundamental changes that are going on around us. It seems clear to me that the project manage-

ment profession, as we know it, is going to go through such a major transformation. The exact nature

of that transformation isn’t completely clear as it is still evolving; however, it does seem likely that it

will cause us to rethink many of the things we have taken for granted in the project management pro-

fession for a long time in a much broader perspective. It feels very similar to the evolution that has

taken place in other technology areas and disciplines. For example, there is a strong similarity to the

evolution from classical physics to modern physics.

“By the close of the 19th century, the study of physics was widely thought to be essen-

tially complete, with the exception of only a few ‘loose ends’—minor unsolved problems

to be dealt with.”9

Up until that time, the study of physics had been heavily dominated by Newtonian physics, which

defines some fundamental laws of how the universe behaves such as Newton’s laws of motion. These

fundamental laws have been taken for granted in the world of physics for many years, even though we

didn’t fully understand why things in the universe behaved as they did. As modern physics has evolved

8Ibid. 9Physics”, http://www.conservapedia.com/Physics

www.it-ebooks.info

http://www.conservapedia.com/Physics
http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 9

in the twentieth century based on quantum mechanics and relativity, we began to develop a deeper

understanding of the real dynamics behind these laws and we began to understand that the universe

is not as simple and deterministic as we might have thought it was.

The transition from classical, Newtonian physics to a more complete and more dynamic model

based on quantum mechanics provided a deeper understanding of the forces and principles behind

those laws as well as the limitations in those laws and when and where they are really applicable.

That deeper understanding didn’t invalidate the laws of Newtonian physics in most situations—“on

an ‘everyday’ scale; that is, situations in which energies are large enough to permit one to neglect

quantum effects, but small enough to neglect relativistic effects.”10

The similarity to the transition in the project management profession should be apparent—we’re

moving from a world in which we had the impression that the behavior of the universe was highly pre-

dictable and controllable and totally subject to some well-defined rules to a world that is much more

dynamic, much more probabilistic, and much less predictable.

What’s driving this change, and why now? You might ask, “Why is it becoming so essential for the project management profession to make a

change at this particular point in time? There are several major factors that will force us to rethink the

concept of project management:

1. The nature of projects is changing. The modern concepts of project management were devel- oped as result of big projects like the transcontinental railroad . . . Today, we have new indus-

tries and a much broader range of projects such as web development, e-commerce, large IT

projects, etc., which weren’t common before the mid-nineties. It is becoming increasingly

apparent that applying a “one size fits all” approach to such a broad range of projects will not

have optimum results.

2. Technology is rapidly changing. Figure 1.1 shows how the adoption rate of new technolo- gies has changed over the past century. Project management approaches that worked in

the 1950s and 1960s must be reexamined to adapt to the current fast pace of technology

adoption.

A similar transformation took place in the quality management profession in the 1980s and early

1990s. At that time, the Japanese auto industry was demonstrating huge improvements in quality of

products that made conventional quality management methods based primarily on quality control and

inspection very inadequate. They forced people to rethink the whole strategy and approach for doing

quality management. Without the leadership of people like W. Edwards Deming and the significant

improvements in quality that were demonstrated in the automotive industry, the transformation of

quality management might never have happened. What started primarily in the automotive industry

10“Physics”, http://www.conservapedia.com/Physics

www.it-ebooks.info

http://www.conservapedia.com/Physics
http://www.it-ebooks.info/
10 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

Electricity

Telephone

Radio

Television

Personal Computer

Mobile Phone

Internet

1860 0

5

10

15

20

25

Ye ar

s to

2 5%

P en

et ra

tio n

30

35

40

45

50 Time From Initial Availability to 25% Penetration

1880 1900 1920

Year of Initial Availability

1940 1960 1980 2000

FIGURE 1.1 Adoption rates of new technologies

Created with data from singularity.com

has now become a more modern approach to quality management that is widely used in all industries.

A similar thing is happening with agile and traditional project management today:

◾ The leadership of W. Edwards Deming in establishing a total quality management (TQM) philoso- phy can be compared to the thought leadership behind the Agile Manifesto in 2001.

◾ The broad-based adoption of TQM starting in the automotive industry and eventually spreading to many other industries can be compared to how agile has started out in software development today

and is now beginning to spread to other areas.

Other researchers have come to a similar conclusion regarding this; Manfred Saynish published

his findings of a research project in Project Management Journal:

Traditional Project Management. . . is based mainly on a mono-causal, non-dynamic,

linear structure and a discrete view of human nature and societies and their percep-

tions knowledge and actions. It works on the basis of reductionist thinking and on the

Cartesian/Newtonian concept of causality (the mechanistic science).11

11Manfred Saynish, “Mastering Complexity and Changes in Projects, Economy, and Society via Project Management Second Order (PM-2),” Project Management Journal 41, no. 5 (Dec. 2010).

www.it-ebooks.info

http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 11

The article proposes a new approach to project management called “PM-2” where traditional

project management will play an active and important role but will be “extended to consider dynamic,

nonlinear, multi-causal structures and processes as well as the principles of self-organization,

evolution, and networking.” The article goes on to say:

For an effective attainment of project goals at a defined finishing point in time, we need

the linear processes and Cartesian causality and the Newtonian logic from Traditional

project management. But evolutionary and self-organizational-based management meth-

ods are necessary to master complex and uncertain situations on the way to the defined

finishing point in time for a project. A well-balanced interaction of traditional project

management and the evolutionary and self-organizational principles is the message of the

Project Management Second Order.12

I agree with that view—we are on the verge of a new generation of project management that

will cause us to rethink many of the accepted notions of what “project management is.” It requires

blending traditional project management principles and practices with a much more empirical and

evolutionary approach to deal with the uncertain, dynamic, and fast-paced environment we live

in today.

AGILE PROJECT MANAGEMENT BENEFITS

I am a strong believer in agile, and there are some very significant benefits of an agile approach in

many situations. However, many proponents of agile oversell the benefits and sometimes position

agile as a panacea that should be used for all projects. The real benefit to a typical project manager

of developing an agile project management approach is not in throwing away any notion of using a plan-driven approach, converting to agile, and using a totally agile approach for all projects. Rather,

the benefit results from recognizing that a traditional, plan-driven approach is not the best way to

manage all projects and thus learning to blend adaptive/agile and plan-driven principles and practices in the right proportions to fit a given situation.

Even if a project manager never uses a fully agile approach, I believe that knowledge of agile concepts and principles will make him/her a better project manager. It’s really a matter of learning

a broader range of approaches (adding more tools to your tool box) and developing a more adaptive

project management approach (developing more skill in using those tools). In my previous books,

12Ibid.

www.it-ebooks.info

http://www.it-ebooks.info/
12 T H E P R O J E C T MANAG E R ’ S G U I D E TO MA S T E R I N G AG I L E

I used the analogy of a project manager as a “cook” and the project manager as a “chef” (with credit

to Bob Wysocki):13

◾ A good cook might have the ability to create some very good meals, but those dishes might be lim- ited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals might

be primarily based on following some predefined recipes out of a cookbook.

◾ A chef, on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. The chef’s knowl-

edge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef

will create entirely new and innovative recipes for a given situation. The best chefs are not limited

to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.

I think that sums up the transformation that needs to take place—we need to develop more

project managers who are “chefs” rather than “cooks.”

Here are five specific benefits of developing an agile project management approach:

1. Increased focus on business outcomes. Many people think that the primary benefit of an agile project is just getting it done faster, but that is not always the case. The primary emphasis

in an agile project is really to deliver value in the form of very successful business outcomes

by taking an adaptive approach to maximize the value that is delivered. That doesn’t always

result in the fastest delivery times. In some cases, it may require some experimentation and

trial-and-error prototyping to find an optimum solution—that may or may not be the quickest

way to get it done, but it should result in a better product in the end.

2. Reduced time to market. Time to market is, of course, an important consideration, and agile accomplishes that in a couple of ways:

◾ By reducing the startup time required for projects as a result of simplifying some of the requirements definition practices

◾ By improving the efficiency of the overall project and delivering functionality incrementally as much as possible

◾ By focusing on simplicity and eliminating non–value-added work

3. Higher productivity and lower costs. Agile can also result in higher productivity and lower costs by eliminating unnecessary overhead and bottlenecks and doing work concurrently rather than

sequentially.

4. Higher quality. A very important benefit of agile is higher quality. In a traditional waterfall project, quality is sequential and is often perceived as a separate effort that is the responsibil- ity of the quality assurance (QA) department. The developers many times develop the software

and then “toss it over the wall” to be tested by QA. In an agile project, the team, as a whole

(which includes QA testers) jointly owns responsibility for building quality into the design of

13Cobb, Charles, Making Sense of Agile Project Management, Wiley, 2003, p 96

www.it-ebooks.info

http://www.it-ebooks.info/
I N T R O DU C T I O N TO AG I L E P R O J E C T MANAG EM E N T 13

the products that they produce—it’s not someone else’s responsibility. The development effort

is broken up into short iterations called sprints that are typically two to four weeks in length. There is an emphasis on producing a shippable product at the end of every sprint, which means that quality testing must be more integrated with development and cannot be put off

indefinitely.

In the traditional environment, the developers may pass software over to QA that has not

been fully tested, expecting QA to test it and find any bugs. In an agile environment, code is

not considered “done” until it has been tested and proven to be working without defects.

5. Organizational effectiveness. Finally, a very important benefit of agile is a more effective orga- nization with higher morale: