6 ms·

"One group is instructed to submit 100 photos over the quarter and the other group is instructed to submit one perfect photo. The group that is instructed to s

"One group is instructed to submit 100 photos over the quarter and the other group is instructed to submit one perfect photo. The group that is instructed to submit 100 photos gets better because they start right away and start taking photos and learn about composition. While the other group doesn't get better because they hem and haw over what a perfect photo is." If true, I would want a refund if placed in the latter group.

brailsafe 3y ago
Ironically, this is also the downfall of most "agile" practicing dev teams. They've adopted scrum, they've adopted all the overhead of Jira and 2 week sprints that they never rethink, but nothing gets shipped unless it's perfect, and so nothing gets iterated on, nothing progresses, no evaluation of the work ever actually feeds back into a positive reinforcement cycle, and so you just get waterfall with much more agony. In my last company, we were trying to ship refactors and improvements at the same time, and it inevitably broke down horribly when we'd discover some requirement that had originally never been documented or built in some component. So the scope for shipping would change from a one-to-one refactor with incremental iteration in subsequent sprints, to many cycles of QA and fixes before even minor design improvements could be shipped. It's characteristic of every dev team I've been on that's tried to use off-the-shelf agile practices, because there's no risk tolerance at any level higher than IC. Everyone's afraid of how they'll appear, and nobody trusts anyone lower than them on the org-chart.
- teeray 3y ago
  > nothing gets shipped unless it's perfect, and so nothing gets iterated on… That’s why a solid, painless, quick rollback story is absolutely vital but underrated for agility. It’s not a big deal if you ship a regression but can roll back quickly. On the other hand, if every release is playing for keeps, you’ll slow down to a glacial pace to try to ship perfection. But perfection is impossible no matter how much process you put in front of it—you will ship a bug some day. So pretending like you can’t ship bugs because you have initial design reviews, multiple code reviews, sign-offs from multiple stakeholders, CI that takes 3 days to run, etc. just makes the day you do ship a big that much more painful.
  - cogman10 3y ago
    The issue is that big messes can be made that are hard to clean up in one small release. For example, one of our teams had the requirement "Allow end users to programmatically configure widget xyz". Now, widget xyz has a janky design and a table with 50 columns associated with it. So what did this team do? They took that internal table definition, made a CRUD api that exposes the whole thing, and moved on. Tell me, how do you fix something like that like that? They followed the agile route, got an MVP out with hardly any effort on their part. But now we have this API that shows off 20 years of legacy that our end users now depend on. And to be clear, of those 50 fields, maybe 3 of them mattered to the end user and the rest could have been inferred. But doing that inference is a lot more work as it takes understanding the domain.
    - brailsafe 3y ago
      Well I suppose that's the difference between thoughtful systems and process and zero systems and process, and also poor problem definition. There is some nuance between "ship literally anything to end users" and "ship an improvement" or something else to end users, or to a beta that roles out to end users and isolates the possible regression to a smaller surface area. It also seems like those developers might either suck (possible, but uncharitable), or that the system rewards the wrong things. But much of the time, better or worse laters of bureaucracy in the system come about from these mistakes which will eventually happen, so it's a very valid point, and I do think a lot of the time it's companies building up scar tissue and not being capable of getting the necessary surgery to fix it.
      - cogman10 3y ago
        > It also seems like those developers might either suck (possible, but uncharitable), or that the system rewards the wrong things. Yes, they do, but also it's an entire department problem and one that the upper bureaucracy doesn't see as an issue. I'm really not surprised this was the route that particular department took. Office politics are fun, though, so sucking at your job often doesn't mean anything if your managers are all buddies. But before the creation/evolution of that department we already had these sorts of problems. This may just be a "just my company" problem but I don't think it is. After all, from what I know of business management, this sort of "extra staff and rework is waste" mentality seems really pervasive.
- paulddraper 3y ago
  > nothing gets shipped unless it's perfect, and so nothing gets iterated on Wow that is literally the exact opposite of agile. Like.... There is no worse descriptor for this than "agile"
  - rlayton2 3y ago
    I might have read it wrong, but I read OP as saying something like "people want to do agile, but wait until the project is perfect, thereby negating the whole point".
    - brailsafe 3y ago
      Not so much the overall project, but definitely the smaller components within an ongoing project. Probably should have specified that because I'm almost always working on an established thing, rather than a greenfield thing.
    - siva7 3y ago
      I’ve never seen that behaviour in the wild and i’ve seen over hundred teams adopting agile.
      - cookiesboxcar 3y ago
        I see it everywhere... not with "hundreds" of teams but enough teams over a 12 year career in consulting to make this not anecdotal.
      - marcosdumay 3y ago
        Like the sibling comment here, I've seen this plenty of times too. Not on "most projects" or "most places", but certainly on most spectacular failures I've witnessed.
        brailsafe 3y ago
        I don't think the one who's seen "hundreds" of examples could have done so without being an "Agile coach" or something, maybe a temporary contractor at most, either way getting a pretty arms-length look at how a team is operating or is starting to adopt a new procedure.
