Hacker News Reader

Comment by yamtaddle | Hacker News Reader

The best effects I've seen from agile practices have been getting everyone to frequently think about deadline/feature trade-offs, reducing the occurrence of surprise bad news. I'm sure this is possible without "agile", but it's a thing I've seen it aid with.

The worst is probably standups-gone-wrong. There's little more demoralizing than a 20-person 3-team standup where you couldn't possibly care about what anyone says (because it's irrelevant to you) except three or four people, and you already know what they're going to say because you all, you know, talk, and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting and that's the kind of dumb-shit tone they've set for it ("now—justify why I should continue paying you" with pointed, bordering-on-hostile follow-up questions to anyone without a sufficiently-convincing theatrical performance) and you'd like to keep your job. Starting every day with a half-hour of that shit. JFC.

But, I'm pretty sure, overall, agile is one of those things where most places that it works, any halfway-reasonable system would have worked just as well, and places where it doesn't, no system was going to work.

View on HN

> and then also having to turn yesterday's work into some epic (LOL) tale of adventure and adversity because your manager's in the meeting

I find myself going over what I’m going to say in my head so it sounds good when it gets to my turn. I then end up not paying any attention to what anyone else is saying.

Yeah I wish more people would just say "I'm working on the same thing I was yesterday, no blockers, just need a few more days" and legitimize that if that's what's actually happening

I’m not sure why weekly status meetings lost favor.

Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.

The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.

Regular problems and communications are raised in the same group chat/group email.

It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.

At most places I’ve worked, long standups turn into “watch somebody else use Jira” meetings that all participants ignore until they hear their names. Not a great use of anybody’s time.

What is supposed to happen in Good standup?

"Any issues/blockers?" ... "No? ok - chat tomorrow".

“Good standup” also surfaces what people are working on because it might be important for the rest of the team to know for innumerable good reasons. It can serve as an opportunity for many-birds-one-stone, or even as an opportunity to interrupt work that doesn’t need to be done because it’s redundant to other efforts or because other efforts made it moot.

But yeah, you won’t get that from standups where people aren’t invested in what others say they’re working on. That’s just people blabbing for a (hopefully short) ritual time.

But why am I waiting for a standup to raise issues/blockers.

Nearly every company has a team chat now. And even before team chats became popular email lists existed.

And if you’re co-located then you just ask your neighbors.

I never have any issues to raise in standup because I’ve already raised/resolved them.

Exactly this. Why should we wait next day standup to discuss blockers? This is non sense.

In the few cases those need some synchronisation, further discussion and knowledge-sharing across everyone in the team, it's a time set for that to happen.

Anything else can be discussed asynchronous, when the need for some synchronisation happens the stand-up is a good way to tackle it in a iterative way. Everyone knows what to expect.

By the way I'm not disagreeing with you, my current team (and the best teams I've worked with) don't need a daily stand-up, just a recurring time slot available for a synch time when people feel the need. People can show up when they want.

Because everyone may not be available all the time except standup when all hands are on the deck. Or maybe the discussion is better done face to face. Or maybe the issue happened just before standup and the timings aligned with standup. Or any of the myriad reasons. The example also doesn't preclude raising issues outside of standup.

"Anything to bring up on those blockers, any help needed? No, ok, next: anything you want to bring up in the work in progress? Ok. Any further topics? By the way, if these topics are not relevant to you, you're free to go".

That's basically it.

The best daily standups I ever had went like this:

Everybody is physically standing up, in a place where there are no computers. Going around the circle, everybody answers three questions:

    1. What did you do yesterday?
    2. What will do you today?
    3. Any blockers?

Any long discussions were tabled until the standup was finished. It took about 5 minutes to get through a team of 6, and was a great way to kick off the workday. On Zoom, you can't get quite the same kind of effect. But you could still keep it short, and you could leave your ticket-board out of the meeting.

I find that the no-Jira standup is better, because it makes people more honest about what they've actually been doing. They don't feel the pressure to fit some kind of Jira narrative, and will instead just talk freely about whatever's on their mind. Much better from a team collaboration perspective.

When I’ve experienced this, I’ve availed myself of my personal favorite cargo cult rule: if you’re not getting value out of a meeting, you can leave.

Cargo culted from Urban Airship, and almost all of their meeting rules have been well received several places I’ve introduced them. Although admittedly in my experience this particular rule is best invoked with some extra social subtlety.

