Srum Master Stance

What authority should a scrum master excersise when teams intentionally veer from the framework? 

To me, "authority" is indicative of the Command-Control practice of Management.  Since Scrum Masters are servant-leaders we actually have no authority.  The best we can do is influence others.  

In the situation you mention, I have to ask a couple of questions.

• Is the team delivering value and potentially shippable increments in every sprint?
• Does anyone on the Scrum Team (other than yourself) feel like these things are problems?

If you answer "Yes" to the first and "No" to the second, then I would say you have a functional team that is self-organizing and self-managing.  Save your coaching for when things stop working and start to impact their ability to continuously deliver value.

The team adding new cards is not straying away from the framework. The Guide says that the PO is responsible for the Product Backlog but it also says that he can delegate some of the work to the Development Team. If the PO is ok with the cards that are being added by the Dev Team, then you are still in the framework.

The only part I personally have a problem with is the PO assigning work.  The Dev Team gets to decide how the work occurs.  But again, if the Dev Team is not complaining, raising it as an issue, does not have any issues with it, then it sounds like they have self-organized. Again still in the framework. But definitely something I'd do some coaching on by reminding everyone how that is a conflict of interest and reminding that the Dev Team is self organized and no one can tell them how to do the work. 

What authority should a scrum master excersise when teams intentionally veer from the framework?  Things like team adding new cards and PO assigning work?  I realize coaching never stops but what about when a team should be mature ( one or more years working in scrum)? 

How about putting transparency in place over those behaviors and their consequences, and then seeing how a supposedly mature team responds to this information?

One of the primary responsibilities of the SM is to ensure the team lives within the framework. That doesn't mean the SM can squash attempts of the team or anything though; the SM has no authority to do that. Were I the SM in that scenario, I would simply speak up with something to the extent of "Hold on guys. I'm not saying you cannot do this, but if we are going to be a Scrum Team, utilizing Scrum and living Scrum; this practice does not fall within the Scrum Framework. My suggestion would be to do (fill in the blank with an appropriate response that provides the team with the direction needed to live within the framework)" It is a coaching moment, the team can still decide to go down the wrong path, but simply call out that they are out of the framework when they do that.

Telling it's not part of scrum is one way to do this, but I think people in general don't like that as an "explanation", as they shouldn't. If you go down this road, I expect the team to ask you to "decide scrum things" instead of them owning the process.

When violating scrum rules, there usually is a significant risk that comes along with it. Explain this risk, or better: get them to figure this out themselves by asking the right questions.

Norbert, Definitely agree that explaining the risk is a great plan but you still have to explain that if the team chooses to utilize the Scrum Framework; they need to stay within the framework. 

The only concern I have with what I call "preaching the gospel of scrum" is that it may be Scrum, but it isn't Agile.  If something isn't working for your team that is dictated by Scrum, it seems to me that it's more important to find out why it's not working than it is to insist on a specific approach.  Maybe the way you're doing cards isn't working because the PO isn't responsive to the Dev Team's concerns. Maybe the reason that the PO is assigning work is because work either isn't getting done, or not being done to the required level of quality?  Both of those will need to be resolved, but not necessarily by insisting on following Scrum to the letter.

Scrum works, but it may not be the best approach to insist on the following:

1. We have to follow Scrum to the letter

2. If there is any doubt, see rule 1.

To me that's putting process over people, and isn't in keeping with Agile principles.

Scrum works, but it may not be the best approach to insist on the following:

1. We have to follow Scrum to the letter

2. If there is any doubt, see rule 1.

To me that's putting process over people, and isn't in keeping with Agile principles.

I would argue that almost always, Scrum is 'not the best approach' because of a failure to change for the better rather Scrum genuinely not being appropriate. Assuming, however, we find a case where Scrum really isn't the best approach, sure, change it to what works, but don't call it Scrum.

I would agree, with  you, Alex.  My point was that if Scrum wasn't working for some reason, beating people over the head with the Scrum Guide and insisting that Scrum was never the problem, isn't useful.  

This may be my comparative religion major in college coming out, but I am a firm believer in avoiding what I call technijihadism.  Or Technical Inquisitions. 

Is the goal to implement scrum or to release usable increments of software?



I happen to think Scrum is an excellent framework, but I also believe that in some cases, Kanban, XP or other approaches work better.  The important thing is to have a variety of tools in one's toolbox so that the best approaches can be put to use.

My main point was that It's more important to find out why Scrum isn't working than to insist that it's practitioners practice it to the letter.

I think >90% of software dev cases where people think scrum doesn't work for their particular case, they just don't get it.

As already mentioned before we are servant leaders, things can not be forced but can be suggested and triggered with a spark. Retrospectives are good way to bring out impediments, but you have to organize it in the way that you target specific topic and people open themself and find solution.

Second thing is the question how well is the team performing, can it be improved, if yes your goal is to find a way and suggest an experiment to whole team. If they decide yes you go trough and do it, track velocity for few sprints and you are good to go.