I was talking with someone at a conference a few weeks ago and he asked the question:

What do you think about the concept of “Elastic Teams”?

To be honest, I’d never heard teams referred to in that manner, so I had to admit that I didn’t know. I asked, what do you mean by an “Elastic” team? He went on to explain.

He said that these are teams who are formed, dissolved, and reformed around business needs and priorities. For example:

If you had 3-5 teams working on a set of products in your portfolio and the overall business priority changed. Then you could possible shrink each of those teams by 3-4 individuals and assign them to another team (or group of teams) for 2-3 months.

If something else shifted, perhaps something smaller. For example, a customer escalation of a performance problem. Then you might shift members amongst teams to address the situation. In this case, it would hopefully be a shorter-term reassignment, and then things could go back to normal.

Ah, Now I understood…

Now I get it. What you mean is moving folks around quite a bit. So, what you’re saying is that:

Projects, business goals, emergencies, multi-tasking, etc. towards business priority trumps cohesive teams. Teams that stay together (learning, growing, trusting, improving, delivering, etc.). That the individuals have a commoditized flavor to them and are mostly focused towards business goals.

Right?

He said that he might not phrase it exactly as I had, but yes, that was right. So back to his original question, what do I think of “Elastic Teams”?

And the undertone of his question was that – he REALLY liked the idea and wanted to see how I (as some sort of “agile expert”) would react. In other words, it was a test of sorts.

Well…

I hadn’t said it earlier. But this person was the VP of Development at a potential client. He would probably be my most important contact as their agile coach.  The key decision-maker. So, there was a lot potentially hanging on my answer.

But in the end, my answer was that:

I didn’t care for elastic teams. Or the notion that people were interchangeable parts or commodities on teams and that we, as leaders, were responsible for composing and recomposing them.

I went on to explain that my views were:

• That teams were fragile things. That it took time to form them. So, I was incredible careful about not being too disruptive, too often.
• That it took even more time for them to become high-performance. And that high-performance wasn’t just delivery-focused. It also included high-quality, high-trust, high-risk tolerance, and high-fun.
• That I honored teams above business events. For example, if I had a choice of elasticizing a team OR redirecting work to an existing team, then I would always do the latter.
• Of course, I had moved folks from team to team in my career based on shifting priorities. BUT, I had always put the continuity of the team front-of-mind when making those decisions.

That didn’t go so well…

In the end, I think we agreed to disagree. And I’m not sure how well I impressed my client with my alignment to his thoughts. Read that – I lost the potential business.

That being said, I was true to myself, my experience, and my beliefs. I just bet I could have done a better job of picking the time and place to have this discussion. And perhaps chosen my words more carefully. You see it was at the end of a long day and I was a bit shorter-tempered than I normally am.

@Velocity

We often get a lot of pressure at Velocity Partners to move our teams around. Clients will leave and new clients will join. Team members will look for a new project/team for new learning or challenges. And we simply have the normal contraction & expansion pressure associated with any nearshore partner.

But one thing we do is honor the notion of our people and our teams. It’s what keeps our attrition low – less than 7% annual attrition.

It’s what keeps our team members growing, passionate, and engaged for our clients.

But it also keeps many of our clients reaping the benefits of long-lived teams. You see many of our client teams have been together for 4-5-6+ years. Beyond being a nearshore team, they become an extension of the client culture, business domain, and technology. Often these teams are helping the client chart their products into exciting new opportunities.

This doesn’t happen accidentally. It requires leadership and a focus on the value of each Agile Team. And it’s a responsibility Velocity Partners takes very seriously.

Wrapping Up

I think the key point I want to make in this article is that we need to handle our teams as if they are precious to us. Because I think they are. (see the Sidebar below)

No, I’m not saying to allow the Inmates to Run the Asylum. Not at all. But at the same time, I truly believe we need to honor our teams.

That if we need to disrupt them for any reason, do it thoughtfully and carefully. Also, do it infrequently.

As leaders, we need to be more aware that our teams are our number one investment and they are NOT commodities.

Stay agile my friends!

Bob.

Backup reading / listening

This is a past blogpost where I explored some parallel thinking that aligns with and compliments this topic. Please consider reading it –

And here’s another perspective from Tim Wise. This is a podcast that he and Dave Prior recorded related to this topic. Enjoy!

SIDEBAR

From 2009 – 2012, I was the Director of Engineering at a company called iContact here in the Raleigh, NC area. iContact still operates as  

During the course of those 4 years, we built an incredibly healthy and productive Scrum environment that I was immensely proud of. As part of building those teams, we hired ~ 20 testers. Some were developers and automated our code. Others simply performed manual and exploratory testing. But at the end of the day, they were AGILE testers who integrated with and complimented their Scrum teams incredibly well.

IMHO, they were one of the reasons our teams kicked-ass. We hired the best and invested in them to become incredible, quality/testing focused team members. And it took a while for us to get the teams balanced and behaving the way we wanted.

In 2012, iContact was acquired by another firm. Their VP of Technology really didn’t care for agile nor did he believe that teams needed testers on them. Instead the developers simply needed to test their own code.

So, he fired all of the testers.

What it took us 3+ years to build, he managed to dissolve in a few weeks. And the teams were never the same.

What is my point?

Effective, high-performance, kick-ass teams take time to hire, build, form, evolve, and grow. And it’s incredibly hard work. But you can break apart, dissolve, and elasticize great teams in the blink of an eye. I guess with great power comes great responsibility (or not).