Team doesn't see value in Scrum
Hi,
I am a Scrum Master who has been working with a couple of different teams over the past few months.
One of the teams I joined, from my observations and discussions in retro's, don't want to follow the basic rules of Scrum. eg. One of the developers sees no point to the Planning meeting, and is happy once the items have been Groomed in advance to figure it out himself once he picks it up - he has made it clear he sees himself as a prisoner in most of our meetings and does not want to go. Another developer sees anything process related as being a waste of time, and just wants to focus on coding. The team don't have a stable velocity, and there is no concern if stories don't get done within the sprint. We do retro's, and I try to explain the benefits and reasons we do these meetings, practices, etc. and I have given workshops on things like writing user stories, Agile values, etc. - its clear Scrum or Agile is not widely accepted by the team. Here's the thing: the Product Owner is happy, the team is happy with the way things are, and management aren't concerned or putting pressure on around things like predicability, as we have very long release cycles to our production environment (every 6 months). I find this a difficult position as a Scrum Master to work in and its not something I've experience with other teams before. Has anyone ever been in this situation as a Scrum Master, and if so, what did you do?
If people are happy right now then that's great. Perhaps the organization faces little risk and complexity and don't actually need Scrum.
Rather, the problem would lie in pretending to do Scrum. It's important to avoid using Scrum terminology where Scrum isn't happening. If I was you, that's where I'd start. I'd correct people when they use the terminology inappropriately. I'd explain what is needed for the words to hold true. Part of being a Scrum Master is being an organizational coach. If coaching is perceived negatively by the organization - and it might be - I'd want to flush the problem out.
Hi Ian,
This is the feeling I get - the organisation doesn't see a risk of doing things wrong because they are quite far ahead of competitors.
Any advice on flushing the problem around coaching perceptions out?
I had faced a similar issue sometime back, rather than trying to implement/force Scrum, I gave myself time to understand/observe areas that need attention or most prominent areas of focus.
Then taking clues from Agile principles, I started making smaller changes that would help the individuals/teams. In 6 months time there were many Agile practices that the team were following without actually using Agile terminology.
Being rigorous around the use of language may be enough. It's part of a Scrum Master's job to coach people in the appropriate use of Scrum vocabulary. When people are content to fake Scrum they may view such coaching negatively. Be warned though, it can bring things to a head. The question then becomes: does the organization even *aspire* towards implementing Scrum properly, and if not, do they really need the services of a Scrum Master?
Ian adding my experience to your last comments ""The question then becomes: does the organization even *aspire* towards implementing Scrum properly, and if not, do they really need the services of a Scrum Master?"" I have had the same feeling where in I felt whether the organization really need the services of the Scrum master or not. They were just faking to put a face in front of the customer and no one from the team or management believes in Scrum.It's like "we will and want to do our stuff like this only" who are you to teach/mentor or coach us.
The situation were so worse that ultimately they lost the customer.
Any suggestions/ real examples on how to deal with such situations?
A Scrum Master ought to have a low tolerance for organizational impediments. These impediments can include weak sponsorship, such as poor communication by management of the urgency for change.
My advice is to understand what your own level of tolerance for organizational impediments should actually be. That's the way to deal with it. There is no single right level that must be held by every Scrum Master. Your personal tolerance may change over time as your experience and circumstances evolve. The important thing is to have an honest and ongoing conversation with yourself about this matter.