Hacker News Reader

Comment by woutr_be | Hacker News Reader

I've had a similar impression in my previous company, this was a large multi-national bank who proclaimed they want to go agile. Spared no expense in hiring agile coaches and scrum masters.

It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams.

Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process.

Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.

View on HN

IME it's just scrum masters trying to prove their worth. Since they're either non-technical or not close to the tech, they're reduced to robots asking "do you need me to escalate that?", or "so can we move it to done?". I'm sure most scrum masters could be replaced by chatbots.

It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself.

Instead I just disengage for the hour and half of standups I have per day (yes, I know)

I don't understand hiring scrum master as a full time employee from my experience it always is role for one person in the team that does other stuff full time.

I never saw scrum master who is doing only scrum stuff myself but from what I read on the internet there are people who saw it.

Scrum masters are one of the reasons I chose to be overemployed. Their presence in an organization taught me that it is highly rational to be performative over performing.

How’s it working out for you?

Rule 1.

Do you also have scrum-of-scrums? Because that is out DevOps team's latest idea to speed up an ERP project. So we get scrum masters instead of functional ERP experts and consultants. I am curious so, what a scrum-scrum would actually look like...

> Do you also have scrum-of-scrums?

I remember my previous employer trying that out in one or two departments. Ultimately that company landed on SAFe Agile and it was a complete and utter shit show.

Where I'm at now is "doing" Kanban but the standup is really just a daily status update. I'm slowly getting the management to recognize that these things are problems, why they are problems, and what can be done about them. But I'm much happier with this situation because I can actually push back against it and try to improve the thing. At my previous employer, any attempt to even begin highlighting problems would render you standing alone against what amounts to a committee of management (in this case, specifically, people who are only employed because of the fact that they use these extremely heavy processes) if you wanted to discuss these things.

Your previous employer sounds a lot like my current one. Add to that a DevOps head who currently holds his first job in anything IT related and actual developers that are almost exclusively external and subcontractors... All our internal developers are doing is Palantir dashboards and some interfaces to get the data into Palantir.

Scrum of scrum doesn’t work, you shouldn’t have a separate “devops team”. If you really must, someone from that team should sit in your scrum to link back to their team any blockers.

Otherwise what you have, and I’ve seen this in multiple places, is developers getting blocked by DevOps constantly, so basically setting up “shadow” infrastructure to try and work around the problem.

IME whenever an organization like that hires an agile coach they either get a jaded cynical jobsworth who powers through the motions implementing some process heavy thing or an idealist who ends up clashing with managers who definitely want "agile", but with status updates, quarterly planning and accountability metrics and all the other shit that makes it impossible to be agile.

The latter will typically get managed out or even fired.

There doesnt really seem to be a way to square this circle.

At least what happened at my company, is that they hire an idealist who preaches agile to management, and then gets frustrated when reality doesn’t match what they preached, because now their job is on the line.

It was somehow hilarious to watch him weasel his way out of missed deadlines and failed project. Every developer ended hating him, since developers got the blame for everything, since we didn’t follow his idealistic view of agile.

In fairness Ive seen data scientists get equally surly when management hires them expecting them to work their magic and the reality is that the data is so filthy that there's nothing they can usefully do.

Ideally you should quit if conditions make your job impossible - that being the economically "efficient" thing to do. But mortgages, kids to feed and the everpresent reality of the capitalist system often prevents one from doing that.

> to the actual developers who were trying to improve the process

I went from a company which adopted agile after I joined, to an older company which has never adopted agile.

My current take is that without agile, there's no process to improve. Well, yes, but not on a bi-weekly basis.

We are grown-ups, things work, brokenness gets raised when needed and there's no heavy process crushing people to fix.

I do agree with you, and it’s not that I hate agile, I actually think it’s a great way of working, if you allow teams to change what it means to work agile. However, more often than not, those agile coaches or scrum masters follow to handbook, without allowing real world experiences to change the process.

In my experience, they don't even follow the handbook, but rather the management's decisions about which parts of "agile" we want (Jira tickets, daily meetings) and which parts can be ignored (retrospective, having no long-term deadlines).

The old form or substance discussion. Some compabies have the substance, e.g. Toyota when it come to lean, some have both form and substance while the majority implement the form without getting the substance. The latter also wonder why things don't work as expected...

This sounds eerily familiar. Let me guess, there were sprint planning sessions that went on for hours. More time was allocated to planning the work, than for the actual work.

Replacing one dogma (waterfall) with another (dogmatic agile), is not agile.

I think it is a necessary step in the process. No org is going to go from full on dogmatic waterfall to fully agile in one step. Dogmatic agile either works or fails on its own. If it works then the org might try going actual agile.

Reply on news.ycombinator.com