1. Thats no longer a standup but a planning meet

2. Those participants are not good employees then and should be told to pay attention or face further action. Meetings are for everyone to get on the same page, I’ve had too many engineers who think they have better things to do then implement things wrong or ask questions we covered in the meeting. Not something I’ll deal with anymore.

If one of ten employees isn't paying attention in a meeting, good chance it's the employee's fault. If most of the employees in a meeting aren't paying attention, it's probably the manager's/meeting-runner's fault. In between those, it might take some digging to figure out who needs to adjust to fix the problem.

I've seen 1hr 11am weekly status meetings turn into "does anyone have a 1pm?" as Sr managers drill into every developer over the minutia of their status reports. Single handedly the most unbearable meeting series I've ever attended.

At least standups have structure and they are "supposed to be short", which helps a lot in keeping managers nitpicking at a minimum. Open ended 'status meetings' are horrible. A weekly 1 hr "standup" with a "no managers are allowed to speak", "stick to what you did, what you'll do, what are you stuck on and need help", isn't that bad, but you have to have structure.

Plus, if you are doing "Scrum", in a retro you should be able to suggest just having a "mid point" sprint review and change the process. I realize that's easier said then done, but its a good smell test on your org's attitude towards their process. Just make the suggestion and from the reaction you can tell if you can change the process like you are "supposed to".

This is a problem with the manager then.

As far as I know, there's no such role as "manager" in a Scrum team.

The Scrum way of working is a joy, which I have gotten to experience in my career just once. Practically it also seems very difficult for an organization to support, at least many have failed.

Scrum teams need to be autonomous, or the process becomes torture. Scrum as a process is rather simple, but the context is exactly a team working on their own. SAFe and such seem more like consultant slideware to me .

> I’m not sure why weekly status meetings lost favor.

Likely because, at least in my experience, they suffer the same problem as daily meetings: They provide no value. If you aren't already in the know about status before the meeting comes around, you didn't care about it in the first place and won't magically start to care when the meeting is in progress.

Those who have meetings for the sake of process adhere to daily status meetings because that is what the process literature suggested to them. Anyone who questions that further questions what is to be gained by having them at all, leaving little in the way of middle ground.

> Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.

So you're spending longer and getting less accurate results?

> The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.

What prods them to think about that though? Often there's no clear threshold, and if you're supposed to keep it on your mind continuously then that's taking away from your capacity to think about what you're building. Having that daily sync point to take stock is very useful.

> It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.

I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.

Weekly isn't terrible, but I'd look at it from the other side: how long is it ok to be blocked for before you want to make sure you remember to raise things? A day works best IME. Maybe even twice daily would be better.

You don’t wait for the meeting to raise things. You raise them when they happen. We have enough async communication tools that you can raise issues without having to wait for a meeting, and yet without disturbing someone who may be focused on something specific.

Really easy to thrash at something for days though thinking you are ‘almost there’. And someone else on the team might be able to help either directly or help you think of the solution if you just spoke out loud with the team sharing information.

> I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.

I don't think that is what was meant by context switch persay. It's like reading a fiction book, the context is the story. If you put that down, you might have to come back and re-read the last few pages to remember where you were exactly.

Worse yet for meetings, personally, about 15 minutes before I have to stop doing mostly anything so that I'm not too into it to then be late. About 5 minutes before I literally do stop everything otherwise I'll get into something and look back at the clock and it'll be 3 minutes past the hour.

A productivity hack I'm trying is to set an alarm for a few minutes before a meeting so I can do this more reliably without so much of a context switch.

All in all, given about 10 minutes before the meeting it is intentionally doing little so you can click that button on time, and then there is the time needed to get back into your work (most literature says it takes about 20 minutes to regain programming context), any meeting costs about 30 minutes of context switch overhead. It's a lot of time given a 8 hour work day.

You hit the nail on the head here. The whole standup process is extremely degrading. I don't think I'd ever work at another company that does a daily standup, the most I can take is 3x/week - and ideally as short as possible.

My current employer doesn't do any stand ups at all. I've been there four months and not a single all-devs meeting. Sure we avoid degrading. But I've never been part of a team that's more dysfunction than this one.

Introduce one? But call it a quick 5 mins regroup with the team.

I wiah. But it's not even on the radar. In fact, I'd be marginalized more than I already am. I said to someone on the leadership team, "How can we have a team without a single team meeting?" I got no reply. I'm not even sure they heard me.

