BN.com Gift Guide

Collaboration Explained: Facilitation Skills for Software Project Leaders [NOOK Book]

Overview

Collaboration Explained is a deeply pragmatic book that helps agile practitioners understand and manage complex organizational and team dynamics. As an agile coach, I’ve found the combination of straightforward advice and colorful anecdotes to be invaluable in guiding and focusing interactions with my teams. Jean’s wealth of experience is conveyed in a carefully struck balance of reference guides and prose, facilitating just-in-time learning in the agile spirit. All in all, a superb resource for building ...

See more details below
Collaboration Explained: Facilitation Skills for Software Project Leaders

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac

Want a NOOK? Explore Now

NOOK Book (eBook)
$27.49
BN.com price
(Save 42%)$47.99 List Price

Overview

Collaboration Explained is a deeply pragmatic book that helps agile practitioners understand and manage complex organizational and team dynamics. As an agile coach, I’ve found the combination of straightforward advice and colorful anecdotes to be invaluable in guiding and focusing interactions with my teams. Jean’s wealth of experience is conveyed in a carefully struck balance of reference guides and prose, facilitating just-in-time learning in the agile spirit. All in all, a superb resource for building stronger teams that’s fit for agile veterans and neophytes alike.”

—Arlen Bankston, Lean Agile Practice Manager, CC Pace

“If Agile is the new ‘what,’ then surely Collaboration is the new ‘how.’ There are many things I really like about Jean’s new book. Right at the top of the list is that I don’t have to make lists of ideas for collaboration and facilitation anymore. Jean has it all. Not only does she have those great ideas for meetings, retrospectives, and team decision-making that I need to remember, but the startling new and thought-provoking ideas are there too. And the stories, the stories, the stories! The best way to transfer wisdom. Thanks, Jean!”

—Linda Rising, Independent Consultant

The Hands-On Guide to Effective Collaboration in Agile Projects

To succeed, an agile project demands outstanding collaboration among all its stakeholders. But great collaboration doesn’t happen by itself; it must be carefully planned and facilitated throughout the entire project lifecycle. Collaboration Explained is the first book to bring together proven, start-to-finish techniques for ensuring effective collaboration in any agile software project.

Since the early days of the agile movement, Jean Tabaka has been studying and promoting collaboration in agile environments. Drawing on her unsurpassed experience, she offers clear guidelines and easy-to-use collaboration templates for every significant project event: from iteration and release planning, through project chartering, all the way through post-project retrospectives.

Tabaka’s hands-on techniques are applicable to every leading agile methodology, from Extreme Programming and Scrum to Crystal Clear. Above all, they are practical: grounded in a powerful understanding of the technical, business, and human challenges you face as a project manager or development team member.

· Build collaborative software development cultures, leaders, and teams

· Prepare yourself to collaborate—and prepare your team

· Define clear roles for each participant in promoting collaboration

· Set your collaborative agenda

· Master tools for organizing collaboration more efficiently

· Run effective collaborative meetings—including brainstorming sessions

· Promote better small-group and pair-programming collaboration

· Get better information, and use it to make better decisions

· Use non-abusive conflict to drive positive outcomes

· Collaborate to estimate projects and schedules more accurately

· Strengthen collaboration across distributed, virtual teams

· Extend collaboration from individual projects to the entire development organization

Read More Show Less

Product Details

  • ISBN-13: 9780321630056
  • Publisher: Pearson Education
  • Publication date: 1/20/2006
  • Series: Agile Software Development Series
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 1
  • Pages: 456
  • File size: 5 MB

Meet the Author

Jean Tabaka is an Agile Coach with Rally Software Development, specializing in creating, coaching, and mentoring collaborative, agile software teams. Jean brings over 25 years of experience in software development to the agile plate in a variety of organizational contexts including internal IT departments, ISVs, government agencies, and consulting organizations. Having implemented both plan-driven and agile development approaches for Sybase, Siebel Systems, and Qwest, as well as a variety of smaller ventures, her work has spanned industries and continents. As an agile mentor, Jean coaches software teams through training and facilitation to adopt agile principles and practices using a hybrid of the leading agile methods. With a passion for collaboration practices through facilitation techniques, she guides organizations in creating high-performance teams. She is the co-author of Physical Database Design for Sybase SQL Server (Prentice Hall, 1995) and is a frequent lecturer and contributor on the topic of collaboration practices in agile teams. A Certified ScrumMaster, as well as Certified ScrumMaster Trainer, and Certified Professional Facilitator, she holds a Master of Arts from Michigan State University and a Master of Computer Science from Johns Hopkins University.

