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.
Great question! Our users see a 6 point improvement in ISI (insomnia severity index) on average in the first 7 days, which represent a categorical improvement in insomnia severity e.g. from severe (clinical) insomnia to moderate (clinical) insomnia, or moderate (clinical) insomnia to mild insomnia. ISI continues to improve during the program, and the benefits are sustained after that.
Another important consideration is patient adherence (i.e. how likely someone is going to stay for the program), which is something that many digital health apps (and even in-person therapy) struggle with. A lot of this is influenced by personal preference too (do you prefer reading, or watching a video, or listening to an audio to consume content etc). So you can tell from the first 7 days if our approach resonates with you.
We also have a 30-day moneyback guarantee, so if the program doesn't work for you, we'll be happy to issue a refund.
if we had to eat this elephant one bite at a time, one option to consider is completely seperating sports from colleges?
What would be the impact? What are the drivers that could enable youth to participate in sports run/administered by a 3rd party as well as attend college?
Instead of a GirlfriendGPT, a personal assistant GPT - which is hosted in a private location, and receives feeds of all your personal data ( emails, calendar, fitbit) and adhoc ( I can send a note to it saying I drank 6 beers last night).
It also then remembers all the past conversations, and i guess by then forms a decent idea of your tastes, etc.
this "not knowing the neighbors" is a flimsy excuse at best. This is mostly true of any densely populated city around the world, where people move in for jobs.
In the past few years, crime in some US cities are committed by certain groups of the population - who are partly encouraged by the local powers.
reply