Few would argue with the benefits that can be gained from a switch to an agile approach. Agile teams enjoy more autonomy and greater fulfillment from their jobs while organizations enjoy faster time to market and and an increased ability to respond to the emerging needs of their customers and marketplace.
But, even with all of the benefits of an agile approach, occasionally some individuals will still find themselves unhappy or even feel trapped in their current team assignment. In fact, it may even seem as if we encounter this more after teams begin following an agile approach. However, there are actually two, very legitimate, reasons for this.
First, teams who follow an agile approach tend to work in small teams, which can exacerbate an unhappy team experience. For example, it’s much easier to tolerate working alongside someone you don’t quite see eye-to-eye with in a team of 15 rather than in a team of 5.
And second, most agile approaches encourage us to be more reflective about our working environment and then to share those feelings with our organizations. In fact, many agile methodologies even have specific mechanisms built into their frameworks to elicit these feelings from their teams in a productive manner, such as the Scrum framework’s Sprint Retrospective. This means that while those feelings may not be new to an individual, that individual simply may not have had an effective way of communicating their feelings to their organization before their organization adopted an agile approach.
To help alleviate these feelings of unhappiness, some organizations experiment with regularly rotating individuals across teams. This can be tempting, as the opportunity to move teams can not only reduce burnout in team members, but also introduce the promise of a reprieve for individuals who may be unhappy in their current team. But while this option may at first seem reasonable, it may not always be the best solution.
For one reason, each time the composition a team changes the dynamics that have formed on that team also change. This means that the remaining team members must go through a period of readjustment as they learn to be productive under the new dynamics that have emerged on the team. In fact, Tuckman’s stages of group development is a model often cited by agile coaches that exists specifically to model the dynamics that emerge during team formation.
In addition, regularly rotating individuals across teams can also create other problems which are often felt across the wider organization. The most nefarious of these problems is that the team never seems to stabilize so their output suffers. As a result, the constant changes in team composition also tends to result in corresponding changes in the the team’s velocity, which makes it difficult for the team to produce value with any predictability. This is before we even consider the aspect of team members never quite settling in to a team because, no matter how successful that posting may be, they know that in their organization no team posting is ever permanent.
And finally, any attempts to institute a process of regularly rotating individuals across team by an organization’s management is likely to be met with suspicion and resentment from the team itself. This is largely because management-instituted policies which focus on a team’s composition infringe on the team’s right to self-organize, which is a fundamental trait of all agile approaches and key to a team’s long-term success.
Rather than asking your organization to rotate team members on a regular basis, a better solution is to introduce the concept of an open team. Under an open team approach, any team member can move to another team at any time.
However, as appealing as this might first sound, it’s often not as simple as it seems. One challenge with this approach is that the sudden departure of a team member can open up a sudden gap in the team. This gap can be even more painful if that team member is key contributor or if they have a specialized skill that can be difficult to replace.
It’s also worth mentioning that this approach is often more successful in product organizations than in service organizations. In a product organization, users typically only interact with the end product, rarely interacting with the team directly that produces that product. As a result, the customer is abstracted from changes to a team’s composition. However, in many services organizations the individual members of the team may interact closely with the organization’s client. In these situations, clients will often form attachments to certain high-performing members of the team and resist any changes which could result in those members leaving that client’s project. This can make it very difficult for an organization to honor a request from an individual to leave a certain project without also risking the alienation of key client.
To remedy this, successful open team approaches are often implemented in collaboration between the individual team member and the broader organization. Rather than simply allowing a team member to pick up and leave on a moment’s whim, this approach is most successful when a team member expresses their desire to move to a new opportunity and the organization agrees to facilitate that move when the timing is optimal for everyone involved.
However, under an open team approach individuals do not actually move between teams as often as you may expect. Recall that many of the feelings of unhappiness and dissatisfaction a team member might feel stems from that individual’s feelings of being trapped, but we tend to feel trapped only when we’re held against our will. Once we are granted the freedom to move, many of these same feelings largely dissipate. In addition, this same freedom is often enough to encourage team members to work out their differences with other individuals, rather than simply allowing those feelings to fester.
Finally, whenever we’re free to choose our own team we tend to be much happier with that decision over the long term. One reason for this is that we’re much more likely to choose a team that’s a better fit for our skill set and personality whenever we’re free to make that decision ourselves. But a more important reason is due to our own confirmation bias: whenever we make a decision, we tend to be much more reluctant to admit that decision was wrong than if someone else made that decision for us. Due to this bias, we’re more incentivized to work to make that decision successful to better confirm our original decision, in the first place.
While it may first surprise to you to encounter someone who is unhappy on their current team there are legitimate reasons why these problems may be more likely to appear than in the days before agile.
But by creating a culture in which your team members are free to express their concerns as well as by giving those team members greater accountability to remedy those same concerns, you’ll find that your teams are much more likely to self-organize into happy and successful teams that can add value to your organization for long into the future.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
