Situations like these are often negative feedback loops.
- Bad practice and (unreasonable) technical challenges lead to significant development issues and obstacles.
- Significant development issues and obstacles lead to (good practice) developers leaving the project
- High turnover rates means the work is mostly done by developers who are new to the codebase. Because of the development issues and obstacles, these developers make mistakes and cannot handle the already flawed codebase, leading to more issues.
Note that I'm not digging into the specific issues themselves as you didn't really elaborate on the technical side of things here - you mostly describe the social/HR challenges as opposed to technical ones. But it's my educated guess that there are significant technical challenges that are at the base of this social/HR issue.
Your question suggests that the project in question contains these issues and obstacles:
- "an astonishing amount is not known about any part of the system"
- "The team doesnt seem to know much more than what is required to get through the next sprint."
- "then he would have twice as many bugs to solve and would never get his sprint done"
It seems like there is not much effort being put into the quality of life for the development cycle (and, by extension, the quality of life of the developers).
First, I want to prepare you for something that you're going to have to deal with: This is going to suck for a while. It will require effort to fix these problems and the payoff will not be immediately visible. If you/the team/the company are liable to balk when there is no immediate payout to effort put in, this issue may not get resolved.
Until it does, your team will be putting in more effort than you currently are, and if people are already at capacity, it's going to be hard to keep morale up when asking for even more effort. It can be beneficial to hire several extra consultant for the short term so your developers can keep up with both the daily workload and the improvement process at the same time.
This feedback loop can be broken, but you need to address several topics: development practices, work attitude and ethics, management and planning.
Based on your description, there is an environment of developer fatigue and an unwillingness to deal with "even more" bugs. This goes to show that the current development life cycle is already too riddled with technical challenges, which is making your team unwilling/unable/inflexible to tackle unexpected issues that may arise. That's a really big problem.
You haven't elaborated on the technical challenges, so I can't do more than suggest to brush up on good practice and actually fix things rather than patching them. These are suggestions based on my (anecdotal) experience of what commonly leads to an undesirable codebase.
Work attitude and ethics
You're right that the conversation you overheard shows an attitude problem. However, more often than not, the attitude is a reasonable coping mechanism to deal with an unpleasant situation (see the above development practices section).
If that is the case, you should not approach this as a behavioral issue. Doing so will lead to two possible outcomes: your developers leave, or they simply do not voice their issues anymore and it'll decrease communication in the team.
Instead, you should investigate the voiced unhappiness to find the underlying problems. The unhappy developer might be able to identify or even suggest a fix to the problem that is causing them unhappiness, and it's up to the team lead (or the company) to assist their employees so they can do their work.
Should this be a case of bad developer attitude that is not grounded in development issues, then you may need to take the HR route, but only do so once you a certain that this is the case. If you guess wrong, you're going to make things worse, not better. Any misstep on your (or the company's) part is going to be seen by all employees and will have a massive impact on both employee and team morale.
Management and planning
One of the things that really stood out to me is how developers are thinking about bugs:
he would have twice as many bugs to solve and would never get his sprint done
This suggests to me that bugs are currently being considered as "extra" work on top of the planned sprint. That is a major red flag that you are overloading your sprints, which is driving your developers to fatigue and is causing them to make bad decisions along the way.
Bugs are part of development, and they should be estimated and planned as well. I'm aware that it's not always possible to reasonably estimate how long it takes to resolve a bug (could be 5 minutes, could be 5 days), but in either case time must be allocated specifically to resolve bugs.
If a developer knows that when a bug is found, it falls on them to take it on in their own time, then you're going to create an atmosphere that incentivizes developers to avoid bugs until they can't avoid them anymore. This creates a huge technical debt, which contributes to or is the predominant source of the technical challenges in the codebase.
Since you do point out a lack of bigger picture knowledge, documentation goes a long way here. Similar to bugfixing, if you want your developers to not cut corners when writing documentation, then there should be explicit time allotments for writing documentation.
- Developers need to be more proactive about good practice and bugfixing, but the team/company should support them in doing so.
- The team lead should investigate common issues and experiences and actively work to alleviate them. Happy developers lead to better task handling.
- The planning should specifically free up time for bug fixing and documentation. This can be done by adding a blanket padding to tickets to account for unforeseen circumstances; but extra time should be allotted for sizable bugs with a wide ranging impact or long expected time to resolve.
- More generically: any behavior the company wants to incentivize should therefore be given incentives (i.e. planned time to dedicate). Don't expect your employees to pick up extra slack and take on more work without any recognition of that effort required. And no, a pat on the shoulder doesn't cut it.
- This initiative will cost more effort without paying off in the short term, but it must be endured if the situation is to improve. Though it comes at a cost, hiring additional developers for a short term can alleviate the added pressure, especially when the current developers are already fatigued and on the edge of burning out.
- If the company is unwilling to put take the time and effort to improve their employees' quality of life, then high turnovers are a logical consequence that cannot be avoided.