Group Coherence for Project Teams - Common Purpose

However, the reality at many companies is such that the teams' Agile methods are threatened or not adequately supported at the enterprise level. Rather than developing and strengthening the shared sense of Common Purpose, many basic group decisions are made by individuals in other parts of the organization and delivered to the project team.

"In the traditional model we leave the interpretation of data to senior or expert people. A few people, charged with interpreting the data, observe only a few of the potentialities contained within that data. How often do we think about all the data that goes unnoticed because we rely on these solitary [isolated] observations?"

Margaret Wheatley (1999, p.66).

We believe group decisions are hard to make because we are not trained to reach them. We engineer our organizations hierarchically to provide single-point accountability at every node. Thus, group decisions and consensus are optional or not visible. Many organizations amplify this by focusing their bonus schemes on individuals rather than teams. This creates an incentive for critical decisions to be made by individuals without involving their teams despite having centuries of collective relevant experience at their disposal.

Mapping Group Coherence to the Enterprise
We defined Group Coherence in our previous 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. The following table recaps the interdependent instances of Group Coherence, their types and their mapping to associated enterprise decisions.

The first decision above, the vision, is normally set at the executive level. For decision two, senior management is brought in to define the optimal enterprise project portfolio. For number three, the process methodology is often defined by the project manager or approved by an enterprise PMO.

Finally, for project implementation, Agile teams include representatives from each functional silo which helps the group to develop its Common Purpose. This creates an opportunity for the fourth type of Group Coherence to occur. The other Group Coherence types are generally unavailable to project teams operating in hierarchical organizations.

Table 2 reflects this reality at many companies, and shows where in the organization these enterprise decisions are typically made.

We believe that our knowledge about Group Coherence can help us to improve on this common reality.

In enterprise decision number one, full enterprise participation in determining direction could setup the coherence of the organization at every level. We are otherwise handing our project teams a vision they haven't bought into, and expecting them to get behind it and execute on it. They haven't developed their Common Purpose from the enterprise vision.

In enterprise decision number two, once the vision is set, people are assigned to projects rather than asked as a group to participate in self-selection of both the projects and of the teams. The enterprise community could select projects the group felt capable of delivering or that the group found suitably challenging.

With Agile methods, assignment of work within the project team is unnecessary because individuals or pairs volunteer to do individual tasks. Extending this approach to the enterprise, there is a higher chance of success when a group chooses the project than when the project is chosen for the group.

In enterprise decision number three, the best action for the enterprise is to make the training and support available to its project teams, as well as create the framework for continuous process improvement and learning across teams. Project teams are instead often limited by a requirement to adhere to a prescribed and "approved" set of methodologies.

Project teams lose out on the opportunity to experience Group Coherence of these three types because the responsible parts of the organization reach those decisions in isolation. Like the Group Coherence types, the four enterprise decisions are interdependent. Through participation in these decisions, an enterprise Common Purpose is developed and the project team would enhance its ability to deliver an appropriate implementation.

The element that is missing in order to reach a completely coherent enterprise, is Practice at every level. The Group Coherence research shows us the importance of Practice in reaching group decisions. Practice was the only ingredient that was connected to and in support of every other ingredient in the Group Coherence research.

Practice
The ability to identify difference and learn through attentive repetition, either for individuals or groups, is a simplified description of Practice. Through Practice we can get a feel for the contextual application of knowledge, rather than the acquisition of individual techniques.

Commuting by car to a new job serves as an example of an individual's use of Practice. Each day the driver can learn about traffic patterns along the route from day to day, changes brought about by the weather and effects of periodic events outside of the immediate route. Over time these add to the driver's ability to deal with change in the journey and to commute more effectively. Practice is the mindful comparison of experiences that introduces improvement over time in a particular task or action.

Practice in a group helps to create a collaborative product. This Practice at the group level requires participation of all the members to understand and create a product consistent with the group's Common Purpose. For example, the recording process of a professional jazz group illustrates the playful interaction among technically proficient group members. The group product is the music they produce. In their shared Practice to create music, Group Coherence can occur.

Group Practice in the enterprise would involve the project team in the entire organizational decision-making process to bring the full experiential abilities of the group members into the group's product. Enterprise Practice means replacing the "?"s with "X"s, giving the project team participation in all four enterprise decision types in Table 2.

