Organizations avoid team measures and rewards because it is easer to measure individual activity and achievement. A cultural clash is created where team action is the solution but rewards are only available to individuals. Where team members each have accountability for a different project, pairing with others reduces time spent on advancing one's own goals. Helping you hurts me. Focusing on team results we choose collaboration over competition and avoid this conflict.

"What must we do that is:

- bigger than any of us,

- requires all of us, and

- none of us can claim victory until we are done?"

Teamwork Is An Individual Skill: How to Build Any Team Any Time - Christopher Avery, QConSF2008

Agile methods promote collaboration, transparency and trust at the group level. They create a safe environment for individuals to volunteer their effort rather than have work assigned to them. In this post we discuss how Agile adoption is made harder to achieve in organizations that emphasize individual rewards over team incentives. We also identify some possible obstacles to collaboration and a group method for collaborative continuous improvement that was used by the Group Coherence research team.

Rewarding Individuals Stifles Collaboration
In hierarchical organizations the ‘org chart' is one of two operating hierarchies. The second one is invisible; a functional hierarchy of how things are actually accomplished in the organization. If only individual performance measures drive rewards, participants will use the functional hierarchy that appears in the "organizational white space" (DeMarco, 1999, p. 214) to accomplish individual goals first and team results second.

Even when the project would not have completed successfully without the efforts of all of the participants, the contributions of one person, a leader, a hero, or a small number of individuals get special recognition. This fosters cultural behavior of competition rather than collaboration and makes it possible for someone else's failure to lead to your success.

Companies try to address these symptoms or dysfunctions by introducing objectives for achieving a required level of collaboration. Objectives about how much to collaborate aren't credible in an environment that measures only the individual. Sustaining collaboration requires team participation and results. Managers trying to attribute results to individual achievers sabotage the collaborative process.

