Who Should Read This Book?

The goal of this book is to help companies see both agile and non-agile methodologies in a whole new light and understand how they can use these approaches effectively in an overall strategy to gain the right balance of both control and agility. The book is intended for a fairly broad audience—some of the examples in the book are from a software development perspective; however, most of the book is applicable to improving any product development process for software, hardware, and services.

Brief Overview of the Book

Many businesses have cumbersome and bureaucratic product development processes that can seriously hamper their competitive ability. Typically, these processes have been developed to satisfy a need to provide control and predictability for costs and schedules; however, an overemphasis on control can lead to rigid and inflexible processes that may not be well designed to adapt to business needs. In many businesses today, flexibility and responsiveness to change are as important as control of costs and schedules:

• A project that successfully meets its cost and schedule goals but misses an important market window because the schedule wasn't aggressive enough might not be considered very successful overall.
• A project that fails to achieve the desired business outcome because the development process didn't provide a sufficient level of flexibility to rapidly adapt to new and changing business requirements might also not be considered very successful even if it met its cost and schedule goals.

If we accept a broader definition of how to determine the success or failure of projects, it forces us to take a close look at the level of emphasis that has traditionally been put on establishing a level of control designed to meet cost and schedule goals. Achieving a more balanced approach might mean rethinking the way projects are managed, but if it is done correctly, it is not necessary to completely sacrifice control over costs and schedules in order to achieve agility. It does require some skill to achieve the right balance of control and agility, and the right approach may be somewhat different from one business to the next.

Implementing a balanced approach successfully in a business environment poses some significant new challenges for project managers:

• There's a much greater range of methodologies, principles, and practices (both agile and traditional) that a project manager needs to consider.
• There's a need to fit the methodology (or combination of methodologies—either agile or non-agile) to the business environment as well as the risks and complexities of typical projects rather than trying to force-fit projects to any standard methodology (agile or non-agile).

That requires a broad-based understanding of different methodologies and practices as well as a deeper understanding of the principles behind them to tailor and customize an approach to fit with the business environment and the risks and complexities of individual projects.

In the past, some project managers may have acted as “cooks”—they knew how to prepare a limited number of recipes (methodologies) and sometimes did so “by the book”. In the future, being a good “cook” may not be good enough, and more project managers may need to become “chefs”—they will need to know how to prepare a much broader range of dishes and go beyond preparing standard recipes by the book to create highly customized and innovative “recipes” tailored to fit a particular business and project environment. The agile movement forces project managers to consider a much broader range of “recipes” and “ingredients” to “cook” with and requires a much more customized and tailored approach.

This book has two major objectives:

1. 1. For all readers (and, in particular, business leaders); this book is intended to provide an understanding of how to fit agile methodologies into an overall business strategy that provides the right balance of control and agility for their business. Doing that effectively requires analysis and planning. In many cases, agile methodologies have been implemented from a development perspective—they need to be understood from a much broader business strategy, project management, and project governance perspective in addition to a development perspective.
2. 2. For project managers, this book is intended to provide a much deeper understanding of agile principles, methodologies, and practices to enable project managers to develop a more agile project management approach and understand how to blend and tailor both agile and traditional principles, methodologies, and practices to create an appropriate balance of control and agility to fit a business environment, as well as the risks and complexities of any individual project. Key topics include:
   • How the project management role is changed in agile projects and what new skills and career directions may be needed to grow into agile project management roles.
   • How to develop a project management approach that can be adapted to agile as well as non-agile project environments.
   • How to integrate existing project management knowledge such as the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—Fourth Edition with new and rapidly evolving agile principles, practices, and methodologies
   • How to design and tailor the right combination of principles, practices, and methodologies (agile as well as non-agile) to provide a balance of control and agility to fit the needs of a business and the risks and complexity of projects rather than attempting to use a standard “off-the-shelf” methodology (either agile or non-agile) for projects.

This book has intentionally been designed to avoid an in-depth discussion of the mechanics of implementing any particular methodology (either agile or non-agile) for two primary reasons:

• There are already numerous other books on the market that are readily available to provide that kind of information.
• Digressing too far into the details of the mechanics of how any particular methodology is implemented would distract the reader from the high-level view that this book is intended to focus on.

Why I Wrote This Book

I recently attended a local agile group meeting to hear the presentation “Essential Deprogramming for Traditional Project Managers.” The person who gave the presentation had over 15 years of project management experience, and the tone of her presentation was that she has now “seen the light,” forsaken all the things she used to do as a project manager, and transformed herself into an agile coach.

She made a number of very negative comments about project management that were based on a lot of popular stereotypes, myths, misconceptions, and clichés about what project management is, and she made a particular statement that “‘Agile Project Management’ is an oxymoron.” I don't agree with that point of view at all, but it indicates how large a “chasm” there is between the traditional project management perspectives and newer, more agile approaches to project management. One of the major obstacles to crossing this “chasm” is that there are people on both sides of the “chasm” who are somewhat opinionated and narrow-minded:

