1

I recently joined a new company as a scrum master. I have six years of experience as a web developer and the last two years as a lead developer.

I did have some experience and I am quite good as a scrum master, receiving good feedback from the teams and managers.

My question is about my new job: in my new experience, there are three developers and two of them are not fans of the scrum methodology. They do not want to participate in some team-building activities and, for scrum ceremonies, they are not motivated at all. They even think that scrum and scrum masters are useless. Conversations were not easy with the previous scrum master (who left this company partly because of the team behavior).

My strategy is to keep proposing team building (they need it for sure), keep trying, but not force them. But being a nervous person, I think I will lose my nerves. Do you think I should involve the managers since the problem is being opposed to the methodology that the company chose (scrum and agile) and against the company's values? Should the directors and managers intervene?

Updates

I proposed some slides to present during the sprint review. In these slides, I proposed to show our work we did during the sprint, so for each developer I proposed a slide where we basically see his/her tasks DONE during the sprint, I just finished the meeting to propose them this new format (before, they had one page slide with the full tasks of the sprint, and randomly developers start to speak..) So my idea is basically to be just a bit more organised, and split by speakers... I get a BIG rejection, this is the argument : NO, this format shows that developer X did more than developer Y and stakeholders will prefer developer X.. My answer: Anyway stakeholders will know what each of you did because even if you'll not have your own page, you will speak from one big list and everyone will know what you did.. I got this point but this is the REAL conflict: they still say no even when you give good arguments.

EDIT I just wanted to edit my post and close it, maybe it can be helpful. So what basically happened was that I decided to keep serving my team as much as I could, but having at some moment, one team member (the same who was against any proposition) was not respectfull with his own manager (he made him cry), he was not respectfull with other team membres, with other people not from his team, so HR sent to him 2 letters so far (3rd one will be the last), being in such a toxic team was not good, plus they did not want to try my propositions as all propositions are countinuous improvement, they did not want to change, so they decided to send email to managment and they said : we do not need a Scrum Master. So I joined a new team in need of Agile and scrum, in the same compagny and literally in the same openspace as the first team, so my take away and answer is : I should have left away before, when the team is against Agile and Scrum Master, and they say it clearly : WE DO NOT NEED IT, do not lose your time and energy trying to convince, life is too short and there so many teams waiting for your services, so say thank you, and move :)

10
  • 2
    "they even think that scrum and scrum master are useless" - this is a very popular opinion. Scrum tends to be very intrusive and distracts the team a lot. Have you looked at more light weight/agile methods like Just-in-time (what many IT folks refer to as Kanban) and Theory of Constraints? These prescribe much less. They don't mandate any meetings, so you can build most of the process yourself as the team wants. Commented May 10, 2022 at 5:25
  • 2
    Closely related: pm.stackexchange.com/q/33930/4271. Basically, though, if Scrum is a management mandate, then senior leadership needs to be involved. Otherwise, the team needs to be self-motivated to use Scrum, or they won't because it's not in their self-interest.
    – Todd A. Jacobs
    Commented May 10, 2022 at 14:28
  • @StanislavBashkyrtsev You often have valid points, but they sometimes get buried under your clear disdain for Scrum and other frameworks and practices. The OP was hired as a Scrum Master, not as an agile coach or business process consultant, so it's safe to assume that Scrum is a priori a company-mandated framework. Furthermore, no process can make a putative team work effectively together, so that's really the X in this X/Y problem. Until that's addressed, no framework that requires trust and collaboration will work.
    – Todd A. Jacobs
    Commented May 10, 2022 at 14:35
  • @ToddA.Jacobs, 1) I didn't answer the question directly and that's why I left a comment, not an answer 2) If OP made a career mistake, he can still fix it. Scrum is not for life - I'm laying out additional options which he probably doesn't know about. Because everyone is only talking about Scrum. 3) Not liking Scrum doesn't mean that the team has issues. Maybe the issue is that someone is trying to force Scrum on a perfectly healthy team. And since the symptoms described by OP are typical for such situation, I think my comment is relevant. 4) That being said, I do disdain Scrum :) Commented May 10, 2022 at 17:10
  • 3
    Regarding the "update" section: why would you present individuals' achievements in Sprint Review? You ought to be presenting what the Team has achieved, rather than perpetuating the belief that individual developers "own" stories. I think that might be indicative of why your team members are reluctant to work together on stories. Save the per-developer stuff for the Retrospective where you don't have stakeholders present, and probably ditch it altogether in favour of "how can the Team do better?". Commented May 16, 2022 at 17:04

6 Answers 6

4

Scrum is about collaboration, trust and empowerment.

It is going to be very difficult to make people do those things. They have to want to do them.

Some things I would suggest include:

  • Try and build up trust - perhaps by giving them good advice or by being an effective facilitator of their meetings
  • Spend time coaching - try to get them to understand why they would benefit from following the Scrum framework
  • Use the retrospective to hightlight challenges the team faces
  • Introduce them to teams that are successfully using Scrum

