31–40 of 51 posts
Specs need detail and refinement. Generated code still needs reviews, edits, and perhaps iterations and extra tests. None of this is automatic or fast.
“Interactive obituary - 22 min” Ugh is there a regular text version I can read at my own pace? Also why light text on black background? Hurts my eyes and is very difficult to read. Guess I’ll wait for someone with more patience and better eyesight to maybe provide a summary or something :)
Here is a more static one: https://death-of-scrum.net/static/
I hope that helps!
LLM slop article. But as for the topic: To me, "Kanban with refinements and retrospectives" is the sweet spot. The concept of Sprint seems not only superfluous but to add unnecessary rigidity. But you do want everyone to understand the tickets, so refinements are useful, and you do want to try and improve "meta" issues where possible (and have the amount of effort going into that limited so you don't end up in the me…
It's not a law of the universe that there's got to be a sprint every 2 weeks. For instance I'd schedule them around holidays and vacations. Try to make sure for instance that the next sprint planning coincides with a team member returning from vacation. That way they're in the loop about where things are at, and we don't make a plan based on some assumption of what Bob might do when he returns mid-sprint without him being there.
Overall I think sprints are a fine idea, projects can be complex, it makes sense to me to periodically sit down and figure out if we're getting there or not and what the next steps are. We'd also try to have demos each sprint to make sure that something actually works.
It was immediately apparent to me why these existed, it was because "software development" somehow collectively decided to abandon core principles of PM.
Like the most basic stuff, e.g. Projects have a beginning and an end.
I chose to not take any of it too seriously in terms of what I taught undergrads, and post-mortems like this make me feel quite justified in that.
> By the time the meeting ends, an AI agent in a teammate's terminal has shipped two pull requests, refactored a service, and updated the docs Screw you
My favorite scrum story: When I worked at reddit, we were still owned by Condé Nast, and we worked in the corner of the Wired magazine office. Condé Nast got a new CTO, who was completely all-in on agile. To the point that she called everyone into a conference room to read us the agile manifesto word for word. We then went back to our little corner conference room and continued to build things in an agile way, like w…
My favorite scrum story: When I worked at reddit, we were still owned by Condé Nast, and we worked in the corner of the Wired magazine office. Condé Nast got a new CTO, who was completely all-in on agile. To the point that she called everyone into a conference room to read us the agile manifesto word for word. We then went back to our little corner conference room and continued to build things in an agile way, like w…
It's the reddest of the red flags to have such CTO. Modern incompetent CTOs are measuring performance by token spend. They are in the same bucket though - coming up with some dogmatic ways with extremely thin foundation.
“Quickest ceremonies to appease managers where we learn of new hot priorities from top down and say ‘no blockers’ then after that we get back to work delivering what’s needed for our regular user base.” Has a certain ring to it I think.
(Edited for typos and clarity)
> By the time the meeting ends, an AI agent in a teammate's terminal has shipped two pull requests, refactored a service, and updated the docs Screw you
I'm not actually sure who you are mad at here. The engineer who is being super productive with AI, or the author for suggesting that an engineer can be that productive with AI.
Especially today where LLMs have been reinforced and trained to spew tokens
A gentle reminder that the task of Engineering is to (1) reduce costs and/or (2) increase revenue
If you aren't doing either. You are faffing around. No matter the jargon jiu-jitsu you do on your quarterly performance self-review :)
Earlier quoted context omitted.
People must realize that it's people who book meetings, not processes. And some of them book meetings to try to justify their presence. Blaming scrum for having meetings on the calendar is a scapegoat. You will have those meetings show up regardless of what processes you chose to replace scrum.
Lies, damned lies. SCRUM by definition is meetings. in fact, I like this topic, because usually people use the motte and bailey of Agile. (as in, Agile is a manifesto to some, or a process to someone else) but scrum is super well defined, and it is defined by: structured meetings.
My understanding is there are 3 meetings in core scrum:
- planning (which is not about planning meetings, but about breaking down work)
- review
- retrospective
None of those are 2nd or 3rd order "meeting planning" meetings.
If people throw in backlog grooming or other sessions, that's up to them.