Scrum Master not Following Scrum Guide
A little backstory, our team wanted to started trying to implement Scrum about a year ago. We currently have four developers on the team, including our Scrum Master. Previously, everyone worked very individually on usually long running projects. What would happen though is that the inevitable random issues would crop up fairly regularly and prevent us from getting those projects done according to their original time estimates.
Our current SM brought up that Scrum might be good to try in order to alleviate some of the interruptions. He said that he had experience with Scrum from his previous company, so we made him SM. Keep in mind here that there was probably about as complete buy-in for a first time Scrum team as you could possibly get. Everyone was excited that we were finally going to fix some issues that had been plaguing us for a while. Even with the buy-in, I understand that change takes time. However...
We very slowly started implementing parts of Scrum around April last year. I say slowly because the only thing we actually did from the guide, and very poorly at that, was sprints. It took us several months to get those right. In the beginning, they wouldn't end until all the issues added to them were done and would end up overlapping with the next sprint that started.
Over the rest of the year, we added Retrospectives and Reviews and the Daily Scrum. Each of these additions were several months apart. Part of the reason for that is because our Scrum Master will only ever add something from Scrum if he sees "value" in it.
Fast forward to today and we have all of the events in place and our process is halfway decent. However, to get to here, it's been the developers having to fight the Scrum Master to follow the Scrum Guide. And even then, he just throws some stuff out because "we're a small team".
In our last sprint, I brought up in the retrospective that we can't just be adding issues to the sprint for free. In other words, we haven't met our goal and are nowhere close to it, but something has suddenly become "important" to the PO so we add it to the sprint and start doing that instead. We've previously agreed that when that happens, we need to meet as a team and remove some other stuff if possible or it should wait until the next sprint.
Last Friday, a fairly important but not what I would consider critical issue came up. We have one developer in Texas and the rest of the team is on the West Coast. Our Scrum Master/developer/manager talked with our PO and made the decision for the team that we were going to hotfix the issue that day.
The only problem was, our very inflexible goal was nowhere near complete and our sprint ended on Monday. When the rest of the developers (including myself) got in not much more than an hour later, we found out about the decision. Fixing that particular issue cost our team just about the entire day.
Come the next Sprint Planning meeting, our SM tried to keep the old sprint open (while starting the new one again) so that we could finish up what we didn't get done because of the hotfix to "make it look cleaner" or something.
Our Scrum Master is constantly meeting with other people like the PO and making decisions for the team without consulting the team first or pulling the team into the conversation. He's essentially become our representative in the guise of "removing distractions from the team."
He's ignoring or downplaying pretty important parts of the Scrum Guide in order to "serve the business".
Because I have had no experience with Scrum before, I have no idea what typically happens in the transition or how long it should take. Is this normal?
I've read the Scrum Guide many times as well as plenty of posts on here about various other issues people experience. I'm not trying to downplay the role at all and I understand it can be difficult, but from my view, this doesn't seem right at all.
Other than constantly bringing up the Scrum Guide, which conveniently has parts we don't do, is there a good course of action that we as a development team can take to improve the situation?
is there a good course of action that we as a development team can take to improve the situation?
What's actually stopping you from taking ownership of your way-of-working, right now?
Our Scrum Master is constantly meeting with other people like the PO and making decisions for the team without consulting the team first or pulling the team into the conversation.
Am afraid whether you have the individual with the right understanding and expertise of playing the role of Scrum Master playing that role now.
In continuation to the question from Ian, do you provide any feedback to your Scrum Master?
Also, what are you trying to achieve with this approach? Are you measuring any outcomes?
What's actually stopping you from taking ownership of your way-of-working, right now?
Other than definitely burning a lot of bridges at the least, and possibly a serious step towards losing my job, not much.
I mean, ultimately, that's what I would like to see happen. The ownership part I mean. I think most of the team's frustration comes from the fact that we're trying to constantly police the SM when we'd like to be focusing on other things. And also the fact that we know what the SG says but are told we can't do it randomly.
We have actually had several discussions, some heated, about our failure to actually try and do things the right way and follow the SG. Every one of those discussions ends up with the SM giving excuses as to why we can't do something. And while our PO is fairly hands off, she always defers to the SM because "we'll get there eventually" and "now is not the time to worry about that".
Given that our SM thinks that he is "in charge" of Scrum and our implementation of it (yes, he has actually said that) and that he is officially above the rest of the team organization-wise, it would make me very nervous to "step out of bounds".
I can totally agree Ian and for me, your Scrum Master has the wrong position. If he wants to be a manager he should apply as a manager. But maybe I am wrong and the Scrum Masters intention is to supporting you with his doings. Probably check the Scrum Master role from the Scrum Guide with him and clarify the roles in the team.
Remember him that he serves the team and not the business.
In addition to the great answers of Ian and Martin, I would add that maybe you should make with the SM a workshop, to agree with everybody what are the accountabilites of person, so that everybody agree with the frame. This way if there is a problem everybody can use this frame/agreement to show that there is a problem :D
This would be my way of doing what would be the one of your team ?
Wow, this is really a tough one, Tyler. Issues like this can be really frustrating, especially when you're trying to get familiar with the whole process. The only person who seems to have experience isn't helping the situation either( I say this respectfully). I think you should give Laurent's advice a try. Hopeful it should help, but if it doesn't, you might consider going through your Scrum Master's role in the Scrum guide with him, just as Martin suggests. Goodluck
I'm going to take a different approach to this. Scrum requires organizational changes. Trying to make those organizational changes as a single team of individual contributors will usually fail. Evidence of this is very easy to find in your case. Your Product Owner doesn't understand how to manage a Product Backlog for a Scrum Team. Your Scrum Master isn't establishing Scrum as defined in the Scrum Guide. But since there doesn't seem to be anyone else in the organization that is wanting Scrum to be implemented and the Scrum Master does not appear to be doing anything to educate the organization on Scrum, I feel like you are in a no win situation. I'm going to guess that your management chain is happy with the results you are getting because I expect you would have mentioned the negative feedback.
Yes, you have some people that wanted to implement Scrum. But this statement from the Scrum Guide doesn't reflect the situation you described.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
You have someone that is taking control and making decisions for everyone. That individual is trying to use Scrum as a smoke screen for taking control. If you really want to make changes you will have to go outside the Scrum Framework and pull in that thing that all organizations have...a Manager. Someone in a position of authority needs to become involved. I know you have them at your company based on the scenarios you have described. And even though the Scrum Framework does not recognize those titles, it does acknowledge they exists as the word "stakeholder' is mentioned 13 times and statements like these:
The Scrum Master serves the organization in several ways, including:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
Removing barriers between stakeholders and Scrum Teams.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The Scrum Team and its stakeholders are open about the work and the challenges.
You are attempting a Scrum Revolution in an organization that has not recognized a need for changes. I admire you for your efforts but in some cases, example yours, it may not a futile battle. You may want to stop trying to implement Scrum Framework for your single team and instead focus on using practices and techniques from many agile methodologies and frameworks to make your team more effective.
Our Scrum Master/developer/manager talked with our PO and made the decision for the team that we were going to hotfix the issue that day.
This is your problem right here. Your Scrum Master, is the manager. So, you're not privy to the details or the direction that's almost assuredly coming from a top down command and control perspective.
You, imo, sound more like a scrum master than your boss is, or at least you sound like someone more passionate about the role.
If I were in your shoes, I would try to find another place to work because you are very unlikely to succeed in a mutiny. You've repeatedly brought up that you're not following scrum, and that the team is not working as a team. Since that's obviously being ignored, and you're in an inferior position, speaking truth to power isn't going to make it better.
I'm sorry you're placed in that position, because clearly the team wants to embrace scrum and believes it can actually do some good for you, but instead, you're being controlled by someone who doesn't trust the process and is not being transparent with the team or fostering trust.
Go seek other employment, get an offer in hand, and then bring this to your manager and let them know that if they do not agree to change the process, allowing you to play the role of scrum master, that you will be leaving. Because, based on my experience with this type of environment, you will only continue to be frustrated and experience this impediment if you stay.
You could also try presenting to your managers superior this information once you've received another offer, but that's up to you, it's a power play either way. I personally, would just walk away.
We very slowly started implementing parts of Scrum around April last year.
There are a lot of good advice already given, but I would also want to highlight another part. The possible answer here is not in the Scrum Guide. It is just a framework and you have to complement it with appropriate tools. The change is also a complex problem and needs a proper tool to implement.
As far as I remember, John Cotter's 8 step change is not mentioned on Scrum.org courses but it is actively suggested in other Agile sources and I like it a lot.
The way how you describe the change suggests that there are no sense of urgency and no shared vision of the change trajectory. Such "gradual" change in fact creates a false sense that people may stick with old habits. Sometimes transformation needs to be rather a surgery than a therapy to cut off bad practices fast. It is not only beneficial for the value delivery but also makes it easier for people to relearn new behavior.