Scrum and traditional Project Managers

Sometimes you have to take what you can get.

When i meet resistance or skepticism on the implementation of my scrum, I revert back to the three pillars - transparency, inspection, and adaptation.

One thing you can try is to be transparent about letting them have their way for a sprint or two. Inspect the impact that the decision has had and then solicit suggestions for adaptation.

In my opinion, the responsibility of being a scrum master isnt to "order" the team to not do waterfall or to do scrum. It is to suggest and let the team self organize. When we suggest, we have to accept that sometimes, those suggestions may not be agreed to and adopted. When we suggest and *expect* that the team does what we say, we are no longer suggesting and are simply giving orders.

Right and don't expect the 180 degree change. Let them control the direct the team, let the team work according to them. You job is to ensure that the Scrum process is being followed. This set up is going to fail so let team inspect and adapt accordingly, just keep guiding them on it.

Cheers
Sanjay

Thank you both guys!
Let's see how it goes...

If Scrum "must" be implemented, then BA's and PM's don't have a whip to crack. Are you sure the organization is committed to Scrum, and isn't wasting your time as a Scrum Master?

I'd be tempted to have a forthright conversation with the CTO.

You have to first gel in and create a good rapport with them. Earn their respect. Prove yourself, only then will they give respect. And don't expect sudden change. Give it some time.

You have to first gel in and create a good rapport with them. Earn their respect. Prove yourself, only then will they give respect. And don't expect sudden change. Give it some time.

_______________
http://www.agiledistributed.com/testingDistributedAgile.html

Hello guys,

First of all I want to thank you for all of your replys, I really appreciate them.

Unfortunately, things still are not going so well.
I am doing what I already did when I was the Scrum Master in other companies, and that is to suggest, based in Scrum best practices, how PMs and BAs should start retrieving User Stories instead of creating large documentation with analysis and requirements (that are not well understood by themselves and by the Development Team either).
The only thing I've got, was an email from one of them (PM) making it clear that I must stop telling him how to do his job and that if I wasn't happy on how he is working I should talk to his senior managers. After that, the PM just ignored me the whole day and went to talk to Development Team members directly (as they always did before...) and ignoring every single Scrum rules as well.

They are really turning my job in a daily nightmare and it seems that nobody wants to stop them.

Never had this kind or rejection to change in the other companies, maybe because they were committed to implement Scrum for real?
I am not telling that it was easy, not at all, but here, it's not difficult, it's almost impossible.

What should I do? Speak with Senior Managers? CEOs? CTOs?
This is the first time since I am working as a Scrum Master that I am feeling so powerless and so disrespected, and I really don't know what else I could do to change this situation.

Thank you all guys!

It looks like you feel disappointed that the PMs and BAs are not following scrum best practices and ignore your suggestions for change.

I am kind of confused when i read your posts though. You say that there are communication issues between the PM's and the team but right afterwards you say that the PM "went on to talk to the development team members directly" and that "nobody wants to stop them"

Can you tell us what exactly are you frustrated about?

In what ways have you made the current process transparent so that inspection and adaptation can be done during your retrospectives?

Hi Randyh,

Yes, you're right, maybe I didn't explain the problem very well.
I am disappointed because PMs/BAs are going to speak to team members directly about other projects/developments right in the middle of a Sprint, asking them to give estimations for these new developments and changing the User Stories as many times as they want, even if many of them are already included in the current Sprint.
I saw the development team very excited when we told them that the company decided to implement Scrum, but now they are saying that "as always, it's the company that is not respecting their own rules", they thought that with the new methodology, they wouldn't do multitasking, changing the requirements, and jumping from one development to another in the same day as they always did, so they are asking me "what's changing? They (the company) are always saying they want to change but at the end of the day, we are doing always the same thing" so this is very frustrating for them as it for myself.
When I say that nobody are stopping them (PMs/BAs)I am talking about the management, if they are not the ones that give the "order" to follow the Scrum rules, the PMs/BAs, just simply keep working in the chaotic way as they alway did and ignore anything I say or suggest.
Currently there is no communication between PMs/BAs, it's just "Stop doing whatever you are doing and now do this".
Even if I am trying to stop this behavior following Scrum rules, PMs/BAs just don't want to follow them, as simple as that.
Unfortunately I have the feeling that the management is not supporting me the way they should.

