Planning Your Agile Transformation - 5 Questions to Ask When Forming Teams

Anthony Mersino
November 28, 2015

A key part of an Agile Transformation for an organization is forming the development teams. The starting point for most organizations is typically a functional organization such as developers, business analysts, and testers who report to their respective managers.  It is common for each person to be assigned to multiple projects. So how do we go from that to having dedicated team members on cross-functional teams?

The end goal of team formation is to establish stable, cross-functional Scrum teams with full-time team members. Ideally, each team is co-located, that is, all team members are working from the same location.  Our hope is that these teams become high-performing and that they support our business agility.

There are several different factors to consider during this team formation process:

  • specialized skill sets like architecture or security
  • gaps in skill sets or knowledge - not enough for all teams
  • too many projects to dedicate people to just one team
  • distributed team members

It is that last factor that I find hardest for organizations to tackle. My work these days is mostly with Chicago organizations who are getting work done using teams they have assembled from various locations. They are chasing low labor rates and plugging in X days of .NET development as if each person was just a cog in the wheel. They don’t see the need or think they have the ability to form co-located teams. Or they believe it will be too expensive.

If we are serious about transforming our organizations, we’ve really got to rethink how we staff our teams, how we treat ‘resources’ as a commodity, and the value proposition for ‘offshore labor’. We need to look closely at team productivity and learning, when team members are spread across the globe. How practical is it to expect them to gel as a team, to work together toward common goals, and to cross train and share knowledge? How quickly does a distributed team move through Tuckman’s stages of team development to become high-performing?

More significantly, can you expect people working in different geographies and and in timezones with little or no overlap to really work “together”? Or does this lead to more of what we had in the traditional approach - people working in their own silo and creating documents that they handoff to one another? We know that silos and handoffs are problems, so why would we continue to do that?

Can we just use Scrum with our distributed teams as they are? Absolutely!  But like Jeff Patton famously said at Agile Day Chicago last year, “If you want to run a marathon with ankle weights, don’t complain to me about your time.

So before we decide to use Scrum with our distributed teams, here are 5 questions to ask yourself.

1) What Can You Do to Form Co-located Teams?

Where possible, create cross-functional teams that are co-located. Be creative. Can you have 2 complete fully cross-functional teams, each in their own geography, rather than one big one that is split? This may require some cross-training, knowledge-transfer, or hiring a key person to fill a skill gap, but it is still better than having teams split across multiple geographies and timezones.

2) Can You Form True Co-Located Teams and actually Seat Them Together?

If we are forming a Scrum team, let’s actually get them working together in the same room. Let’s have them sit within earshot of each other so that they can have high-bandwidth, face to face conversations easily and frequently.

Many clients have their team members in the same town or in the same building, but not sitting together. You may as well be in separate cities. Coming together for a 15 minute daily meeting is no substitute for working together in the same room. Heck, I’ve seen teams that were in the same building but they still dialed in to a daily call, rather than going to a conference room. That misses the point.

One common pushback I hear about getting teams sitting together in one room is that there is not enough space. Really? Isn’t it the same number of people? Have you really thought about this?

When there is a crisis, we set up “war rooms”. Why? Because they work. Everyone comes to the war room and we work our way through the crisis. The richness and speed of the communications is important. So we know that co-locating people in one room works great when things are important. Isn’t building great products important? The long term benefits far outweigh the temporary disruption.

3) Can You Form Mostly Co-located Teams? 

It may not be possible to have entirely co-located teams because you are using a vendor for development. Some vendors have a model where they have the ‘onshore coordinator’ working with your team in your country and the rest of the team located somewhere else. The onshore coordinator is generally responsible for handing off work and answering questions. This is highly inefficient for many reasons.

A recent client of mine had a similar arrangement for developing solutions with vendors. We experimented with a few different approaches for development teams in Buenos Aires. What we found that worked for us was to have a fully formed development team at the vendor location in Buenos Aires with a co-located Scrum Master. The Product Owner and Architect were in Chicago. The key benefit here is that the development team gets a chance to gel and has close support from the Scrum Master. The downside is that the Product Owner and Architect are separate. It is still better than a completely distributed team.

4) Have You Calculated the True Cost?

Getting an apples to apples comparison between team members spread across Belaruse and Hyderabad and staffing a team only in Chicago can be difficult. Most organizations don’t look beyond the dollar cost per hour of each team member and see that someone outside the US can be 4X or 5X more expensive. This is shortsighted, and it ignores the cost of the low-bandwidth communications, early or late meetings, lack of visibility, the silos and handoffs, and the lack of cross-training and learning. Leaders shouldn't compare velocity between teams of course. So how do you determine what it really cost to have solutions built?

I don’t know the real savings of sending work from Chicago to say Argentina, China, or Ukraine. If the tasks are simple and can be done by one person, it probably makes a lot of sense to do it in the cheapest possible location. But what if the tasks are not simple and a team is required- does it make sense to have some of those team members in one location and the rest in another? I don’t think so.

A recent client ran some experiments to bring some visibility to this question. When they went through their Agile Transformation, they formed teams that were co-located - one in Chicago, one in Tampa, and one in Chennai. The teams had to synch their story point scales, and groom their backlog items together in order to pull work from the same backlog. But it was as close to an Apples to Apples comparison as I've seen. And it became clear over time that simply using hourly rates for team members completely missed the point.

5) Is Scrum for You?

If forming co-located teams is too hard, maybe Scrum isn't for you. Scrum is a framework for continuous improvement and making organizational impediments visible so that you can address them. You may not view your current team staffing strategy as an impediment, but I would ask you to think about the overall goal of business agility. Does your current approach to establishing stable, long -standing and high performance teams increase your business agility?

I'd love to hear your thoughts about forming teams.

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.

Comments