Who hasn’t experienced the following scenario:

A project was canceled and suddenly you have a lot of people that need to be either relocated to other projects removed from the company.

The reason why this happens is that investment is attached to projects. Following the basic business logic projects are a way to convert some money into more money – or at least more money that other alternatives would generate.

As a result of the available funding teams are assembled to follow the project’s vision through and create something that will ultimately return multiple times the investment.

While I agree with the notion that businesses are there to make money I strongly believe that basing team coherence on the association with projects can be hazardous and costly for the company.

And here is why.

The Constant Reset

Based on Tuckman’s observations on team dynamics we know that teams are not simply created – they evolve over time. Going through the phases Forming, Storming, Norming, Performing (and Adjourning).

 Not surprisingly a team is most productive in it’s „Performing“ phase. Team members have gotten to know each other, working standards have been established and trust has been built. The team can focus on delivering.

Reaching the „Performing“ phase takes time – sometimes a lot more than six months. Now add to this fact projects that are the basis for the team’s existence. As soon as there is a change in the project – for example cost reductions leading to less head counts available – the team dynamic is disrupted. The team will most likely revert to an earlier stage such as Storming leading to conflict and severely reduced performance.

 Previously this was less of a problem as projects tended to run longer usually for years.

With the advent of Agile development we will (hopefully!) see smaller more nimble projects, coming to life and retiring in reaction to the business needs.

While this nimbleness will certainly bring with it a lot of benefits such as lowered monetary commitment and risk it also carries with it the cost of team coherence.

A team that is constantly being reassembled because it’s underlying project is frequently changing will rarely have the time to settle down and get to the „Performing“ stage.

The team dynamics will be constantly reset to their infancy.

The Cost of Constant Team Changes

With team members constantly having to go through the earlier stages of team development they are tied up getting their bearings and finding their spot inside the new team.

This takes away time and energy from their capability to perform the job they were hired for leading to decreased performance, lowered satisfaction with their job and in extreme cases even workplace aggression (See also: Workplace violence and workplace aggression / Baron, Neumann / 1996).

Another potential problem is the negative impact on the willingness and/or ability to form (professional) relationships with co-workers.

Just think about it: If you know already that all these other strangers on your team will be none of your concern in less than a year why bother getting to know them? Why spend the energy and time to socialize if you will have to go through the same steps again in the near future?

This problem is very similar to the one faced by children having to constantly relocate during their childhood ultimately being less capable of forming lasting relationships, having lower life satisfaction and expectancy (see also June 2010 issue of Journal of Personality and Social Psychology).

Both of these problems are amplified when the teams are not co-located.

Integrating remote workers is a challenge on it’s own.

Most literature focused on virtual teams will cover the feeling of isolation and lack of integration with the overall team. Why? Because these issues can be just as problematic as the ever-present challenge of effective communications. Many experienced leaders recommend overcoming these issues and creating a feeling of belonging by engaging the team members in conversation, getting to know them, listening and showing your appreciation for them not only as a professional worker but also as a human being.

 Now imagine having to go through this every few months – either as a leader or a professional.

 Taking into account the above effects of constant team changes can create a negative impact the on business in the form of lowered performance and employee satisfaction that quickly outweights the benefits of being able to reshape the team landscape in reaction to the market.

 Having said that – what can be done both reap all the rewards of being Agile and responsive while creating a pleasant work environment?

Fund Teams – Not Projects

Putting the money where the people are might sound obvious – but it’s quite a change from the existing funding approach.

The idea is based upon the thought that the workforce is to be considered well-trained and motivated and established teams are ready and willing to attack new projects. (If you are struggling with an unmotivated, unskilled workforce that is rejecting new projects you are having a completely different problem on your hands).

Instead of funding a project and stuffing people into it – fund a team!

The team knows it’s coherence will be respected and can spend the time and effort to get to and remain at the „Performing“ stage, creating strong bonds between each team member.

 Once you have a new project you now take a look at your available teams and assign the project to the most suitable team. That way your worry is less of getting people into funded projects but more a decision of which project to tackle first.

 Agile and Scrum support this notion with short-term commitments taken up by self-organized teams. This way you can quickly attempt a new project without having to factor in all of the team dynamics. If you are satisfied with the project – let it run. If not stop it and give the team another one of your ideas to chew on! Also with the underlying T-Shaped capability model you have (or can create) a workforce that is able to handle a variety of project types from day one instead of having to painstakingly assemble a collection of specialists by scouring other projects or waiting for resources to become available.

There are some drawbacks to this approach with the main one being that you can no longer easily tie expenses together with (future) income as the expenses are defined by the team while the income is a result of a project attempted.

Also the Product Owners / Program Managers are forced to be able to whip out a new project idea latest if an existing project does not seem to pan out. However I’d be wondering if that isn’t exactly the job these people are already doing.

The Bottom Line

Basing teams coherence on the existence and shape of their underlying projects can be hazardous for the business if projects are created/changed/retired in quick succession.

The adoption of Agile will (hopefully!) drastically increase the frequency at which projects are aligned with the market needs. This in turn increases the frequency at which projects and teams change.

This constant change prevents teams from performing optimally and can cause severe negative effects such as workplace aggressiveness, isolation and ultimately employee dissatisfaction.

To reap the rewards of Agile project management while creating a pleasant work environment the team coherence has to be decoupled from project assignments.

This is achieved by funding teams instead of projects.

The end result is a productive, satisfied workforce able to tackle new projects quickly.

This in turn gives you the freedom to start new, promising projects easily while making it less painful to retire failing ones.