ISBN-10:
0321714091
ISBN-13:
9780321714091
Pub. Date:
04/15/2011
Publisher:
Addison-Wesley
Individuals and Interactions: An Agile Guide / Edition 1

Individuals and Interactions: An Agile Guide / Edition 1

by Ken Howard, Barry Rogers
Current price is , Original price is $39.99. You

Temporarily Out of Stock Online

Please check back later for updated availability.

Product Details

ISBN-13: 9780321714091
Publisher: Addison-Wesley
Publication date: 04/15/2011
Pages: 240
Product dimensions: 5.90(w) x 8.90(h) x 0.60(d)

About the Author

Ken Howard works at Improving Enterprises, where he specializes in helping companies increase productivity through efficient practices and pragmatic organizational dynamics. Ken has been involved in most aspects of software development for more than 26 years with such languages as diverse as COBOL, Smalltalk, and Java. Over the years Ken has provided consulting, training, and mentoring to companies in 12 countries around the world, helping with adoption of software development best practices. He eagerly embraced the opportunity to share many of the things he has learned with a broader audience through the publication of this book.

Barry Rogers is President of Improving Enterprises, Dallas, Texas. He is an accomplished Certified ScrumMaster and Certified Scrum Practitioner. Barry supports clients in both a hands-on and mentorship/coaching capacity, helping teams adopt agile/Scrum and improve human dynamics. Barry is a Speaker and also facilitates leadership, agile, and project management training sessions.

Read an Excerpt

PREFACEPREFACE

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.

Resource

When you see the book icon, look for a reference to a resource that you can dive into for deeper coverage of a topic being discussed. Rather than having to scour through a bibliography at the end of the book, look for sources of great material presented alongside the topics it supports.

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.

© Copyright Pearson Education. All rights reserved.

Table of Contents

Preface xv

Introduction 1

A Brief History of Organizational Behavior 2

Stage 1: People Are Machines (Late 1800s—Mid 1900s) 2

Stage 2: People Are Emotional Beings (1940s—1970s) 3

Stage 3: Organization Is a Machine (1980s—2000s) 4

Stage 4: Empowered Teams Transform the Organization (Current Trend) 6

Birds of a Feather... 6

PART I: INDIVIDUALS AND INTERACTIONS

Chapter 1 Autonomous Securities, LLC 11

Chapter 2 Behavior and Individuals 13

Communication Framework 14

DISC History 15

DISC Definition 15

So Why Is This Important? 17

Understanding and Accepting Others 17

Communicate in Your Own Language 19

The Language of DISC 20

Strategies for Communicating 21

How Do You Take a DISC Assessment? 22

Closing 23

Chapter 3 Team Dynamics 25

An Apoplectic Dilemma 25

A Different Approach to Teams 26

Capitalizing on Strengths 28

The Anarchical Team 30

The Evolution of a Maturing Team 30

Conflict 33

Now What? 40

Closing 42

Chapter 4 Communication 43

Lingo 45

Empathy 46

Eye Contact 48

Ambiguity 49

Body Language 50

Cultural Awareness 53

Reflecting Body Language 54

Small Talk 54

Collaborative Conversations 57

The Power of Shutting Up 64

Communication Latency 65

We the People... 68

Closing 69

Chapter 5 Collaboration 73

Working as a Team 73

Vox Populi 74

Group Survival 77

Problem-Solving Versus Decision Making 78

Individuals and Decisions 79

Groups and Decisions 79

Group Influence 80

Six Degrees of the Perfect Ice Cream Sundae 83

Diametrically Opposing Forces 85

Closing 88

Chapter 6 Behavior and Teams 89

Harmony/Conflict 89

Why Not Hire a Team with Members That Will All Naturally Get Along? 92

Be Prepared for Conflict 93

Stressed Out 94

Fill the Gaps 94

Organizational or Team Culture 95

Closing 95

Chapter 7 Change 97

A True Story 97

Why Is Change Difficult? 99

Change Squirm 102

Change Apprehension 103

Fear of Changes to Self-Actualization Needs 104

Fear of Changes to Esteem Needs 105

Fear of Changes to Love/Belonging Needs 105

Fear of Changes to Safety Needs 106

Fear of Changes to Physiological Needs 106

Change Coach 107

Change Catalyst 108

Tracing to the Roots 109

Grass Roots Resistance to Change 110

Exposing the Origins 111

Exercise 113

Closing 114

Chapter 8 Motivators 115

Individual Workplace Motivators 115

Theoretical 116

Utilitarian/Economic 116

Aesthetic 117

Social 117

Individualistic/Political 117

Traditional/Regulatory 117

Why Is This Important? 118

Strategies for Motivating 119

Leveraging Strengths 122

Leadership and Environment 123

Closing 124

PART II: WORKSHOP

Chapter 9 Team Dynamics Workshop 129

Preparation 129

Workshop Instructions 130

Pre-Workshop 130

The Workshop 132

Chapter 10 Communication Origami 139

Materials 140

Setup 140

Facilitation 141

Post-Exercise Discussion 141

Chapter 11 Bridge Building 145

Materials 146

Setup 146

Facilitation 147

Post-Exercise Discussion 148

Chapter 12 Moon Survival 151

Setup 152

Facilitation 152

Individual Exercise 152

Team Exercise 153

Scoring 153

Post-Exercise Discussion 153

Moon Survival Expert Analysis 158

Chapter 13 BalderDISC 163

Materials 164

Setup 164

Facilitation 165

Post-Exercise Discussion 166

Chapter 14 Assessing Concordance and Discordance 169

Materials 169

Setup 170

Facilitation 170

Post-Exercise Discussion 171

Chapter 15 Change Exercise 175

Overview 175

Setup 176

The Drawing Board 177

The Teams 177

Facilitation 178

Post-Exercise Discussion 179

Chapter 16 Groups and Decisions 183

Setup 183

DISC-Homogeneous Behavior 185

Appendix How to Take the DISC 187

References 195

Index 199

Preface

PREFACE

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.


Resource

When you see the book icon, look for a reference to a resource that you can dive into for deeper coverage of a topic being discussed. Rather than having to scour through a bibliography at the end of the book, look for sources of great material presented alongside the topics it supports.


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.

© Copyright Pearson Education. All rights reserved.

Customer Reviews

Most Helpful Customer Reviews

See All Customer Reviews