Preface

The Agile Manifesto resulted after that legendary group of individuals met at a Utah ski resort in February, 2001.

It’s ironic that despite buy-in and adoption of the manifesto, most of what has been published, spoken about, and even practiced are things from the right half of the manifesto. You have probably used many of the common agile-related items such as Scrum, user stories, eXtreme Programming, test-driven development, product backlogs, task boards, and the list goes on and on. At a high level, the majority of these are either processes or tools. Yet the Agile Manifesto espouses individuals and interactions over processes and tools.

So, why is there so much focus on process and tools? Because they are all enablers of the values depicted in the Agile Manifesto. For example, if you maintain a product backlog as part of the Scrum process, you have a prioritized list of features, and every four weeks (or whatever your iteration cycle is) you develop potentially shippable code. At the end of each iteration, the product owner helps the development team determine what they will develop next. You can easily see that these items enable “responding to change over following a plan”; “working software over comprehensive documentation” and “customer collaboration over contract negotiation.”

The one value that does not get as much attention is “individuals and interactions over processes and tools.” One reason for this is because the majority of individuals in our industry started out in college as computer SCIENCE or software ENGINEERING students. Yet individuals and interactions focus more on psychology and human behavior. It is less black and white and less perfect. Arguably the most common and most complex issue companies and project teams typically face is related to human behavior and communication.

In one of the first popular agile books, Agile Software Development, Alistair Cockburn introduced us to agile with an excellent discussion of the human side of developing software. He addressed culture, communication, cooperation, and other “soft” subjects that are at the core of agile. Since that book was published in 2002, there has been sparse coverage.

This book is not intended to take you on a philosophical journey. Instead, it is structured as a user’s guide. Practical information is presented that is relevant to the issues that project teams tend to encounter, with stories, tips, and best practices that can be put into action. In addition, facilitator instructions are included with valuable exercises that you can administer with your team or that can be combined as part of a comprehensive team dynamics workshop.

How to Use This Book

This book is written as a user’s guide to optimizing individuals and interactions on an agile project. Your use of this book may vary based on your role.

If you are a manager, ScrumMaster, or product owner, or play some other leadership role, you may want to make two passes through the book: First, read the chapters to gain a better understanding of your team and why it behaves the way it does. Second, choose activities described in the book and facilitate exercises with your team to improve.

If you are a consultant tasked with helping teams succeed, identify areas needing the most attention and select content and exercises that address those areas. It can be useful to facilitate reading groups (for example, lunch and learn book reviews) where the team reads and discusses one chapter at a time.

If you are a trainer, the book has been designed to provide the ingredients you need to facilitate an Agile Team Dynamics workshop. Instructions for conducting the workshop are described in Chapter 9, “Team Dynamics Workshop.”

Lastly, most readers of this book are members of project teams. Some work on agile projects, some may be considering agile, and others have not had the opportunity to work on agile projects. The knowledge and exercises in this book are not exclusive to agile project teams. Understanding behavior and social factors on any project team is the first step to building a cohesive, productive team.