Self-Management versus Scrum 'rules'

This type of behavior is usually a result of some larger dysfunction. For example, the team does not value (or want) continuous improvement. These dysfunctions can be worked on in Sprint and may lead the team to see the value in following the 'rules' of Scrum. You may also have a team that values remaining hidden within the organization, in which case you have your work cut out for you. Not having a retrospective is dysfunctional. Call it out as such and continue to coach the team towards removing dysfunction. How you do this is a bit of an art form but there are many techniques available. Books, Scrum.org courses, seminars, etc. Alternatively, I would be happy to discuss this with you more offline.

That would be great...my email is jill.graves@cra-arc.gc.ca. I understand what you are saying....but the choices on the exam were:

Stop having retros...the team is self managing
Continue to faciliate positive, retrospectives

When push comes to shove...what wins? Enforcing the rules or allowing the team to self manage?

I had that question too in the PSM I. If I recall right the question was about you being the Scrum Master. As Scrum Master your role is to manage the Scrum process. The scrum process is composed by events and artifacts, one of there events in the sprint retrospective meeting. If the development team refuses to have the retrospective they are outside the boundaries of scrum. Keep in mind that the team is self-managed but inside the scrum process. So your role as scrum master is to keep the scrum process running and healty facilitating the spring retrospective meeting. So I think that e correct answer is the second one. Let me add that the refusal of conducting a sprint retrospective meeting in my experience is a sign of some sudden problem in the development team, if this happens pay attention and try to understand the root cause of the situation maybe asking the five whys.

Are you sure Marcello? :-)

Never sure, just inspecting ad adapting :) do you think I'm wrong?

I wrote a little on this back in May:

http://blog.chadalbrecht.com/post.aspx?id=f13ffe3c-fdd9-44d1-944a-ce9a8…

If I'm taking the PSM I exam...

My answer is to continue to have retrospectives, but it's been a while since I took that exam and I don't know first hand what the "correct" answer is.

Also, I have always interpreted the "self organizing" aspect of the team to be "self organizing to do the work", not "self organizing to change Scrum."

In short, it is not the role of the Dev Team or PO to change Scrum. It *is* the role of the SM to enforce the Scrum principles, roles, etc, and make sure Scrum is followed.

These sentences in the Scrum Guide seem relevant:
"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team."

In practice...

I've always interpreted this is as: "The Scrum Master makes *sure* that Scrum is followed, in the nicest way possible."

If the team rebels against this, I would look for some underlying dysfunction or team level impediment and try to get it solved. If that doesn't work, I'd escalate to someone higher up, in the nicest way possible. :-)

I have always viewed the "inspect and adapt" motto to mean "inspect and adapt, *within* the Scrum framework."

Charles
http://www.ScrumCrazy.com

I agree with Charles. "Self-directed" teams do not select what they will do, only how they will do it. As a Scrum Master, I would encourage the team to change retrospectives to be as useful as possible. The team doesn't get to "choose" not to have them.

Mark Noneman, PST

I have had this with several teams, for different reasons. The best way to address this issue was by conducting a retrospective :-)

Of course I didn't call it that, but I asked my Team to come together and explore the reasons why they didn't want to do a retrospective. In all cases, the underlying issues could be identified and solved (even though not right away). In my experience, a self-organizing team will never want to stop doing retrospectives as long as they have trust that they can change something for the better and they are not punished for making problems transparent. In my case, it always were "beginner-Teams", trying to opt out.

It's the brilliance that comes from Toyota where the Chief Engineer is responsible for the results of the product but has NO authority over the people doing the work! John Shook called it "responsibility without authority".

So if you have no authority you cannot force your team mates to do anything. You you have to coach them by presenting real facts, making them aware of the need for a retrospective , making them aware of potential improvements and make sure that when you have a retrospective it results in valuable, measurable improvements.

You know you're did a good job when your team members think they did it all themselves.