One of the main reasons Agile software development is so popular - maybe even the main reason - is that there are many reports from the field about hyper-productivity. Teams that have built software and released without ever having one bug go out to the customer and others that have reduced their time to market to just a fraction of what it was before. Joanna Zweig and Cesar Idrovo have written four articles describing Group Coherence, their theory of how hyper-productive teams work:
- Group Coherence for Project Teams - A Search for Hyper-Productivity
- Group Coherence for Project Teams - Common Purpose
- Group Coherence for Project Teams - Collaborative Interaction and
- Group Coherence for Project Teams – Group Creativity .
They start out the series by pointing out a short-coming of the way we currently work:
Group characteristics and group dynamics are invisible to most of us. We are not trained to detect them, let alone manage them. Our work is influenced by much more than what we see. This can make project success (and failure) sometimes appear to be random.
If you ask a project manager to give you a summary of the state of their project you would reasonably expect the answer to include several metrics. In some cases that might be all you get, or all you feel you need to hear. The bias towards the quantitative is quite prevalent in our projects and in our lives.
The tools and training to identify and analyze qualitative input are a lot less developed. Even project management methodologies that practitioners don't consider "traditional" have only started to scratch the surface of the human aspects of our work.
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. The quantitative voice might quickly suggest "hindsight is always 20:20". However, it seems that the ones that experience the strongest success or achieve hyper-productivity are often the ones that also have qualitative observations. We think exploring qualitative research methods can provide a source of rich learning about teams.
We want to share new research and the insight it offers to project teams.
With that introduction, they define group coherence, what it is, and why it is important in the first article, and in each subsequent article they dig in to one of the aspects of group coherence.
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. This simplistic interpretation is a starting point for discussion and we acknowledge that it doesn't begin to do justice to all the interdisciplinary components of Group Coherence that include behavioral, psychological, spiritual and sociological.
In reality Group Coherence is a more elusive concept than one would imagine. Indeed during their research Joanna and her group overlooked Group Coherence, seeing only a great meeting or experience rather than a shift at the group level.
In each of the later three articles, they dig deep into one aspect that enables a team to reach hyper-productivty. In Group Coherence for Project Teams - Common Purpose:
In our continuing search for Hyper-Productivity, we have observed that a strong and highly adaptable shared sense of Common Purpose can increase the group's ability to execute on the project vision or enterprise strategy.
Agile teams apply several methods that support this. They self-organize around a common goal agreed with the customer. This goal is most often embodied in the set of stories or tasks to be included in the next iteration. A shared definition of "done," a "living" and dynamic backlog and an involved customer all help to remove ambiguity around the goal and keep each iteration adaptable to inevitable changes.
And in Group Coherence for Project Teams - Collaborative Interaction:
The hyper-productive teams we have observed apply high rates of practical collaboration. We believe that fostering Collaborative Interaction leads to increases in productivity, yet performance is recognized at the individual rather than team level. In environments where collaboration is required, managers should avoid assigning project work and accountability to individuals. Inappropriate rewards for individuals are additional distractions from their collaborative project duties.
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.
And finally, in Group Coherence for Project Teams – Group Creativity:
Creative achievement is typically associated with individual effort. Think of Newton, Edison, or Leonardo Da Vinci. Until not very long ago, creativity and design were the focus of a few, while the work of the masses was broken down into repeatable steps. Creativity was perceived to undermine the result of mass-production.
Today, the work depends on the design and creative skills of the knowledge workers that perform it. In this post, we explore the different ways in which Agile methods foster individual creativity and allow for something far less commonly acknowledged: group creativity. We discuss four attenuators and five amplifiers of group creative activity.
Joanna and Cesar do not claim to have a step-by-step method of creating hyper-productive teams, but they do point out the attributes that hyper-productive teams exhibit and tell us that these are necessary for the creation of such teams. They also give us guidelines on how to change the way to work in the hopes that mimicking the attributes of hyper-productive teams will lead to hyper-productivity. Their work also resonates with Christopher Avery's well-known work on effective teams which we have reported on at InfoQ in Touchy-Feely Impediments to Agile Adoption and Responsibility, Personal Agility, and Other Touchy-Feely Ideas. Does this work resonate with your experience?