Can we add new developers once a sprint is started?

There are 3 developers in the scrum team. The sprint has been launched, in which only prioritized tasks (Sprint Backlog) will completed. The existing developers are 100% busy to achieve the goals of the current sprint.

Why aren't the Developers planning a clear Sprint Goal nor allowing for any contingency in achieving it?

My advice is to get this right before adding more people. Scrum is about learning to build the right thing at the right time.

There are a lot of problems in this scenario.

The sprint has been launched, in which only prioritized tasks (Sprint Backlog) will completed.

The purpose of a Sprint is not to "complete" the Sprint Backlog. Instead, the commitment made by the Developers at the Sprint Planning event is to the Sprint Goal. Committing to a goal rather than a body of work gives the team flexibility to handle emerging work and other events that may arise during the course of the Sprint while giving stakeholders something to expect before the conclusion of the Sprint.

The existing developers are 100% busy to achieve the goals of the current sprint.

Working at full capacity is not a good practice. It leaves no room for when the unexpected happens. The team may discover that some of the Product Backlog Items selected for the Sprint have unexpected work associated with them. Someone on the team may need to take unplanned time off from work. There may be a critical and time-sensitive request from a key stakeholder that needs to be addressed within the Sprint. There's work to support discovery activities and refinement. There are also overhead activities associated with the job and company that take time away from product discovery and delivery work.

However, the customer asked to develop and launch a new business process within the next two weeks. Estimated implementation 60 hours.

This seems fine, on the surface. Although I would question why, if it is so urgent to launch within the next two weeks, why it was an unknown until now. In my experience, not many things are discovered to be necessary and need to be delivered with such a rapid turn-around time. There's plenty of opportunity to understand what happened here. If this is a regular occurrence, the team should look at their Sprint cadence and how it aligns with cadences of key stakeholders.

The customer asks to add up additional developers.

If the team is a self-organizing and self-managing team, the customers don't have a place to change the composition of the team. What outcomes or objectives are the customers looking for? The team should examine those outcomes and find their own solutions, which may include expanding the team.

Developers are always busy, their work calendar is planned for a long time 

Why do plans extend so far beyond the Sprint? The Sprint is the team's planning horizon. Having long-term plans reduces agility as the team needs to change those plans when they learn something new.

New developers must be immersed in their project

Immersion of a new developers in the project, especially for the implementation of a task with the specifics of the client's business, eats up a lot of time of the team, including the product manager.

These are true statements, but I'll also go another step. Adding people to a project reduces the capacity of the other people on the team to do work associated with delivering value. Until the new team members on onboarded and trained, the stakeholders will have to accept a reduced rate of delivery. It sounds like the work is time sensitive, so it doesn't seem like something they'd accept.

What would be the best possible solution to handle this situation?

It sounds like the key stakeholders could use some education around Agile and Lean methods, their advantages, and how to best work with a self-organizing and self-managing team to focus on value delivery.

the customer asked to develop and launch a new business process within the next two weeks. Estimated implementation 60 hours. 

What is the customer basing their 2-week estimate on?   Will the customer be willing to make themselves available throughout the next 2 weeks, to support discovery and quick feedback around such an unknown requirement?



If the team working on this request is not providing either the 2-week or the 60-hour estimate, how can your company or the customer have any reasonable assurance that such a short timeframe is even achievable?



Perhaps taking the next couple weeks to discuss and refine the request, and plan for it accordingly, is a better course of action, and can dramatically improve the chances of success?



"The customer asks to add up additional developers."

• Why does the customer believe the current team is incapable of delivering their request within the 2-week target?
• How many 'additional' developers does the customer feel are needed to do the job?
• Does the customer have in-depth knowledge of your company's IT processes and schedules (refinement, development, testing, release) to even make such a request?
• Are both your company and your customer aware that there is usually a productivity decline when a team needs to adjust to roster additions or subtractions (Tuckman)?