Skip to main content

Self-Management versus Scrum 'rules'

Last post 09:28 am September 5, 2012 by Cesario Ramos
10 replies
04:40 am August 10, 2012

I realized after taking the PSM 1 assessment that I am unclear about the priority of having a self managing team versus the practice of Scrum 'rules'. Specifically - if the team does not want a retrospective what is to be done? My personal reponse on this would be to question (challenge) the team on this, but if the team still didn't want it, I would comply with the teams wishes. I would then question/challenge them again after running the sprint - specifically on their thoughts on continuous improvement. Alas,.....this was not one of the answers. So...what is correct in this scenario?


08:22 am August 10, 2012

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.


08:40 am August 10, 2012

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?


04:06 am August 11, 2012

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.


07:58 am August 11, 2012

Are you sure Marcello? :-)


08:40 am August 11, 2012

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


10:16 am August 26, 2012

11:58 am August 26, 2012

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


11:26 pm September 4, 2012

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


02:59 am September 5, 2012

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.


09:28 am September 5, 2012

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.