Chapter 1. Introduction

There have been a number of "agile" methodologies documented in recent years including Extreme Programming, Scrum, Crystal, Lean, and more. Each has strengths and demonstrated successes. Teams have used these methods to deliver high-quality software rapidly. In particular, teams using these methods have been able to adjust to changes in market pressures and deliver software in response to changing customer demands. However, for those engineers who are working in non-agile development organizations, moving to an agile process is a huge leap and brings significant risks. Agile processes require different skills in the engineers and in the management of the project. Such a radical change to the development process could result in delays and difficulty in delivering acceptable results. The enthusiasm behind the agile movement has generated a wealth of literature on various development and management techniques and philosophies that have been shown to be effective. The sheer volume of that literature can be overwhelming for people who are considering agility.

Imagine the typical software development team: they are working hard to produce a quality product that their customer wants, and they are using a process that is unique to their environment and customized to their culture and skills. The process they follow may be waterfall or simply ad hoc (for this example, it doesn't matter). One day, Joe Engineer, a member of that team, reads a book on an agile development process (it doesn't matter which one). Things seem so obvious! "We should ask the customer what he wants regularly instead of only at the beginning and end of the project. We should work in a collaborative environment where we maximize every engineer's skills. We should measure ourselves by the features we produce, not the milestones we pass or documents we write. We should put the parts of our system together as soon as possible to be sure that the code we've written really works. We should use tools like automated testing to help us guarantee quality, and we certainly should be allowed to refactor the parts of our system that need it."

Having had these revelations, Joe takes his enthusiasm to his colleagues and management. Although they have some reservations, they are willing to look into the possibilities. Other team members start reading books on other agile methods, and soon the team is overwhelmed. The processes are similar in philosophy but differ in their details. Which one should they pick? Then management begins to recognize the scope of the change being proposed. "These new methods require some new skills. Do we have team members who have this experience?" The team has to admit that they don't because they've been busy producing the product. The significance of the change in the process scares management (and some of the engineers). "How will we continue to produce the products that pay all of our salaries while we figure out how to make this transition?" "Are we sure that even if we make the switch, the benefits will outweigh the costs?"

No agile methodology is "best" or works for every organization. Selecting the methodology that adds the highest value by matching its strengths with the capabilities of your organization is non-trivial, and it is unlikely that any methodology you choose would yield the optimal solution for all of the issues that are particular to your organization. It would be far more useful for an organization to be able to incorporate the most valuable techniques as they pertain to its unique process, independent of any one methodology.

This book lays out a process to assist the organization's transition to agility with minimal risk. Although this "mix and match" approach may seem to add complexity to a transition from plan-driven to agile development, in reality it will reduce the risk of that transition by allowing a more customized, step-by-step approach.

The structures of agile methods are very different from traditional software development methods and require new skills in your engineers and your management. The goal of this book is to allow an organization the freedom to become agile without the fear that accompanies replacing all elements of the current plan-driven approach with a new agile methodology in a single step. That goal is supported by a transition framework that will help everyone (engineers, managers, customers, etc.) manage the process change in a way that maximizes potential benefits while minimizing risk. After agility has been achieved, a strategy for optimizing the process is presented.