Comment by justonceokay 2 days ago
In my opinion the entire structure of scrum and sprints is structured to help people with autism and adhd. Most workplaces that produce creative output are much more focused on soft power, networking, and hard deadlines—things that really don’t work for the “au-dhd” crowd.
It’s easy to remove the locus of control by saying “this environment wasn’t built for me” but do appreciate how much it actually /is/ created for you.
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.
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.
> (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.
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.
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.
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.
Scrum is pretty bad for au-dhd crowd. It misses proper checks on business interference, which makes things even worse. It is constant pushing the worthless points (why not a time unit), kpi is about scoring points or useless improvements which have to happen anyway (merciless refactoring, yeah!). Devs could simply atomize every task and win this stupid game, but then you lose oversight and we get to lie number whatever. Everyone should be responsible, most people ain't generalists. They are specialists often.
Kanban gives more flexibility. Scrum seems to fall apart like that eventually leaving a power vacuum for tasks out bound of scrum. Active products have constant support questions.
Then you have SAFE, which is even worse. Waterfall but then even worse. Coordination seems to be very complex, the diagram is close to unreadable. Looks like a badly designed production street for its purpose.
That is a problem. For who is it created exactly?
> the worthless points (why not a time unit)
The story points people won the battle against time units, claiming that "complexity" can be measured and quantified better than "hours" could, but in every place I've worked, people just treat them as though they're actually some unit of time. Product managers and my bosses always believe you can do arithmetic with that (multiply engineers assigned to project by 2 to cut time in half right? Sum up 25 points and be confident 5 engineers can complete them all in a week right?)
Then we occasionally have to pretend to really care why our "velocity" isn't arbitrarily higher or why it's less than it once was, when all of the tasks have estimates from 1-5 with at least a 1-point margin of error. There's so much noise that no amount of smoothing yields useful data that you can use to achieve "certainty" -- such as that X project will be done in Y number of sprints, which is what senior management craves most, but can never safely be promised unless you have a death wish.
Basically I'm convinced at minimum like half of teams that "do agile" or "do scrum" are just cargo-culting and derive no particular benefit from it. I don't think I'd even do estimation of any kind if I ran a software team as I saw fit.
I had to laugh about your comment, this is exactly how it goes. People are used thinking in time units.
Then you have modified fibonacci, which make me puke. 1, 2, 3, 5, 8, 13, 20. I get special headaches because of names like this.
However you can find this page if you adding them up by as strings, it isn't connected, but attack on titan was a good anime: https://www.pixiv.net/en/artworks/123581320
Weird coincidence. I need to sleep, spend a lot today in my headspace.
Thinking about complexity as entropy, the friction, so they try to estimate "useless work" in their eyes. Heat transfer is velocity then. Firing up the next cycle. Detectable Delectable malicious, makes me hot really. Fiery.
It is just engine design really;) How bad can that be?
We don't even get real time, just pretend time. But I have to say, I admire this idea. All the time wasting around it, retro's with stupid humiliations. They run on naming and shaming. Sticks and carrots.
Works well :D Until people stop participating in the retro's. There is nothing to say, nobody says anything. They start atomizing the tasks infinitely or always inflate the estimate by 2. The standup nobody speaks, but they work like silent ghosts.
Scary sight huh? Happy Helloween vibes inglorious bastards.
Scrum is literally a scam though. It was invented by some guy not even worth remembering who sold it to both sides (buyers and sellers of software). On the buyer side, the incentive was to encourage the seller to use scrum to communicate progress. On the seller side, they are encouraged to use scrum because the buyer wants it, and it "proven" to be an effective management tool.
There are too many unknowns to deal with to actually make use of it, and managing the unknowns is a whole other aspect of management outside scrum. This is why most scrums essentially devolve into ad hoc work per sprint with very loose planning.
Its not so much as estimation as a whole work style, but
Make it work -> Make it right -> Make it fast
is arguably the best way to go about things, then structure your work around that.
Ive done this with greenfield projects when I used to work for Amazon (while still ironically operating under scrum), and was able to get SD2-SD3 promo within 2 years (entering an an SD2).
In terms of planning work, you basically allocate people as necessary. The first part deals with a lot of unknowns, so estimation is pointless - basically everyone is on board in terms of getting software up and running and talking to other software.
Once you have that, making it right is a lot easier to estimate because you can do a lot more fine grained planning (like for example, a certain team member that worked on a feature can add all the correctness and unit testing way faster than someone who has not)
Then making it fast is basically just optimizations, which can be done by a subset of team members while the rest work on adding features (and adding features needs to be done in the same way - make the feature just work, make it correct for all use cases, and then make it optimal)
If there was a fund to help remove sprints, scrum, Jira and standups I would donate to it.
It's like a factory but the people are the machines.
Probably many of the people who hate writing code for a PM at work, love working on their own open source project.
And the difference is freedom.
Hear, hear.
I think higher management likes to believe that those things (sprints, scrum, Jira and standups) provide a safety net against lazy employees not working hard enough, so they cling to them. Of course, they actually do little and are pretty easy to game. Their failure to magically make all software work predictable and deterministic and all developer time fungible actually means that you still need a manager involved and close to the work to identify people who BS their way through everything and take way longer than they should.
I'd rather be in an environment where you are given access to simple tools like kanban to prioritize and track work, and for people who don't deliver, the manager just fires them (maybe with one warning).
I've been in the software business since 2007, which was also when I first met Jira and Scrum (at least something with 14 days sprints).
My first encounter with Scrum (or whatever it was) was good. It felt good to work in cycles and reprioritize twice a month.
Since then I have seen various versions of working systems and various versions of broken systems.
The two last projects have been extremely agile, the current project has exactly 5 mandatory meetings in an average week:
- 3 x stand ups that typically take <10 minutes and never more than 15.
- 1 stand up plus planning (scheduled 1 hour, typically takes 20 minutes)
- 1 stand up plus voluntary demo + retro (scheduled 1 hour, typically takes 30 minutes)
The previous project had a lot more structure but also worked well.
Common themes:
- Communication is 2 way
- Both teams are friendly and competent
- Customer care about results and leave programming to us
- Clear communication about what they hope, but without stress. Especially the first project were the stakes were serious: if we manage to hit the deadline we knew we would save the organization millions, but if not, nobody was in trouble. It was an actual challenge, not a scary thing.
Have I seen dysfunctional Scrum and Agile as well? Yes!
Some examples:
- endless estimation meetings which not only eats programmer hours but also mean that everyone feel they have to match the estimates
- one way communication (in a loop from customer - ux - programmer - tester - customer). Doesn't help if there are 14 days sprints when every sprint is a mini waterfall
- taking time of the project to do agile workshop after agile workshop while continuing to be absolutely rigid
- "release" after "release" but no actual customer
- "finish one thing" taken to mean that styling has to be perfect even on placeholder pages
Scrum gives you (the team member) the power to decide what your commitment for the next sprint will be.
If you have a manger, that decides this, or the PO decides this, IMO that’s a key problem of your scrum implementation.
This, it is costly, certain personal walks away. Proper roles seem to emerge anyway.
The cost of control and the costly overhead has everything to do with atomizing the work load. Just like in a distributed system. The synchronization mechanisms get more complicate.
The more layers, the less trustable the organization, since every manager under their manger, is a potentially corruptable.
This makes the communication lines unclear and makes people over promise. Also distributing the workload has diminishing returns.
I am not a fan of scrum or other systems.
Why would you expect freedom at work? Employment is by definition working for someone else, so you are going to be working on their goals, not yours.
It’s built to make upper management happy with the facade of productivity, middle management employed, while they squeeze the most out of the workforce and keep up the constant pressure (endless sprints).
It’s not built for the product team (devs, designers, QA).
In some cases, coincidentally, it might be good for some neurodivergent folks, I guess…
…as long as they don’t mind the constant bugging for updates, interruptions, and constant pressure… I’m sure it’s an environment where people with ADHD etc shine.
No, just no.
As someone with ADHD, I am orders of magnitude more productive when I do freelancing than in an SCRUM based corporate environment and much happier. And I mean orders of magnitude, I am not being dramatic. (Though that only works if I work on something I am interested in otherwise my lows are even lower.)
Task switching is a typical issue for both ADHD as autism people and SCRUM has so much. Just the damn dailies are complete murder for my mental health and productivity.
The problem with SCRUM is that it focuses on everyone being a cog in the machine. Everyone replaceable. At best it allows teams to self-organize (in theory, seldom in practice) but does not acknowledge individual needs of team members.
I agree with this
In my opinion the entire structure of scrum and sprints is structured to help people with autism and adhd.
Unfortunately the principles are rarely adhered to.
Whenever you are forced to be around people, you are forced to put on your mask and perform. Exhausting.
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.