TL;DR
Agility assumes a certain level of skill and intrinsic motivation within a team. Likewise, agile coaching assumes a certain level of mastery of the frameworks and practices you're applying, as well as care and concern for the people on the teams where you yourself are a member.
Agility Assumes a Desire for Continuous Improvement
Does agility assume that any group of people can evolve into an agile team with the help of a Scrum Master, or is it possible that some teams will never evolve and it is therefore not possible for the Scrum Master to do anything with some groups?
Agility is a set of values, principles, and practices. While there is no framework called "agile," many agile frameworks like Scrum and XP do make a few basic assumptions. For example:
- That the team is populated by high-performing people, rather than a random agglomeration of mediocre people. While agile frameworks might make the mediocrity of a team or the failure of management to hire and build teams instead of random groups more visible by creating process transparency, it can't actually fix the underlying problems directly.
- The people on the team benefit from the Theory Y model of management, and are intrinsically motivated to succeed. People who only work well under Theory X generally don't perform well in roles that require collaboration, introspection, or self-improvement.
- The Scrum Master or agile coach is able to effectively communicate how to leverage the framework to the team, to management, and to the organization. While some high-performing teams may not need the level of ongoing help that a new or lower-performing team does, the failure of the Scrum Master role to be able to communicate effectively or to help the team apply and optimize the framework is one source of "agile in name only" implementations.
- Senior leadership is actively on board with agility. The "tone at the top" defines the culture of an organization, and companies that want the benefits of agility without adopting the values, principles, and practices that enable it are simply setting themselves up for failure. Since company culture, hiring practices, budgeting, and organizational structure are all core responsibilities of senior leadership, chronic failures in these areas can't be fixed with any kind of "buzzword management," including ersatz agility.
- The team and the company culture embrace change. Forcing agility on a company culture that doesn't encourage teaming, collaboration, or creativity among its employees, or requiring people to adopt a framework that doesn't fit the composition of the teams or the organizational structure of the company is essentially doomed from the start.
If a majority of these assumptions are simply false in your context, then it's unlikely that an agile framework (or any framework, for that matter) will be successful. Agile frameworks just make the problems with false assumptions more visible.
Agility Assumes a Desire to Create Opportunities for Improvement
All that said, part of the problem is very likely to be with you based on the way you framed the question (e.g. that the team you have is inherently unsalvagable) and a communication style that attempts to blame rather than identify opportunities for improvement. For example, you said:
What I was thinking is that I should raise it with management, and let them know that I cannot do anything with this group of people.
The first part of the sentence is likely correct: you need to communicate continuously and clearly with both the team and your organization about the process and progress of your project. If the process is failing then senior leadership certainly should be informed, especially if the process is not yet transparent enough to make that self evident. However, taking a tone of I can't do anything with these people! does several very negative things:
- It presumes that the problem is inherently the team or its members, rather than considering underlying process or organizational problems.
- It is a form of othering, as if you yourself are not a member of the team.
- It is intrinsically hierarchical, implying that you are in charge of the team rather than a guide, referee, servant-leader, or coach.
- It discounts any worth or value of the team members as people, employees, or contributing members of the organization.
- It is dismissive of any positive contributions that could be received from the team or its members through the application of process changes, education and support, or the adoption of a different framework that would be better suited to the team or the organization.
If your style of agile coaching is command-and-control, or if it creates an environment of blame where "failure is not an option" and a lack of success is punished rather than treated as a learning opportunity, it's extremely unlikely that you are the right person to help the team improve within the current framework or migrate to a better one. There are certainly times when agile transformations fail for any number of reasons, but Occam's Razor strongly suggests that a complete and utter failure without any form of validated learning is more likely to be the result of poor leadership, poor adoption planning, poor framework implementation, or a toxic culture than the likelihood that a "two-pizza team" of 5-10 people (many agile teams aim for around 7 people) is chock-full of incompetent underachievers.
Unless your company culture actively encourages throwing other people under the bus, you'd be much better off communicating the problems and challenges the team is facing and asking for help rather than trying to blame everyone on the team but yourself. That seems much more constructive to me, and much more aligned with the agile values and principles your role is intended to communicate and support.