Read More Show Less

Read an Excerpt

PrefacePrefaceA Path of Learning

When I started my career in IT back in the 1970s, I began as an intern for a JCL helpdesk that supported a team of analysts who expected their programs to run smoothly (enough) in the massive farm of IBM 3270s built for that purpose. I never met the analysts I supported; I never really knew the business they were supporting. I just knew that a stream of data from one system through tape drives to another system had not completed correctly (ABEND!) and I needed to restart the job or redirect the stream from box to box as needed.

The only "collaboration" I experienced was in the form of directions from my supervisor when I didn't know how to solve the problem. There were no team meetings, no team decisions (except about the smoking policy that encouraged cigarettes but banned cigars), and no sense of team ownership of success. Each of the other members of the "team" had their separate set of analysts they supported, their own stacks of punch card carriers, and their personal, safeguarded mag tapes they used to manage their work.

In subsequent jobs, I moved into other 3GL environments, still working largely without access to a customer or other developers. With regard to the development teams, the work was divided up by our manager who made decisions about what we should be doing, how it should be done, and when it should be completed. Our team meetings were weekly bug report meetings where our manager would prioritize what needed to be done and its due date. We passed work from one job title to another (analyst, to designer, to developer, to tester), and teamwork for me was largely restricted to one-on-onedebugging sessions with another developer. But a change was beginning to unfold about how software development projects, their teams, and their managers could work more effectively.

I first dipped into the notion of a learning-oriented approach to software development via Wicked Problems, Righteous Solutions by Peter DeGrace and Leslie Hulet-Stahl (Prentice Hall, 1998). The book became my bible about what was wrong with phase-driven, waterfall approaches and what might be right about a more empirically motivated approach. My next epiphany came in the late 1990s with a visit to the UK where I learned of a new methodology being adopted in Europe: the Dynamic Systems Development Method, or DSDM. What was startling for me about this methodology at the time was its emphasis on timeboxes versus scope for software delivery. It turned my notion of software development methodology on its ear. Moreover, as documentation was de-emphasized, rapid effective face-to-face communication was explicitly built into the approach through its facilitated workshops.

At this point, I made a conscious decision to steer my methodology focus toward facilitation practices that I could apply to software development teams. Because I had seen too many examples of how teams can crumble in bad meeting contexts and in bad control environments, I wanted to learn ways to make all the various team collaborations more reliable, more frequent, faster, and more productive. I took classes in facilitation, read books on facilitation, and attended facilitation conferences. I became a certified professional facilitator, and I began to teach facilitation as well as apply it.

And I learned a few things: facilitation has a place in how we create teams and coax collaborative work from and for them. Additionally, I learned that facilitation is not about control or manipulation. Rather, it is about applying tools, techniques, and processes in support of teams eager to engage in high performance. Good facilitators listen and echo in a way that helps a team hear itself and apply its best wisdom. Project managers and software team leads with facilitative skills become leaders who can listen and echo as they lead teams in vision and success.

Today, I find myself in teams that create a common goal, work to communicate frequently, and make decisions based on their collective wisdom. The agile methodologies we now consult (Scrum, Extreme Programming, Crystal Clear, Feature Driven Development, and Lean Software Development) emphasize project success through disciplines of engineering and communications that can effectively respond to change. In these contexts, I recognize the stabilizing force of collaboration and communication as fundamental practices in project success. Projects need teams; teams need communication. And while communication comes in a variety of forms from one-on-one to very large groups, at the team level of three or more people making decisions and acting on them, communication relies on collaboration.

This book brings together my specific lessons about the importance of applying collaboration in teams. Specifically, it catalogues the practices of facilitation I have learned to use in order to liberate teams into a variety of information gathering and decision modes that promote high performance. I have come to rely on facilitation not as a manipulation or control technique, but rather as a way to encourage participatory decision making among teams of experts. For me, facilitation, more than any other leadership or team practice, has proven to be my greatest gift to teams in creating a vision for them and encouraging their best teamwork.

A number of colleagues have warned me about negative experiences they've endured where a facilitator has used his role in a meeting to manipulate and control the team. That is not my intent here. I believe in leaders who engage facilitatively in service to the team, not in control of it. I believe in teams who recognize the wisdom of a powerful leader and how such a leader's move through various decision approaches strengthens them. A good leader absorbs a rich set of tools in creating success with and for their teams. In this guidebook, I offer one subset of those tools, the facilitation tools.

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Table of Contents

Acknowledgments xix

About the Author xxi

Foreword xxiii

Preface xxv

Overview xxix

