0

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?

Is a failure of the team to become agile assumed to be an issue with the Scrum Master? If not, what is the process that a Scrum Master should take?

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.

1
  • 1
    If the scrum master would inherently at fault, the logical conclusion would be that agile is something that can be singlehandedly and unilaterally enforced without anyone being able to push back if they wanted to. That is a high bar to clear.
    – Flater
    May 7 at 8:26

3 Answers 3

5

As a Scrum Master, you can do your best. But your best might not be enough. I have seen people that were so distrusting and obviously hurt by their former bosses and management strategies of backstabbing, blaming and favoritism that they could not let go of those experiences and bring up the initial mental investment of extending a minimum of goodwill and trust to a new beginning.

Teamwork is all about trust. "I need help" is a basic, fundamental sentence in team work. If you cannot find the courage to say it, because you have been experiencing for years or maybe even decades that this sentence only causes you pain from people that will exploit your weakness to its fullest to gain something, then teamwork is impossible.

I have had the fortune of witnessing this first hand. We had a big company with ~50 developers and we transitioned from command and control to multiple Scrum teams. Of the new formed teams, all under the same conditions, under the same Agile Coach and same line manager that did not interfere, some worked great, some just worked okay and some just didn't. Or only formally, but not as a real team. As a Scrum Master, you can educate and offer the opportunities for teamwork, but they have to be taken. You cannot force teamwork and trust on someone. If they don't put out a little bit of good will and see what happens if they are "weak" and ask for help but instead stay in their defensive shell, there is little you can do.

You are a Scrum Master with a potential team member, not a psychologist with a patient. You can lead by example. You can offer opportunities. You cannot make people take them. And you certainly don't have the skillset to fix people's trust problems.

As a step forward, if you find that your offered opportunities are not accepted, find out what the problem is. Do they not trust you? Then you need a different Scrum Master. Do they not trust each other? Then you need maybe a different team composition if you have multiple teams, or you need to replace those people that aren't trusted. Do they not trust the whole process, because they have been burned by the company before? Then there is little you can do.

Make a list of opportunities you offered, explanations you gave, workshops you had, teamwork games you played, demonstrations to show that Scrum and teamwork produce better results. Go through it yourself and think about other opportunities. Talk to your team about it. If you cannot find a solution, talk to your manager about it. Scrum is not a silver bullet. It works through team work, it cannot enforce team work. If you find member(s) on your team to not be team players despite your best effort, you need to switch them out, as you would in any other team.

1
  • 1
    Leading by example by saying, "I need help," has been very effective for me in forming a team from a collection of individuals. Even those who were enthusiastic to try Scrum took some time to open up to asking for help on a regular basis - now there is more recognition that there's no hierarchy: everybody is "best" at some activity and "worst" at another. May 5 at 6:49
4

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. It presumes that the problem is inherently the team or its members, rather than considering underlying process or organizational problems.
  2. It is a form of othering, as if you yourself are not a member of the team.
  3. It is intrinsically hierarchical, implying that you are in charge of the team rather than a guide, referee, servant-leader, or coach.
  4. It discounts any worth or value of the team members as people, employees, or contributing members of the organization.
  5. 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.

1

Agile should be applied considering the work that the company produces. If we are talking about a product or feature that is supposed to change often then agile is a good choice.

After it was decided that agile is a match, then, the meaning of agile must be well understood by people. There are a lot of articles available online and maybe a training for the entire team in this direction is needed in order to make sure the team understands the benefits of using small iterations and deliver often in order to get early feedback.

I would focus more on identifying the benefits that this methodology offers: transparency, adaptability, early feedback, good response to change. These are only a short list of benefits.

If there is the possibility, maybe you can run a trial on a prototype and use 3 iterations to deliver. Make the team realise that after the first iteration, the stakeholders can already visualise part of the prototype and can provide feedback for possible changes. The team can adapt in the next iteration to provide what it was requested. Concrete examples might be your key to success. Good luck

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.