> do not adopt all the "Scrum rituals" like standups, retros, etc. wholesale, and if you do, keep them asynchronous. There is little added value to a voiced update

I couldn't disagree more. I know it's an unpopular opinion, but when standups are done synchronously, everyone actually pays attention, notices blocks and helps with them. Things get surfaced and quickly addressed that simply wouldn't otherwise, which is the purpose of standups. When it's async, people just put in what they're working on and mostly ignore everyone else. Standups need to be about 2-way communication, not 1-way.

And retrospectives are about improving how the team works. Every team has challenges of every kind. Retrospectives are for surfacing those and addressing them. They take up a couple hours a week, but the idea is that after several months the team is more productive and it pays for itself in time.

> Organic 1:1s (as opposed to recurring ones): keep them topic-heavy and ad-hoc, as opposed to relationship maintenance like in the corporate world.

Also disagree. 1-1's aren't about "relationship maintenance", again they're about surfacing issues that wouldn't arise organically -- all the little things that aren't worth scheduling a conversation over, but which need to be addressed for smooth functioning.

At the end of the day, managing a team is managing a team. In terms of managing people, it's not fundamentally that different if you're a 10-engineer startup or a team of 10 engineers at a megacorp. These things aren't "anti-patterns" or "rituals". When done correctly, they work. (Obviously, if done badly, they don't -- so if you're managing a team, do them correctly.)

▲

bob001 11 hours ago | parent | next [-]

I disagree. In a company of 5-6 total engineers who are actually self-motivated and competent none of these things matter. If you need stand-ups for people to be aware of work being done then you're bandaid fixing a deeper issue. Same for retros since all of that should already be getting communicated in five other ways. If not then you've got bigger issues. Same for 1-on-1s. If the founders don't know these things organically then they have failed either in their own roles or in who they hired. The solution to that isn't rituals.

In a large org where the most senior IC and the manager are both in 35 hours of meetings a week while the rest have 20 a week you need rituals. When all they are focused on in engineering then you don't.

▲

crazygringo 10 hours ago | parent [-]

It has nothing to do with motivation or competence.

Teams don't just work together magically and "organically". They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when. Different levels of experience, having worked at different places with different practices, and different preferences about how to do things. This is a recipe for a hundred miscommunications and inefficiences and misunderstandings a day.

These processes exist to surface the most important things not being surfaced, and to identify and fix problems that affect the team but which nobody is understanding in full because everyone only knows their own perspective.

Again, these aren't "rituals". They're processes that are proven because they work. Including with 5-6 engineers.

▲

bob001 9 hours ago | parent [-]

To me you're describing a team with mediocre communication and social skills. That's common but its not all teams.

It has everything to do with maturity, motivation and competence. The best teams I've been on didn't care about these rituals because each person bridged the gap with other people. The TLs kept an eye on everything the TL and EM kept an eye on all the people side and concerns. In a startup it'd be the founders. There was mutual trust built by those in leadership roles and issues were communicated and everyone kept an eye out for them.

> They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when.

Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.

	▲	crazygringo 8 hours ago \| parent [-]
		> Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids. Yes... the meetings are called retrospectives. One of the norms is called standups. You don't need to belittle these processes as being for "little kids". That's deeply unprofessional. Maybe there are some teams made up entirely of these 10x communicators you describe where everybody perfectly "bridges the gap" with other people. All I can say is, I've never seen it. And knowing everything I know about how easy it is for miscommunication to happen, I'm inclined to suspect that if you think you worked somewhere like that, you simply weren't aware of how much further communication and processes could have improved. After all, how could you? It's incredibly easy for us to assume that things are working as well as they could be. Until we try something like standup+retrospectives and are surprised at how much value they end up bringing.

▲

OhMeadhbh 11 hours ago | parent | prev [-]

yes and no. "agile" has become doctrinaire and "one size fits all." i miss the eXtreme Programming era where standups, pair-programming, test-first, timeboxing, etc. were all "tools in a toolbox" to be applied as needed. i think the OP is experiencing a world where they're told "oh, here's AGILE. you have to do everything in this book," which i think i would push back on as well.

but... if you're going to do standups and retrospectives... i agree with you. do them synchronously. the idea is to get everyone to listen to everyone else. the reason they're STAND-ups is 'cause everyone's supposed to be standing so there's motivation to keep them short. this often makes it difficult to do "follow the sun" development. i quit a job a couple years back because my management insisted my engineers on the US west coast be included in standups for teams in Pune (India).

and that 1-on-1's are for surfacing issues that haven't come up elsewhere seems like received wisdom among my peer group. it seems to work well for me, so +1 on that too.

the phrase "when done correctly" is doing a lot of heavy lifting here. i bet people who have bad experience with these practices were in situations where they weren't done correctly.

one of my problems with environments where management thinks devs are interchangeable bots motivated only by money is that there is zero motivation for management to change their approach when it doesn't work. if they think the only thing that motivates people is money, they think they have to add more money or fire their devs and get devs that are appropriately motivated by cash.