Enforcing scrum roles is creating resistance

Last post 03:27 pm May 5, 2020
by Daniel Wilhite
9 replies
Author
Messages
02:36 pm April 23, 2020

Hi Guys,

I am a scrum master of a scrum team for quite some time now and i am experiencing a hard time with coaching roles as it is being treated as a "change" in the way we currently work. 

One good example is this scenario,

Product owner should be aware and know exactly what goes in and out of the backlog. 

For me the way it is perceived is that the product owner thinks that i am telling how to do his/her job when i am raising scrum roles to be followed. 

I am doing partly the role temporary because it would impact the team if the voids are not filled and the next steps is to actually transition them to the P.O.

I am running out of answers with how should i approach this as this was escalated many times and i dont feel that i am getting the support i need. 

Was wondering if some of you guys can help me with this as i am about to give up with pursuing Scrum and stick with the current setup which is like just scrum titles to say we are agile. 

Thank you,

07:40 pm April 23, 2020

What could happen if you step aside and actually allow PO and Dev Team to do what they think is enough to do? Maybe it is only your assumptions and everything will be fine, or maybe the other way around. But consider stepping back, sometimes only by allowing someone to fail, you can move together forward in the long term.

03:08 am April 24, 2020

Thanks Piotr for your response, 

 

To explain the context, what we currently have is Waterfall approach masked by "Agile" roles. A big project being identified, gather the requirements at the start, a design phase, and an implementation phase.

 

I am also seeing that the roadmap that we currently have reflects not the actual work needed for a feature to be completed, but reflects the "deadline" of the committed features to the stakeholders. This is a double edged sword as the development team can't visualise properly the needed work and is ending up with the below based on actual experience,

 

Too short commitments - Pressured development team members struggling to complete everything within the dates

Too long commitments - Unclear direction what to do once the required development work is done. 

 

If this is the case, stepping aside would mean we will still follow the traditional way of software development. We would succeed the team chooses to do the waterfall approach as i trust that they would deliver. 

 

However my goal is to educate on how to become agile, and we are doing the best we can (SM and Dev team)  translating those requirements into agile. But it seems we are not getting the support from the product as the team is expected to just build whatever the stakeholders want.

 

07:29 am April 24, 2020

Where have you seen cases where they would have been better off with the PO knowing indeed the insides and outside? That can be a supportive argument for the case you're trying to make. I guess this is also what Piotr means with letting them fail, inspect and adapt.

11:41 am April 24, 2020

Yes i am, partly my role is also part of a team lead. it works well though but it is hard to get the product vision. since the only focus is the next big project. 

however i am looking for the sense to shift responsibilities for the benefit of every body. 

Right now, it looks like the best way is to leave everything as is. as mentioning this scrum roles is just creating conflict.

07:24 am April 27, 2020

I am a scrum master of a scrum team for quite some time now and i am experiencing a hard time with coaching roles as it is being treated as a "change" in the way we currently work.

Where did the idea of implementing Scrum in your organization actually come from? Why is the attempt being made? Who in the organizational executive wants change to happen, and feels a sense of urgency for it?

04:48 pm April 27, 2020

I am going to join in on @Ian Mitchell's comments because your statements seems to indicate that your organization is not supporting these changes.  If you do want to champion Scrum adoption, you have to go beyond the team. The Scrum Guide list 3 areas of responsibility that the Scrum Master has.  You seem to be focusing on the Product Owner and Development Team while totally neglecting the Organization.  

Yes i am, partly my role is also part of a team lead. it works well though but it is hard to get the product vision. since the only focus is the next big project. 

I suggest that you are wrong.  It is not working well as evident by your comments.  It doesn't seem to be working at all if you are doing the job of Product Owner, Scrum Master and team lead (which is not a role at all in the Scrum framework).  You are undermining the very goal you say you want to achieve by doing all of the work for the team instead of letting the team self-organize.  You are undermining yourself by not helping the organization as a whole understand how Scrum, or any other agile practices, will benefit the value delivered to the stakeholders which in turn will benefit the organization. 

The fact that you are trying to enforce Scrum roles is another sign that you are undermining yourself.  No one enforces anything in Scrum.  Everyone understands and values the make up of the Scrum framework can provide and desires the impact. 

If the organization has been successful with waterfall, then why are you "Enforcing Scrum roles"?  Is there any empirical evidence to support that Scrum would be a better solution?  How would you as a Scrum Master go about helping the organization to realize that using and supporting the Scrum framework would provide a positive impact? 

08:38 pm April 27, 2020

the roadmap that we currently have reflects not the actual work needed for a feature to be completed, but reflects the "deadline" of the committed features to the stakeholders.

Who identified these dates, and what data did they use to support such expectations?   Did any of the estimates originate from those doing the work?

Pressured development team members struggling to complete everything within the dates

It cannot be overstated that in Scrum, NO ONE pushes anything to the Development Team.   The Development Team must be in charge of what they believe they can comfortably achieve over a given time period (i.e. - Sprint).   

If this is not happening, or this way of working is not being supported by your organization, then you are not working under the Scrum framework, and you would be better-suited to cease pounding that square peg into that round hole.

 

04:41 pm May 4, 2020

Hi Thanks for the responses.

@Ian, being agile is the organisations directive. However for me i feel that it is just jumping in the agile train. the trend nowadays in tech organisations. 

@Daniel, I understand that in scrum, everyone should understand the roles. however i get product owner looking at other areas like performance of the team.

any suggestions on how to manage this? as any suggestions i do is treated against me since I want to follow scrum roles.

@Tim, Roadmaps are also being done on the product side and estimates are not really that transparent. which focuses only on the new initiatives and not the actual sprint by sprint improvement and delivery. 

I am still checking how can we move with baby steps towards being agile. but to be honest, i see this being a long journey.

 

Thanks again for the inputs

03:27 pm May 5, 2020

being agile is the organisations directive. However for me i feel that it is just jumping in the agile train. the trend nowadays in tech organisations.

If "being agile" is the organizations directive then Scrum is not their choice.  An organization can be agile without following Scrum.  In fact, it is possible to be somewhat agile while following waterfall (controversial topic so I'm not going to elaborate much so as not to derail the conversation).  Being agile is nothing more than the ability to react to changes in an efficient manner.  Scrum is a framework that can help organizations be agile but the organization has to support the use of the framework in order for it to be successful.  In your case it seems that your organization wants to be agile but does not want to support Scrum.  You can use some of the Scrum methods and provide benefits but again the organization has to be supportive.  

Many companies use the Scrum Roles as titles but do not use Scrum.  I am assuming this is the case with your organization. They seem to want to have some kind of "agile" job titles but do not want to use any specific framework or methodology.