- indeedmug 3y ago
  Your team's process should be flexible enough where you don't have a name for it.
- dgb23 3y ago
  When the users/buyers of software don't actually want (sometimes for legal reasons!) agile development, then shoehorning them in results in what you describe?
- dalbasal 3y ago
  I think "The Problem with Agile," especially at this point, is mostly upstream of any implementation details. What kind of an organisation is going to adopt a packaged management method like that? Cargo cult adoption of practices, language, job titles, consultants, tools and formal certifications... The company that invented agile would never have "gone agile" in 2023. I'm not saying that agile can't work. I'm saying that an insurance company "adopting agile" is an insurance company buying a trendy management method for their engineers. It matters not if the method is called agile or a 1972 booklet from the USSR. Practices, practiced blindly are rituals.
edgarvaldes 3y ago
Is this a real variation of the myth of the ceramics teacher and the two groups? It's the same method.
- maxverse 3y ago
  Yes, it sounds like the same idea to me.
- dorkwood 3y ago
  The photography version is the original. It was retold as ceramics in the book 'Art & Fear', because the authors (who were photographers themselves) were trying to appeal to a broader range of artists. https://austinkleon.com/2020/12/10/quantity-leads-to-quality-the-origin-of-a-parable/ https://austinkleon.com/2020/12/10/quantity-leads-to-quality...
Fnoord 3y ago
Faith No More fan?
quickthrower2 3y ago
That old chestnut? If told that and I was in the "other group" I would pipe up and say "only one way to do this, submit 100 photos to me ASAP and I will pick the best one.
raincole 3y ago
> If true, I would want a refund if placed in the latter group. It (allegedly) happened on a university class. *: https://sebastianhetman.com/why-quantity-matters/ https://sebastianhetman.com/why-quantity-matters/
- zerocrates 3y ago
  Apparently the "ceramics class" story that you see all over the place after it appeared in the book "Art and Fear" was a modification of this real story, retold in a closer-to-original form in "Atomic Habits." The Art and Fear authors credit Uelsmann himself as the source of the story; whether I believe he really did it with actual students for a whole semester, on the other hand... It's a little bit of a "just so" story in any form, though the lesson of repetition is fine regardless of its literal truth.
dorkwood 3y ago
If one group submitted 100 photos and the other group submitted only one, I’d argue that the first group was simply given 99 more chances to impress their professor.

brailsafe 3y ago

Ironically, this is also the downfall of most "agile" practicing dev teams. They've adopted scrum, they've adopted all the overhead of Jira and 2 week sprints that they never rethink, but nothing gets shipped unless it's perfect, and so nothing gets iterated on, nothing progresses, no evaluation of the work ever actually feeds back into a positive reinforcement cycle, and so you just get waterfall with much more agony. In my last company, we were trying to ship refactors and improvements at the same time, and it inevitably broke down horribly when we'd discover some requirement that had originally never been documented or built in some component. So the scope for shipping would change from a one-to-one refactor with incremental iteration in subsequent sprints, to many cycles of QA and fixes before even minor design improvements could be shipped. It's characteristic of every dev team I've been on that's tried to use off-the-shelf agile practices, because there's no risk tolerance at any level higher than IC. Everyone's afraid of how they'll appear, and nobody trusts anyone lower than them on the org-chart.

teeray 3y ago
> nothing gets shipped unless it's perfect, and so nothing gets iterated on… That’s why a solid, painless, quick rollback story is absolutely vital but underrated for agility. It’s not a big deal if you ship a regression but can roll back quickly. On the other hand, if every release is playing for keeps, you’ll slow down to a glacial pace to try to ship perfection. But perfection is impossible no matter how much process you put in front of it—you will ship a bug some day. So pretending like you can’t ship bugs because you have initial design reviews, multiple code reviews, sign-offs from multiple stakeholders, CI that takes 3 days to run, etc. just makes the day you do ship a big that much more painful.
- cogman10 3y ago
  The issue is that big messes can be made that are hard to clean up in one small release. For example, one of our teams had the requirement "Allow end users to programmatically configure widget xyz". Now, widget xyz has a janky design and a table with 50 columns associated with it. So what did this team do? They took that internal table definition, made a CRUD api that exposes the whole thing, and moved on. Tell me, how do you fix something like that like that? They followed the agile route, got an MVP out with hardly any effort on their part. But now we have this API that shows off 20 years of legacy that our end users now depend on. And to be clear, of those 50 fields, maybe 3 of them mattered to the end user and the rest could have been inferred. But doing that inference is a lot more work as it takes understanding the domain.
  - brailsafe 3y ago
    Well I suppose that's the difference between thoughtful systems and process and zero systems and process, and also poor problem definition. There is some nuance between "ship literally anything to end users" and "ship an improvement" or something else to end users, or to a beta that roles out to end users and isolates the possible regression to a smaller surface area. It also seems like those developers might either suck (possible, but uncharitable), or that the system rewards the wrong things. But much of the time, better or worse laters of bureaucracy in the system come about from these mistakes which will eventually happen, so it's a very valid point, and I do think a lot of the time it's companies building up scar tissue and not being capable of getting the necessary surgery to fix it.
    - cogman10 3y ago
      > It also seems like those developers might either suck (possible, but uncharitable), or that the system rewards the wrong things. Yes, they do, but also it's an entire department problem and one that the upper bureaucracy doesn't see as an issue. I'm really not surprised this was the route that particular department took. Office politics are fun, though, so sucking at your job often doesn't mean anything if your managers are all buddies. But before the creation/evolution of that department we already had these sorts of problems. This may just be a "just my company" problem but I don't think it is. After all, from what I know of business management, this sort of "extra staff and rework is waste" mentality seems really pervasive.