I suspect it depends a lot on the standup. My favorite place I worked had a great one. 10-15 minutes every morning, a brisk and helpful way to get focused, line up the help you needed, and kick off the day. I miss it deeply.

We talk for a full hour every day, but there are only usually 5 or 6 of us, and we are all invested in every feature, so the meetings end up being a fairly detailed review and feedback on everybody work.

> full hour every day

> invested in every feature

Sounds like hell to me.

I got pushed to a team that did this. I decided to try to extend the meetings for as long as possible with the goal of eating so much time nothing got done anyday. The daily stopped shortly after

Interesting! Did you all find that helpful and worth the time?

Conversely, I did a project once where we had not a single stand-up in 9 months. CEO would come up with some designs, I'd asynchronously comment on them with questions or concerns, then slice the designs into tickets that'd I'd pump good amounts of context and detail into, estimate and prioritize, then chuck my engineering team at them. We'd all asynchronously work on them. If they had questions, they'd slack me. This across five timezones.

Once or twice we'd have a miss on a ticket probably because I didn't define it well enough, but I'd just point out the issues in code review and they'd rewrite as needed. Oh well.

Meanwhile we all have a phenomenal quality of life because our entire day schedule is set on our terms. And we delivered a whole ass SaaS product from scratch in like 9 months for around 2,500 engineering hours if my brief math is right so the founders were happy.

Behold: Utopia.

Why, "conversely"? It sounds like you had a great experience, which I'm happy for. But I think there are plenty of good ways to work.

Converse argument I mean. As in, allow me to offer a different experience I had. I may not be using the word correctly.

Could you say more about the team size? Taking a 2000-hour year as ballpark, 2500 hours in 9 months is puzzling to me.

And as long as I have your attention, how many releases happened during that period?

2500 hours in 9 months could be two developers logging hours on the project. The project may have had stretches when dependencies limited the amount of work that could be done, and often one assumes at least an hour of non-billable time lost to miscellaneous business shit, per IC, per day.

The rest of the team (not logging engineering hours) may have included a (probably part-time) designer and likely some kind of project manager (likely also part-time—that is, managing 2+ projects at once for different clients).

7 (billable, on average) hours * 47 weeks (assuming 25 weekdays lost to holidays, sick days, and vacation, over a year) * 5 weekdays only yields 1,645 hours per worker per year, anyway. Divide by four, times three, to get ~9 months, and 2500 hours just looks like two full-timers on the project, really, if we're talking billable hours, but that's also (it reads like) not counting support roles and non-dev contributors like design or PM or maybe testers. Or it might be one full-time and two half-time devs, or whatever. I'd guess not more than four developers contributing significant time, anyway, based on the numbers and with fairly pessimistic assumptions for how many hours could be logged a week, and maybe as few as two.

I'm rough on the math cause I don't have the billing sheets in front of me, but the other person was pretty close.

The team I managed was me, functioning as frontend lead / architect / engineering manager as well as individual contributor. I then had three junior / early mid-level frontend engineers working with me.