Enterprise Common Purpose
Most projects require integration with participants from the right side of Table 2. In A Spaghetti Dinner from Peopleware, DeMarco and Lister describe how a new project manager invites her team to her house shortly before the project begins. Her intention is for everyone to rally around a common challenge - making the dinner collaboratively!

Although the dinner is a group product that enables the group to start to Practice together, it does not represent a deliverable consistent with the Enterprise Common Purpose. Social "jelling" does not compensate for the lack of Practice in previous enterprise decision-making which still affects the group when performing the implementation work.

Agile methods help to replace silo definitions of functional success with a sense of purpose, which the project team shares for each implementation. Agile project team decisions incorporate group members from the right side of Table 2. This allows the project team to collaboratively develop a shared definition of "done" through Practice.

Without this group definition, every functional team optimizes for not being the team to blame for failure, rather than optimizing for the project's success. A silo environment makes it possible for someone else's failure to contribute to your own success.

The Practice in making decisions on the left side of Table 2 provides opportunities for Group Coherence for the designated participants but not for the project team unless they are included. To prevent this silo effect, an enterprise definition of "done" needs to be developed with participation by the project team. Enterprise Practice gives the team experience and information that guides them throughout the life of the project, improving their judgment to the point where they can make the right decisions with little or no oversight.

Achieving this might be possible through self-organization into non-hierarchical structures such as enterprise communities. This would allow decisions to be made by groups in a safe environment where everyone can have access to Group Coherence and a shared Enterprise Common Purpose.

Enterprise Management by Communities
Tacit Knowledge is an elite global Agile consultancy founded in the Bay Area in 2002. They are experimenting with what could ultimately be defined as enterprise management by communities.

Chris Andrasick, CEO and founding partner, shares the principles in his public blog post "Empowering the Karaas". Chris describes how his company "needed to support communities in places where a nexus between company strategic goals and a pervasive human interest existed - then get out of the way". He defines eight components to shape and empower the communities, which we summarize as:

1. Common interest

2. A mission statement established through consensus

3. Rules for consensus-based decision making

4. Principles for self-organizing

5. Rewards by valued contributions to the community

6. Enterprise 2.0 Collaboration Tools

7. Frequent but sustainable meetups

8. Shared content

 Their approach could create a large number of opportunities for employees to experience different types of Group Coherence in the context of the successes of each community. While initially many of these successes might not have a direct link to company results, they will provide Practice so employees can achieve success together on anything they agree to take on. As employees get familiar with the experience of shared success, they will seek to repeat it more frequently and get better at learning from Practice.

Eventually a community success will be aligned with a corporate goal or obstacle. At Tacit, a group of employees with a shared interest and skills in solving technical operational problems created an informal yet highly responsive technical support function at no cost to the company. Together they responded to requests for new hardware, enterprise software and support. Shortly thereafter they setup an internal mechanism called "Operator" to answer formal requests.

This informal group of people is a community with its own set of values and principles and takes pride its success. No executive needed to get involved to set up a service agreement, to schedule work, to agree to shifts or prioritize the work. It just happens.

This community first experienced all four types of Group Coherence in the context of creating "Operator". Shared success has earned that community a level of trust within the enterprise to participate in the full decision-making process. They can now participate in all four types of enterprise decisions for their projects, making Group Coherence available to them at all four levels.

Conclusion
Agile methods include participants on the right side of table 2 in the definition of project team. We suggest that it is also necessary to create participation of this project team in the decisions traditionally made on the left side of the table. Managers and executives shouldn't make decisions in isolation from the people doing the work.

In the process of making their own choices on enterprise decisions, the group is far more likely to learn about the project, to improve on its starting definition, to have a strong personal attachment to its success and to embrace the changes that inevitably occur during the execution of complex projects. Decision-making through Enterprise Practice thus creates a strong sense of Common Purpose.

Management by Communities is one possible approach to reversing the consequences of fragmentation in our organizations. Other collaborative approaches and tools will be discussed in future posts.

Book References

• Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams - 2^nd ed., New York, Dorset House Publishing Co., Inc., 1999.
• Margaret Wheatley, Leadership and the New Science, San Francisco, California, Berrett-Koehler Publishers, Inc., 1999.

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.

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.