...is not able to help the remaining member of the team with his tasks since he is not suitable for it?
Currently, in this scenario 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.
Is this the correct approach?
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.
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.
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.
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.
This is an internal problem for the Development Team and you should allow them to solve it themselves. It is absolutely not the job of the Scrum Master to allocate work, create tasks, or decide on who is best to complete work.
You should refer to the Scrum Guide for how this works, but here are some relevant points:
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
As long as the Development Team has the skills available within the team to do the work then you can step back and let them get on with building Working Software in the way that makes the most sense based on their composition.
If they don't have the skills it is the Scrum Masters job to facilitate providing them.
The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Helping the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Nowhere on here will you find that the Scrum Master assigned work to the Development Team, and indeed their job is to protect the Development Team from people trying to assign them work directly.
It sounds like you don't have a self organising team, and that each person is held individually accountable for work. This is the biggest killer to self-organisation and a blocker to gaining high performing teams.
On reflection it sounds like your Product Owner is not ordering the backlog, and that your Sprint does not have a Sprint Goal.
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
You need a Sprint Goal to give the team both focus and some wiggle room in what is selected for the current Sprint. Always the Development Team selects the work that it is to complete, and the Sprint Goal gives them the direction they need if the Product Owner is unavailable.
When teaching and coaching new teams I work with them to make a "Decision Tree" as part of the working agreements. I teach them the basics of Kanban first and over the years I've found most teams settle on a similar decision tree.
So as I write my Agile Coach's Cookbook, this is what I'm offering as an example of a Good Practice.
In Scrum, I am done with my current task, what do I do next?
As you can see, starting something new, from the backlog, is well down the list and there should always be the caveat of "in this sprint". Slack is vital to a successful organization. Tom Demarco, management consultant and author of Slack, states "Innovation is what happens when there is slack."
... I allocate a new item ...
Please be careful with doing this. Scrum (and most Agile in general) works best as a Pull system, not as a Push system.
Additionally, be careful of accepting new work into an ongoing Sprint - doing so threatens to make the entire purpose of the Sprint estimation pointless. Any new work added to the Sprint should generally be agreed upon by the entire Development Team, as adding work to the Sprint is essentially the same as having the Dev Team commit to that work.
While adding more work to the Sprint is sometimes a valid approach (again, assuming everyone on the Development Team agrees), other options are available as well. There are many ways to make use of slack time. Pair programming (even if he is not 'suitable' for some other work, he may be able to learn by pairing up on it). Code review. Writing documentation. Independent learning/research. Performing spikes/low-priority side-projects. Et cetera.
You need to build a plan / road-map for this friend so he / she can, at least to some extent, contribute to other stories. In order for said plan to be successful you should align with other roles: Product Owners / Managers etc.
Just start with some small Proof of Concept / spikes and research tasks in the domain of other colleagues. Then organize some pair programming and soon you will see first results.
There are various reasons for which such a strategy might not work. If this is the case, figure out which tasks outside the backlog which are beneficial.
Having idle team members work on bug prevention steps such as tweaking automation tools, reviewing tests, doing root cause analysis of recently resolved defects, and revising documentation would be more effective in the long run.
For future sprints, backlog estimates may need to be revised in a different way:
For a two-week Sprint, five percent of the duration implies that each Sprint there is a half-day Product Backlog Refinement workshop. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. With this practice, Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items. A sign that this refinement workshop is not being done (or not being done well) is that Sprint Planning involves 24 significant questions, discovery, or confusion and feels incomplete; planning work then often spills over into the Sprint itself, which is typically not desirable. Ending the Sprint One of the core tenets of Scrum is that the duration of the Sprint is never extended – it ends on the assigned date regardless of whether the Team has completed the work it committed to.
Establishing a baseline for commitments based off of past experience is key:
A Team typically over-commits in its first few Sprints and fails to accomplish its commitments. Sometimes it then overcompensates and under-commits, and finishes early (in which case it can ask the Product Owner for more Product Backlog items to work on). But by the third or fourth Sprint a Team has typically figured out what it is capable of delivering (most of the time), and they will meet their Sprint goals more reliably after that. Teams are encouraged to pick one duration for their Sprints (say, two weeks) and not change it. This helps the Team learn how much it can accomplish, which helps in both estimation and longer-term release planning. It also helps the Team achieve a rhythm for their work; this is often referred to as the “heartbeat” of the Team in Scrum.
Standardizing the definition of done to include code that can be measured and visualized can also help. For example:
In addition, spending time to update APIs and code that use deprecated data is always a good use of time.
References
I would have simply switched him to pair programming or pair him in any other task.
I think you should check out the Wikipedia article on pair programming. The Question asked is not unique but happens in many teams... two people working together will not only be more efficient but also gives an opportunity to brain storm.