I was pulling 40-60 hour weeks (contract so I didn't mind, just meant more money), the other devs were between 10-40 depending on how much work I could lay out in a sprint. Timezones were Taiwan, somewhere in Europe can't exactly recall, NYC, and California iirc.

That accounts for the frontend. There was a data system that was mostly built when I showed up, by one full time engineer at the startup. So that would be another 40 x 4 x 9 engineering hours on whatever he was working on in the meantime.

Then there was an API that would middleman requests to the data system and build out models and handle customer accounts and shopping carts and other data adjacent requests. That was one full time backend engineer over whom I didn't have responsibility, so add another 40 x 4 x 9 for that.

Finally, the designer was just the CEO. He would draw things up on figma and I'd slice them into frontend tickets. Now that I think about it I think the API engineer was consulting the same designs as he built out the API, I'm not remembering exactly.

So technically my original estimate is just for the frontend, it cost more when considering the whole system.

We "released" every merge into the main branch, internally. The CEO would constantly be giving feedback. It caused some friction occasionally, the classic "right the alignment is slightly off but what do you think about the actual interaction" type shoulder bumps, nothing major. Good feedback loop that basically daily aligned where I should be directing frontend priority.

There was a major customer facing release where a couple core customers were brought off the no code platform onto the new system, that cooked for about two weeks while we collected feedback and engineered against it, then another major release where I took advantage of the respite to do a major rewrite of the naively implemented request management system and fixed up some auth stuff, then another big release and then everyone else is brought over.

I still work a couple hours a week on the projecy but no longer as a leader. Looks like releases are still just kinda whenever, which I think is fine. There are "sprints" and have been the entire time but always quite informal.

I think a lot of this is just personality driven. I don't find meetings to be a way to get focused or a way to "kick off the day"; indeed, I always need a break afterward. Yes, this applies to a good 10-15 minute standup. And I don't really know what people mean when they say things like "line up the help you need". Why would I wait until a meeting the next morning to reach out to relevant people for help?

However, I recognize that lots of people don't feel the way I feel about any of this.

> Why would I wait until a meeting the next morning to reach out to relevant people for help?

It's hard to notice you're stuck when you're stuck. For a lot of programming problems putting your head down and ploughing through is the right approach - but you do need to come up for air occasionally. And if you need help then it can be hard to ask without feeling like you're interrupting someone else's work, so having a regular point where everyone's already not going to be in the middle of deep work is useful.

Again, I recognize that this is a "to each their own" situation, but I don't relate to this at all. I know when I'm stuck and I know who to ask (or who to ask who I should ask) and I have good asynchronous communication tools where I can ask people things without immediately interrupting them.

A lot of people believe they know the optimal time to reach out. But with my manager hat on, it's also true that a lot of people wait well beyond what's optimal for the organization. Things that can get in the way include pride, anxiety, laziness, a tendency to procrastinate, underestimating the resources available, and overestimating the cost of interruption, and underestimating the cost of delay. Maybe you are the rare sort of person who is perfectly calibrated. But if so, know that it's rare.

No, I'm not that rare sort of person. But it also isn't in the organization's best interest to force everyone into a single style of work, rather than supporting people in their own preferred style of work. That's why management is hard! If it were as easy as "having a status update meeting every morning is the optimal process for everyone", we could pay managers a lot less :)

I think there's conflict between "own preferred style of work" and what's effective for a given team. If there's a team of people who are, say, doing fine communicating only via pull request, then I wouldn't mess with them. But if somebody of those habits wanted to join a team that was into pairing and a faster release cycle, then I would suggest that new person look elsewhere. So although I don't think it's in the best interests for a large org to force everybody to work similarly, I do think it's in an org's interests to support teams finding an effective joint work style, even if that means a given individual might not find it optimum or might even have to find something else to do.

For what it's worth, treating my social anxiety made a big difference for me in this. A bad meeting is still draining, but good ones can be positive and energizing.

> Why would I wait until a meeting the next morning to reach out to relevant people for help?

Having a specific time for it makes it easier for people to do. It normalizes it, so it lowers the bar to ask for help. Also, note that this comes after a discussion of what people are working on for the day. So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?" And it's also natural for people offer help without being asked, so that lowers the help bar futher.

See, I used to think like this, that I have social anxiety. But as I've grown older and participated in more kinds of social situations over the years, I've learned that I don't, actually, have social anxiety problems; I love socializing, I think even more than average (the pandemic social starvation taught me this lesson).

What I have is a personality, which means that I have a set of preferences for my interactions, just like everyone else. It's fine that some people prefer group meetings, and it's fine that I prefer documents, chats, and 1:1s. We're just different people with different personalities. What I don't like is the group-meeting-preferrers seeming to believe that their preference is normal and my preference is aberrant. I find that condescending. I'm happy to accommodate other peoples' preferences, but I don't need to change my own preferences to align with theirs in order to do so.

> Having a specific time for it makes it easier for people to do.

Again, I don't relate to this. I agree with you that it makes it easier for some people to do, but I'm not in that group of people. My point in this thread is that people are different.

> So it's natural to say "Looks like I'll be getting into the foobar system today; who worked on that most recently?"

It is much more natural for me to say "`git log`, what have people been up to in this system recently?". I prefer to read text than listen to verbal explanation. I also don't usually want to be offered help without being asked, I just want to go read and work.

Again, I'm not at all saying this is the one true way, but please believe me that I just have different preferences that make status meetings less interesting to me (and I think a lot of other people) than they seem to be to you (and many others).

