Agile Transformation Plan – Planning Agile Teams

Agile Transformation Plan – Planning Agile Teams

A key part of an Agile Transformation Plan for an organization is forming appropriate agile or Scrum 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.

Before the agile transformation, it is common for each person to be assigned to multiple projects. Each time a new project is started, a new team is formed. The best people continue to be assigned to more and more projects. [Read more about why this is problematic in Stop Assigning People to Multiple Projects]

From Project Thinking to Team Thinking

The best way to move away from the shared resources is to move from project thinking to team thinking. After all, the limiting factor in how much work you can take on is the people you have. You don’t get more capacity by reassigning the same people over and over again, you actually get less.

They key is to move to dedicated stable teams. The work is brought to the teams.

Team Design is a Key Step in Your Agile Transformation Plan

The end goal of team design 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 design process:

  • the nature of the work you need to complete
  • what that work will look like in 6 months or a year
  • specialized skill sets that you might need like UX design, architecture or security
  • any gaps you have in skill sets or knowledge which will be difficult to staff across all teams
  • any skills team members have that are no longer needed which would indicate a training or cross training need
  • where your people are located today

Locations of Team Members is Often a Major Challenge

That last factor mentioned above – location – is often 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 Agile transformation, 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 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?

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 time zones.

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 into 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 are 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 Belarus 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 in your Agile Transformation Plan.

For more resources on creating your Agile Transformation Plan, please visit our Agile Transformation Consulting page.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Close Menu