Section I: Setting the Collaborative Context 1

Chapter 1: What Is Collaboration? 3

Chapter 2: What Are Collaborative Cultures? 7

Chapter 3: Who Are Collaborative Leaders? 13

Chapter 4: What Are Collaborative Teams? 23

Section II: Applying Collaboration 45

Chapter 5: Defining Project Collaboration Events 47

Chapter 6: Preparing Yourself as the Process Owner 71

Chapter 7: Preparing Participants for Collaboration 85

Chapter 8: Setting the Collaborative Agenda 97

Chapter 9: The Organizing Tools 109

Chapter 10: Starting the Collaborative Meeting 137

Chapter 11: Defining the Steps 147

Chapter 12: Gathering the Information—Brainstorming and Listing 155

Chapter 13: Dialogues, Small Groups, and Expert Input Approaches 167

Chapter 14: Team Estimating Approaches 185

Chapter 15: Processing the Information 193

Chapter 16: Visioning, Retrospection and Other Approaches 213

Chapter 17: Managing the Meeting Participants 227

Chapter 18: Managing Conflict 253

Chapter 19: Guerilla Collaboration 263

Chapter 20: Closing the Collaborative Meeting 269

Section III: Extending Collaboration 277

Chapter 21: Collaboration Practices for Small Teams 279

Chapter 22: Collaboration Practices for Distributed Teams 285

Chapter 23: Collaboration for Organizations 297

Section IV: Collaborative Facilitation Guides 301

Chapter 24: Generic Project Meetings 305

Chapter 25: Crystal Clear 325

Chapter 26: Scrum 341

Chapter 27: XP and Industrial XP 357

Bibliography 387

Index 391

Read More Show Less

Preface

Preface

A Path of Learning

When I started my career in IT back in the 1970s, I began as an intern for a JCL helpdesk that supported a team of analysts who expected their programs to run smoothly (enough) in the massive farm of IBM 3270s built for that purpose. I never met the analysts I supported; I never really knew the business they were supporting. I just knew that a stream of data from one system through tape drives to another system had not completed correctly (ABEND!) and I needed to restart the job or redirect the stream from box to box as needed.

The only "collaboration" I experienced was in the form of directions from my supervisor when I didn't know how to solve the problem. There were no team meetings, no team decisions (except about the smoking policy that encouraged cigarettes but banned cigars), and no sense of team ownership of success. Each of the other members of the "team" had their separate set of analysts they supported, their own stacks of punch card carriers, and their personal, safeguarded mag tapes they used to manage their work.

In subsequent jobs, I moved into other 3GL environments, still working largely without access to a customer or other developers. With regard to the development teams, the work was divided up by our manager who made decisions about what we should be doing, how it should be done, and when it should be completed. Our team meetings were weekly bug report meetings where our manager would prioritize what needed to be done and its due date. We passed work from one job title to another (analyst, to designer, to developer, to tester), and teamwork for me was largely restricted to one-on-one debugging sessions with another developer. But a change was beginning to unfold about how software development projects, their teams, and their managers could work more effectively.

I first dipped into the notion of a learning-oriented approach to software development via Wicked Problems, Righteous Solutions by Peter DeGrace and Leslie Hulet-Stahl (Prentice Hall, 1998). The book became my bible about what was wrong with phase-driven, waterfall approaches and what might be right about a more empirically motivated approach. My next epiphany came in the late 1990s with a visit to the UK where I learned of a new methodology being adopted in Europe: the Dynamic Systems Development Method, or DSDM. What was startling for me about this methodology at the time was its emphasis on timeboxes versus scope for software delivery. It turned my notion of software development methodology on its ear. Moreover, as documentation was de-emphasized, rapid effective face-to-face communication was explicitly built into the approach through its facilitated workshops.

At this point, I made a conscious decision to steer my methodology focus toward facilitation practices that I could apply to software development teams. Because I had seen too many examples of how teams can crumble in bad meeting contexts and in bad control environments, I wanted to learn ways to make all the various team collaborations more reliable, more frequent, faster, and more productive. I took classes in facilitation, read books on facilitation, and attended facilitation conferences. I became a certified professional facilitator, and I began to teach facilitation as well as apply it.

And I learned a few things: facilitation has a place in how we create teams and coax collaborative work from and for them. Additionally, I learned that facilitation is not about control or manipulation. Rather, it is about applying tools, techniques, and processes in support of teams eager to engage in high performance. Good facilitators listen and echo in a way that helps a team hear itself and apply its best wisdom. Project managers and software team leads with facilitative skills become leaders who can listen and echo as they lead teams in vision and success.

