5 ms·

It'll be same as with Agile: when it doesn't work, consultants will just tell you you've been doing it wrong.

by melted 11y ago

trhway 11y ago
it doesn't work with me (or in my presence) - i don't even need a Scotsman, i grew up in the USSR and it is like telling me that USSR (or China or Cambodia or Cuba ...) were doing socialism/communism wrong. Recently many orgs inside our BigCo have been through couple years of the best Agile/Lean/Scrum/<whatever crap> the money can buy. It was a zombie-like horror show and a spectacular failure across the orgs. And one wonderful day the management and PMs just seem to have waken up and just magically forgot all these words. We're back to normal planning and developing features like nothing happened in those 2 years. Magic.
- hderms 11y ago
  How do you characterize your normal mode of development? Just curious if you would mention a brief overview of how you do things
  - trhway 11y ago
    like it has been for the last 25 years starting at the University and through the places i worked in Russia and here - natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall"). It has mostly been pretty large projects with multiple teams involved (though even in 1988 in high school with a friend developing a small game we followed the same "process"). As someone said "you can't successfully run marathon by running a series of sprints". One can try him/herself to run even a couple of miles by running it as a series of sprints to understand the foundational principle from systems analysis about the cost of low latency and synchronicity (normally one would expect that software engineers are aware about it without self-mutilating experiments, yet here we're ... to really feel the pain make somebody tell you, strictly each 20 seconds, where to run the next sprint) - those being the 2 main paramount features of Scrum ( note : Agile,insisting on low latency while relaxing somewhat the requirement of synchronicity, is a little bit less disastrous on its own, ie. when isn't attached to Scrum).
    - will_hughes 11y ago
      > As someone said "you can't successfully run marathon by running a series of sprints". I think that's a lazy argument. If you don't like the word 'sprint' use another term to denote a period of time. > natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall"). Actually, if it's in small units of time/work, then it's pretty close to agile. The problem with waterfall is the big upfront planning where you try to estimate how long it'll take to implement things months ahead of time.
    - melted 11y ago
      For me it's more like this: prototype, design, implement. I do some lightweight planning while I prototype. All of this is anathema to Agile. Prototyping alone could mean going dark for a week or two. Design, likewise, has no useful status to communicate. Implementation fits pretty well, but it's maybe 1/3rd of the work. I don't think I'd be able to deliver quality software any other way.
      - thawkins 11y ago
        Agile, supports prototyping, and design, its just a task, maybe you where being too litteral about things.
        melted 11y ago
        Sure it does, about like the USSR supported freedom of speech. What do you report in your daily standup? What if your prototyping takes four weeks instead of two? How about if your problem is particularly gnarly and it takes six weeks? What if it's only reasonable to devote, say, two people out of the team of six to prototyping? Do they report status (which they already know) to each other? "Syncing up" with them is useless for the rest of the team. What if I'm already an adult and therefore don't need adult supervision? Why would you want to interrupt my "make time" with your bullshit, useless standup, thus knocking me out of my zone for an hour or more? On the teams that I ran, we relied on a weekly meeting, lasting about 30-45 minutes to go over what we did last week and what the plans are for this week. The rest is handled perfectly well with ad-hoc communication. Those teams were far more "agile" than any of the Agile teams I've seen, since people expended all their effort on achieving the goals as opposed to figuring out what they're going to say in the next standup.
  - tamana 11y ago
    There are two models of development: 1. Agile: when stuff works ,it's agile. When stuff fails, its not agike. 2. Not-Agike: when stuff works, its not agile. When stuff fails, it's agile. The agile debates are just shows of tribal colors, not substantive analyses.
alistairSH 11y ago
Yeah. There are no panaceas. And change for the sake of change isn't useful. This certainly mirrors some of the horror stories of "agile" adoption I've read online. With most of those, either an executive read a book and forced change on everybody, an over-priced consultant tried to force change on everybody, or some combination of the two. Counter those exmaples with my own experience in an organization adopting scrum. My current employer started that process 3 years ago and it has been reasonably positive. There were growing pains, but the company invested in training to alleviate FUD, there way buy-in across the board, etc. Based on this one article, it really sounds like the executive team failed to get buy-in from the broader management team and then doubled-down on the failure by not providing the employees with enough training to overcome FUD-induced panic.
- ethbro 11y ago
  You've got it all wrong! The executive reads the book and then hires the overpriced consultant(s).
  - fsloth 11y ago
    And then tells the employees to implement the consultants model. While the management continues in old ways and refuses to totally let go. Now the team is supposed to be "self organizing" but actually the management uses the tools intended for teams self-organization, learning and communications as precision vehicles in employee evaluation. Which completely erodes the 1. requirement for succesfull 'agile' - trust. Also, goodbye honest communication.
    - ethbro 11y ago
      IMHO, agile is a bad fit for a lot of legacy, heavily-employeed companies. Would it be incorrect in saying that agile has an implicit position of "if you don't trust this developer, fire them"? Which I think is much more of an option in a startup than some politicized offices.
      - alistairSH 11y ago

It'll be same as with Agile: when it doesn't work, consultants will just tell you you've been doing it wrong.

by melted 11y ago

It'll be same as with Agile: when it doesn't work, consultants will just tell you you've been doing it wrong.

it doesn't work with me (or in my presence) - i don't even need a Scotsman, i grew up in the USSR and it is like telling me that USSR (or China or Cambodia or Cuba ...) were doing socialism/communism wrong. Recently many orgs inside our BigCo have been through couple years of the best Agile/Lean/Scrum/<whatever crap> the money can buy. It was a zombie-like horror show and a spectacular failure across the orgs. And one wonderful day the management and PMs just seem to have waken up and just magically forgot all these words. We're back to normal planning and developing features like nothing happened in those 2 years. Magic.

hderms 11y ago
How do you characterize your normal mode of development? Just curious if you would mention a brief overview of how you do things
- trhway 11y ago
  like it has been for the last 25 years starting at the University and through the places i worked in Russia and here - natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall"). It has mostly been pretty large projects with multiple teams involved (though even in 1988 in high school with a friend developing a small game we followed the same "process"). As someone said "you can't successfully run marathon by running a series of sprints". One can try him/herself to run even a couple of miles by running it as a series of sprints to understand the foundational principle from systems analysis about the cost of low latency and synchronicity (normally one would expect that software engineers are aware about it without self-mutilating experiments, yet here we're ... to really feel the pain make somebody tell you, strictly each 20 seconds, where to run the next sprint) - those being the 2 main paramount features of Scrum ( note : Agile,insisting on low latency while relaxing somewhat the requirement of synchronicity, is a little bit less disastrous on its own, ie. when isn't attached to Scrum).
  - will_hughes 11y ago
    > As someone said "you can't successfully run marathon by running a series of sprints". I think that's a lazy argument. If you don't like the word 'sprint' use another term to denote a period of time. > natural cycle of plan, design, implement of the stuff slated into the next release (ie. the dirty word of "waterfall"). Actually, if it's in small units of time/work, then it's pretty close to agile. The problem with waterfall is the big upfront planning where you try to estimate how long it'll take to implement things months ahead of time.
  - melted 11y ago
    For me it's more like this: prototype, design, implement. I do some lightweight planning while I prototype. All of this is anathema to Agile. Prototyping alone could mean going dark for a week or two. Design, likewise, has no useful status to communicate. Implementation fits pretty well, but it's maybe 1/3rd of the work. I don't think I'd be able to deliver quality software any other way.
    - thawkins 11y ago
      Agile, supports prototyping, and design, its just a task, maybe you where being too litteral about things.
      - melted 11y ago
        Sure it does, about like the USSR supported freedom of speech. What do you report in your daily standup? What if your prototyping takes four weeks instead of two? How about if your problem is particularly gnarly and it takes six weeks? What if it's only reasonable to devote, say, two people out of the team of six to prototyping? Do they report status (which they already know) to each other? "Syncing up" with them is useless for the rest of the team. What if I'm already an adult and therefore don't need adult supervision? Why would you want to interrupt my "make time" with your bullshit, useless standup, thus knocking me out of my zone for an hour or more? On the teams that I ran, we relied on a weekly meeting, lasting about 30-45 minutes to go over what we did last week and what the plans are for this week. The rest is handled perfectly well with ad-hoc communication. Those teams were far more "agile" than any of the Agile teams I've seen, since people expended all their effort on achieving the goals as opposed to figuring out what they're going to say in the next standup.
- tamana 11y ago
  There are two models of development: 1. Agile: when stuff works ,it's agile. When stuff fails, its not agike. 2. Not-Agike: when stuff works, its not agile. When stuff fails, it's agile. The agile debates are just shows of tribal colors, not substantive analyses.

alistairSH 11y ago

Yeah. There are no panaceas. And change for the sake of change isn't useful. This certainly mirrors some of the horror stories of "agile" adoption I've read online. With most of those, either an executive read a book and forced change on everybody, an over-priced consultant tried to force change on everybody, or some combination of the two. Counter those exmaples with my own experience in an organization adopting scrum. My current employer started that process 3 years ago and it has been reasonably positive. There were growing pains, but the company invested in training to alleviate FUD, there way buy-in across the board, etc. Based on this one article, it really sounds like the executive team failed to get buy-in from the broader management team and then doubled-down on the failure by not providing the employees with enough training to overcome FUD-induced panic.

ethbro 11y ago
You've got it all wrong! The executive reads the book and then hires the overpriced consultant(s).
- fsloth 11y ago
  And then tells the employees to implement the consultants model. While the management continues in old ways and refuses to totally let go. Now the team is supposed to be "self organizing" but actually the management uses the tools intended for teams self-organization, learning and communications as precision vehicles in employee evaluation. Which completely erodes the 1. requirement for succesfull 'agile' - trust. Also, goodbye honest communication.
  - ethbro 11y ago
    IMHO, agile is a bad fit for a lot of legacy, heavily-employeed companies. Would it be incorrect in saying that agile has an implicit position of "if you don't trust this developer, fire them"? Which I think is much more of an option in a startup than some politicized offices.
    - alistairSH 11y ago