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.
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.
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.
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.
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.
Scrum can protect you some really nasty stuff.
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.
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 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.
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.
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.
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.
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)
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.
I don't have a PM.
If you have a manger, that decides this, or the PO decides this, IMO that’s a key problem of your scrum implementation.
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
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.
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).
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.
It's there to help management control the 'au-dhd' crowd with a manufactured focus that rarely aligns with what they could naturally focus on.
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.
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.