jksmith

Also, for anyone who grew up in Atl, Wolfe's book "A Man In Full" drips with the kind of delicious look-in-the-mirror satire home grown Southerners love.

I bought a rack-mount Alpha back in the early 90's running Symbolics on it. Probably all I need to say about that.

Yeah, but I think more importantly much of the value that Rust brings would have been available 30 years ago if language development/selection wasn't so siloed, full of biases, and driven by (often undeserved) popularity.

So with FPC/Lazarus you have a full dev system if works as wiki suggests.

Modula-2 40 years ago. The ship had strong bones to build upon a long time ago, but alas, C. The tyranny of the masses.

But first principle, this is a physics issue: Whatever way a team comes up with to maximize the amount of work not done to deliver the same or better outcomes, I'm all for it.

Estimations are meant to be exactly that, estimations. Don't try to make them anything else. They offer a grey answer, so use the best tools you have to deliver that grey answer. In this case, it's simply comparing challenges for size, complexity, etc. Don't try to do estimations in a different way just because you want an immediate answer. Estimations are meant to be a starting point to get to a minimum survivable solution. That's how humans use instinctive tools that use the least amount of energy to get to a point that they can survive a challenge. Think about the elliptical example.

In scrum, estimations are the conscious way to get this discovery kicked off; they aren't meant to be an answer, because you don't have enough data yet for a solution. They are meant to be a starting point. Iterate to the solution. When you think you have enough signal for a solution (the sprint), do your final check and balance, which is a tasking plan in hours, during sprint planning.

Another example: The year is 1929, and you're asked to guess the weight of the Empire State Bldg before construction has even begun (1931). What answer delivers more survival information? 180,000 tons, or this: "Well, we know each floor is going to have x concrete, y steel, but not sure about the other construction materials. So it will be something like (x+y+?)*#floors. If your life depended on it, which answer would you go with?

You are looking for a number, and that's why people don't understand what estimating is about. The incorrect approach is like, "Well these estimations are crap, so let's change the estimation methodology." Yeah but it's still and estimation, and you already have a great instinctive tool to make those estimations via relative size comparison, which can be done so quickly, it could literally save your life. Instinctively, we accept that, conscoiusly we don't, so we turn into ill tempered Veruca Salt.

Regarding the golf reference, I'm from Florida. Sorry if the attempt at levity was weak.

The best scrum teams I've worked with maintain a very important survival notion: We don't know the full minimum survivable solution today, but that's ok because we do know enough to get to tomorrow at least. We survived another day. Point is, estimating was never meant to be an answer. It was just meant to kick off discovery. And that's a great way to start because humans tend to be exceptionally good at quickly comparing things for difficulty and complexity. It's an instinctive survival skill.

Ultimately, well after estimating this scrum team will do an implementation (tasking) plan in hours if needed during sprint planning. They will compare that plan against their team capacity plan in hours. If the implementation plan blows out the cap plan by say, 30% then that's a warning sign and they'll tell the PO they need to drop a story for the upcoming sprint. If the cap plan compared against the imp plan shows a 30% surplus, then they will pull in a stretch story and bump their velocity, or won't tell the PO and maybe go play golf at the end of the sprint.

So the story pointing exercise just gets the team some data that helps them get to the next day (survival speak). There's still a lot of story refinement to be done, before they will tell their PO a story is ready to be pulled into one of their sprints.

When teams pull in stories to their sprint backlog, the team is committing to get that story done, so they need immediately actionable data on what's going on at every standup. If the burndown was done in points, the graph ends up looking like a straight line for days with sudden dropoffs toward the end of the sprint - that hides problems. So a sharp team will use task hours instead. Makes the plot a lot more actionable from day to day.

Here's a popular presentation I do on estimating, and why we tend to misunderstand its usefulness. "How to do estimating while being chased by a rhinoceros:" https://github.com/jamesksmithiii/Presentations/blob/main/Th...

