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.

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.

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.

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.

Just rank by date needed order on a kanban board and work your way through everything in order. If it's constant fight to meet deadlines it will be clear enough that things are backed up.

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)

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.

Working on somebody else's goals, and being systematically micromanaged are two very different things.

This is a fallacious argument.