Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Scrum suggests small teams as far as I'm aware. This means that we often have single frontend developer, single backend developer, single QA engineer, etc.
Doesn't it negatively affect the project success? If, for example, a backend developer gets sick, then what should we do as a manager? Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? How should this situation be stated in a contract document?
The scrum part is irrelevant of the specific questions asked.
There are misconceptions around Scrum and team sizes. The first common misconception that I've seen is that Scrum mandates small teams, specifically a Development Team of between 3 and 9 individuals. Scrum contains several concepts that are immutable - "roles, events, artifacts, and rules" - and changing these core concepts would result in something that is not Scrum. The statements that "fewer than three Development Team members" and "having more than nine members" refer to the ranges at which Scrum has been seen to be most optimal. It doesn't mean that Scrum can't be used with a Development Team of one or two or ten or eleven people, but with teams smaller than three or larger than nine, there may be problems where Scrum is either introducing unnecessary overhead and coordination or where the communication is complex and events cannot be completed effectively within their timeboxes.
The key characteristic of a Development Team is that they are cross-functional and have "all the skills as a team necessary to create a product Increment". In addition, Scrum does not recognize titles or sub-teams among Development Team members. Having a "frontend developer", a "backend developer", a "QA engineer", and so on is recognizing titles among members. Consider that someone can have expertise in a particular domain or skill, but the team should strive for distributing the knowledge and the ability to work across all members of the team.
In a situation where the team is reliant on a single individual to provide particular knowledge and skills to deliver, that is something that should be identified as a project risk. As with any risk, it can be avoided, reduced, shared, or retained. The risk can be avoided by increasing the team size to double up on key skills or not taking on work that is too risky. It can be reduced by implementing knowledge sharing, and shorter Sprints may also reduce the chance for unexpected events to occur in the timebox. It can be retained by accepting the risk as it is and moving forward.
Scrum doesn't blindly suggest "small teams" without qualification and definitely doesn't advocate for having a team so small that one member being sick means that work can't progress. The Scrum guide says (emphasis mine):
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.
In the scenario in your question of only having 3 development team members, you would be right at the lowest sized team that Scrum recommends. There are various ways to reduce the risks you describe from one team member being unavailable, the most obvious ones would be
Doesn't it negatively affect the project success? Not in any way that wouldn't also apply if you weren't doing Scrum and were bottlenecked on individuals.
If, for example, a backend developer gets sick, then what should we do as a manager? Short term, discuss with the team what the most valuable thing is they can do without that member being present. Long term, work with the team to remove this bottleneck.
Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? - If you can't produce as much value using Scrum as you can when using a different methodology, then either adopt that other methodology or improve how you're doing Scrum.
How this situation should be stated in a contract document? - I wouldn't expect a contract document to get into the level of detail of discussing what happens when a team member is sick.
As you already tagged it, it's (partly) a question about Risk Management, so I'll address that part, since the Scrum part has been addressed in the other good answers.
Obviously, if you decide to have tiny teams, the risk factor of any single team member being unable to work is high.
This would be addressed in your Risk Analysis. I.e. how high is the risk and what you plan on doing to mitigate it. Whether this is added to the contract is a question for your legal team.
As a rule of thumb, we usually pad the schedule taking into account about 20% for sick-leave and vacation. Anything longer than that - or the team member being permanently unavailable - probably falls under the Force Majeure clause, implicit or explicit in contracts.
In conclusion: You never want a situation where a single team member being unavailable for more than a few days would jeopardize the project. You need some contingency plan like having one "jack of all trade" available to take over in an emergency.
I would imagine this is then priced into the contract, though probably not mentioned explicitly.
Mixing DevOps with Scrum helps here, meaning blending responsibilities between developers and operations for greater learning and efficiency. I've seen many projects delayed waiting for an external (and often less motivated) team to take a simple action. Often those admin actions are with an external team such as DBAs out of habit or siloing so moving them to the team is a big help (I recommend the book Phoenix Project, which talks about this as well as CI/CD).
This works especially well if you can hire or grow "full stack developers". Where reasonable, skill sets should overlap. For example while your UI resource may fully understand accessibility, usability and styling fine points, if they get sick a developer should be able to pick up. Moving operations such as database or environment setup to the team will further reduce your risk.
Automated integration tests (ideally combined with continuous delivery) are also very useful here. Done right, they can be written or at least maintained by a developer if you have a dedicated QA person and they get sick. Another approach is to shift that responsibility to developers, though people have strong feelings pro and con there (for example that QA testing is a specific skillset that not everyone can do).