• There are some project managers who are deeply entrenched in thinking that traditional, plan-driven, control-oriented approaches are the only way to do project management.
• There are many agilists who are equally entrenched in their perspective that the only way to be “agile” is the pure agile way and that there is no need for project management at all—they see project management as a role rather than a set of skills that can be adapted to a broad range of different environments, just as the agile principles can also be applied to a broad range of different environments.

I've been doing project management in product development and other project environments for a long time. That has given me a very broad view of what works and what doesn't work in different situations, and I've learned that there is no single methodology (agile or non-agile) that works for all projects. One of the risks in project management is that if you are schooled in one particular methodology (either agile or non-agile), it's easy to get lost in the mechanics associated with implementing that methodology and not step back and consider that an entirely different methodology or approach might make much more sense for a given project.

A major goal of this book is to help build a bridge across this “chasm” between traditional and agile project management approaches and help people see these methodologies in a very different light. This “chasm” really isn't as large as people think it is, and the “chasm” is as much perceived as it is real. This is an extremely strategic and important topic for the project management profession. For many project managers who have been schooled in traditional project management approaches, agile methodologies will require developing a new perspective:

• Project managers need to expand the tools in their toolkit to embrace newer, more agile forms of project management in addition to traditional project management approaches.
• In the past, project managers may have attempted to force-fit a project to a given methodology (either agile or non-agile) because that's what they're most familiar with. Agile methodologies will require tailoring the methodology (or combination of methodologies) to fit the business environment and the risks and complexity of the project.

These factors will require project managers to develop a broad-based understanding of agile and non-agile methodologies at a deeper level to apply them successfully in the right combinations for a given project. CIOs, CTOs, development managers, and business leaders also need to understand the potential role that agile methodologies can play in improving the effectiveness of their organization in meeting increasing demands for timely and flexible software solutions that satisfy very demanding business requirements.

I've had some unique experiences in my career that ultimately led me to write this book:

1. 1. In the mid-1990s I was the director of corporate quality for a company that developed hardware and software products for telecommunications applications. It was quite a challenge:
   • The quality of the products was weak, and the company had ongoing customer service issues to try to keep up with problems generated by software quality issues.
   • The software development organization had a number of very bright developers who didn't want anything to do with any defined methodology or process.
   • The company had grown by acquisition and had acquired other companies in four different worldwide locations (Manchester, UK; Canton, Massachusetts; Dallas, Texas; and Wichita, Kansas) and each of those organizations had its own way of doing things.
   • My primary job at the time was to get the entire company to agree on a single development methodology, and get everyone to adopt and consistently implement that methodology and then pass an external audit on the process implementation. I had moved into the quality management arena from a project management background, so my natural orientation was toward the control and predictability provided by the Waterfall model; however, I was working with a number of software developers and managers who knew a lot more about software development than I did at the time, and I learned a lot from that.
   • To make a long story short, I came to realize that forcing people to adopt one methodology like the Waterfall wasn't going to work—it was overkill, it had way too much overhead for many of the company's projects, and the software developers would never follow it if we implemented it as a standard methodology for the whole company. On the other hand, there were some projects for which it did make sense. The end result was that we wound up with several different life-cycle models and the project manager could pick one of those models that he/she felt was most appropriate for the project, and he/she could also tailor it as needed to fit that particular project.
   • Another lesson I learned is that no methodology (agile or non-agile) should ever be taken as absolute dogma. Project managers must have some ability to apply it intelligently and make changes as needed to fit the scope, risks, and complexity of the project.
   • That implies that those project managers have a sufficient level of training and understand the concept and principles behind the methodology to make those decisions intelligently.
   • The impact of those decisions is understood, reviewed, and approved if necessary by the project's stakeholders.
2. 2. Since that time, I've worked with many companies in many different application environments, using numerous project management methodologies (both agile and not-so-agile) to help them improve their product development processes. I also have a very strong background doing hands-on development work, so I understand first-hand what it takes to develop good software.
3. 3. In 2003, I published a book called From Quality to Business Excellence—A Systems Approach to Management. A key objective of that book was to try to demystify and unravel a lot of confusing and competing approaches to process improvement and quality management that were in use at that time (Six Sigma, TQM, BPR, etc.). At that time, Six Sigma was very hot, as agile is today, and people were just jumping into it, treating it as a “panacea” for solving almost any kind of problem, and doing it superficially without fully understanding what it took to do it successfully. I hope that this book will play a similar role in understanding the potential business impact of agile product development methodologies.

How to Use This Book

The following is a summary of how the book is organized to meet these objectives.