#agile #scrum #tech #softwaredevelopment #meme #funny
-
@ahltorp @crazyeddie @mwshook @PavelASamsonov It's all just "we suck at gathering requirements and writing specifications so we're going to dress that up as a virtue and give it a fancy name".
@woe2you It’s not only ”we suck at gathering requirements”, it’s also ”it’s often not meaningful to gather requirements in a vacuum”. Those are actually among the good parts, having stakeholder representation in the team. ”Fancy name” is among the bad parts.
-
-
The Laundry books are like that, a nice Lovecraftian (or other) horror story spliced with Cold War bureaucracy and IT.
This moose got nowhere near "death march" programming and Agile, but did have to endure ISO9000/BS5750 and "Lean", plus "Race to the bottom" Outsourcing/Offshoring, "Everything at the cheapest possible price", and every problem/change management system being worse than the one before.
I'm retired now. I have no regrets.
@Cadbury_Moose @mwshook If you liked Laundry Files you might like The Rook, Antimemetics Division, and Monday Begins on Saturday.
-
@Cadbury_Moose @mwshook If you liked Laundry Files you might like The Rook, Antimemetics Division, and Monday Begins on Saturday.
@PavelASamsonov @Cadbury_Moose @mwshook
+1 for antimemetics division -
@PavelASamsonov this happened to me about as literally as possible on this plane
-
@PavelASamsonov @Cadbury_Moose @mwshook
+1 for antimemetics division@jaystephens @PavelASamsonov @Cadbury_Moose @mwshook
There is no antimemetics division -
@ahltorp @travisfw The oldest book I have in my library is Schwaber's "Software Development with Scrum" from 2002, which is quite interesting. It's a lot more people / culture focused than even the Scrum guide (there's just so much you can write on 11 pages). They do have burndowns there, but even their they put in bold that it's (delivered) "results" that matter. The burndown shows how much work remains so you can plan. That's it. Overall the book feels very close to the Agile Manifesto
-
@ahltorp @travisfw well, yes, it's been part of the Scrum "story" just like certifications, trainers and whatnot. But it's not integral to Scrum.
You can do Scrum without "Velocity". You can use any other method to a) track how much work you do (better = track how much value is delivered and realized) and b) how much you can commit and reliably deliver at the end of the sprint (overcommitting = disappointed client).
You could track man-hours instead, and it works. -
@travisfw @kwramm The ”immutable” Scrum Guide has been updated(!) many times since I was doing anything called Scrum more than 15 years ago, and conveniently that version of the document seems hard to find, but I believe you. But even the current Scrum Guide says that ”Other sources provide patterns, processes, and insights that complement the Scrum framework”.
@ahltorp @travisfw I read the Scrum guide first in 2014 or so, after starting off with all kinds of books that add tons of extra complexity.
It's kinda liberating how simple Scrum can be. I feel the simpler you keep it, the more powerful it is.
And if in doubt between the Scrum guide and what helps your team: Talk to your team FIRST about what works for them - that's what Retrospectives are for - that's pretty much in line with Schwaber's book that I mentioned in my other reply. People first!
-
@crazyeddie @mwshook @PavelASamsonov There are some things that are useful in Scrum, but those things are usually what gets thrown out first.
Then there are things like ”velocity” that is some real bullshit.
And once you have ”leaders” imposing Scrum, it’s not self-organised anymore. So in practice it probably only works when the team is self-organised to begin with, which makes the whole framework have very limited value.
@ahltorp @crazyeddie @mwshook @PavelASamsonov I've worked with someone who was keen on "velocity" and quite unreasonable about sticking to it. Fortunately I haven't encountered anyone else who used the term, let alone is that unreasonable about sticking to it. I'd probably end up a nervous, twitching wreck if I did!
-
@ahltorp @travisfw well, yes, it's been part of the Scrum "story" just like certifications, trainers and whatnot. But it's not integral to Scrum.
You can do Scrum without "Velocity". You can use any other method to a) track how much work you do (better = track how much value is delivered and realized) and b) how much you can commit and reliably deliver at the end of the sprint (overcommitting = disappointed client).
You could track man-hours instead, and it works.@kwramm I can’t rely completely on my memory here, because Scrum has just existed around me for about 20 years, and I haven’t cared about it so much that I’ve remembered dates.
But as I understand it, Scrum (as a generic corporate tool) began as books and certifications, then the Scrum guide came later. So ”integral to Scrum” can’t really be defined by what’s in the Scrum guide. And in fact certifications seem to have been very integral to ”what Scrum is” in the early days.
-
@ahltorp @crazyeddie @mwshook @PavelASamsonov I've worked with someone who was keen on "velocity" and quite unreasonable about sticking to it. Fortunately I haven't encountered anyone else who used the term, let alone is that unreasonable about sticking to it. I'd probably end up a nervous, twitching wreck if I did!
@geoglyphentropy Maybe it’s fallen out of fashion, and that would be a good thing. I haven’t attended a talk on ”what Scrum is” in maybe 15-20 years.
-
@kwramm I can’t rely completely on my memory here, because Scrum has just existed around me for about 20 years, and I haven’t cared about it so much that I’ve remembered dates.
But as I understand it, Scrum (as a generic corporate tool) began as books and certifications, then the Scrum guide came later. So ”integral to Scrum” can’t really be defined by what’s in the Scrum guide. And in fact certifications seem to have been very integral to ”what Scrum is” in the early days.
@ahltorp what I mean with integral is that you can take velocity tracking away (and certifications, and story points, and trainers, and planning poker, and whatever fluff they try to upsell you) and you can still do the whole Scrum thing: empiricism, the events, the roles.
Those 3 things have always been there from the beginning. They change here and there a bit, but overall that's Scrum. That's why it's a framework. Being dogmatic about implementation is pretty much the least Agile thing
-
@ahltorp what I mean with integral is that you can take velocity tracking away (and certifications, and story points, and trainers, and planning poker, and whatever fluff they try to upsell you) and you can still do the whole Scrum thing: empiricism, the events, the roles.
Those 3 things have always been there from the beginning. They change here and there a bit, but overall that's Scrum. That's why it's a framework. Being dogmatic about implementation is pretty much the least Agile thing
@kwramm Upselling and the Scrum-Industrial-Complex has also been there from the beginning, and I would argue are even more foundational than the actual core parts.
I can agree that there should be a simple framework that is free from the fluff, and I guess the ”Scrum Guide” is an attempt at that, but Scrum as a name has never been free from the fluff as long as I’ve seen it.
-
@kwramm Upselling and the Scrum-Industrial-Complex has also been there from the beginning, and I would argue are even more foundational than the actual core parts.
I can agree that there should be a simple framework that is free from the fluff, and I guess the ”Scrum Guide” is an attempt at that, but Scrum as a name has never been free from the fluff as long as I’ve seen it.
@ahltorp oh yeah, that's true. Scrum got a pretty bad rep. Just mention the name and people roll their eyes thinking of tedious stand ups
-
@ahltorp @crazyeddie @mwshook @PavelASamsonov I've worked with someone who was keen on "velocity" and quite unreasonable about sticking to it. Fortunately I haven't encountered anyone else who used the term, let alone is that unreasonable about sticking to it. I'd probably end up a nervous, twitching wreck if I did!
@geoglyphentropy @ahltorp @mwshook @PavelASamsonov Why?
What's upsetting about it?
1. Come up with some metric you use to measure task difficulty. Establish criteria.
2. Practice estimating tasks by estimating tasks.
3. Graph results.
4. Meet occasionally to discuss ways to improve your task estimates. Try to eliminate variance.This causes seizures?
-
@geoglyphentropy @ahltorp @mwshook @PavelASamsonov Why?
What's upsetting about it?
1. Come up with some metric you use to measure task difficulty. Establish criteria.
2. Practice estimating tasks by estimating tasks.
3. Graph results.
4. Meet occasionally to discuss ways to improve your task estimates. Try to eliminate variance.This causes seizures?
@crazyeddie @geoglyphentropy Graphing made-up values is a/the problem.
-
@geoglyphentropy @ahltorp @mwshook @PavelASamsonov Why?
What's upsetting about it?
1. Come up with some metric you use to measure task difficulty. Establish criteria.
2. Practice estimating tasks by estimating tasks.
3. Graph results.
4. Meet occasionally to discuss ways to improve your task estimates. Try to eliminate variance.This causes seizures?
@crazyeddie @ahltorp @mwshook @PavelASamsonov It was that my initial estimate was treated as set in stone and any failure to ahere to it was blamed on me. Granted, this is probably a boss being a bully rather than an issue with velocity.
Also, I probably phrased things badly wrt the outcome, I was thinking more of being hypervigilant and very nervous rather than seizures.
-
@crazyeddie @ahltorp @mwshook @PavelASamsonov It was that my initial estimate was treated as set in stone and any failure to ahere to it was blamed on me. Granted, this is probably a boss being a bully rather than an issue with velocity.
Also, I probably phrased things badly wrt the outcome, I was thinking more of being hypervigilant and very nervous rather than seizures.
@geoglyphentropy @ahltorp @mwshook @PavelASamsonov Yeah. I keep running into this. It's pretty common. People really hate on various bits of agile methodology but when you ask them why it's a complaint about some horrible nonsense someone did one time.
Agile methodology is quite clear here. You're supposed to try getting better at estimates, not bitch slap people for not meeting bad ones or making bad ones to begin with. Agile doesn't fix bad management that points fingers.
-
@woe2you It’s not only ”we suck at gathering requirements”, it’s also ”it’s often not meaningful to gather requirements in a vacuum”. Those are actually among the good parts, having stakeholder representation in the team. ”Fancy name” is among the bad parts.
@woe2you @ahltorp I first came upon scrum under “extreme programming” -we used it when things went wrong in emergency-replacing the weekly team leader meeting with daily stand-ups -mainly to demonstrate to managers we were working even when we weren’t typing - what they thought we should be doing -not the talking.about requirements which was the real necessity. Management never truly trusted thinkers -hence the lines of code then the burn down- then the tickets-trust zero
