Planned Rotations on Dedicated Teams – Winning Strategy?

Agile Methodology, Customer Experience, DevOps, Nearshore, Product Development, Project Management, Successful Outsourcing

Rotating team members on agile software development teams is a controversial subject. Some leaders in the agile community are strongly opposed to the idea and won’t consider it at any level. Others are open to the subject, but frankly too concerned about the possible downsides to actively plan rotations or even hint to their customers it might be a good idea. And of course, there are the wild-eyed optimists who claim it is the best idea possible for every situation.

Our focus for this article is dedicated teams – teams with members selected for their skills and reliability over the long run. Typically, dedicated teams have no set sunset. They are dedicated to a product or part of a product suite and they generally stay through the active development and maintenance of a product lifecycle – which for enterprise software maybe years. But, that said, the ideas that bring up the subject of rotating members of a dedicated team could apply to any long term project, especially with smaller (3-5 member) teams.

And let’s be honest about one other thing too: the longer the project or product lifecycle, the more likely it is there will be an «unplanned» member rotation. Births, deaths, illness, vacations, career advancements and changes – all sorts of life events have to be managed as a part of maintaining a dedicated team. Even if the time a member is away is relatively short, in less than two weeks, the impact on the productivity of a small team needs to be managed to continue to meet client schedules and expectations. In some cases, the remaining team members can sustain production for a period of time by adding additional hours daily and on weekends, but eventually, that will take a toll on their personal commitment to the team. And when there is an unplanned need to bring in a replacement, there are consequences to the team regardless of the additional manpower provided. In fact, it is well understood that if for some reason two members of a small team needed to be replaced over a short period of time, it would be catastrophic for the team. Bringing the new member «up-to-speed» with mentoring and knowledge transfer takes time and effort of other team members away from their work.  And, there is the well-understood impact of a team «forming, storming, norming, and performing» cycles as described by Tuckman. Changing a member of a small team always creates issues. Without some planning and forethought – it can kill the effectiveness of a team for an extended period of time.

So – why would anyone want to consider the idea of rotating team members on dedicated agile teams?

• If unplanned changes in a dedicated team are going to happen anyway, why not be prepared? Why not have the process for selecting, integrating, training and mentoring a new team member planned, documented and tested before it actually happens? Why wouldn’t you want the expectation that «this can happen» and «this is how we deal with it» in place and in front of the team and the client from the beginning?
• The longer a team works on a product, the more likely they are to develop «tunnel-vision.» They see the UI, but they become blind to the problems a new user might encounter trying to use it. They know there are newer technologies that might make something more efficient or resilient, but it takes time to test, advocate change, and demo the option to the client team. If what you have works, is it really worth the effort? The longer a team works together, the more «normal» the little quirks about a product become. In the long run, it can make them resistant to needed change and reluctant to suggest options.
• Working with the same people, on the same product, eventually leads to a level of isolation that can begin to make it difficult to want to get started on the «same old stuff» each day. Developers are part of «geek culture» and love to see new technologies, get input from other sources and try «cool» things. When this happens, production slips and members of the team may become less committed to the success of the product they are working on. It doesn’t happen in a day; it is a slow drip that eventually eats away at the team and makes it less effective. It can also make individuals on the team consider career changes because they are afraid their resume will reflect stagnation rather than stability.
• Bringing in «fresh (but experienced) blood» can bring cross-pollination from other experiences, new points of view on coding practices and processes, a new look at alternatives as you move forward and other benefits from another set of eyes on the project. If long term members of the project are not ready to accept new ideas, they can create strong resistance, but if they are positively primed for the idea by considering they could also benefit individually and as a team, it can be a shot in the arm for the team.
• «Ownership» of a product, or an area of responsibility, can be a strong motivator for a team. Their understanding of its deeper value and continued success is part of their pride and keeps the team on track. But, there is also a downside. If the team is the single point of knowledge and «truth» for a product, they are also the single point of failure. If there is no base of knowledge about the product outside of the team, in the wider pool of developers around them, there is no way to replace a team member easily or help them if there is a problem that causes a loss of a member or if the team runs into a serious internal disagreement (it does happen).
• Operationally, these long-term teams become silos. Outside the team, they are the go-to subject matter experts that always have the answers. Inside the team, individuals tend to become specialists, filling a niche that no one else can come close to. This not only runs against the whole concept of «agile organizations» – it becomes a growing risk within the organization.

