Where This Book Fits

I wanted to write this book because I see a need for it. Quite a bit of the agile development literature focuses on project management practices that promote agility. Project management practices are, of course, vital. But just as vital is the realization that in order to be agile, your software itself and the methods you use to develop it had better support your ability to be agile. You can't be agile if your software is brittle and is difficult to change with too few safeguards in place to enhance confidence in the changes. Software project management and development practices and software must go hand in hand.

I also feel that too many software projects focus exclusively on features and bug fixing and not enough on excellence. Software quality is an issue for our industry, but we too easily accept it as inevitable and somehow a result of the need for constant change. But as software becomes increasingly important in our daily lives, issues like security and quality are becoming more urgent. I think it's time we find ways to achieve features AND quality, not just view them as exclusive to each other.

As I see it, this book falls into a bit of an awkward spot. While this book is heavily influenced by the agile development community, and Extreme Programming (XP) in particular, agile in my opinion leaves too much to the imagination of the reader/listener, and this leads to many misconceptions. Some of these misconceptions are dangerous and very falsefor example, that in XP there is no software design and that teams who practice agile development are somehow less disciplined. What I have tried to do in this book is expand on the existing agile literature by drawing on my work experience to introduce a team-oriented approach to achieving short-term and lasting excellence on a software project through principles (mindset) and practices.

I don't mean to imply that the outcomes, principles, and practices I describe in this book aren't employed at all in agile teams. I know they are, but sporadically and inconsistently. By not talking about these practices, it is too easy for traditionalists to dismiss agile development because it does not openly address some critical practices. The opposite is also true: Many of the practices in this book are advocated by the traditional software development community and are thus dismissed by some agilists. But I think this misses the point.

What I try to emphasize throughout this book is that what separates agile from non-agile practices is the perspective to the practice, not the practice itself. Hence this book's subtitle: An Agile Perspective. An agile perspective means in a nonbureaucratic way that emphasizes trying new things out and always learning, changing, and adapting as circumstances dictateand with lots of collaboration. So maybe this book is a little bit like a bridge between the traditional and agile camps, but with an unerring bias toward agility. I hope that the saner minds in the agile community agree with me.

The Three Foundations of Agile Development

Agile development practices have three foundations: project management, technical excellence, and collaboration. Using the flywheel analogy from the excellent book Good to Great [Collins 2001], agility is just like trying to spin a massive flywheel. The forces that can be applied to the flywheel are the principles and practices you use for software development, which can be categorized by agile's three foundations as shown in Figure I-3. If any of your principles or practices are not agile, then this will act as a brake on the flywheel. That is, appropriate project management practices promote agility, as does an emphasis on collaboration within project teams and with customers, as does an emphasis on technical excellence, and all of these practices combined support agility. If a team employs agile project management practices but non-agile/inadequate technical excellence practices or little or no collaboration, the team's ability to be agile is going to be constrained.

Figure I-3. The three foundations of agile development are the principles and practices used for project management, technical excellence, and collaboration. If agility is considered to be like attempting to spin a massive flywheel, then the principles and practices used for software development either act as a positive force or a brake on the flywheel. Hence, the principles and practices used for all three foundations must support and enhance each other.

About the Structure of This Book

What is needed for agility is a balanced blend of principles and practices that reinforce each other and the three foundations of agility shown in Figure I-3. The principles and mindset of sustainability are vital because they are the filter through which all the practices are chosen and implemented. Because of this, the core of the book (Chapters 47) consists of a chapter for each principle of sustainable software development, with practices that help implement the principle described in enough detail to get started. Chapters 1 and 2 describe sustainable and unsustainable software development, and Chapter 3 focuses on the important distinction between principles and practices. The closing chapter, Chapter 8, is targeted at creating culture change, because change is usually required to achieve a culture oriented around sustainability.

Quite a few of the practices described in this book are outlined in greater detail in other sources, and so I have included Appendix 4 with my recommendations for further reading. In general, when it comes to the foundations of agile development, project management and collaboration practices are typically described extremely well in the literature while technical excellence is often left as an exercise to the reader (except of course in Extreme Programming). Hence, I have tried to provide a slight bias toward the technical excellence practices.

I've consciously tried to ensure that this book is not just another technical book. I've encountered too many software developers who are brilliant architects and coders but don't, for example, understand the interdependence between their decisions and their company's larger business interests. I've seen too many projects that redesign their software simply for the sake of an elegant design when a pragmatic approach ("if it works, don't change it") is often in the better long-term interests of the project. I also have seen many teams who focus on creating the best possible software or, even worse, spending an endless amount of time writing requirements and design documents often with NO software and losing their focus on what every project's sole aim should be: shipping!

This book is for software developers, managers, and users who believe in self-discipline, professionalism, and in shipping software products with high quality that last. Especially for those who are looking for ways to embrace change and increase efficiency, while continually improving themselves, their teams, and their organizations.