Managers that pretend to be Agile

Hard for someone to see the need for coaching when they see themselves as an expert in Agile frameworks.

Still sounds like coaching is needed. Expert certainly is subjective, and fleeting at best. Regardless, Agile is not story points, stand-ups, refinement (let's use that term and not grooming please, for you know, obvious reasons), planning, etc. Those are scrum related activities. Even so, what does the manager have to do with those activities anyway? If it is Scrum that has been or is being, implemented, then there would be a Scrum Team to focus on the activities you highlighted, not this one person. Potentially, then, the issue lies with the organization or immaturity of not having the scrum team established yet.

I am in charge of that right now. SAFe is a framework then the next step to do after the organization decide to use SAFe is to decide how to fill it up with the best tools and practices in accordance to organizational current situation. That is what you have to talking about, not the framework. People will use tools and practices then you have to sell and implement new behavior and way of thinking not the framework itself. Nothing in Scrum said that you have to use user stories, story points, etc. Nothing, there is not line about that inside the Scrum Guide.

Cargo cult and doing agile are just two outcomes of a lack of behavior and mindset shift. A Theory X manager pretending to be agile will likely hurt a team worse than if they were open and honest about their views.

Kiron

Yes, and it reminds me of my early engineering college days when I tried to tutor non-engineering students in basic physics...

Engineering physics was calculus based and with a little bit of fundamental understanding of a problem and a gram of math I could derive any formula needed. Other studies used algebra based physics where you had a ton of formulas to memorize and figure out which to apply in which situation. It became very frustrating to me because while I could show the students how to solve entire classes of problems very easily, they wanted a dogmatic cook book approach, rather than understanding the problem and applying some basic theory. Each new problem became an exercise of which formula to apply.

I see some managers trying to apply agile methods in the same way. They don't want to understand what they're doing and instead want a cook book to prescribe to them the exact recipe. I've seen people come back from a weekend seminar convinced we must change the organization to exactly what they learned in their 2 day primer or all is lost.

To me, these people have memorized all of the formulas, but they have internalized none of the fundamental theory. Their "agile" is little more than dogma, and when a new problem comes along that doesn't fit the formulas, they're lost.

Agreed,

I think the point of iterations is to help provide that feedback loop to try and get better- although there are other (and sometimes better, in my opinion) ways to do it.

A lot of my early Agile experience revolved around really badly implemented Scrum. What I learned later is that badly implemented Scrum can be better than well implemented Scrum ---
but I wasn't seeing that in my early days. I saw a guy who led the Daily Scrum, called a project manager, focus not on empowering the team but ruling the team with an iron fist - don't you dare make a decision on how to go about your work without him. He didn't follow Scrum or Agile guiding principles. They adopted the fancy Scrum name and threw on same daily meetings that they called a Daily Scrum, the Project Manager led them. There was no talk of improving our work, ourselves or coming together to unite as a team. Instead, it was lots of meetings under the guise of being collaborative but it failed (I actually recently wrote about my average day under that arrangement using real-life examples I encountered - https://agile-mercurial.com/2019/03/16/i-h...ion-developer/. )

Some of the best functioning teams I have been on didn't concern themselves with following a pre-defined process. They might have started with Scrum, and kept some of the Scrum names - but they ADAPTED and became flexible enough to find what works. They realized that sometimes holding a daily standup every day was just stupid. They realized that sometimes an iteration isn't needed or iterations of varying lengths worked better. So it messed up their structured tracking - the primary measure of success is the produced product, not the velocity of production anyway. They asked us what we thought, they expected us to make decisions on how to get our work done. They didn't force us into meetings because they thought we should know a whole bunch of ancillary stuff not relevant to our work.

Retrospective? What's that! We're in the process of cleaning up and refining our backlog (third attempt at it in 2 years). I work in a waterfall culture the past few year and painful seeing the transition, but the good news is they haven't completely given up on it!

" [...] I saw a guy who led the Daily Scrum, called a project manager, focus not on empowering the team but ruling the team with an iron fist - don't you dare make a decision on how to go about your work without him [...]

I think when talking about empowering the team it is very important to specify the type of decisions the team members should be empowered to take.

For instance many software developers only care about the purely technical decisions and simply don't want to be involved in other types of decisions. Of course the non-technical decisions do impact the technical ones and vice-versa but still many technical experts don't like to take non-technical decisions.

That being said many times it is better not to "empower" the team as the team members may not like to be empowered to take decisions they don't want to take.

And of course the degree of technical knowledge the PM/Scrum Master has is crucial when leading the team as a non-technical PM or Scum Master can't really lead the team in an authoritarian way. I mean he will not be able to give any commands to the developers as he would not be able to formulate them.

Only technical leads and technical managers with deep technical knowledge can really lead with an iron fist. Non-technical managers trying to lead with an iron fist would just look like clowns and the team members would make fun of them and of their lack of knowledge.