If a scrum should get handled near to idealistic way

My first advice would be to stop talking about this individual as a "resource" to be "used".

If both teams are self-organizing, and everyone respects the Scrum Values, I would expect them to collaborate to find the best way to work together.

It really depends so much on the context, but I would expect the people doing the job to find the way that is most effective, which could be having one individual on both teams, having them on just one team, or having them work outside of the teams. The role of this individual may become that of a coach, to help both teams develop the necessary skills that are currently in short supply.

I have only one resource who is skilled in one technology stack, and we are running scaled scrum with 2 scum teams. How the resource should get used if he/she is required in both scrum teams? 

Are the people on the teams capable of self-organization, and of visualizing and managing their dependencies? With only two teams, no other scaling ought to be necessary.

Remember that in professional Scrum, the solution to a problem lies in teamwork and not in resource utilization. The associated competencies should be mastered with just one team first before the organization attempts to scale.

@Simon

I admire your advice.



@Simon and Ian



Yes Self organising team is one of key for handling such kind of things.



Also, One more thing can be done that User stories get picked my one scum team related to that technology and other team will pick others so the Individual can work with more focus,

OR product backlog can be adjusted as per.

untill cross skills get developed in the team for this technology stack.  



Could this be example for self organising?



 

A. Organising

Dare to ask the question whether you can improve the current way you are organised.

Begin with the Product Backlog (not with ‘we use scaled scrum and have 2 teams’). Let developers select items, organise and sequence the work. See what emerges.

I mean: let the ‘how’ and ‘with what’ follow (be the result of) the ‘what’.

B. Number of developers (more developers is not equal to more product value created)

If there isn’t a good reason for having eighteen? developers then don’t.

I mean: if eighteen developers forecast to deliver a done increment and a lot of incomplete work then half? of them should possibly be delivering value elsewhere/learning much needed new skills to be applied in a future development activity.

C.

If there isn’t a good reason for scaling scrum then don’t. If it emerges that having two to three teams are of real value, then pay extra attention to Product Backlog refinement so work dependencies become transparent and inter-team dependencies can be avoided/eliminated/minimised. Then, ‘just’ do scrum. Do it well.

D.

If you have positively identified a constraint:

1. be creative in getting the most out of the constraint

2. adjust the rest (the non-constraints) to a ‘setting’ that will enable the constraint to deliver maximum value. (e.g. adjust Sprint PBis/plan/goal/cadence, according the constraint's value creation capacity/capability)

3. if this (1, 2) is not enough then more drastic action is needed. You will need to dig deep and uncover the root cause of the constraint (e.g. is the development organisation keeping up with the ever faster changing world?)

My first reaction was "why do scaled scrum with just 2 teams?"  But that isn't your question so won't go any further than that because you have gotten good advice on that already. 

Here is how organizations I've worked for have handled you situation.

1. As @Simon suggested, we used that individual as a coach to disseminate their knowledge to others.  After others became aware enough to handle the most common situations, the "expert" moved back to an individual contributor on a team.  Then an almost Community of Practice emerged to help address new found issues that required the "expert" to consult.  This practice raised all teams ability to handle all of their work significantly.
2. Created a group of "experts" that would do work for other teams in situations where the knowledge was silo'd.  The work would be identified as a dependency on the story and would have to be resolved before the team could bring in the story to finish the work.  This one failed miserably.  The "experts" were overwhelmed with work and all of the teams suffered due to external dependencies. 

But with all things Agile/Scrum, ask your teams how they feel it would be best to organize.  Try it, inspect it, adjust it until you find the right thing for your organization.

My first advice would be to stop talking about this individual as a "resource" to be "used".

So true