Bring the work to the team, not the other way around.

This is the main concept behind “standing teams”, and there are certainly merits worth considering behind it. I’ve been part of many teams over my career as a software developer, including one which ended up becoming a standing team for a few projects. Having said that I have some observations on the the merits of standing teams, both positive and negative, that I’d like to share.

Before diving into standing teams however, let’s take a step back and talk about how teams are most often formed and some of the effects of this model.

The “Standard Model”

Frequently, when a new project is identified, prioritized, and finally green-lit a team of individuals is gathered and formed specifically for that project. That is, the project is created first, followed by the creation of the team, which I’ll refer to here as the “Standard Model”. Most of the time this involves scouring the region for available contractors who have the skillsets required by the project, or if is it an in-house project, pulling individuals from other projects and putting them all together for the new effort.

Once the team has been assembled a period of time follows in which the members of the team learn about the project, each other, and how they’ll work together to deliver the project. This is frequently referred to as “Forming, Storming, Norming, and Performing”.

The first three phases of team development can often be turbulent, as people who haven’t worked together previously learn the dynamics of the new group and the project domain, and the team velocity may not be consistent. Once the team hits the “Performing” phase of its development velocity tends to increase and become more consistent, until it eventually levels out and becomes somewhat predictable. This is of course the goal, as project leadership needs a way to provide some kind of estimate for how long it will take to complete and deliver features.

The Standing Team

The Standard Model has been around since the dawn of software development, and it is still used today for a variety of reasons, some more dubious than others. One thing people noticed about this model however, is the aforementioned turbulence of the team forming, storming, and norming. “Rather than undergoing that turbulence on every project”, they said, “wouldn’t it be great if we could skip straight to performing?”

One way to accomplish this is to keep the team together from one project to the next. When one project is completed the entire team simply begins the next one together. No need to break up an already performing team, no need to spend time and effort building a new team. With this model, the idea is that the team will already have formed, stormed, and normed, and so they can move straight into performing on the new project.

Pros

There are definite benefits to this model that can make it appealing, especially for members who are looking for some stability, and for project leaders who want high performing teams right out of the gate.

  • Forming, Storming, Norming: Been There, Done That: This one definitely has value; a team that moves to a new project together already knows how to work together. In my experience on a standing team we were able to skip the usual hiccups in personality conflicts, disagreements on style and approach, and adjustments to our roles. We had worked together for so long that these were simply not issues anymore. Even better, we got along well and enjoyed working together. All of this combined to make us a tight-nit, functioning team.
  • Hit the Ground Running: Given that we knew how to get the work done we were able to focus on the problem at hand and ramp up quickly, even though the domain was different from our previous project. In fact, in one engagement our new Product Owner was amazed to see how quickly we were able to break down work, estimate, and implement user stories. Having worked together already we knew how to go about our business and could focus on delivery.
  • Skillsets are a Known Quantity: Due to our long association there was no question about what everyone on the team was good at. We knew what we knew, and what we didn’t know. We also knew that certain individuals were better at some tasks, and to pair with them when that focus was needed. Need a focus on front-end? Pair with Cory. Need to crank up velocity? Pair with Jonathan. Need an assessment of the architecture and its pitfalls? Talk to John. Need to figure out how to test something? I’m your guy. Because we paired everyone also started improving in these areas as our knowledge was shared around.

Cons

The Standing Team model is not without its downsides, and unfortunately they were less than obvious.

  • Welcome to the echo chamber: After working with the same team for a while you start looking at problems with a similar lens. This is fine in terms of methodology and style, but less than ideal when tackling new problems in new domains.

    It turns out that introducing new members to the team is important for many of the same reasons that diversity in the workplace is important; different backgrounds and experiences make for more creative teams with more and different ideas, and a generally richer team experience.

    As an example of this, when our team moved from a project with an agricultural and hardware focus to one more focused on search and big data we stumbled and had to learn how to adjust in this world. At one point two members left the team, and one of the incoming replacements had experience in big data. He brought a wealth of knowledge to the table, and this provided a significant boost in our ability to tackle this new domain.
  • Everyone is An Expert or No One Is: This is the flip-side of the pro mentioned about, “Skillsets are a Known Quantity”. Everyone on the team knew what we knew, and what we didn’t know. When the team moved from the Big Ag space to the Big Data space we all knew that none of us had experience in this area, and that we had an uphill battle to fight. The Standing Team model was now working against us; it didn’t matter that we had worked well together on the previous project. Even though we worked together to remedy this deficiency we still had a knowledge and experience hole to fill. Having a new member brought in with that background ultimately served the team well.
  • Stagnation of Individual Growth: This is probably the most insidious side-effect of Standing Teams. The longer the team works together, the less likely individuals are to be challenged to grow and adapt to new situations.

    I was the tech lead for the standing team that I was a part of, and while I like to think that I tried to push the members of my team in positive ways, ultimately I probably stood in the way of their continued growth. I could see that the individuals on my team had grown to the point that they were each ready in their own right to move on to lead roles, but as long as the team stayed together they wouldn’t have the opportunity or impetus to make this change. In terms of my own growth I also knew that I had become extremely comfortable in the existing team dynamic, and that I had to find a way to push myself outside of my own comfort zone as well.

    The team eventually split up, and while we still work together it’s at different clients and different projects. I think this is for the best, as everyone needs to be exposed to new team dynamics, environments, and challenges.

Conclusions

As I said, the Standing Team model has merits, but there are other considerations besides high performance and the ability to hit the ground running. Without mitigating actions, such as rotating members of the team or even disbanding the team after 2-3 projects, team growth and adaptability both suffer under this model.