I hope this clarify a little bit more the scenario and how I am currently working.

Thank you for your interest!

Are you fustrated because the PBI's commited to the sprint are changed mid sprint? Is developer morale impacted because of this?

You haven't mentioned a PO in your posts. Do you have a single PO? What is his role in sprint planning and how does he interact with the development team and PM's?

Yes, the PBIs are changed frequently and even inthe middle of the sprints, and this frustrates the developers because they can't finish what they have commited to do in the current Sprint. Obviously they come to me to complain and ask for help, because they are feeling like PMs/BAs do not respect them.
I am not mentioning POs, because the idea was the PMs and the BAs to become POs, but they are not working on the PB, they qre not creating user stories and they really don't want to be POs.

If you want to be successful at implementing the scrum framework, you really should revisit your PO role.

The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a backlog item’s
priority must convince the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog.

Hi Randyh,

I'm sorry but didn't get the idea.
I know very well the concept of the PO role, I am not the one that have decided that the PMs and BAs would be the New POs, it was the management that had decided it before I started working in this company.
The problem here is the resistance from PMs and BAs to become POs.
I also sent the same role definition you wrote in your message to all the PMs and BAs from day one.

it's okay to break the rules of scrum so long as the scrum team is being open and honest about it.

Your team has chosen to not have a PO for several sprints and are running into problems.

I would wait until the next retrospective and approach it as follows. When i refer to the "team" below, i mean your scrum team (PO (committee of PM's, BA's), Devs, SM)

1. State the situation and get feedback. Do not assign blame.

2. Solicit feedback from the team on how they feel about the current setup.

3. Ask the team about what they need but arent getting with the current setup.

4. Ask the team for suggestions on what they can try to change for the next sprint.

5. After the team agrees to a direction on the next sprint, stick with it until the next retro!

I would recommend to stick to the retrospectives to inspect as it seems the team is very much in chaos and your relationship with the PM's have been compromised. By including the development team in the equation and focusing on the needs of every member in the retro, you may have better success.

Hi Randyh,

Thank you for the advices, I agree with you,the Development Team's feedback is very important and my hopes are that the PMs/BAs hear what they have to say and finally realize that it's important that they work together, not only for themselves, but also for the company.

Thank you again for your replies and for your advices, I really appreciate it.

Hello Michael,

Just wondering, Does the team of PMs, BAs had a presentation of Scrum and its benefits for the company?
Was there a presentation of their new role within the organisation?

This situation reminds me of a sentence in the book Agile Coaching I'm reading, when the author says that often when there is a reorganization, people tend to protect their jobs rather than embrassing the changes. So maybe they don't see how and where they are fitting in the new organization. They may think that you're replacing them, hence the resistance.

