Idle resources

How do the team members feel about:

1. being referred to as "resources"?
2. being "loaned out"?
3. not being required?

Does the Scrum Team see the current situation as problematic, and can the team members agree on a more effective way of proceeding, without causing short or long term harm to the team or product?

Could all of this indicate a more fundamental problem with the suitability of the team for the work that is expected of them?

It would appear that the usefulness of certain team members is constrained to being backend developers and database experts.

What does the team think about that? Are they happy to be subordinate to such a constraint, or would they rather start the process of overcoming it?

'Resources','loaned' , I agree these words can make one feel objectified , but pretty much that's the way the management addresses us and should be avoided. Thanks Simon for pointing it out.

This has been a one off case. Team always had work where each member was involved in completion of the stories. After three sprints, they are definitely going to start working on the skills they are proficient on. 

The team isn't very keen to learn up any frontend work as they know this is temporary and there isn't a lot of work there.

They however are interested to learn new technologies related to their areas of expertise and get certified on, during this period. I had recommended this to the management and currently on discussion.

I would want to know how would have others done it?

Also, does agile/ scrum appreciates if few talents join another scrum team for a short period? I have a previous experience where due to this shifts between the team ,a later bug that cropped up called for these talents to go back and attend to it , which of course impacts the sprint.

In addition to the other great points made:

• What is the state of their Increment?  Is there any technical debt to pay back over the next few Sprints?  Are there any quality issues that need to be addressed?  Are there any Sprint Retrospective items that may be taken up?
• Might this be an opportunity for the Development Team to increase their cross functional skills?  Ask them how they might be helpful to the front end developers (through testing, building automation, pairing).

Scrum on.

The team isn't very keen to learn up any frontend work as they know this is temporary and there isn't a lot of work there.

Empirically speaking, this has happened once. Could it happen again? Therefore, does it make sense for the team to take steps to learn how to handle this situation in case it occurs in the future?

Scrum doesn't prescribe what a self-organizing team should do in such a situation.

There is plenty of evidence about the impact of changing teams, particularly with the intention of addressing a short-term issue.

Does the team have enough knowledge about the current and future product plans, so that they can make appropriate decisions? Are they trusted to fully self-organize?

Is there enough transparency so that the team can inspect the impact of the decisions they make, and ultimately learn from the experience?

I have a previous experience where due to this shifts between the team ,a later bug that cropped up called for these talents to go back and attend to it , which of course impacts the sprint.

Have you shared your previous experiences with the current team? What did the previous team learn from this experience?

>>  Also, does agile/ scrum appreciates if few talents join another scrum team for a short period? 

How would this new Development Team feel about that?  Sometimes adding members to a new Development Team decrease their productivity short term, as they have to get the new members up to speed.  It may also impact team dynamics.

Rashmi, in Scrum, the team as a whole forecasts a body of work over the next sprint, and agrees with the rest of the Scrum Team on a Sprint Goal that focuses their efforts.   Scrum is not about "resource utilization", even if that is what your management is focused on.

Bottom line - is the Development Team meeting their objectives each sprint, to the satisfaction of the Product Owner and key stakeholders?   If so, does it really matter how "utilized" each Development Team Member is?

Granted, cross-functionality would likely result in the Development Team being able to achieve more each sprint, but the solution to squeeze more productivity out of the team (a traditional/poor management approach if I ever heard one) is not through shuffling members between teams, for reasons already explained.

The feedback you've provided so far indicates to me that Development Team members are still thinking selfishly (how can I work in and improve my expertise?), and not as a self-managing and organizing team.   

Your efforts would be well-suited to helping Dev Team members understand the benefits to everyone (especially the company they work for) of teaching, learning, and cross-functionality, along with helping your management understand the negative effects of shuffling team members around based on their skill set.

Good luck!

The work would pretty much be for frontend developers , over the course of next three sprints.

This situation occurs when the vertical thin slicing of functionality is not properly done. How can any functionality be delivered with an incomplete or inefficiently tested front end piece of any vertical slice? A fully matured Scrum team producing releasable fully tested increment each sprint won't usually face this situation. A robust Definition of Done will avoid such aggregation of work by horizontal technical layer. 

For the current situation, I guess the team members can utilize this time to expand their skills in front end development and normalize their skills as a cross-functional team.