Making Sense of Agile Project Management

Balancing Control and Agility

Charles G. Cobb

• Publisher: Wiley
• Year: 2011
• ISBN:
  9781118015704
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Making Sense of Agile Project Management

Business & Economics/Project Management

The essential primer to successfully implementing agile project management into an overall business strategy

For a project to be truly successful, its management strategy must be flexible enough to adapt to dynamic and rapidly evolving business needs. Making Sense of Agile Project Management helps project managers think outside the box by presenting a deep exploration of agile principles, methodologies, and practices. Straying from traditional bureaucratic procedures that are rigidly defined, this book espouses a heavy reliance on the training and skill of collaborative, cross-functional teams to adapt the methodology to the problem that they are attempting to solve—rather than force-fitting a project to a particular methodology. Making Sense of Agile Project Management:

• Focuses on how agile project management fits with other more traditional project management models to provide a more effective strategy
• Includes many cases taken from real-world companies illustrating good and bad agile implementation
• Provides coverage that is balanced and objective with discussion of both agile and non-agile methodologies

Making Sense of Agile Project Management employs a straightforward approach that enables project managers to grasp concepts quickly and develop adaptable management tools for creating a vibrant and fluid business environment. By utilizing the principles laid out in this book, business managers and leaders will strengthen their ability to meet the risks and complexities of any individual project—and better understand how to blend the appropriate balance of control and agility into an overall business strategy.

PART I
Overview

The primary objective of Part I of the book is to help companies understand 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.

In order to accomplish that, it is essential to overcome some popular misconceptions associated with “agile” such as:

• “Agile” is an undisciplined process of simply writing code with no planning, no documentation, and no disciplined methodology for how it is done.
• The only way to be “agile” is to implement pure agile methodologies such as Scrum.
• At one end of the spectrum is the most extreme forms of traditional plan-driven, control-oriented methodologies like the Waterfall process; at the other end are pure agile approaches like Scrum, with nothing in between.

The truth is that:

• Implementing an “agile” process requires just as much or more discipline as traditional approaches such as the Waterfall model, but it's a different kind of discipline. Rather than relying on rigidly defined and prescriptive methodologies, agile approaches rely much more heavily on the training and skill of collaborative, cross-functional teams to adapt the methodology to the problem that they are attempting to solve.
• Pure forms of agile like Scrum have many advantages, but they can be very difficult to implement and aren't necessarily appropriate for all business environments and projects. Many businesses require a balance of control and agility, which may be more suited to a hybrid approach.
• There are many ways companies can become “more agile” without necessarily going to the extreme of a pure agile approach, but it may take a more sophisticated approach to blend together the right combination of agile and non-agile methodologies and practices to craft a customized approach. The best approach is always to fit the methodology and practices to the business environment and problem you're trying to solve rather than force-fitting a project to a particular methodology, but doing that requires a much higher level of skill and it requires developing an understanding of the methodologies and practices at a deeper level.

There are many companies that are locked into very cumbersome and bureaucratic traditional methodologies that don't see how to improve that situation, because it can be so difficult to move to a pure agile approach and there is also a fear of losing control in the process. Part I of the book is designed to help companies understand some of principles behind agile approaches in order to see how to develop an appropriate strategy for how to integrate more agile practices into the way they do business.

Chapter 1
Introduction

“Agile” is definitely the latest and coolest buzzword in the software development world—everyone wants to be “agile,” but there are many misconceptions of what “agile” means, and many people don't fully understand the implications of what it takes to develop an effective agile development process.

Meaning of the Word “Agile”

First, it is essential to define what we mean by the word “agile”. In the software development arena, the word “agile” has become synonymous with specific forms of agile such as Scrum and Extreme Programming (XP):

---

Scrum is an agile software development model based on multiple small teams working 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. This requires well-trained and specialized teams capable of self-management, communication and decision making. The teams in the organization work together while constantly focusing on their common interests.¹ (See Appendix B for more detail.)

---

---

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, every contributor to the project is an integral part of the “Whole Team.” The team forms around a business representative called “the Customer,” who sits with the team and works with them daily.

Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business value, the team produces the software in a series of small fully integrated releases that pass all the tests the Customer has defined.² (See Appendix A for more detail.)

---

This connotation of the word “agile” has become widely accepted in common usage in software development and creates the impression that the only way to be “agile” is to practice those specific methodologies. In other words, if you're not doing Scrum and/or Extreme Programming, you're not agile at all.

The meaning of the word “agile” has become confusing because of these widely-used specific connotations that have become associated with it. These connotations are also in the context of a development perspective and a much broader context is needed. A more general connotation of the word “agility” is defined by Dr. David Rico³ as follows:

---

• “The ability to create and respond to change in order to profit in a turbulent global business environment
• The ability to quickly reprioritize use of resources when requirements, technology, and knowledge shift
• A very fast response to sudden market changes and emerging threats, by intensive customer interaction
• Use of evolutionary, incremental, and iterative delivery to converge on an optimal customer solution
• Maximizing the business value with right-sized, just enough, and just-in-time processes and documentation”⁴

---

The word “agility” as defined above has a much broader meaning than the meaning that has typically been associated with the word “agile”—it implies that there are many different levels of “agility” and not just a limited number of specific ways to being “agile”. A key idea that this book will develop is that there is a spectrum of different approaches to “agility”:

• At one end of the spectrum, there are approaches such as the traditional Waterfall methodology ...

Table of contents

• Cover
• Contents
• Title Page
• Copyright
• Preface
• Acknowledgments
• PART I: Overview
• PART II: Overview
• PART III: Appendices
• Index
• End User License Agreement