Job rotation - does it do any good or essentially anti-Scrum?
Dear Scrum Practitioners,
Just wanted to walk you all over one common situation which we find ourselves in almost all IT Organizations now a days and seeking your opinion on whether it does any good or more harm to the Scrum teams...
My Organization/ Leaders always press for job rotation for team members to other teams/ accounts/ business units once they spent time equivalent to 1-1.5 years in a team. They say that its a necessary practice as it lets the team members to be part of a new team, work on new challenges, get exposure to new areas and hence builds job satisfaction which then counters the attrition rate in the company.
However, I find this practice quite frustrating as a Scrum Master. It take a team quite some time to come to a position where they can call themselves truly cross-functional, self-organizing and 'whole-meaning-more-then-the-sum-of-its-constituent-parts' mindset. I have worked with my team quite hard where they can now work almost independently upon any challenging work they have been given and has now become a truly competent and value-delivering team. The team also now jells quite well with each other and have developed a good deal of understanding about each other where one can complement the other. Now, management is forcing me to provide me names of team members for job rotation, as they have their targets to show.
I know I should ideally ask the team members if they want some sort of job rotation or not, but aside that, isn't it a Scrum/ Agile anti-pattern in first place? The agile way of thinking says that we should build long-lasting teams around products and not projects who should work together at least as long as the product lives. Is there any problem with this mindset? Should we ideally encourage job rotation among team members after some time (by involving the team members in this decision making process of course)? In that case, how come a team which gets new faces every 12-18 months work together to truly cultivate the traits of agility then?
Awaiting for your valuable inputs/ suggestions to get me out of this dilemma...thanks!
Now, management is forcing me to provide me names of team members for job rotation, as they have their targets to show.
It's difficult to see how this encourages or facilitates self-management within Scrum Teams. What evidence have management provided to show that this policy of theirs, and its associated targets, achieves good agile outcomes?
Job rotation is often seen as a good thing for the reasons that you mention. There are people who find it necessary to change teams and work on new problems or build new skills in order to stay fully engaged at work. Keeping employees happy and engaged is generally better for the company - it's better to have one person move around the company and stay internally rather than have them leave and need to onboard new hires every year or two.
The thing that concerns me is that it seems like organizational leadership is forcing people into this rotation. I can see two immediate problems with this. First, not everyone wants to be part of a rotation. It is good for some people, but others are happier staying where they are and working on the things that they are working with roughly the same people that they have been. Forcing these people into a rotation may have the opposite effect and cause them to leave the company. Second, rotations need to be well planned. They can be disruptive to the team's dynamics, so the team should be well aware in advance that someone will be joining, when they will be joining, information about the background of this person, and how long they will be with the team. Ideally, the team should also be able to opt in to having someone on a rotation join the team - it's not always appropriate based on the work being asked of the team to support someone new joining.
Coming from an Agile perspective, I'd build a case around the self-organization of teams and individuals. Individuals should be able to opt-in to rotation programs and teams should be able to opt-in to having someone rotate in and be involved in making the choice of who rotates in.
Thomas Owens and Ian Mitchell have both made good points. Whilst the practice can be beneficial, it seems like Scrum is not being respected, because Development Teams aren't being allowed to self-organize.
Now, management is forcing me to provide me names of team members for job rotation, as they have their targets to show.
This sounds like behaviour I've seen before, where middle-management or the executive team aren't empowered in the way they report to their own managers / investors.
If that is the case, perhaps the ideal situation is to work with this layer of management and help them do the right thing, so that the desired results eventually come.
If you find they're deliberately harming the organization in order to reach their own targets, perhaps you will need to put transparency over this behaviour, by working more closely with the people they are reporting to.
It's risky, and could be terminal to your future in the organization, but something you may want to weigh up in general, before determining whether you want to highlight, solve, mitigate or ignore the problem.
I agree with everything said above. Job rotation can be good for some and bad for others. I'd ask your team if any of them would want to rotate and do it in a group setting so that everyone on the team will know. I'd also ask if the entire team would like to rotate to something new. That is an alternative for teams that work well together and want to stay together. And it would accomplish the same result that your management seems to think is beneficial. Instead of rotating single individuals, rotate teams into new problem space. Sure it will through the entire organization into some level of chaos but it also enables fresh eyes on problems and can result in new solutions.
I would also ask your management team if the individual Scrum Teams will be able to participate in the decision of who will join their teams. This also plays into self-organization.
I once read an article (that I wish I had a link to now) where a company would do a quarterly session. In that session all of the Scrum Teams would gather in a single room. Each Product Owner would provide information on the items in their Product Backlog and explain what they would like to accomplish over the next quarter. They would post information on the wall. After all of the Product Owners have presented, every Development Team members would approach the walls and sign up for the work they would like to participate in. The company stated that after 3 months, it was becoming obvious that teams stayed together. Everyone on a specific Development Team would sign up to work with the same people. It appeared that being part of a consistent team was more important to the individuals than rotating to new work. There were a few exceptions at times but consistently teams would stay together.
I would ask for the support for this practice. I'd want to see what they are basing their decisions upon and suggest that it might be time to ask the employees what they would like to see happen.