Do you feel sometimes the SCRUM ceremonies can be counter productive.

In my current company I feel that SCRUM is overused. Pointless discussions in retrospective meetings with unavailable or impracticable action items.

I do feel like all the meetings and conventions can take way more time than needed.

Once you follow a procedure without reason except because it is what you follow, that is now your religion and it has nothing to do with rational thought.

Beware all who enter ;-)

Yes. At my company the managers are obsessed with trying out new processes but they never reevaluate them later and cut them if they're not working. The end result is this gross homunculus of half-baked ideas that they still call agile. If I stay at this company for a few more years I'm pretty sure I'll spend more of my day on the rituals than I will on actual work, and then they'll add some more rituals because they think that will help us get stuff done.

@ArcaneEye I completely agree. I do love scrum but you really need to adapt it. We don't have standups because we are a single three member team on the project.

Do I sometimes feel scrum meetings are counter productive, no not "sometimes"!

@351483773 than you are not doing scrum

@Codex404 is this just a No True Scotsman, or can you link to where someone's explained the maximum amount of time that can be wasted on Scrum Agile cargo cultery and have it still be Scrum?

I thought I was the only one who didn't really like all of the ceremonies. But I am glad to hear that I am not alone.

Yes I do. To me the only actually useful meetings are rectrospective and planning, where it's a benefit that the entire team comes together. The others slow me down. When I need to discuss things or get status info, I get up from my chair and talk to people. No need to force the entire team into a meeting.

OTOH I can see how they are useful for less experienced or independent devs. The sprint review helps them feel acknowledged. Daily standups help them stay in the loop. Without these, they are the ones slowed down.

In the end the question is who you want to slow down - or if there's a way that slows down neither. I don't know yet.

@HollowKitty it depends, standups can not take more than 5 minutes. Retros at max 15 minutes unless things went apeshit crazy during the sprint.

Sprint planning depends on the preparation, but this is time that is otherwise also invested in understanding tasks.

@Codex404 ok so this is a No True Scotsman then? I've never, ever worked for a company where it was done as you're describing. Maybe there are one or two companies in the world actually "doing Scrum". How is that helpful info? The 99% of companies that implement Franken-Scrum still call their process Scrum. If you don't like that managers call their crappy processes Scrum, go talk to the managers, not the people being subjected to them.

https://linkedin.com/pulse/...

@Codex404 15 minutes retrospective?.
We do have 2 hours of retrospective madness.

@HollowKitty how does that work? Managers are not supposed to be in these meetings and for sure can't manage these meetings.

I am scrum certified and am consult on both dev work and project management. In two years time and 5 companies I have not yet seen it that bad as you describe.

it depends on the scrum master, i think. if the person knows how to manage time and make the most out of the ceremonies, i don't think it's wasting time

@BlueSky that is fine if every sprint you instead of adding features are mainly removing them. The longest retro I had was three hours but that was because that team took 3 sprints what another team did in one. If someone is being bullied than that is also not something you can do in 15 minutes.

