5 ms·

How do you characterize your normal mode of development? Just curious if you would mention a brief overview of how you do things

by hderms 11y ago

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.
      - bane 11y ago
        That's basically how I run my teams also. Weekly tempo-setting meetings to go over status and adjust planning as needed. Plans are made with broad brush strokes and are expected to be fluid and details are figured out during development. Planning sets goals, and are used to time box the work (even if the boxes are different sizes, so no adherence to stupid 2-week one size fits all sprints). Pre-planning makes it easy to get stakeholder buy-in without having to go into deep philosophical development notions. Ad-hoc communications and gasp my involvement with the teams covers 90% of the rest and if major problems occur, the appropriate parties are pulled into a meeting to discuss and resolve. My teams are pretty consistently the most productive performers in my organization, use the fewest people and resources, and produce the highest quality product at the end of the day. As a result, my teams are consistently in demand to work on things, and once they're out of my hands and back into some scrummaster's their performance goes back to normal. I've noticed an inverse correlation on all of these metrics the more "Agile/Scrum" the teams seem to be. Between standups, retrospectives, scrums, and whatever activities the other groups get mired down in, the consistent complaint is that nobody seems to have time to actually get anything done. The problem is that Agile is supposed to be about liberating teams from process and tools and documentation and so on and focus on people and product. However, the Industry that's exploded around "Agile" has simply created another pile of rigid processes that bring everybody back to square one again. Even worse, most people in the industry are so young they think this is better than what the old fuddy-duddies greybeards used to do and don't have the perspective to realize they've just become trapped in another set of process ceremonies that get applied to everything without regard to the nature of the task at hand. I just got out of sitting in another team's sprint planning meeting and they spent 2 hours trying to figure out how to fit O&M and R&D into their next sprints...30 minutes of which was spent figuring out how to model the Epics. Agile is a great idea in theory. Agile in practice is a terrible one.
- luckydata 11y ago
  I'm not completely certain you know what you're talking about, especially about Agile. Tell me which part of the agile manifesto you disagree with, or why you think waterfall increases the likelihood of success of your projects. That's an honest question, I'm truly interested in your reply.
  - trhway 11y ago
    i don't agree or disagree. I just apply basic system analysis principles which explain the observed behaviour. It is pretty valid choice to choose low latency and synchronicity as the top priorities over everything else. I just find it very funny that making such choice people frequently declare productivity increase as the goal. And even more funny when they find that productivity really went down at the end (in the case of one project - after very major feature priorities change - low latency and synchronicity make this much easier, i'd even say tempting - each sprint for several last sprints before the release, and as result there was nothing to release at all).
  - guiomie 11y ago
    I don't think he is referring to the manifesto, but to the concept of agile, and all it`s related buzzwords being promoted to sell you 5000$ 4 day courses or conference tickets.
- spacecowboy_lon 11y ago
  That is how you run a marathon you break it down into individual miles and work out your target time. E.g I can run a mile in x minuets flat out but to last for 26 I need to target x+y minutes per mile.
  - gaius 11y ago
    Curious, how many Marathons have you run? I've done 5 and I've never had a plan hold after the 20th mile.
    - tamana 11y ago
      Sounds very agile planning.
    - spacecowboy_lon 11y ago
      I was thinking more of the elite athleats who have a target time and work out what thy should run each mile at to arrive at that time.
  - trhway 11y ago
    you don't do frequent start/stops, route change midway, conferences with judges/observers/coach/journalists/etc. What you describe is pure waterfall - you have the preset target/route, you work out the plan and you execute it.
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.

How do you characterize your normal mode of development? Just curious if you would mention a brief overview of how you do things

by 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.
    - bane 11y ago
      That's basically how I run my teams also. Weekly tempo-setting meetings to go over status and adjust planning as needed. Plans are made with broad brush strokes and are expected to be fluid and details are figured out during development. Planning sets goals, and are used to time box the work (even if the boxes are different sizes, so no adherence to stupid 2-week one size fits all sprints). Pre-planning makes it easy to get stakeholder buy-in without having to go into deep philosophical development notions. Ad-hoc communications and gasp my involvement with the teams covers 90% of the rest and if major problems occur, the appropriate parties are pulled into a meeting to discuss and resolve. My teams are pretty consistently the most productive performers in my organization, use the fewest people and resources, and produce the highest quality product at the end of the day. As a result, my teams are consistently in demand to work on things, and once they're out of my hands and back into some scrummaster's their performance goes back to normal. I've noticed an inverse correlation on all of these metrics the more "Agile/Scrum" the teams seem to be. Between standups, retrospectives, scrums, and whatever activities the other groups get mired down in, the consistent complaint is that nobody seems to have time to actually get anything done. The problem is that Agile is supposed to be about liberating teams from process and tools and documentation and so on and focus on people and product. However, the Industry that's exploded around "Agile" has simply created another pile of rigid processes that bring everybody back to square one again. Even worse, most people in the industry are so young they think this is better than what the old fuddy-duddies greybeards used to do and don't have the perspective to realize they've just become trapped in another set of process ceremonies that get applied to everything without regard to the nature of the task at hand. I just got out of sitting in another team's sprint planning meeting and they spent 2 hours trying to figure out how to fit O&M and R&D into their next sprints...30 minutes of which was spent figuring out how to model the Epics. Agile is a great idea in theory. Agile in practice is a terrible one.
luckydata 11y ago
I'm not completely certain you know what you're talking about, especially about Agile. Tell me which part of the agile manifesto you disagree with, or why you think waterfall increases the likelihood of success of your projects. That's an honest question, I'm truly interested in your reply.
- trhway 11y ago
  i don't agree or disagree. I just apply basic system analysis principles which explain the observed behaviour. It is pretty valid choice to choose low latency and synchronicity as the top priorities over everything else. I just find it very funny that making such choice people frequently declare productivity increase as the goal. And even more funny when they find that productivity really went down at the end (in the case of one project - after very major feature priorities change - low latency and synchronicity make this much easier, i'd even say tempting - each sprint for several last sprints before the release, and as result there was nothing to release at all).
- guiomie 11y ago
  I don't think he is referring to the manifesto, but to the concept of agile, and all it`s related buzzwords being promoted to sell you 5000$ 4 day courses or conference tickets.
spacecowboy_lon 11y ago
That is how you run a marathon you break it down into individual miles and work out your target time. E.g I can run a mile in x minuets flat out but to last for 26 I need to target x+y minutes per mile.
- gaius 11y ago
  Curious, how many Marathons have you run? I've done 5 and I've never had a plan hold after the 20th mile.
  - tamana 11y ago
    Sounds very agile planning.
  - spacecowboy_lon 11y ago
    I was thinking more of the elite athleats who have a target time and work out what thy should run each mile at to arrive at that time.
- trhway 11y ago
  you don't do frequent start/stops, route change midway, conferences with judges/observers/coach/journalists/etc. What you describe is pure waterfall - you have the preset target/route, you work out the plan and you execute it.

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.