We decided to create a workshop on Group Coherence to offer an extension of the learning that we are writing about. We have proposed it to Agile 2009 in order to create an opportunity for group Practice in the Agile community. In this article we describe the structure of the workshop to share a step-by-step method you can Practice with your teams. A way in which one could come to feel Group Coherence through experience is to introduce the topic through focused discussions about your team's perceived ingredients of Group Coherence and relate them to Agile principles.

First it might help to review a few terms. We have already offered a simplified definition of Practice in our second article in this series, Group Coherence for Project Teams - Common Purpose: "The ability to identify difference and learn through attentive repetition, either for individuals or groups... Through Practice we can get a feel for the contextual application of knowledge, rather than the acquisition of individual techniques."

The basic structure of our workshop is Cooperative Inquiry, a qualitative research method. We recommend you also consider using Cooperative Inquiry in your session because of the obvious parallels with Agile methods. We discussed this structure in our third article: Group Coherence for Project Teams - Collaborative Interaction

"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 the congruence among four ways of knowing [Experiential, Presentational, Propositional, and Practical] to transform their direct experience into new knowledge and skills. An Agile team might call these iterations and retrospectives."

This structure can help you conduct a series of exercises, each followed by an opportunity to make meaning of the experience. This toggle between action and reflection is congruent with the pursuit of experience of Group Coherence and helps associate Group Coherence with Agile principles.

We have prepared six possible cycles of action and reflection about Group Coherence and its relationship to Agile principles, presented in Table 1 below.

Table 1 - Group Coherence Practice Cycles

Cycle 1: You may already have experienced Group Coherence
To help setup the group session and make the learning process personal, the first cycle is an opportunity to identify past experiences of Group Coherence and evoke the feelings from the experience. In our first article we provided a definition you could use to get the session started:

"Group Coherence is 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."

Group Coherence appears to be a common phenomenon because people need very little introduction or description in order to recall an instance from their own experience. This is why one of the key ingredients of Group Coherence is Perception of Group Coherence. We introduced it in our first article in the series: Group Coherence for Project Teams - A Search for Hyper-Productivity. You might also share with participants some of the ways you have perceived Group Coherence.

Participants may associate the definition of Group Coherence with a former team with which they experienced the strongest hyper-productivity, deepest bonding, or most fun. There may be many types of Group Coherence, including some we mentioned in our article on common purpose:

1. Taking part in setting the enterprise direction or vision
2. Taking part in identifying a project or project portfolio
3. Helping select process methodologies to use in the group's own project execution
4. Taking part in project implementation or solution within a self-directed and/or self-organized team

All of these require group participation for the opportunity of Group Coherence to emerge.

Cycle 2: Ingredients of Group Coherence
The subsequent cycles in the workshop are focused through discussions about the ingredients of Group Coherence to provide participants with a way to communicate about their experiences. Once the group is aware of each other's instances of Group Coherence, you can continue to explore ingredients as they interact in coherent groups. A brief introduction to ingredients is useful to get cycle 2 started:

"It is curious that at the end of a project - once the measuring stops - teams can typically describe qualitative factors that influenced their ability to deliver the project... Among the seventeen [ingredients identified by the research] were five... they considered to be "key" because the group felt that these ingredients would be present in every type of Group Coherence:

1. Relationship between Individual and Shared Creativity: individual creativity contributing to group creativity.

2. State Shift: change in energetic level (like water to steam or water to ice)

3. Bonded State: individual group members bonded but everyone had bonded when Group Coherence occurred.

4. Fugue: acceleration of the group members' activity and interactions producing great increases in group energy.

5. Perception of Group Coherence: awareness of Group Coherence.

This second cycle is about identifying the ingredients present at the time when they believe Group Coherence took place. Participants can write the names of their own perceived qualitative ingredients on post-it notes and share brief descriptions of each with the group. An Agile team might associate Group Coherence with the moment when they finally got a product owner to sit in the team room with them, or when they started to take pair programming seriously. While this association may be correct, the discussion should include all the other activities that were likely going on at the same time. You should also challenge them to come up with group behavioral and qualitative ingredients rather than name the practices and principles being supported by those ingredients.

