How to react to people willing to do Scrum, but compromising Scrum integrity
I've been working on multiple products as a developer under Scrum, and now that I've studied Scrum, and now that I'm certified PSM1, I find that the integrity of Scrum was systematically compromised.
Looking back, I find out two main blocking behaviors that my Scrum masters of the time probably tried to manage, but couldn't:
- N+1 or N+2 trying to bypass PO, reprioritize PBI and SBI because "I know what's good for clients"(or for my career probably), and putting high pressure on dev team not even to reach the Sprint Goal, but to react 0 on burndown chart(old fashion biased productivity)
- PO not doing his work, because he was because he was not competent and not willing to be a PO. Unable to take decisions about simplest things, reprioritizing PBI and SBI, changing designs without telling anyone and refusing done SBI because of that, putting deadlines about demo to stakeholders which must contain all in progress work right in the middle of the sprint("and demo is tomorrow, so be fast please..."), not understanding his own PBI because of a lack of interest for the product, hierarchy not wanting to change him because unable to fire him
I'm not talking about little problems here. It causes product ending to fail/dead-end, or imploding/depressive dev teams.
Those was deadlocked situation, caused me to quite the job(as developper) every time because it was a toxic environment with high pressure as a developper, and work without satisfaction and with huge frustration. I wasn't able to try to solve those issues, because it wasn't my role, and I'm the kind of guy tending to think that people doing a work that I don't always know better than me about their field.
Now I studied Scrum and got certified, I know how to argue and coach about Scrum without having fear of talking nonsense. I'll probably react to those kind of blocking behaviors by trying to coach and educate them about the framework, but at some point if it remain blocked, I will probably quite while explaining that they are not truly willing to do Scrum or even agility, and they don't allow me to apply the framework they hired me to apply.
That's what I will do, because I respect and love the fact that Scrum as such strong values, and force those who want to use it to apply it in its entirety.
Regarding that, my question is, is this too extreme for me to react like that and to be as determined in my ideas about applying Scrum? Is that a behavior that could harm the scrum community and its detractors? Should I adapt to those kind of managers/PO and alterate Scrum for a project probably lost in advance, because "it's always ends like that"?
they don't allow me to apply the framework they hired me to apply.
Welcome to my life.
is this too extreme for me to react like that and to be as determined in my ideas about applying Scrum? Is that a behavior that could harm the scrum community and its detractors? Should I adapt to those kind of managers/PO and alterate Scrum for a project probably lost in advance, because "it's always ends like that"?
A Scrum Master should be generally tolerant with people while demonstrating a low tolerance for organizational impediments.
Be careful that you don't become the "Scrum Police". Just as in agile a team is expected to provide incremental deliverables I have found it most effective to incrementally improve the organization's appreciation of Scrum. Based on your statements, it seems that the organization is ok with the behaviors you describe. If you want to truly want to have Scrum be successful, you will have to help the entire organization change. It can't be done in a single team.
The feelings you are experiencing are going to be well known to almost everyone that has ever posted in these forums. So many people say that they understand Scrum but their knowledge is limited to doing a Sprint and having a daily Standup. I applaud you for taking the time truly study and understand Scrum and wish you luck going forward. But be ready for frustration and learn to be patient with others. Incrementally affect change and learn how to deal with upper management because they will be one of your biggest obstacles.
Ian and Daniel both have provided effective pathways.
Since you have asked specifically about "reacting", I would like to add something for you to investigate and learn as you move forward with Scrum.
When I was trying to establish my credibility and trust with teams, I took up reading more and more about negotiations. Negotiations are not limited only to deals and C-suite but are an inevitable part of our day to day life. I would go even further and say that the Scrum Master's most important tool is his/her negotiation skills. In my opinion, you should start with what is known as "Integrative Negotiation". In integrative negotiation, the parties cooperate to achieve maximum benefits by integrating their interests into an agreement while also competing to divide the value. You have to be good at both creating value and claiming it.
As you move forward you will be able to deal with the situations with other negotiation methods or types and will be able to successfully push for right Scrum without sounding like or becoming "Scrum Police". You will need to adopt different negotiation techniques depending on the specific situations. This will aid you in increasing organizations' inclination and appreciation of Scrum at different levels.
@Aditya, this is indeed the challenge I am facing at the moment with one of the teams: inclination / appreciation of Scrum. I am going through endless thought cycles of how to convince the team of the benefits of using Scrum to its integrity. The team has points like:
sprints are more of a planning tool (read: no regards to define concrete sprint goal, consistently)
what efficiency are we trying to achieve by following Scrum in its sanctity?
area of expertise are limited to individuals (each individual is an SME and has primary skill with no consideration for being cross functional) so benefiting and inclinitation towards estimation (using planning poker) is a far fetched reality.
questionable sense of urgency (as said here)
In above cases I have been having negotiative discussions and using influence, but cannot really save myself from sounding like a Scrummando (Scrum Police).
In short I sense little are no support / pull within the team to adopt integral scrum, leaves me pondering for an answer to the question What really means a sucessful sprint, per Scrum and per such team?
Hello Niranjan,
Let me please point out certain peculiarities/words in the points that your team has given which has made you believe that you have reached kind of dead-end in some ways.
- sprints are more of a planning tool
- what efficiency
- benefiting and inclination towards estimation
- urgency
There is a commonality in all these points, i.e. time. I get the feeling that the team is viewing Scrum as another task management/ project management tool, which it is not. Scrum indeed may aid in these things but I view Scrum more as a "framework to consistently deliver quality and enhance quality". If you could demonstrate multiple aspects related to quality enhanced by adopting Scrum in its totality, you will observe immediately that the inclination and appreciation towards Scrum are getting established.
For me, a successful sprint means achieving the sprint goal plus at least one quality enhancement. Please note that quality enhancement may not be related to the product itself. I am unsure what your team views as quality enhancement, but I would assume that reducing operational risk/s and NPS are worth to start with.
@Vaibhav, thanks for that insight. That indeed resonates with my observation as well. I beleive I have been trying seek their engagement towards agility (mind it I am not saying adopting scrum) by having setting more general themes for retrospectives: e.g. ways of working, goals, self organisation, early feedback (including testing early). I can see that they are engaging. BUT, some how I feel the sprints have the below attributes (as said here)
- low-grade time-boxed Kanban
- no reason to cancel the Sprint either. It was just an ordinary Sprint
Somehow I think accountability (scrum value: Commitment) is not at the expected levels in each individual. I sense that something that could have been completed was not, and no one really asks WHY, or there does not appear to be much impact of it.
As a servant leader its necessary to align to a more generic approach towards continuous improvement (related here)