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.