This is an excellent question and you will see a spectrum of answers which demonstrate the polar opposites of the Scrum community attitudes.
There is an official answer which is supported by the Scrum Guide and will help you pass any number of Scrum exams but has little applicability in the real world of software development.
Let me break your points down one at a time.
- Your closing question.
Is this the correct approach?
Always remember that doing Scrum is not the thing. Scrum is the thing that gets you to the thing. It is a framework designed to help you deliver software, it is not an end in itself. Unless you work for Scrum.
If your approach is helping to deliver working software then it is not wrong, it could just be improved slightly.
Don't approach Agility with a sense of right and wrong, it will just divide your stakeholders/customers/co-workers.
It's simply a spectrum of effectiveness.
Effective short term, effective long term.
Getting stories done now in mini silos does not mean the team are building resilience to get stories done in the future if one of the development team leaves / goes sick etc.
- Your underlying issue
Team member is unable to help another team member
This could be many things and is worthy of a question in it's own right.
The default response of the Scrum Community will be that cross-functional people are king but that is not always viable in practice, especially in Enterprise organisations or those with strict regulatory frameworks that need sign off. It could be that the developer has en employment contract which states his/her specific role and skillset.
The aim is a cross-functional team as much as possible but a COBOL developer does not magically become a Jenkins expert and a QA Tester does not instantly become a Java developer etc. We have to be sensible.
As a Scrum Master you should spend time with the Developer and probe their motivations. Are they opposed to learning new skills? Do they feel uncomfortable? Does the organisation and the project allow punish failure? Do they feel pressured to work on new tasks? Do they have a line manager they report to discouraging a new skillset? Are they incentivised by user story completion?
You will need to spin a few plates but you are paid to manage relationships. They are paid to manage the code pipeline.
Ask the Product Owner if they see the value in cross-functional working and can they devote some Sprint time to the Development Team to train/coach/mentor the developer? Is there capacity to have them do self-guided learning with online resources?
It's important to consider that the needs of the Scrum Team may not be in line with the career aspirations of the Developer, especially in large organisations with entrenched employees and HR. HR is on their side, no ifs, no buts. Not every Scrum Team works in a start-up environment.
My approach is to simply tell a Developer
"We will be no worse off if you simply try. Does that sound like
something we can work with?"
If the answer is no then you have some tough choices to make for your recommendations.
- Your current approach
I allocate a new item from the backlog that my scrum member is more suited to doing and leave the remaining item for the colleague who is still behind. This is with the full consent of the development team.
Firstly, you have gained consensus from the team which is fantastic. Your direction of travel towards a self-organizing team in underway. Maintain that.
Do you feel you should allocate work though? Do it feel to you that that is the role of the Scrum Master? If you are a former Project Manager then maybe this behavior comes easily.
Ideally, the Product Owner should be continually ordering and prioritizing the backlog so that development team members can see the highest value stories at the top. If a situation arises where the team have more capacity then they can simply call a quick meeting, review the backlog and select the stories they feel are most appropriate for the Sprint taking account of the Product Owners prioritization.
Typically you will find a healthy tension between engineering stories (best practice, refactoring etc) that the Development Team wish to implement and Feature stories which the PO pushes to have done. Not always, but it's common.
Having capacity in a Sprint is an excellent chance to let the Development Team focus on those engineering tasks without disrupting the Sprint Goal.
In summary, you shouldn't assign work but encourage the team to pull from the backlog in a considered manner.
Lastly, no Scrum Team member is ever behind. They are a team. It is a team delivery.
Reinforce this. Like a relay team, the clock stops when the last man crosses the line not the first; they are not behind; they are simply demonstrating to the business more realistic expectations of what can be achieved. Timelines move, developers don't work longer hours. That's the sustainable part of Scrum.
Build a team, not a collection of individuals...and don't throw the Scrum Guide at them. It's just a PDF written by a couple of guys no smarter than yourself.