Cycle 3: Evolution
Next, participants reflect on the overlaps, differences and interactions among the ingredients and draw them. For example, if the drawing reflects a timeline, participants should place the ingredient post-it notes from cycle 2 on the relative point in time on the project where they think they perceived the ingredient to be present. In the previous cycle the focus was on the moment when Group Coherence was experienced or perceived. In this cycle, participants consider how the ingredients were manifested to the group, when they started and where they might have come from.

One common depiction of the evolution of ingredients is to show amplified or attenuated effects over time. Take Chaos as an example ingredient of what the group might come up with. Perhaps there was a point when Chaos was not a tolerated ingredient in the team, and around the time when Group Coherence was perceived the level of Chaos was at its peak. Collaborative interaction may have been evident by this time but perhaps its origin might be shown shortly after to the group agreed to take collective ownership for all their work. The evolution of a few ingredients is illustrated on Figure 1 below.

Figure 1 - Sample illustration of ingredients and obstacles on post-it notes and evolution annotation on a whiteboard

The sort of questions you might hear the group asking are: "what needed to happen for this ingredient to appear?" or "when did this ingredient plateau?"

Cycle 4: Obstacles
After the group shares its representation of ingredients associated with Group Coherence, in cycle 4 they can undertake a discussion of obstacles that get in the way of Group Coherence. It might be useful to read our article on collaborative interaction where we discuss how Team K identified group collaboration as an ingredient whose absence was caused by at least eight obstacles. Among these were: focus on personal accountability, assignment of individual rather than group projects and lack of team incentives and rewards.

Participants may choose to add obstacles to the drawing. The focus is on obstacles to Group Coherence rather than ingredients because each obstacle may affect several ingredients. Team K might depict the focus on personal accountability on the drawing as a constant that disappears the day they decided to unite efforts as a team and be collectively accountable for all their work. The sort of questions that might appear during the discussion are: "how could we have removed this obstacle earlier?" or even "why are we not doing anything about this persistent obstacle?"

Cycle 5: Associating Group Coherence with Agile principles
If the Agile principles have not been featured already in the cycles so far, ask participants to make an explicit association from the ingredients of Group Coherence to each principle, and to reflect this on their ingredient interaction charts. Even practicing Agile groups may find it useful to have a quick review of the Agile Manifesto first or to have a cheat-sheet available for reference.

For groups that are not developing software, this may require a session about capturing the spirit of each Agile principle and adapting the language to the activity of the group. In doing so, the group will be acknowledging and agreeing upon what they perceive to be their highest priority, what their primary measure of progress is, etc. Such a session on its own may be an opportunity for Group Coherence to emerge.

Using the earlier example, a team that recognizes "assignment of individual projects" as an obstacle may associate it with the Agile principle: "Business people and developers must work together daily throughout the project." The discussion might revolve around how they can expect to work with the business people daily when having separate projects means they don't even really work with one another daily.

Cycle 6: Group Retrospective
Finally participants can reflect and build further learning that may be instructive for Agile teams. Cycle 6 can take the form of a familiar retrospective and should allow them to share and consolidate their learning from the entire session. Also ask "What would you do differently (at work, at home, implementing Agile...)?"

"What do you value most/least after this exercise?" Focus on actions to be applied in a practical mode to improve their own teams' abilities.

Thus, their ‘homework' starts another cycle of inquiry in action.

At the time of writing our workshop is being considered for inclusion in the Manifesting Agility stage of Agile 2009. If you'd like to read more about it you can find it under the title When Agile Just Works - Exploring Group Coherence. We hope to see you there.

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.

He also blogs at Nonlinear Enterprise where he is starting to exploring creative ways for large companies to deal with nonlinear behavior - and at times potentially explosive behavior - without losing the required adaptability to rapidly changing market conditions.

In 2008 he has given over 50% of his time to nonprofit initiatives, focusing mainly on BayAPLN.org, chartered for community research and education. It creates, fosters and supports a learning community of Agile leaders in the Bay Area. He contributes as a Community Builder, Organizer and Connector.

He holds a Masters in Engineering from Imperial College London and a Masters in Finance from London Business School.

Comments (0)

Write comment

Show/hide comment form