My experience has been 100% the opposite. Daily public status check-ins, top-down decisions, every work interaction mediated through artificial structure? The points are made up, the deadlines are obviously fake, but everyone acts as if they are real? Except when they're not?

That, on its own, would make it clear the environment wasn't built for me.

The fact that the environment was very obviously built for management—for information to flow up so that decisions can flow down—but also that nobody is willing to acknowledge that? That just makes it even clearer.

I've worked in an environment that did feel like it was built for me, and it was pretty much the opposite of scrum/agile/etc. I had real trust with a clearly defined area of ownership. I was responsible for managing the interfaces and interaction points around my area and, occasionally, for real deadlines (with real context!), not a slog of fake short-term deadlines that exist just to create pressure. I didn't have to break down or justify my work in terms of bite-sized tasks that could roll up into somebody's spreadsheet.

And the best part? We got more done, faster, than conventionally managed teams.

If the culture hadn't been totally ruined by a reorg, I'd still be there. I'm still sad I haven't been able to find anything similar since. But, having experience that, I am only more confident that scrum et al are absolutely not built for me.

▲

justonceokay a day ago | parent | next [-]

Of course the environment was built for management. But if you have ever been in management you know that getting useful updates on progress is like suqeezing blood from a stone.

I didn’t say that anyone liked the process, but I assure you that the average autistic engineer would actually do worse in a more feeeform environment. They would like it more though.

▲

jrockway a day ago | parent | next [-]

It is sometimes difficult to get progress reports because it's difficult for the people who are doing the work to figure out where they are in the process. For example, imagine that you have some tickets; "Add create method, "Add delete method", "Add list method". You take the first ticket, and decide to add the RPC server, and the authentication infrastructure, and the test harness, and the CLI wrapper. What do you say on the progress update? "You've been working on this for a week, why isn't at least one of those done?" The answer is because the tickets are pieces of value that the business wants to ship (you can ship without delete, I guess), but it's not actually how the software is assembled. What happens is that someday, you say "I'm done with create" and then 2 hours later say "I'm done with delete and list". That makes execs feel like they're being misled, but it's true.

Of course, if you actually enumerate the "how" and not just the "what" in your ticketing system, you can get a much more realistic view. "Add foobar RPC server", "Hook auth into the foobar RPC server", "Add foobar subcommand to CLI", ...

I think everyone does better with a clear set of expectations, autism or not. That's why we do design docs, design reviews, and try to put a realistic set of work into the ticket tracker. I would say personally, though, 99% of the time I don't really need to do that to get a good result out of myself. I can just say "by next Tuesday I will have this subsystem done". Typically this is done with heroics rather than good planning (Monday becomes a longer-than-average workday), so I try to avoid it, but I definitely understand why people want a more freeform environment.

	▲	lazyasciiart a day ago \| parent [-]
		> (you can ship without delete, I guess) And some management type will say when you're halfway through 'add' that they'll cut 'delete', but it's impossible to automate anything without a delete option, so you implement it anyway during your testing and then they get mad.

▲

Rumudiez a day ago | parent | prev [-]

I've been my own manager more than once and on teams from a few folks to a couple dozen in size. Rigid schedules and expectations absolutely make me less productive. My last 2 startups were chock full of fast paced, high quality work that got us off the ground and up to hundreds of thousands of users with me as the single engineer building apps for web, iOS and Android by myself. That is, until we hired engineering managers who tried too hard to get a glimpse inside my head, after which productivity dropped off a cliff. My current startup now has around 10 app devs and it feels like we deliver fewer features over longer timelines at a lower bar for quality than ever.

▲

liveoneggs a day ago | parent | prev [-]

You're just describing a high-trust/senior team. That same group of people would have made scrum seem cool too.

Scrum can protect you some really nasty stuff.

	▲	tikhonj a day ago \| parent [-]
		I've also worked on some relatively senior/high-trust teams using roughly scrum-style processes, and the experience was decidedly worse. Even with the best setup and intentions in the world, the process still makes focusing on small, individual tasks the path of least resistance, which leads to less collaborative, more short-term focused work with less flexibility and ownership. A sufficiently strong team can make even a bad process work out okay, but that just means they're strong enough to compensate for the process, not that the process had any latent merit.