Problems that are caused during Scrum when a team member is not full time on the project

In the ideal case, a person will be working on the Scrum project full time, with that also being the assumption made when the several items of Scrum such as Daily Scrum Meeting, Velocity, Burndown Charts, etc are all calculated. However, there are cases when a team is fairly busy in multiple items and people are assigned to multiple tasks. As an example, consider the case of a development process where there is a daily build available to the team; on some days, the build fails and a person in the team is assigned the task of ensuring that the reasons behind the failure of the build are investigated, and corrective actions taken. Such types of tasks (or consider another task where a team member is responsible for the safety and security of the code repository, and that can also take some regular time) take up time for team members away from their Scrum duties, although they are not factored as part of the effort that a person can put in. Consider the case when something out of the ordinary happens, such as too many build failures, the ability of the responsible person to be able to put in 100% effort for the Scrum tasks is impaired, and there will be some shortfall. This shortfall in effort impacts the Scrum tasks progress as well, but analysis does not take the effort spent on other tasks in account.
What are some of the ways in which such other tasks can be handled ?
- If such tasks will happen on a regular interval, enough to cause some impact to the Scrum effort, then it is better to call out such tasks and dedicate one person to handle these (rather than spreading the tasks through the team). Further, since such tasks tend to be more mundane and boring, these can be switched between team members on a regular basis (say, every Sprint cycle can have a different person)
- Set aside one day in the week for these other tasks, or the maintenance efforts. This can be a bit of problem sometimes in tracking since the need for such tasks does not follow the pattern of once in a week, but it can still be useful to ensure that the effort is being tracked
- Set aside some hours every day (could be as short as 1 hour per day) for such tasks, but this gets complicated in terms of tracking and does not take care when the task suddenly develops into an emergency (as a example, when the code repository crashes or reaches an unpredictable state)
- Hire some additional people (who do not contribute to the team effort, but instead have skills more suitable for the other tasks) and use them; this entails additional costs, but prevents any impact to your team effort
- Add such effort (after calculating the effort over a period of Sprints and averaging it out) to the product backlog so that the Product Manager also realizes that such tasks are there and done by the team, and need to be accounted for in terms of effort