My advices (I totally agree with Randyh's)

- Get a senior manager to present the way the organization is implementing Scrum
- Get a senior manager to explain your role within the organization and the nature of your interactions with the other people in the company
- Don't rush on the team to adopt and absorb Scrum, but ease the transition from the old way to the new one.

Anyway, good luck with your mission, keep us update.

Hello Choisel,

Thank you for replying!

In fact, what I did first was to prepare a brief introduction to Scrum for PMs/BAs, Development Team and Testers. I also have prepared small documents (4-5 pages) with Scrum information regarding their new roles and what Scrum expects from them, so they could use them as reminders of everything I explained during these small introductory training courses.

I explained all the benefits of Scrum, how it fits with their "new roles", and I also had some "one to one" meetings with them, so I could know them better and also to know if someone had already some kind of experience with Scrum in their previous companies. Most of them never had worked with Scrum or in Agile before, and that's OK.
What really shocks me is that most of the problems come from the few people that told me that they had already worked with Scrum! So I think they could have had bad experiences with Scrum before or that maybe even if they've been told they were working in a Scrum environment it wasn't really an Scrum environment or maybe... they just didn't say the truth? It's strange, isn't it?.

I agree with you when you say "when there is a reorganization, people tend to protect their jobs rather than embracing the changes", but that was what I wanted to avoid giving them an introductory training course about Scrum and specifying their "new roles", but it didn't worked as I expected.

Thank you for your best wishes!

Hello guys,

After my last post, I have discovered many problems in the company that are not related with the methodology (any...), but related with rejection from PMs/BAs (that as I said in other posts, should be the next POs) to implement Scrum and now with the fear that many developers have regarding implementing the new methodology. They have told me (and to the CTO as well) that they are feeling that the company is implementing Scrum because the management want to control them and fire them based on the performance measurement retrieved with the burndown charts. They also said that they don't want to share their knowledge they have about the applications to others because they "have" to save their "a..es" and keep their jobs keeping this information for themselves.

I have told the CTO that we need to convince the management to be involved and to have a meeting between them and the team so they can show and openly express all their fears, and explain why PMs/BAs don't want to implement Scrum as well, this way the management could clarify everything to everyone otherwise, implementing Scrum in the company wouldn't be difficult, but "impossible"!

What do you think guys? What shoukd you do in a situation like this?

Thank you in advance for helping!

As a member of any organization, I would feel very concerned if a colleague actively tried to hide knowledge from the rest of the team. It isnt healthy to the development of everyone else and increases the risk to the organization through a single point of failure.

You can google Bus Factor (http://en.wikipedia.org/wiki/Bus_factor for ideas on how to address this issue

The first question for me is: Why does the company want to change to scrum? Is there enough awareness at the involved persons that the change is important? It sounds the problem is not changing to scrum, I think the problem is changing.

Also the invovlement of the CTO and the other management is not clear to me. Are they comitted to the change or do they only bring someone in the company and say: make it good?

As I mentioned before, I think in your case it wont matter if you are changing to scrum or anything else, the change itself is the problem.

There is a great book on this, but it is only in german (http://www.amazon.de/Scrum-Einf%C3%BChrung-Unternehmenspraxis-Strukture…) but it is not translated yet and I don't know if there is a similar english book, at least I can't recommend one.

But Kotters "Leading Change" is a good start (not scrum specific but I think there is no problem @ your scrum knowledge)

Hope it helps.
BR,

Hi Michael

I fail to see how a company can fire people based on the metrics of burn-down charts. For one thing these charts relate to the team, not to individual developers. No one developer can be isolated for criticism on the basis of Scrum metrics. For another thing, burn-downs are not comparable between teams. Each chart will reflect that particular team's policy of requirements sizing and Definition of Done.

The proof of success is in delivery. It's theoretically possible that an entire team could be fired if they consistenty fail to deliver increments of value, but (interestingly) that doesn't seem to be the concern here.

As for keeping technical knowledge private, in order to make oneself more valuable, that's a strategy I've seen developers try before. However I've never seen it actually work. Ironically, it is the sort of thing that actually CAN get you fired. No developer will ever be allowed to hold a company to ransom because of technical debt. It may take a year or two, but that individual's days will definitely be numbered.

Managers can get away with this kind of behavior longer, because they can use poor transparency to conceal their failings. They can even present organizational chaos as evidence of why they are needed, rather than as evidence of their failings. I think you should bear this in mind when approaching managers for assistance, as some may be reluctant to lend their weight for this reason.

The CTO seems to be on board, so sound that person out for which other C-level executives are on-side. From what you say, I'm not convinced that agile transformation is recognized as a strategic initiative, though it seems fairly clear that it has to become one if the transition is to have any real chance of success.

Hello guys,
I really agree with all of you guys (Radyhl, Philipp and Mitchell).
Today I have discovered that the PMO manager is telling (behind the scenes) to the other PMs to not "waste too much time" with all this "Scrum stuff", even if in a meeting with the Managing Director, he agreed to collaborate and implement Scrum in his team as well.
I am feeling so frustrated and exhausted, because I've been answering the same questions over and over again to the PMs, and now that I knew what their manager is telling to them I am feeling like they are fooling me and just continue asking me the same questions only for "pretending" they want to implement Scrum.

Philipp, when the CTO explained the situation to me, he told me they have decided to implement Scrum, because they never had implemented a "real" methodology (neither waterfall), everybody got accustomed to work in such a chaotic way and obviusly this lead both teams to blame one to the other everytime the projects haven't been delivered on time or without meeting the expextations of the customers because there was a lack of clear or real requirements.

It seems that for some reason, the manager of the PMO want to keep the chaos.

Many times I am feeling like the CTO doesn't have wight enough in the company for making real changes and also that they just leave me there and say:make it good (as you said Philipp)

How could a burndown chart could be use to fire someone? I really don't know as this never happened to me before. But what the developers told me is, as there would be a Daily Scrum, they feel that they have to "show" what they have done (yesterday) and what are they are going to do (today), so for them, this mean "we are controlling them because the company wants to fire them", even if I tried to convince them this is not what Scrum is used for.

Do they are really committed to implement Scrum? I am not sure anymore. How can I tell the Managing Director that the PMO is playing this game saying "yes" to him, but doing the contrary with the rest of us without seeming that I have something against him?

As you can see, my job is not easy at all, and many times I am feeling so lonely while trying to do my job (implementing Scrum) the best I can, the same way I did in the last five years and in different companies as well.

Thank you for "hearing"!

Hello.

Thank you for sharing your experience. I read real passion in your posts blocked by an environment that sounds like full of fear. The first thing we should always consider in such a case is the Thomas Theorem ("If men define situations as real, they are real in their consequences.")

Two things I would start with is, collecting as much concrete data and information on why they change from chaotic to any methodology. If it always worked great why should they change? Make it clear, transparent and visible what can happen when chaos is going on.

During this, or a little bit after showing the first big problems of not having any methodology, form some kind of leading coalition with who ever is in a leading position (CEO, CTO... and also the manager of the PMO) to get their awareness once again and make a commited team to drive the change.

Don't give them the answer (implement Scrum) only show them the problems and facilitate a discussion about how they want their company to work and how to get there. It seems for me like the company jumped over these steps and now is in trouble because they are missing this awareness.

BR,
Philipp

"Scrum is a framework for developing and sustaining complex products" and not project.
Look for Prince2, it is a framework for project management and work very well with Scrum.

Hello guys,
It's been a long time since I posted for the last time.
Unfortunately things are not changing for better, but for worst.
I have discovered that it's not only one developer that is hiding knowledge, but almost 4 (the elder ones, from a total of 9).
From the other side, they are trying to "show" the CEO/Director of the company that if we have problems, it's because of Scrum and "obviously" because it's my fault as well.
I had some meetings with the CEO because he wanted to know what's going on. So since then I was inviting him to the different Scrum meetings, specially the Sprint Planning meeting, Scrum Review meeting and the Retrospective meeting. Finally he accepted to participate and finally he had the chance to see how Devs and PMOs are behaving. I really ("really") hope that anything changes for good this time, otherwise definitely I could not implement Scrum in the organization and it could be a real failure.

In my experience the first step in any agile transformation is transparency.When dealing with the CEO and others, make it clear that Scrum will firstly *expose* problems rather than create them. For example:

- information radiators (such as scrum boards) that may not be updated properly by the team
- visible Scrum events, where clear Scrum guidance may be being ignored
- missed opportunities to inspect and adapt (e.g. unclear outcomes of standups, retrospectives)
- metrics, which may be too shoddy to be usable
- dependencies and blockages

Even if you never accomplish anything else, or fix any of the exposed problems, getting this transparency is a major win. Use agile transparency as a window on organizational problems. When resistance to the agile transformation is encountered, ask "what else are you going to do to solve this"?

Transparency is in some ways the first and last resort of the Scrum Master. It's the first thing you try to build and it's the last thing you fall back on should things go pear-shaped.

Hi Ian,

Thank you for replying.
In fact, that was exactly what I told the CEO during the meeting, that Scrum is not creating the problems, but it is exposing them and "we" need to solve them as soon as we can.
I am not really sure on how to solve the problem related with "hiding knowledge". In fact, these developers are hiding knowledge, but the others are not doing anything to get the knowledge either, so I have no help from them.
Also I would like to know if anyone of you had to manage a situation when someone from the team ask other member of the team if it's possible for him to do some task and his direct answer is "I am not willing to do this or that, so I won't do it"?. Obviously there were frictions between them.
I tried to help them solving the problem talking face to face with the guy that rejected to do the task, but he just gave me the same answer and also told me that no one can push him to do something that he doesn't want to do. Any advice?

Michael,

I learn a lot from your experience. I, too, have faced impediments implementing scrum on my team. But I believe it's not as big as yours.

Your problem is similar to me when I faced it few years ago. Back then, we are yet to implement scrum formally. But we did have daily scrum, scrum review, and scrum retrospective.

At that time, I was the business analyst. But I'll try to advise you based on my experience.

I think it's time to point out to the boss if they really don't want to work. it's not the scrum problem. but it's the person who doesn't want to work!

My advise, you let the person's boss know. and suggest this person to be taken (kicked) out from the team because he/she doesn't want to work. If telling the person's boss doesn't work, tell the boss's boss (I really did this in my experience).

At that time, I was frustrated, but yet, I still want the project finished and I know something needs to be changed drastically. So I didn't really care what is my position.

What I did works on me 2 times on 2 different project.

But I'm not saying my suggestion is the best. And it's difficult and painful to get someone taken out from our team. But we got no other choice, since I don't want that person affecting other team member's morale. At least, the project moved on and finished.

I hope it works for you.

Cheers.

Hi Iman,

I am so glad to know that my (good and bad) experiences are helping others and also to see there is someone supporting me as well.
During this period I could manage to have a little more support from some of the most difficult developers and also from one of the most difficult PM in the PMOs team. He is "finally" creating User Stories (never did in the last months) and he is asking me for more help for doing it.
Now I have one more challenge, and I think is one of the hardest ones. I am dealkng with the PMO general manager, and he is one of the most difficult man I ever had to deal with. He is a kind of bulling and he is behaving like a silverback gorilla. He is happy yelling to the people, and he is most likely a dictator than a manager, he is the first one that want to break the rules and is the first one that receives you with a smile in hist face but as soon as you turn, he stabs you (and anyone else) in the back. He is one of the most difficult person I ever met.
Now the thing is I cannot behave the same way he does, but also I have to stop him in some way, but many times I run out of ideas on how to deal with him, as he is very unstable.
Here I am asking for your help again. Any advice could be really useful for me.
Thank you all of your for "hearing" and for your support.

The issue mentioned in your example all goes back to the values of a Scrum Master and why the Scrum values will end up helping the business anyway. If you can explain what's in it for the business then they often start to listen. This post may help: http://www.pashunconsulting.co.uk/selling_scrum_blog.html

Hi Michael,

After following the discussion I am starting to wonder whether we are working in the same company :). Probably not, but I am also facing a considerable subset of the same problems you are describing and facing the same issues (although on some I would disagree they are issues).

Basically where I work they have also decided to move to Agile with several teams (each with its own independent product). Some decided to do Scrum, others decided to do Kanban and a few went with a mix (Scrumban?). My team is among those who decided to do Scrum. Decided is an overstatement as the only action taken in this direction was to hire a few experienced Scrum Masters and let them handle any transformation necessary, but without any formal authority. Obviously we ran in the same walls: PM's suddently became PO's in name only, even those familiar with Scrum chose deliberately to overstep their boundaries, the team has had not even an informal training (too busy) so everyone read the manifesto and the guide mixed with previous experience resulted into some strange interpretations of Scrum (even though the Guide is pretty clear on what is and what is not Scrum). Bottom line, it's a mess.

On one hand, the team would like the benefits of Scrum but they fear the PM/PO and are actively choosing to obey him blindly and place all decisions in his hands. For them it goes like this:
- the sprint is a commitment set in stone that shouldn't change and the team must do everything it set out to do regardless of what happens during the sprint (they choose to do overtime to make up for interference). Although there is frustration, they actively reject any change that would draw a line against the PM/PO
- they tend to overcommit on the slightest pressure from the PM/PO
- they are frustrated that sometimes the PM/PO contacts them directly => I don't see this as an issue, as a SM I am not a middle-man, technical clarifications are between the DT and the PO. I do try to step in sometimes and remind them that any change to the sprint should be first considered and them approved by the team, however they approve everything the PM asks.

For the PO, it's a little different. He knows the basic outlines from the Guide.
- he is frustrated that the team overcommits but at the same time he actively micromanages the sprint
- he pressures the team to plan the entire sprint at the planning meeting (although the Guide clearly states that work should be broken down for a few days ahead) and then asks them to make an absolute commit on their plan
- often he pushes interlinked stories (for example: create a piece of functionality while having a story to deliver it in production in the same sprint) instead of waiting to group packs of functionalities (what we call 'increment') done in at least a couple of sprints in the same release. => put this together with the absolute commitment, any change throws everything haywire.

In my opinion (and what I am trying to do now), the main issue is with the DT. If the DT decides to draw its perimeter of responsibilities around the Guide, the combined force of the DT and SM can force the PM/PO back. Any productivity cost will be recovered once a rythm is established and the DT learns to use the velocity at planning.

As a SM you can't take the role of a dictator and push the team. The problem for me is that the team doesn't seem to want a change, despite the situation. What makes it worse (IMHO) is that currently there is a kind of frustrating stability where mandatory sprint deliveries overshoot the commitment with a kind of precision that is simply accepted by everyone. Therefore everyone keeps their frustrations (team has the micromanagement and commitment, the PO has the clients on his back with missed deadlines on their part). Obviously, the concept of "maximizing the work done by the DT" can't be found in anyone's vocabulary.

Hi Adascalu,
I am afraid that we are not workng in the same company, but I also think our problems are almost the same.
I think the main problems here is that the Company is "saying" they want the change but is not "embracing" it for real, a kind of "yes I want it, but not really want it" (you know what I mean?) This way the company just put all the responsibility over the SM's shoulders, so if everything works, the Company will say they made the right decission, but if itdoesn't it will be the SM ans Scrum fault (a very comfortable situation for the Company, isn't it?).
As I said in other posts I have 5+ years as a SM and have implemented it correctly in other comanies, but this is the worst company of them all.

You mentioned that your company hired a bunch of experienced SMs, are you one of them? What the othe SMs say? Do you do Scrum of Scrums? What people say during the restrospectives? Are you the only one that is raising the problems during the retrospective (I do, and I became the "bad guy" in the office, many people hate me (literally...),but also respect me(even if Ithink it's not the best way to be respected...

I rally hope you can shar the answers to my questions soon. Keep strong (I am trying to keep stron as well, even if many times it's no easy...)

It is sad, but it is not working...

Yes, this is the end, PMO definitely gave up and decided to keep working the same way they always did, as Project Managers, agreeing absurd delivery dates and pushing the development team to work long hours to delivery in those dates.

The recurring answer to any question that comes from the Development team is “We already agreed the delivery dates with the customer so if we don´t make it, we are going to lose the customer!” (Shock doctrine?).

What´s worst, top management agreed on this and they are supporting the PMOs even if they told me they have seen changes, but not enough changes… I agree with them, but it´s not because of Scrum, it´s because Project Managers kept being Project Manager, and never demonstrated any willing to change. POs are a very important part of a Scrum Team and expecting a commitment only from the developers is not good at all, as it seems the rules are different for both teams and this is creating a very combative environment (Devs vs PMs) and the projects are not moving forward at all.

They are asking me to do Scrum in a more waterfall way (what?).

Therefore, I am giving up and I will stop wasting my time.

This is the end of a true story.

Thank you all guys for your support.

> This is the end of a true story.

If it's any consolation, it's a common story. The dysfunctions you have witnessed, and your attempts to resolve them, will serve you in good stead in coming projects. You have probably learned ten times more than you would have done if stakeholders had been sensible and given Scrum a proper chance. Ironically, this is a foundry in which the best Scrum Masters are often forged. Good luck.

sounds difficult, if we think back a bit we know PMs have existed a long time and lets not forget different applications of the PM format PMI, PRINCE2, PMBOK, PROPS, so we have a variety of ways to do it.
The one thing that isn't practiced in any of these is change behaviors as they focus on the method rather than the bottom up intelligence, its top to bottom and sometimes with no intelligence as the methods are not adhered to.
Simply just use this as an inspect and adapt opportunity, don't kick yourself and don't be downhearted about it.

Large organizations and generally organizations with a lot of legacy behind them really find it difficult to change.
Why? " because we have always done that" and that's the way forward in their eyes.
Normally change happens in organizations like that when jobs are on the line when the traditional methods have failed, or you get someone that really does support the change that ensures it happens (or both) ie an ambassador not an assassin for something.

Here for example the organization could have done away with the role of PM and made them all PO or simply put one team as SCRUM vs a team of carrot and the stick.
They didn't which makes you wonder how committed they were or just lip service to some current buzzword?
Could be that in time when its getting difficult they get a chance to inspect and adapt with transparency if it all goes wrong, the nice thing is you will be the guy that introduced them to the ways of scrum so in many ways will be responsible for their success if they do adapt to it, hows that for a bad ending. :-)

This is an old post, but extremely contemporary. Thank you Mauricio for sharing your very tough experience.

I am starting my long career path as a Professional Scrum Master. I have read numerous posts @ Scrum.org and other forums in the past few weeks and no other was so educative from a practical perspective as this one. I am very inspired by your case and will definitely save it in my "to revisit" posts list.

My approach (if I may) to this problem would be to immediately identify and get familiar with the organization's process.

Your case, where:

1. PMs and BAs are turning requirements upside down mid-sprint,
2. there is high degree of distrust,
3. there is concealment of information,
4. there is hampering of knowledge,
5. command-and-control culture,
6. among others

strikes me as a chaotic one. They did not acknowledge the complex system they had to cope with. This reminds me of the Cynefin Framework (A simple explanation of the Cynefin Framework).

After identifying the process from beginning-to-end (meetings, sub-processes, people, interactions, tooling, etc.), I would:

1. Map it where the whole organization could see it (start on Transparency);
2. Work with them to identify areas of improvement by asking (start on Inspection):
   • Is there something to be improved in here?
   • If so, what could be improved?
   • If they responded no, I would use analogies to make them understand the need for improvement (e.g., a football team that needs to adapt to each an every new game);
3. Kindly ask them to do some self-reflection and share their ideas with one another (1-2-4-All);
4. Expect they would (jointly) come up with at least one suggestion for process change (start on Adaptation);
5. Repeat the loop until they understand what they are doing - being transparent, inspect, and adapt;
6. Schedule a follow-up meeting to track the progress of the changes discussed, and how the newly changed process compares against the old;
7. Repeat it all over again and again.

And all this without mentioning none of the Scrum roles, artifacts nor events.

The goal is for them to start building trust in you. And when you were finally asked: "What is your opinion on this?",  that's when you could start teach Scrum. I would support an incremental way, like "there is this thing, the Daily Scrum, it's super powerful...".

They would be teaching themselves what Scrum is about without even knowing it.

Law 45 - "Preach the need for change, but never reform too much at once" (Green, R.; "48 Laws of Power")

Thank you again!