If you do decide to speak with your managers, ask them to motivate the team to be more agile. Perhaps by setting agile objectives (e.g. "Demonstrate a good Scrum process") and rewarding them if they do this well.

2
  • I kinda agree with you, we need to keep proposing things to the team, and build trust, but can you please check my last updates I just added to my initial question Barnaby, you'll see what kind of "conflict" it is, it is not easy to "propose" even, so when you get rejections to any idea, it is hard to "fight" being scrum master Commented May 11, 2022 at 12:31
  • 2
    I would recommend until the trust has built up that you focus on describing problems rather than presenting solutions. In the example you give, I would have raised in the retro something like: "I've noticed that when we talk about the work we have done we end up jumping around between the speakers. Is there anything we can do as a team to improve this?". Then support the team in their discussion to find a solution. Commented May 11, 2022 at 16:11
2

If you are trying to make your team follow Scrum, or any methodology, and especially an agile methodology, you are doing something wrong. However, there are a few things that you can do.

First, for the developers who do not want to participate, understand why. There could be any number of underlying reasons why they are hesitant. Understanding why they are hesitant to participate and at least try can reveal some ideas for what you can do to build a collaborative environment.

You should also understand what the organization hopes to achieve. I'd consider forcing teams to use a specific methodology without good reasons to be against the principles of Agile. One of the values of Agile is "individuals and interactions over processes and tools" - mandating and enforcing Scrum, or any other framework, is putting processes over people. Similarly, sticking exclusively to Scrum is failing to uncover "better ways of developing software by doing it".

Ultimately, I've found the best way to convince people is to solve their problems and make their life easier and better. If you can figure out what problems people are having or what pain they feel in their daily work and work with them to find solutions, you can probably win people over to the underlying ideas.

4
  • I don't think it's correct to say "agile methodology". Your team or your process can be agile. On the other hand Scrum, Just-in-time are methodologies, they prescribe a particular response to particular situations. Commented May 10, 2022 at 5:14
  • 2
    @StanislavBashkyrtsev I mostly agree. "Agile methodology" is a much more concise way of saying "methodologies that tend toward enabling teams to function according to the values and principles of the Manifesto for Agile Software Development". The methodologies and frameworks created by the authors of the Manifesto - Scrum, Extreme Programming, DSDM, Crystal, Adaptive - are some examples, but there are others, including unnamed homegrown methods. If you claim that your process or team is agile, and then constrain the team to follow only that process, then your claim of agility is wrong.
    – Thomas Owens
    Commented May 10, 2022 at 9:18
  • Sorry, I thought your post meant Agile as a noun. But you meant it as an adjective. Commented May 10, 2022 at 10:12
  • @StanislavBashkyrtsev Yes. If you have a better phrasing, please let me know. I don't like using "agile methodology" since it can be confusing, but the verbosity of other options also can be confusing.
    – Thomas Owens
    Commented May 10, 2022 at 10:29
2

being against the methodolgy that the company choosed (scrum and agile) is being against the company's values, and the direction/managers should intervent ?

I'm going to go against the mainstream here and say yes. Scrum is not a thing you voluntarily do from the ground up. Scrum (and Agile) are management methods (maybe frameworks) that are a conscious decision of a manager.

Just imagine the opposite: a company operating on strict milestones of a waterfall project and the project manager asks "did you finish the milestone" and the answer is "naah, I hate waterfall, I didn't look at the milestone, I did something else instead." That is not behaviour that needs gentle encouragement and motivation from a peer, that person needs to be reprimanded and fired by management if they continue.

Scrum is not different. Yes, you as a Scrum Master should explain and demonstrate and motivate. But you are not the person to make people show up to those workshops. Those workshops are mandatory and if people don't show, they need to be reprimanded and/or fired by management. Because this is not chose your own adventure. This is a job. And just deliberately not showing up to mandatory sessions should get anybody fired. It's the one thing that should definitely get one fired all over the world. Refusing to do the work as assigned for no good reason.

So yes, Scrum is based on teamwork, but just as in any team, you cannot decide to not participate, but expect to still be paid. A football team is all about team work if you want to win, but you will find out how fast you can get fired from it, if you just sit down at the sideline and say "naah, this whole passing the ball thing isn't for me chief. And I don't see the purpose of this strategy training meeting either, I'd rather kick the ball some more in the back yard without all the other people."

If management decided that you are doing Scrum (and I think shelling out money to hire a Scrum Master is a good indicator at least on paper) then there is two ways this can go: either the people do Scrum, or they get transferred out. Out to another division that doesn't do Scrum if the company is big enough, or just out of the company.

The fact that the previous Scrum Master left over this issue is a red flag that management is actually not supporting Scrum to this extent. And sees you as a Scrum salesman that has to close the deal no matter what, so they don't have to actually manage. But that is an impossible task. There are people who don't want to work as a team, not matter what you do. And that is fine. They might be good people and good workers under different systems. But you cannot have them on the Scrum team then. They need to work elsewhere. That needs to be managed well above your pay grade in the hierarchy.

2

I'll give my ideas on a few of the subjects you've raised:

There are three developers and two of them are not fans of the scrum methodology.

Change is scary, and the developers may not recognize any benefits from scrum. They may also have very poor experiences with it, or feel that they'd be expected to churn out product after product without pause. Many companies use scrum and agile for "getting more out of less" which isn't a great way to work. I'd ask what their experiences are, what they feel worked, and what they feel doesn't (a one-to-one retro, in effect).

They do not want to participate in some team-building activities

Neither do I. Some people don't like "team building" activities, and that's OK. If they're like me, they build their teamwork by working together. It's an organic process that shouldn't be forced - I've never known it to end positively when people who prefer a purely organic way of team building get forced into team building activities. I have known several people get hostile towards colleagues afterwards, which is something to avoid. Learn the way the individuals on the team operate and give them the room to grow based on that, as individuals.

for scrum ceremonies, they are not motivated at all

I'd look for reasons why they feel this way. Do they think they're getting anything useful out of it? If not, what are they not getting? People don't like having their time wasted and if they feel the ceremonies aren't a good use of their time, that'll demotivate them. How can we set things up so we get out of their way and let them focus on their work?

They even think that scrum and scrum masters are useless. Conversations were not easy with the previous scrum master (who left this company partly because of the team behavior).

This seems like a less than ideal experience with scrum masters in the past. All you can really do is show the benefits of having a scrum master around. Actions are the important thing in life, not words.

My strategy is to keep proposing team building (they need it for sure), keep trying, but not force them.

This should work, but be prepared for pushback and don't take it personally. If the team don't find team building useful, be ready to stop and let it happen organically. Give them opportunities for cross-working and remind them that it's the team that delivers the product, not the individual.

Do you think I should involve the managers since the problem is being opposed to the methodology that the company chose (scrum and agile) and against the company's values? Should the directors and managers intervene?

Only as a last resort, and it feels like you're nowhere near that point. How would you feel if the directors and managers started clamping down on you? Not "how would you feel logically" but emotionally? Don't take any time to think of the answer, because that's not the answer you'd get it if happened in reality.

Remember, people are people, and the aim of scrum is to help people do stuff. It's one way, not necessarily the best way, and if you want to work with a self organizing team that means they have to feel self organizing across the board. If they're directed from above, does that make them self organized?

I proposed some slides to present during the sprint review. In these slides, I proposed to show our work we did during the sprint, so for each developer I proposed a slide where we basically see his/her tasks DONE during the sprint, I just finished the meeting to propose them this new format (before, they had one page slide with the full tasks of the sprint, and randomly developers start to speak..) So my idea is basically to be just a bit more organised, and split by speakers... I get a BIG rejection, this is the argument : NO, this format shows that developer X did more than developer Y and stakeholders will prefer developer X.. My answer: Anyway stakeholders will know what each of you did because even if you'll not have your own page, you will speak from one big list and everyone will know what you did.. Remember, in scrum it's the team's responsibility to deliver, not any one individual's. The team delivers product. No single developer fully delivers something if you've got all the skillsets needed - does the developer also run their own testing? Testing's a huge part of the team. Does the developer write content and messaging? Does the developer do any of the user interface design work?

I got this point but this is the REAL conflict: they still say no even when you give good arguments.

Your role is to facilitate so the team can deliver. Your "good arguments" haven't landed with the team, which suggests the arguments aren't as strong as you think they are. We all get wedded to the ideas we have and need to step back and have that separation so we can take on board what other people say. Never take it personally if they don't like your idea - you shouldn't ever force them into something that doesn't work for them, it'll just make for some very tense situations down the line.

1
  • 1
    Thanks Karl for such a good and detailed answer. So far, we did some progress, some icebreakers, I am learning more about the project itself as I am new, and I noticed that it's a good moment to make them share and discuss, so seems like time/patience are my best friends ;) Commented May 31, 2022 at 9:01
1

I think first of all you have to educate the team what scrum is. If they consider scrum useless you try to understand their point of view or concerns. Then you try to explain or answer those questions.

After they understand scrum better only then they will adapt to it.

Scrum master role is more of a servant leader. Therefore you don't have to force them to follow scrum. Rather they have to adapt to it themselves. You just have to enable them to be able to follow the scrum principles and the necessary mandatory time box events

Furthermore this is true that scrum is not the only agile framework there are other agile and non agile approaches and all work one way or the other with proper application and dedication. If scrum is being used in your org it means it has to be supported by the organisation executives as well as the development team.

If team feels that its not the right approach then may be you can hold an org meeting with top executives and team as members where you can discuss and clarify that this is the approach we have to follow as the organisational policy. Transparency is one pillar of scrum and agile too.

0

It does not matter the methods you choose to deliver your project. The hired employees need to get on board or they need to leave. It is one thing, when the company is trying to choose an approach or direction, to solicit ideas from your team, allowing them some autonomy to figure things out since they are the workers doing the work. It is quite another for the team to "strike" because the chosen method is one with which they disagree. If your organization made a decision, then the team needs to get with it. If they cannot, then find a new team. It really is that simple.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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