I believe that you have different preferences. And I'm happy to take your word that you don't have social anxiety. However, loving socializing doesn't prove it. I loved it and also often got anxious. Now I love it as much but am not as anxious, which has made the social parts of collaborative work easier for me.

As to the second bit, I'm sorry to be contradictory, but having a specific, in-person time where asking for help is normal and expected lowers the barriers for literally everybody, because the particular barriers being lowered include costs like "figuring out how to contact the person", "being concerned about catching them at the right time", "contacting the person", and "delay in receiving a reply".

If you have a different approach you like better, that's great! The way a team works should match the needs of the people on the team, and of the team culture. There are plenty of teams out there, and good work gets done lots of different ways. I hope everybody ends up on one that works for them.

That said, "personality" is not an immutable set of characteristics, and not all of the way people express their personalities are equally good for collaborative work. As an introvert who also wants to get things done at the scale only a team can provide, I'm just always going to have to stretch myself.

I may also decide that I can only stretch myself so far, and so my limits may mean that there are kinds of work I'm just not well suited for. E.g., large companies demand too much of what I think of as "political" behaviors for me to find the work sustainable. So although I think we should generally try to honor each other's preferences, we must also be honest about the fact that not all preferences are equally suitable for every kind of work.

I disagree with your (in my view) far too prescriptive certainty that a lot of synchronous communication is universally best for collaboration. It is a common view (especially among managers) that I believe is simply wrong, and based on vibes rather than empiricism.

It's not universally wrong though. All I'm saying is that it isn't universally right. It just isn't universally anything. A good manager or lead should be able to look around on some teams and realize, hmmm, we aren't getting much value out of all these synchronous touch points, and on other teams they should realize, hmmm, we could use some more frequent synchronization here. But a manager or lead coming in with their own prescriptive preference for daily synchronous meetings, and failing to notice if they aren't valuable, is not doing their best work, IMO.

I have been on both kinds of teams. Indeed, right now I'm on a team for which I think daily morning meetings are working really great, regardless of my own personal preferences. But I've also been on teams where they are working terribly and only the manager is happy with the situation, and that's bad.

For me it's based on a pretty simple feedback-loops model. The length of the feedback loops limits all sorts of important things, especially external responsiveness, adaptation, learning, and error correction. Collaboration requires co-laboring.

There are circumstances where collaboration isn't particularly necessary, of course, so maybe that's what you're looking for.

I agree of course that there are plenty of ways to have bad collaboration even with short feedback loops, as in your last example. It's not a panacea. Nothing is.

Your last statement is insightful. Thank you.

The major problem facing the industry is doing agile just because everyone is doing it, not because it is the right tool for the job. No matter how much money or people you throw at it, it's not going to work.

> The major problem facing the industry is doing agile just because everyone is doing it, not because it is the right tool for the job. No matter how much money or people you throw at it, it's not going to work.

I recently started a role running an Engineering org at a startup. The first two questions I asked everyone are why are they doing scrum and what do they want out of the engineering process. Answers to the first question were all over the map, and answers to the second were almost identical.

> you already know what they're going to say because you all, you know, talk

Standups are a pet peeve of mine especially. If the team isn't communicating regularly, then there's a larger issue that standups won't solve. If it is, then standups are a complete waste of time.

> Starting every day with a half-hour of that shit.

Oh, you sweet summer child.

I wish it was only half an hour at the start of the day.

Right? 20 people? Dog and pony show with follow up questions? This isn't a half hour meeting, this is at least an hour.

This is where a decent Scrum Master or Agile Coach makes such a massive difference... I've seen what you're describing so many times and it's a simple fix to get people to stop focusing on what they've done and to instead focus on what the team needs to do (ie focus on work not yet complete for the team and not what on the individual has done/will do)

People care and should care about what they get rewarded for. If promotions/raises/bonuses are based on the manager's view of your personal work, as is the case at most companies, then that is exactly what a sane person should focus on. Removing the manager from the standup or adding another layer of a Scrum Master won't change that but merely change how they get that same information. Standup at least provides an equal opportunity for everyone to sell themselves in those cases.

So people with better communication skills would get rewarded more than people contributing more on the actual delivery side?

He's not suggesting that's how it should work, he's saying that's how it does work at most places. It's my experience too.

As the other comment said I'm simply noting the unfortunately reality that what matters is rarely actual delivery. Trying to avoid that reality won't make things more tied to delivery but simply more opaque as to what they're tied to.