paulddraper 3y ago
> nothing gets shipped unless it's perfect, and so nothing gets iterated on Wow that is literally the exact opposite of agile. Like.... There is no worse descriptor for this than "agile"
- rlayton2 3y ago
  I might have read it wrong, but I read OP as saying something like "people want to do agile, but wait until the project is perfect, thereby negating the whole point".
  - brailsafe 3y ago
    Not so much the overall project, but definitely the smaller components within an ongoing project. Probably should have specified that because I'm almost always working on an established thing, rather than a greenfield thing.
  - siva7 3y ago
    I’ve never seen that behaviour in the wild and i’ve seen over hundred teams adopting agile.
    - cookiesboxcar 3y ago
      I see it everywhere... not with "hundreds" of teams but enough teams over a 12 year career in consulting to make this not anecdotal.
    - marcosdumay 3y ago
      Like the sibling comment here, I've seen this plenty of times too. Not on "most projects" or "most places", but certainly on most spectacular failures I've witnessed.
      - brailsafe 3y ago
        I don't think the one who's seen "hundreds" of examples could have done so without being an "Agile coach" or something, maybe a temporary contractor at most, either way getting a pretty arms-length look at how a team is operating or is starting to adopt a new procedure.
indeedmug 3y ago
Your team's process should be flexible enough where you don't have a name for it.
dgb23 3y ago
When the users/buyers of software don't actually want (sometimes for legal reasons!) agile development, then shoehorning them in results in what you describe?
dalbasal 3y ago
I think "The Problem with Agile," especially at this point, is mostly upstream of any implementation details. What kind of an organisation is going to adopt a packaged management method like that? Cargo cult adoption of practices, language, job titles, consultants, tools and formal certifications... The company that invented agile would never have "gone agile" in 2023. I'm not saying that agile can't work. I'm saying that an insurance company "adopting agile" is an insurance company buying a trendy management method for their engineers. It matters not if the method is called agile or a 1972 booklet from the USSR. Practices, practiced blindly are rituals.

edgarvaldes 3y ago

Is this a real variation of the myth of the ceramics teacher and the two groups? It's the same method.

maxverse 3y ago
Yes, it sounds like the same idea to me.
dorkwood 3y ago
The photography version is the original. It was retold as ceramics in the book 'Art & Fear', because the authors (who were photographers themselves) were trying to appeal to a broader range of artists. https://austinkleon.com/2020/12/10/quantity-leads-to-quality-the-origin-of-a-parable/ https://austinkleon.com/2020/12/10/quantity-leads-to-quality...

Fnoord 3y ago

Faith No More fan?

quickthrower2 3y ago

That old chestnut? If told that and I was in the "other group" I would pipe up and say "only one way to do this, submit 100 photos to me ASAP and I will pick the best one.

raincole 3y ago

> If true, I would want a refund if placed in the latter group. It (allegedly) happened on a university class. *: https://sebastianhetman.com/why-quantity-matters/ https://sebastianhetman.com/why-quantity-matters/

zerocrates 3y ago
Apparently the "ceramics class" story that you see all over the place after it appeared in the book "Art and Fear" was a modification of this real story, retold in a closer-to-original form in "Atomic Habits." The Art and Fear authors credit Uelsmann himself as the source of the story; whether I believe he really did it with actual students for a whole semester, on the other hand... It's a little bit of a "just so" story in any form, though the lesson of repetition is fine regardless of its literal truth.

dorkwood 3y ago

If one group submitted 100 photos and the other group submitted only one, I’d argue that the first group was simply given 99 more chances to impress their professor.