If after three sprints (to get to know each other and each other's work process) it really takes that long something is wrong. In my experience that is the cause of one or two devs.
What is your scrum master doing?

@Codex404 Managers run the meetings, and obviously developers can't self-organize or any of that unless management lets it happen, which they usually don't. I'm tired of hearing "that's not really agile tho" every time someone brings up how they're being screwed over by their workplace's "agile" practices. Most workplaces that do "agile" and "scrum" are just looking for ways to keep their workers on a perpetual hamster wheel.

https://michaelochurch.wordpress.com/...

@HollowKitty the page you linked is kinda amusing. It's assuming it is bad to fail a sprint and that the workload is chosen by managers.

It is part of my job to fix these mentalities and it sure makes them more productive, with less pressure.

I am dev first, mentality changer second, let's be clear on that, but I have had a manager fired once because he did not want to change his ways of micromanaging.

@Codex404 The workload typically is chosen by managers. It's a little psychotic that you think the state of our industry is amusing, but okay.

@HollowKitty I think it's amusing that the writer of this post apparently doesn't know what he is writing about. Instead of shitting all over scrum and agile he should instead explain why the things he writes about are wrong. Most devs are hating scrum because they don't know what it is.

@351483773 wait weekly sprints? Most of the times I think the default two is pretty short and suggest to extend it to three.

Our SCRUM masters enforce a physical SCRUM board on top of the digital one. I really hate that also.

@BlueSky if things are done in house I prefer a physical one. If it's over multiple companies I suggest a physical extra.

I totally disagree. I think it's way better to use a digital one alone.

@Codex404 "I am scrum certified and am consult on both dev work and project management"
You sound reasonable. I know quite a few companies that coud use *ahem* some *ahem* consulting.

I've never seen 5-minute-dailies and 15-minutes-retros. tbh sounds a little short to me. Instead it's excessive 15-30min daily, 1h sprint review, 60-90min retro, 60-90min planning 1, 30-60min planning 2, 30min backlog grooming. People mostly are indifferent or dislike it. But "that's just the way of Scrum, right?" No.

As I see it, "Scrum" and "Agile" are mostly lip service. Many managers have certain ideas how things should run - top down dictating, devs as work drones, meetings to show off one's importance, etc - and don't really want to change. So they slap on Agile terminology and think that's it, with that marketing the devs will like it (and finally shut up and work). Which is also why they love attending dailies: A process with built-in micromanagement opportunities. Awesome.

@VaderNT 5 minute dailies are fine. All you have to say is something like
"I'm working on feature A, currently finished designing the database changes and will implement it today"
Next person.

For retros it's like 5 minutes preparation and a matter of hanging stickies and for the scrum master to work out the issues. The scrum master will lose some more time than the 15 minutes I said.

@Codex404 ah, I should've been clearer. I find 15min retros short. 5min dailies are ok and can be 0min for all I care.
No, seriously. Like I wrote above, if we work together I already know your status. If we don't, I don't give a rat's ass and we're wasting time - imho. I think it helps some, but as for me dailies slow me down. And they drag my mood down.

15min retroes, sorry not sure if I understand you correctly. Don't you discuss your points? Now my perspective is team sizes of 7 and larger, and in such teams 5-10mins is just collecting points for the retro. Followed by 15-30mins discussing them (or the top N). And I'm fine with that, I think retro is the single most important meeting, so it's time well spent.

@VaderNT ah yeah that's quite a big team. 4-5 people of the same discipline is what I normally work with.

Discussing points in depth is rarely needed in my experience. Teams are generally agreeing with the points.

Of course this might be different in multi disciplined teams, but I've only worked in one of those

@Codex404 it's not that much about agreeing on issues but discussing solutions. That takes time. How much are you doing that vs letting the Scrum master handle it?

@VaderNT most issues are quite obvious to solve. The first few sprints there are issues that are not obvious but after three sprints that should be over most of the times. I've had 5 sprints in a row where there were no issues at all besides "internet outage"

I'm wondering what kind of issues are there for you that you need more time?

@Codex404 haha, I wish most problems we had were obvious to solve.

A bit of context, this is in large companies that think inner-company-in-company/"internal free market" is a good principle. It's not, it leads to sealed-off silos that are maximally unwilling to collaborate with each other.

In that light: The hard problems we had were, in general, organizational and people problems. Anything ranging from branching in our Git repo, how we can get POs to not write garbage stories, to working with unwilling managers and other teams.

@VaderNT ah, on of our customers is structured like that.

In the case of unclear User stories => impediment. The moment the PO suffers from his own shitty job they will adapt quick enough.

In the case of unwilling managers, managers have managers, most of the time they are willing and will have a talk with the problematic manager, though I understand that this might be difficult to do for an employee compared to a consult like me.

@Codex404
> The moment the PO suffers from his own shitty job they will adapt quick enough.

Or they'll blame the devs for not starting with points that are clear and fix the rest later.

> managers have managers, most of the time they are willing and will have a talk with the problematic manager

I have literally never seen a manager put another manager in trouble. Never. It's "dog don't eat dog" and making excuses for other managers, however ridiculous they might be.

> though I understand that this might be difficult to do for an employee compared to a consult like me.

Yeah, definitely. :-) Most managers have an almost uncanny tendency to dismiss their devs' ideas, only to gobble them up once a consultant repeats the very same thing.

Most managers I came across think almost in terms of nobility (them) vs mob (devs). With all the excuses you could possibly imagine ("our success means we're right").

@Codex404 Additionally most devs I met aren't confident enough to give a stern "no" to their managers. Most sound like they're in an abusive relationship. "It's not that bad, really", "at the end of the day the boss is right", etc.

Hence the workload really is chosen by managers. Either directly ("these are your next three sprints") or indirectly ("can't you do more?"/"can't you lower that estimate?"). Those are real quotes.
Hence managers get away with the worst shit, like yelling at their devs, micromanagement in dailies, forcing agreements ("I want your commitment to this. If you don't agree, I'll ask again later.").
Man, that almost wore me down.

Anyway. You say "most issues are quite obvious to solve" and it sounds so easy. Maybe you are lucky, maybe I am unlucky. All I've seen so far is the exact opposite.

@VaderNT might be because of my Dutch directness? I've even told the CTO of a million dollar company off, when he started replacing hardware in our machines which caused one leave hall on the airport to be in error.