Today, I find myself in teams that create a common goal, work to communicate frequently, and make decisions based on their collective wisdom. The agile methodologies we now consult (Scrum, Extreme Programming, Crystal Clear, Feature Driven Development, and Lean Software Development) emphasize project success through disciplines of engineering and communications that can effectively respond to change. In these contexts, I recognize the stabilizing force of collaboration and communication as fundamental practices in project success. Projects need teams; teams need communication. And while communication comes in a variety of forms from one-on-one to very large groups, at the team level of three or more people making decisions and acting on them, communication relies on collaboration.

This book brings together my specific lessons about the importance of applying collaboration in teams. Specifically, it catalogues the practices of facilitation I have learned to use in order to liberate teams into a variety of information gathering and decision modes that promote high performance. I have come to rely on facilitation not as a manipulation or control technique, but rather as a way to encourage participatory decision making among teams of experts. For me, facilitation, more than any other leadership or team practice, has proven to be my greatest gift to teams in creating a vision for them and encouraging their best teamwork.

A number of colleagues have warned me about negative experiences they've endured where a facilitator has used his role in a meeting to manipulate and control the team. That is not my intent here. I believe in leaders who engage facilitatively in service to the team, not in control of it. I believe in teams who recognize the wisdom of a powerful leader and how such a leader's move through various decision approaches strengthens them. A good leader absorbs a rich set of tools in creating success with and for their teams. In this guidebook, I offer one subset of those tools, the facilitation tools.

© Copyright Pearson Education. All rights reserved.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 – 8 of 4 Customer Reviews
  • Anonymous

    Posted April 6, 2006

    Put some polish where it counts

    Jean Tabaka has done a great service to Software Development. The highest cost meetings where everyone is attendance can be at least twice as valuable when well run and Jean gives us some great guides to make these fruitful. This is especially true with Agile methods that recommends frequent time-boxed meetings to evaluate plans, inspect them and adapt to the changing conditions our fast-paced environments introduce. I have adopted many ideas and have found them very useful. Finally, this kind of skill is what many technically trained people need most for creating a truly collaborative environment.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted March 21, 2006

    Helpful for all project leaders wishing to avoid a command-and-control style

    A challenge faced by any project leader is how to lead the team without resorting to a command-and-control management style. This book¿s essential premise is that the project leader can do this by fostering collaboration among team members. Jean Tabaka¿s Collaboration Explained is really two books in one. The first explains the benefits of collaborating and why project leaders need to foster collaboration among their teams if those teams are to perform at a high level. The second, and by far longest, part of Collaboration Explained is a compendium of techniques that will foster team collaboration and will help the reader become a more collaborative leader. Any reader will finish this part having learned new techniques. Nominally this book is about team decision making and so most of the book is about the various decisions teams make and how the project leader can ensure that the team makes the best decision. Covered are decisions about project requirements, estimates, priorities, vision, resolving conflict and more. Tabaka provides both general purpose advice that can be used in many contexts as well as very specific advice for each of the contexts or meetings she describes. This book is well-placed in a series devoted to agile software development. However, it is important to point out that the techniques covered here will be applicable to any team with any development process. Any project leader who wants to help his or her team work better together will benefit from reading this book.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 29, 2006

    can use much of the book's advice in any development process

    Tabaka's book is part of an ongoing series on the use of the Agile software development process. It deals with a key idea of involving participants to the fullest extent. The word collaboration is used to describe this idea. The book is directed at someone who has to manage this process. Someone in a supervisory capacity. Though of course the book could be usefully read by anyone else involved. The book has many suggestions. About such tasks as conducting status meetings during the project. Or how to distinguish between a good meeting and a bad meeting. Or supervising small group work. The advice is entirely about the human element. And not about any specific software tools or languages. If you are a supervisor from a programming background, it could be the human element aspects that you are most in need of advice about. Naturally, the text also has numerous instances of how to deal with what it calls Agile Practices. Yet you might not need to adhere to the latter to still derive gain from the book. There is no need to buy into some or indeed any of the Agile Practices. Much of the book has useful advice (like the example above of the good and bad meetings) that is germane to whatever overarching development process you already have in place.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 20, 2011

    No text was provided for this review.

  • Anonymous

    Posted January 26, 2010

    No text was provided for this review.

  • Anonymous

    Posted December 31, 2009

    No text was provided for this review.

  • Anonymous

    Posted December 27, 2009

    No text was provided for this review.

  • Anonymous

    Posted January 6, 2010

    No text was provided for this review.

Sort by: Showing 1 – 8 of 4 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)