Many engineering orgs just give lip service to scrum, which is as good as not doing it, which is good and works better. Meaning, in my experience: You work in a priority queue, that priority queue is re-synced with stakeholders (at least) once every two weeks, retros may be there as an opportunity to get other business verticals into the room to see what engineering finished recently, and the concept of "a ticket going over to the next sprint" doesn't raise blood pressure, because the system is designed for this and sprints aren't deadlines. Features might have deadlines, absolutely, but that's independent of the sprint.
I've worked at ~three places that operated similar to this; "minimum viable scrum" is a good name, or even better, "emergent scrum" because it isn't a process that's designed, its the process that emerges when someone toggles the "agile/scrum" button in Jira, but no one really cares one way or the other. Its a good process.
I've worked in one environment that was hard scrum, had scrum masters, extremely strict. To be honest: I felt almost no stress, but the company also delivered very little. There was a lot of "we can't get to swapping the color on that button until Sprint 18 in three months, but we'll schedule it for then". Missing a sprint was life or death, so every estimate got padded like crazy. When you took vacation, it was common knowledge that you needed to leave halfway through a sprint and come back halfway through another, sprint planning would basically forget about you. That (public tech) company doesn't exist anymore, and it radicalized me against agile/scrum: The entropic end-state of perfectly executed agile/scrum is an extremely well-lubricated machine that actually does very little.
Work queues are themselves an issue. Instead you should have ways of documenting things that need doing that is adaptive. For example a groomed page about all the PDF bugs > 56 Jira tickers going back 10 years, some will take a day work to even fathom. It is a big time waste. For customer communication have case tickets. But a JIRA ticket is like body fat. You burn calories just to maintain it.
We don't do scrum. We release major versions once a month, and bugfixes daily. New features go into the next major version when done, bugfixes gets released as soon as they're done.
We use Kanban boards to get an overview and prioritize work. Apart from that devs mostly manage their own work.
We're a small shop though, perhaps that's why it works well.
But is it? Everything is the same if you squint hard enough.
We do not have anything like a SCRUM master.
We don't do stand-ups, we usually don't have a per-release target for features. For example, for the past three months I've had a target of October 1st for a feature, but no specific sub-deliverables for the realeases before that. This is typical.
We don't have a separate sprint retrospective meeting. We discuss such things during our weekly meeting, even between releases (ie we don't wait).
It doesn't feel like what I've been taught and have read about SCRUM. But sure I'll agree it's closer to SCRUM than to the waterfall method.
There are plenty. All you need is a competent team that trusts each others.
I work for a huge corporation. My team plans and commits to quarterly OKRs and has a team meeting once a week to check in on how folks are doing. There are no sprints and no 2-week deadlines. Once a month or so we update the progress scoring on the OKRs.
Yes. And it doesn’t work very well. Lots of late deliveries or reduced project scopes (often still late and over budget, but mot as bad).
Increasingly, iterative models are used and those are much better. For some reason since it isn’t Scrum people still insist they do Waterfall even though they do nothing like it.
Planes fall from the sky far less than, say, some agile/scrum-based web app shitting itself constantly, which happens all the time. Maybe waterfall has its place.
Eh. Waterfall adds risk to iterative approaches, not value. Wait 3 years to do integration testing because that’s what the schedule says. The smart projects get better quality and use iterative models.
Additionally, there are other iterative models than Scrum. That's pretty much the worst one out there and its only value is to inexperienced teams needing training wheels or overbearing management that doesn't trust the team.
Even worse. When I worked in that sector, the government simultaneously mandated that we use agile methodologies, and also that we do waterfall things. Doing agilefall like that was the dumbest possible thing, because we got the benefits of neither and the weaknesses of both.
