My personal study of what makes successful teams, to which I’ve recently alluded, is ongoing. Most recently I came across the article “Project teams are not teams“, which seems to provide a pretty direct answer to the question I posit in the title of this post.
According to author Mendelt Siebenga,
Unfortunately many organizations do not really have teams. They assign people to projects instead. Part of the confusion about teams vs. projects is caused by the mistaken assumption that a group of people assigned to a project will work as a team. Unfortunately this is not the case, project teams don’t get the chance to behave like teams. Project teams are short-lived, they break up when the project is done or cancelled. They are volatile, people are pulled off the team when needed somewhere else. And often project-teams are unfocussed, older projects still need work so team members work on more than one project and are on more than one team.
It stands to reason that over the course of a single project a team may not have time to go through the evolutionary forming-storming-norming-performing process that, according to Tuckman’s model, is necessary for a team “to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results”. Of course, equating “project” with a relatively short period of time is debatable, too, but that’s a whole different discussion, and I do get his point.
Without some semblance of stability, culture, direction and goal, teams fail. In fact, they often implode. And yet, we in the software industry continue to call groups of people “teams” when they are at best, loosely grouped collections of individuals with similar skillsets working temporarily on a common project. … This is one of the gorillas in the room of current software methodology. … Stability is the critical component of the long term success of a software development team. Doing anything that undermines that stability contributes to the continued failures in software development that we keep trying to cure with a new methodology. A solid, stable, professional team can write software using any methodology. It’s only because we refuse that stability that we have to have silver bullet methodologies to try to cure so many of the symptoms of the disease.
The descriptions above lead me to think of the project-based team as more of a task force than a true team. The distinction being that a task force is, by definition, finite in scope and duration and is combined to complete a specific task or activity, whereas with a team you get that sense of duration – of growth and strengthening as a unit over time.
I can certainly appreciate views articulated in the articles I quoted above. In my experience I’ve seen instances where “task force”-type teams have been convened and then broken up after the project is released and a grace period for support is granted. In my estimation, some of these short-lived teams have been quite successful. By the same token, I can see where leaving the group together could have led to improved in efficiency and effectiveness over time.
There is certainly a different feel between knowing that, “hey, I have my role to play in this project and I’ll do it well. Nevermind that I don’t particularly like this developer guy. I won’t have to deal with him again for a while once this project is over” as opposed to, “you know, we’re in this for the long haul. I don’t particularly like the guy, but he is good at what he does and we’re all going to need to give a little to make this thing work.”
So, instead of answering questions, I know have a nice list of additional questions on what makes teams work. I’m going to list them below. I may post answers to some as I come across them, but I’d ask you to reply with your thoughts and experiences as well.
- What are some ways of managing the balance between allowing a team to stay together long enough to jel and truly perform, but not so long that they begin to stagnate/burn-out?
- What are some indicators that you may be reaching the point of needing to break up a team that has worked together well for quite a while?
- I understand that you might not always get the results of a “performing team” from a task force-type team, but to what degree is that lack compensated for by increased cross-pollination of personnel across groups?
- To what degree are people working in a small to mid-sized delivery organizations already a team, regardless of whether they are subdivided into smaller groups for particular tasks or projects? For example, even if I’m not working with all of the same individuals on every project, if I’m in an environment where I’ve worked with everyone several times and know I probably will again, don’t we realize many of the same benefits?
- How do companies in multi-project environments with personnel limitations maximize the benefits of team work even when some key personnel must work multiple projects at a time?
- Are project teams really that bad?
As with delivery methodology, I am sure the “right answers” are slightly different for each organization. The key is to find what works best in your situation and do it. The bottom line is that it is critical to combine people and personalities in ways that enable the organization to produce quality results as quickly as possible.
In the meantime, I’ll keep on reading. Keep an eye on this post for insightful replies, and I also may add some new questions and quotes on occasion.
How do companies in multi-project environments with personnel limitations maximize the benefits of team work even when some key personnel must work multiple projects at a time?
This is the situation that I work in and have found that the teams that have a structured and defined communication plan are much more able to focus and refocus from one thing to another. The relaity of multi-tasking team members is that there is a degree of difficulty in jumping from one thing to another and certain amount of ramp up time occurs when switchings gears. What proves to be helpful is coordinated communication, both verbal and written, that allows these resources to make the jump as smoothly as possible. This revolves around active and passive communication. Active involves pushing information to the multi-taskers to keep them updated on the critical things that they will need to address. Communication of expectations, needs, direction, and other things that the team is dependent on them to do is critical., as these are the actions that they can attend to from a running start. Passive communication is generally a notification of statuses and other updates, as well as direction to "go here for for more information", which can direct themto documentation and diagrams to help them stay updated.
Are project teams really that bad?
I think that project teams are fine, and I understand the value of keeping teams together to enhance cohesiveness and the like. I think, though, that I'm more of a fan of task force type teams, especially when the resources on them are all part of a larger group that works on the full spread of projects. In these situations, there's always some sort of a running overlap of knowledge building as personnel move from one project to the next while under the same overall umbrella. So for me, task force teams tend to be more focused, less complacent due to stagnation, time and comfort and more sensitive to the things that are not in place, like specific knowledge that must be acquired to get something accomplished. Just a personal opinion.
What are some indicators that you may be reaching the point of needing to break up a team that has worked together well for quite a while?
I would look for patterns of failure or partial failure like missed milestones, poor time and organizational management, scope creep, verbal bantering and bad attitudes.
Thanks Jonathan
DougGtheBA