Also maybe useful: Drawings for what to cover in scrum ceremonies: https://github.com/jamesksmithiii/Presentations/blob/main/Ce...

I think what you bring up though is an interesting point: maybe managers needs to transition to business engineering roles.

This all will play out in the 21st century. 20th century management is a legacy artifact at this point. Best example is F500s, which are generally mediocre in their execution. If a SpaceX type org (14k employees, private) gets into their space, they're screwed. Even with politicians in their pockets, I don't see how rock swallowing dinosaurs like Boeing (170k employees, public) will make it. Just the energy they have to expend to get anything done compared to SpaceX is massive, due in part to their giant management bureaucracy.

Team: "We are having trouble with Bob." Manager: "Ok I'll talk to him."

Team:"We are having trouble with Bob." Manager: "Don't come to me, you guys need to deal with that in your retro."

Team: "We voted Bob off the island." Manager: 'Ok, I'll forward to HR."

Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.

- burn-down / velocity charts: Teams use this at standups to make sure their sprint isn't drifting. That's why a burn-down should be tracked in hours and not points. With points, the data isn't actionable in a reasonable amount of time. The the team sees a problem, they might make use of a pre-determined emergency procedure to address it.

- retrospectives: Yeah most retrospectives are horrible. Retros should be like post rocket test - examine your telemetry deltas to see what changed (edge cases, governance,compliance, desgn, etc.) These conversations are not forced, but good teams always repeat the same data analysis unless they intentionally change it.

- poker sessions: Yeah this is totally misunderstood. Pointing stories is about snap reactions to comparing difficulties and complexity, and that's it, move on. Teams will tighten up estimates when they do an implementation plan in sprint planning. So they don't sweat estimates.

- daily stand-ups: The whole team is responsible for the sprint backlog, nothing is assigned, everything is volunteered. So if you're working on something that is going south, or you have some extra capacity, let your team know about it. The team will work together to scale capacity to get things done, which is how they can disappear on Friday afternoons.

- user stories and related tickets (eg in JIRA): Well yeah, Jira sucks. So do all the other major backlog tools. Jira gets addins, but the fundamental approach to backlog development hasn't changed in a decade. (I'm working on a soln from scratch, btw).

Also, user stories are meant to be work-items with enough signal so they can be executed with certainty in a sprint. So that means a lot of refinement to the left of the story must occur to get rid of the noise (epics to features to stories to tasks). Once a team says a story meets their definition of ready, that story can be scheduled for a (timely) sprint. Team members may be doing hard-core story refinement because of some technical hurdles, so their time outside of development during sprint can be pinned down with the team's capacity plan. BTW, capacity plans and implementation plans belong solely to the team. They're nobody else's business, including managers to CEOs.

When I asked a manager about a particular team, he said "I don't care if they do fight club in the morning, just let them keep doing what they're doing." To reframe, high-performing scrum teams are actually anti-legacy management, they get more done, are happy (low energy state) and stakeholders were satisfied. So their rolling sprint goal was taking a half day each month and going to Top Golf . The key is, everybody on the team was a scrum sme, and understood how to work the process as a team to reinforce certainty and stability. They also didn't need a scrum master.

I've got lots of anecdotes from this couple of teams, what kind of work their managers actually did, and the sneaky ways they made the process work for them. There's a lot more to scrum than a certification. Just the teams approach to sprint planning was in a whole different class from what mediocre teams normally did.

As for the other 99% of teams, they were mostly management tools. Scrum had been co-opted, especially in orgs using the SAFe framework. This has been at F250's in my experience btw.

Confirm, got to see a live demo at Comdex ATL back in 1992? Mind blown.

Point being, have a continuously ready backlog consumed by short iterations with great telemetry - like SpaceX.

Story points are just a warmup for more elaboration, not an xor decision. This article is making a single-level decision, which completely misses point of using story points. The work-effort really required will be discovered in more elaboration. Story points just give you a live or die measurement, that's it.