Identifying Obstacles to Collaboration
Managers have to deal with many built-in resistances to collaboration. In one of our teams (let's call them Team-K) most members had prior experience with Agile methods and they were in agreement on the positive influence of collaboration to team productivity. However, collaboration rates were extremely low.

Over the course of two years, Team-K had been suffering the fate of the metaphorical "slow boiling frog". This led to the team starting to disintegrate. We list some of the factors involved in Table 1:

Managers observed the absence of collaboration and deteriorating team performance, but their relationship to the above constraints was invisible to them.

These obstacles affected both intra- and inter-team collaboration, and held back Agile adoption.

Intra-team Collaboration
Pair programming had been elusive to the team for a couple of years, a symptom the managers could observe. During this time developers' private objectives listed pairing targets but the reality never moved significantly away from zero. The obstacles in Table 1 removed credibility from an annual performance objective such as "20% pair programming."

Performance objectives, incentives and directives assigned to each Individual cannot engender collaborative activities in a team. Even if such an objective got two people to share a keyboard, this does not constitute pair programming by itself and it is likely that the individuals could achieve more on their own. As the two developers start to reasonably detect the waste inherent in their activity, they will shift back to working on their own.

Teams new to Agile are more likely to continue with their activities largely unchanged despite the directives. Additionally, the potential "sum of the parts" benefit from pair programming can be hard to sell in an environment that only measures the individual and does not value team metrics.

State Shift
As with the pairing example, Collaborative Interaction either happens or it doesn't. This was just the experience of Team-K. When they removed the obstacles to their collaboration, pairing started to happen all the time. In the process they experienced Group Coherence, which we defined in our first post as the shared state reached by a group of people that allows them to perform one or more tasks in perfect rhythm and harmony with great energy to overcome obstacles. More seasoned Agile teams are likely to pair irrespective of any directive because they have coherent experience they can draw from.

In the same way that water can become vapor or ice at specific temperatures, so too can a group operate at a visibly different level as a result of a complex set of conditions in their environment. The Group Coherence research team named this sudden transition State Shift. It was one of five key ingredients that they felt would be always present when Group Coherence occurred.

State Shift and Group Coherence were illustrated on a beach at Cape Cod when the tide came in around a hill of sand until it became an island. Joe, Joanna's yoga teacher, sat on his dry towel on the hill as the water continued to rise. Group Coherence is accompanied by State Shift, which appears just the way the tide infused the towel, suddenly and completely (dry to wet).

Team-K
César recalls the moment of Group Coherence accompanied by State Shift in collaboration that occurred in Team-K:

"The members wanted Team-K to be Agile but there was no collaboration. Lack of pairing was the most obvious symptom of this problem. How could our actions be so different from the behavior we aspired to? We tried addressing things under our immediate control like the terrible ergonomics, but because they made no difference, we undid the changes.

I setup meetings with other developers to discuss our own problems rather than blame the hierarchy for not solving them for us. We identified obstacles to our performance [resulting in the list in Table 1 above]. We implemented process changes that didn't require management permission.

Each individual shared his or her project/s with the group and as a community we ranked them in order of importance. This allowed the community to self-organize and collaborate on the most important one. While such changes improved morale our performance did not improve as much as we had expected and pairing was still virtually nonexistent. We continued to implement subsequent changes in short cycles, acting and observing the effects of what we had done.

Then we looked at our work environment again. We changed the desk layouts, lowered our armrests and threw the drawers out like we did before, but this time suddenly everyone was pairing all the time. It was like watching ice turn instantly into vapor. We later made ourselves into the only team around us that wrote every line of code in pairs or even trios and our productivity skyrocketed - but that's another story..."

Team-K also started to communicate with the project sponsors as a community [#7]. By taking ownership of their own lack of collaboration, they removed the inertia [Obstacle #8]. By contributing their projects to the community, they were no longer isolated developers [#2]. Taking responsibility for the best outcome for the team moved the emphasis away from personal accountability [#1, #5]. They recognized that by delivering the critical projects as a community [#6], they would each individually enjoy the most success [#3, #4]. Team-K thus became a hyper-productive team.

The obstacles in Table 1 also affect the interaction between teams. Agile adoption in an enterprise is compromised by an environment where functional teams optimize for avoiding blame, rather than collaborate for project success.

Embracing a spirit of continuous improvement made a big difference in the Collaborative Interaction results achieved by Team-K. There is a group method for collaborative continuous improvement, which can bring structure to teams' collaborative endeavors.

Cooperative Inquiry

Elssamadisy (2007, p. 42).

This emphasis on learning from experience is a fundamental tenet of Cooperative Inquiry, the qualitative group research method created by John Heron and used in the Group Coherence research.

Cooperative Inquiry is carried out by a group of participants who inquire into their own experience to learn about a question that the group has formulated. It "involves two or more people researching a topic through their own experience of it, using a series of cycles in which they move between [their] experience and reflecting together on it. Each person is co-subject in the experience phases and co-researcher in the reflection phases" (Heron, 1996, p. 1)

As co-inquirers move through cycles of action and reflection, they use four ways of knowing to transform their direct experience into new knowledge and skills.

Figure 1: Multiple Ways of Knowing

Heron defines the four ways of knowing thus:

"Experiential knowing is evident when we meet and feel the presence of some energy, entity, person, place or thing. Presentational knowing is evident in our intuitive grasp of the significance of imaginal patterns as expressed in graphic, plastic, moving, musical and verbal art forms. Propositional knowing is expressed in intellectual statements, both verbal and numeric, organized in ways that do not infringe the rules of logic and evidence. Practical knowing is evident in knowing how to exercise a skill." (1996, p. 33)

The topic of the inquiry, taken through research cycles by the members of the group, builds on their knowledge through Practice (previous post). Eventually the four ways of knowing, by providing differing perspectives on the research question, offer emergent congruent knowledge. This increases a team's ability to reach Group Coherence and completes the Cooperative Inquiry. Outcomes in Cooperative Inquiry provide a group with a "knack," a practical ability that restarts the cycle of continuous improvement.

Conclusion
Increasing the opportunities for participation within the project team is a necessary but not sufficient condition for achieving Collaborative Interaction. Critical obstacles to collaboration must also be addressed. Team-K did this in cycles of continuous improvement, an emerging Collaborative Interaction resulting in a hyper-productive team.

Collaborative skills are not imparted during formal education, so attention to group and collaboration techniques such as Cooperative Inquiry is required. This tool can help increase the successful adoption of collaborative methods. Cooperative Inquiry applies to any group that wishes to leverage its experience for a practical result. It can help groups to become more collaborative by providing a methodology that they can follow as the group works on a practical problem.

Cooperative Inquiry can be taught and applied at both the enterprise and team level. All four types of Group Coherence in the enterprise can be approached this way.

Agile development is a good fit for utilizing Cooperative Inquiry as participation by all members is a principle of both. With obvious parallels to short iterations, transparency, inclusion, visual charts, retrospectives and continuous improvement, this tool can help different parts of the organization integrate with the rhythm and methods of Agile teams.

Book References

• Amr Elssamadisy, Patterns of Agile Practice Adoption, C4Media
• Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams - 2nd ed., New York, Dorset House Publishing Co., Inc., 1999.
• John Heron, Co-operative Inquiry: Research into the Human Condition, London, Sage Publications, 1996

About the Authors

This post was written collaboratively by Joanna Zweig and César Idrovo.

Joanna Zweig holds a Ph.D. in Integral Studies with an emphasis on Learning and Change in Human Systems (how groups learn and Change) from California Institute of Integral Studies in San Francisco, California and a Project management Institute (PMI) Project Management Professional (PMP) certification. Her research on Group Coherence was motivated by her practical experience in two collaborative professional fields where groups exceeded expectations and experienced enormous energy and success in their goals. She is a project manager in information technology in large businesses for more than 15 years and a producer and director of theatrical productions for more than 20 years. Her passion for collaboration in creative groups helped her to formulate the idea of group coherence and carry out her four-year research project to find out about it. Her research on group coherence revealed a way to learn about capabilities of collective consciousness. She is currently an independent consultant and CEO of Integral System Response, Inc. http://www.groupcoherence.com

César Idrovo created his first hyper-productive team at JPMorgan London during 2000, in response to strong demand for his own work. He recruited a highly heterogeneous group and implemented "continuous collaboration" to achieve high team cohesion and tangible results. In several instances, his team's tactical solutions were adopted as strategic implementations and are still in use today. From 2003 he has focused on formal Agile methodologies and adaptability to high rates of change in requirements, creating further hyper-productive teams. As a project and program manager, he has applied Scrum for managing, tracking, and delivering working software in time-boxed iterations and introduced Extreme Programming including 100% pair programming. He has worked on practical complementary techniques to Agile practices for management and executive levels such as Project Patterns and Adaptive Roadmap.