There are more reasons too – but those concerns represent some of the more common drivers of the idea. They are all real issues and the problems the teams dealing with them have an impact on the projects they are in. But – does planned rotation actually solve the problems? Does the upside outweigh the downsides? Can rotation be planned well enough to overcome internal team dynamics? Will the supposed benefits last long enough to make rotations something you want to do? Can you actually present a case that would make client support, rather than oppose, the practice?

The answer would have to be – it all depends on implementation.

• Like any change, member rotations have to be sold internally before they can be implemented.
• Frank conversations about the health of teams, experiences in long term engagements have to be surfaced and alternative solutions have to be discussed.
• The timing and requirements for new members have to be considered and accepted by the existing team members. Simply dumping the idea on them without preparation is sure to bring disaster.
• The level of the incoming team member will make a difference in acceptance. Replacing a senior member with another senior developer may be more difficult than bringing in a mid-level or junior developer in their place. With less seniority, the new member will have lower expectations and less to live up to. They will be more accepting during knowledge transfer and mentoring and give existing team members new opportunities to grow. But if the outgoing member is considered to be a team leader, the impact may be very deep no matter who is brought in.
• If the practice is fairly new within the organization, replacing a team member is likely to be more problematic regardless of planning and thought. The practice can be new institutionally or within the team, it really doesn’t matter. If team members are not experienced with the concept, issues will arise. Assuming the issue will iron themselves out eventually is not a good way to manage change.
• Frequency is important. Single-member rotation will always cause thrash and lost productivity no matter how well it is planned. A team can only sustain so much change without becoming distracted and losing their center. In complex environments, it may take a considerable time for a new member to build up the necessary knowledge base. Most industry experience seems to circle around a period between six and nine months for the change of one member. More than that and the team might never gain cohesion again. Less than that and silos will begin to form. But, there is no perfect point. You can’t change a member during a critical release for a product, no matter what the calendar says. You have to work with the client team to gain acceptance and cooperation. Timing is a hard nut to crack and will be different in every situation.

This is an important and evolving area of management for outsourced agile teams. It is not widely discussed in the software development industry. Clients come to outsourcing vendors to avoid issues like team cohesion, resilience, and long-term stability. It may be difficult to bring them into a conversation about an issue that is seen as a vendor responsibility.

But, there are some ideas that are coming forward and worth considering. Larger outsourcing vendors can propose a dedicated «pool» rather than a team. The actual team in production continues to be a small number, but the vendor commits to a larger group, perhaps 7-10 including the active team, of developers that are involved and can become a team member with less overhead from change. This allows the members of the pool to become involved in project and product discussions, review code, and be the sounding board for ideas. There has to be an adjustment of the cost to allow this kind of an arrangement and a clear commitment by the vendor to avoiding the issues that are considered part of dedicated team contracts, but in certain situations, it is worth considering.

In the final analysis, it is hard to value the practice of rotating team members on dedicated teams. It can seem like a great idea if you have experienced the downsides of long-term engagements where unplanned changes and team stagnation become barriers to success. If the motivation, implementation, and outcomes are not carefully considered and monitored, it can become a serious distraction from productive development. Neither outcome is good so this is an important consideration and the decisions are likely to be different in every situation.

If you have experience with team member rotation (and not just fears or wild optimism) – I would be interested to hear your thoughts. This is still an unsettled area in agile team dynamics.

Scio is a provider of outsourced, dedicated and project teams for agile software development to our nearshore clients in North America. We have experience with many team and project configurations and would love to discuss how we could help with your next project. Please contact us with your questions.