There's exceptions but in my experience those teams don't bother with these types of deep discussions on process. The process is somewhat irrelevant since the expectations are fairly clear and what they will be measured on is also fairly clear.

If the SM is seen as or becomes a layer between the team and management, they aren't doing their job correctly

All those people do is make me disgruntled knowing it's someone's _job_ to run this bullshit circus. Automate the lot of it away, don't make it someone's career.

Good in theory

In practice, any standup format where developers show up and basically perform to some standards set by a “master” or “coach” is kind of doomed to feel a little bit like a circus show.

The problem is the existence of someone else running the show in these meetings. The best standup I’ve had were those run by the engineers themselves. Adding a “coach” or “master” just makes everything worse unless the team is really bad at communicating with each other, in which case you have bigger problems.

Lord knows what people are calling coaching these days. But if they're actually coaching, then yes, getting the team to run the meeting was exactly my goal when I did that kind of work.

But that can be tricky. The biggest issue is to train managers to not make it about the manager. For that, an external coach is especially helpful, because it's the rare engineer who can sit their boss down and say, "Look, you're destroying this meeting. How about you not show up for the next two weeks, and then optionally show up but never speak for a month after that?"

But even once you've created a space where power doesn't distort everything, there are a lot of things that can go wrong. People who talk too much or too little. People are unkind, rude, cutting, or outright mean. People who talk about the wrong things. People who don't even know what to do if there isn't a manager around to try to please.

The truth is that for most people in the industry, their median meeting is bad. People with shorter careers may never have experienced a good meeting. So expecting them to just figure out how to have an excellent meeting every day is asking a lot. Especially a stand-up, which has pretty sharp constraints. If a team already knows or quickly figures it out, great. But a coach can really help.

This would be the goal of a decent coach, to ultimately not be needed by the team you're working with (ie they run things by themselves)

Scrum works best if you can find a true Scotsman to be the Scrum Master.

I snorted...stealing that line for future use :-) You win the interwebz for today :-D

> whenever agile project fail, agile shaman say "you didn't do agile right!" grug note this awfully convenient for agile shaman, ask more shiney rock better agile train young grugs on agile, danger!

pure marxism has never tried! if only we try the pure version it will work better! Marx had some good idea, communism stinks. Agile manifesto has good ideas Agile stinks. Maybe not as bad, but let's move on

I've found a direct correlation that the more closely a workplace conformed to the Agile manifesto, the better it was to work in. It absolutely does work in practice, and where it doesn't work I have always found specific, actionable places where they were doing it wrong. At some point you do have to actually spend 5 minutes to try to understand and follow the methodology - I don't think there's any methodology that claims you can ignore everything it tells you, do the oppsite of what it says half the time, and it will still improve your organisation.

(Unfortunately I haven't found any correlation between how much an employer talks about Agile and how closely they actually follow it)

I know you're being somewhat flippant but if agile shaman blame team for not doing agile right team should throw agile shaman off nearest cliff and find somebody who's not doing that job as some kind of dodge... too many self declared agile coaches and scrum masters out there who have no idea what they're doing - it usually starts because the organisation gets their first feed of them and agile through a consultancy who just tells them what they want to hear rather than they reality, and the senior management usually can't get out of that headspace.

To paraphrase: "The 3 questions now considered harmful"

It wasn't until 2020 that the 3 questions were dropped from the scrum guide (https://www.scrum.org/resources/blog/going-beyond-three-ques...)

Personally, I think the biggest difference is just anyone on a team who is empowered and is thinking deeply about process is the key.

Sounds way too familiar. I tried to make things more pragmatic and exciting for everybody and was put down. Human nature at play.

lol, this is exactly the team I'm on that I got moved to because I hate scrum and they thought they were doing me a favor after a product focused reorg.

just...hours of useless status meetings.

It didn't start like that, but they overhired, and the time not in status meetings is split between a dozen slack channels. bleh.

> getting everyone to frequently think about deadline/feature trade-offs

I never let anyone else impose a deadline and a list of features on my schedule.

If the features are mandatory, I will provide the deadline. If the deadline cannot be missed, I will accept a sorted list of features (by priority). In both cases, I'll do my best to cram the most value possible in the next release, but the sooner I need to commit to its content, the poorer it will be.

If the deadline and the list of features are both set in stone, then it's not my problem.

Reply on news.ycombinator.com