"Violations" of the Scrum Guide in a team/project
Hello,
I've started my Scrum Master journey with a team a month ago. So far I tried to observe and not try to change too much (this is one of the hardest aspects of the job, when I have so many ideas! Not gonna lie, probably my biggest personal challenge right now).
However, there are a lot of aspects that are not done within the framework provided by the Scrum Guide, but which seem rather waterfall-y. These include:
- Stories (not Items) are based on developer roles (front end, back end, UX...), and while they are sometimes tackled by more than one developer (I use the word "developer" in the sense the SG uses it), sometimes a story can't be done within a sprint because of blockers; those team members then work on other topics instead, because...
- there is no Sprint Goal (also no distinguishable Product Goal), so no shared commitment of the team
- Several of the Scrum Events aren't done in the way they are meant to be done (at least in my understanding): The Daily is more a status meeting (and who can blame them? If there's no Sprint Goal, how can the team come together to discuss what's necessary to reach the Sprint Goal?), the Review is a demo of "work done" (and "work" often times does not mean value delivered to the customer); the Refinement (not a Scrum Event per se, I know) is not a discussion/conversation about how items need to be split, but rather "does this story have enough AC and does it have Story Points"
Now I'm having a hard time deciding what to do for more than one reason: First, the team is discontinued by the end of the year, so motivation is at a low point, and there's not much point in improving - to what end anyway?
Second, the whole project setup is...difficult to say the least. My company (or at least this branch) uses SAFe, and it's been pointed out in other places that SAFe brings a lot of rather unagile aspects with it. Some I could already figure out:
- There is no single PO, but a collective, and it's unclear to me whether any of them is the PO of the rest, or whether they're all on the same level; in theory I'm a fan of less hierarchy, but it's hard to figure out whom to ask for priorisation
- Budgeting is in the hands of "the leadership", so it's almost certain that the same thing will happen to the next teams (I'm already set up to be Scrum Master in two teams beginning next year); also, it's almost given that whatever any of these two teams can achieve by the end of next year, they will be dismantled and the team members distributed over other teams again.
So my question:
As a beginning Scrum Master, what should I concentrate on here? Since I'm practising my observing skills and not interfering where it isn't due, I'm thinking of simply making notes on what I recognise, then trying to figure out what the reasoning behind these behaviours (both with management/leadership and the teams) is.
Would love some pointers and insights :) cheers!
Alex
As a beginning Scrum Master, what should I concentrate on here?
Find out who wants Scrum to be implemented in this organization and why.
- What outcomes are they looking for, and how are they different?
- How are they communicating, sponsoring and reinforcing a sense of urgency for enterprise change?
- What do they propose to stop doing in order to start doing Scrum?
If you are working in a company that utilizes SAFe, then Scrum Master is not the same as what you learned from the Scrum Guide. SAFe doesn't use the Scrum framework. It uses SAFe ScrumXP. There are some similarities but it is not the same. If you want to continue working at that company, you may want to spend time studying the SAFe framework and the roles within it.
@Ian's advice is still very sound. Knowing what the "people in charge" expect is always the first thing you should seek. Frameworks do not have process built into them. They allow for processes to be created. Frameworks give you guidance on how to be consistent and productive. They give you something to build upon. But even frameworks need support. So knowing what support you have is key.
Hi Ian and Daniel,
thanks for your pointers! Much food for thought. I'll keep observing for now and try to figure out what the higher-ups are thinking :)
Could either of you shed some light on the question how to balance these two ideas - observing and not trying to change too much on the one hand, and holding the team accountable to the scrum rules on the other?
Cheers,
Alex
A Scrum Master doesn't make any changes. They suggest an opportunity to the team, explains why they feel there is room for improvement and then works with the team to facilitate any changes that the team feels are needed. There is no reason you can't do that while you are observing. That is the reason that we observe constantly.
Also a Scrum Master does not hold anyone accountable for "the scrum rules". A Scrum Master helps people understand the benefit of the roles, responsibilities, and guidance that is contained within the Scrum Guide. The team holds each other accountable.
Hi Daniel,
thanks for the pointers. That's good advice and something that wasn't that clear to me yet.
Happy New Year!