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.
Comments