6 ms·

Seems to me yet another confirmation of the first rule of the Agile Manifesto: "Individuals and interactions over processes and tools." The methodology cannot

Seems to me yet another confirmation of the first rule of the Agile Manifesto: "Individuals and interactions over processes and tools." The methodology cannot be effective without creating the right personal dynamics.

crdoconnor 9y ago
I've seen many teams claim to have switched from 'waterfall' to 'agile', but the only ones that haven't slipped back into a 'waterfall'-like mode after a few bad releases have been ones that put a strong emphasis on tools - specifically testing tools. Good interpersonal dynamics are important, but the sheer level of irony that the first rule of the Agile manifesto emphasizes deprioritizing the main thing that will actually get you away from waterfall-like development is pretty staggering, IMHO. Never mind. Forget the tests. If you have a meeting at 11am every morning where anybody who sits down is shouted at then you've done it. You're "agile".
- edejong 9y ago
  The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Take tests for example: blindly going for coverage metrics will be much less effective compared to having a deep, shared understanding of the pro's and con's of testing. To know that your co-workers have a similar understanding of the methodologies, makes the methodology itself of lesser (or no) importance. Personally, I am of the opinion that a strong emphasis on test-driven development in the long run will cause waterfall-style development. Tests are all about risk-prevention, instead of risk-mitigation. Prevention eventually becomes exceedingly expensive, whereas mitigation is all about building robustness into the running system. Due to that, the scalability of mitigation systems, such as true micro-services or actor-systems, are inherently more dynamic and cause less latency in development. I don't understand your last statement. It seems to confirm my position: "... anybody who sits down is shouted at ... ". The process (standing up, not sitting down) is less important than good team dynamics (not getting shouted at). (edit: down-voters, please share why you down-vote! I'd like to know. Also, please don't down-vote based on opinion, but on weakness of argumentation instead.)
  - tome 9y ago
    > edit: down-voters, please share why you down-vote! The one thing that I religiously downvote on HN is complaints about down votes.
    - edejong 9y ago
      Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.
      - tome 9y ago
        I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow-the-leader will soon be voted back up into positive territory. You just have to be patient :)
    - jrs235 9y ago
      I usually only down vote people who begin or include 'i know I'm going to get down voted...' in their original post. If someone edits asking for explanation I usually give them leeway... It tells me they are monitoring the conversation and willing to engage thoughtfully.
  - jrs235 9y ago
    I think you are getting down voted for questioning TDD. TDD seems to be another religion. You're insulting a sacred cow for some. Anyways, I would really like the avenue of thought you've planted in me to flesh out: risk prevention vs mitigation and how it applies to software development.
  - crdoconnor 9y ago
    >Take tests for example: blindly going for coverage metrics will be much less effective... I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes. >I don't understand your last statement. I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.
- Clubber 9y ago
  Waterfall hasn't really been used widespread in years (70s, 80s?), well before Agile in the aughts. It's more of a red herring to compare agile to something. It's like saying memory foam is way better than sleeping on the floor (completely ignoring traditional mattresses). We always used a pseudo waterfall but with much shorter iterations. We called it cinnabun. For example, we would cut 4 CDs a year so our iterations were about 3 months. We would plan what we wanted to do in the 3 months (bugs + features), code it, developer test it and throw it to QA. Once we had a good build, we would distribute it, have a small celebration the start over again. It's similar to agile, but with the 3 month cycles, you could actually plan and design a lot better because you could see out a little further. I suspect Agile is so popular because the business doesn't want to think of, make and stick to a decision for 3 months.
  - crdoconnor 9y ago
    You just said that waterfall hasn't been widespread since the 80s and then basically admitted to using it :) These days it still happens, it's just that few people call it that unless they want to be rude. IMHO waterfall is a natural state to revert to if you have a test deficit, technical debt and you don't trust releases that haven't gone through a round of manual testing first. The level of faith you have in your code/tests basically dictates the length of the mini-waterfall iterations. Continuous delivery (the exact opposite of waterfall) comes equally naturally if you have no test deficit. It doesn't require some kind of paradigm shift or a special 'agile mindset', it just requires an automated regression test suite you can trust. (this usually only happens when you write the tests first, but it's not strictly 100% necessary)
    - Clubber 9y ago
      Well, the definition of waterfall I grew up with was that you plan the entire project end-to-end with MS Project or something similar, including requirements gathering, delivery milestones, timelines and resource allocation. This was mainly done when building massive, in-house mainframe or AS400 apps that were expected to keep running for decades. Waterfall, as described, carried on through the PC revolution but was falling out of favor to version scoping and planning (iterative). Iterations could be whatever you wanted. There were backlogs, usually a list of tickets in some software system like Start Team or whatever. I think Visual Source Safe had this as well. It's fairly simple, so our UI designer just build one in a week or so. Agile and it's short sprints (2-3 weeks) fits nicely with SAAS (websites) because their distribution costs (comparatively none) doesn't lend itself to versioning (or isn't encumbered by it). I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way. >it just requires an automated regression test suite you can trust. Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile, there just weren't any common frameworks and it usually involved custom test harnesses (usually a console/terminal app to run and log stuff). It also requires automated deployment which can be tricky, especially when there is a single / clustered relational database involved. In conclusion, I like the Agile methodology, I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.
taneq 9y ago
Translation: Any software development approach works if you have good people. No software development approach works if you don't have good people.
- edejong 9y ago
  It's not exactly how I interpret it. I believe a methodology functions due to proper embedding in the team. The embedding happens (or has happened) due to good personal interaction, shared beliefs and shared knowledge. In other words, the methodology is a result of the personal interactions of the team.

crdoconnor 9y ago

I've seen many teams claim to have switched from 'waterfall' to 'agile', but the only ones that haven't slipped back into a 'waterfall'-like mode after a few bad releases have been ones that put a strong emphasis on tools - specifically testing tools. Good interpersonal dynamics are important, but the sheer level of irony that the first rule of the Agile manifesto emphasizes deprioritizing the main thing that will actually get you away from waterfall-like development is pretty staggering, IMHO. Never mind. Forget the tests. If you have a meeting at 11am every morning where anybody who sits down is shouted at then you've done it. You're "agile".

edejong 9y ago
The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Take tests for example: blindly going for coverage metrics will be much less effective compared to having a deep, shared understanding of the pro's and con's of testing. To know that your co-workers have a similar understanding of the methodologies, makes the methodology itself of lesser (or no) importance. Personally, I am of the opinion that a strong emphasis on test-driven development in the long run will cause waterfall-style development. Tests are all about risk-prevention, instead of risk-mitigation. Prevention eventually becomes exceedingly expensive, whereas mitigation is all about building robustness into the running system. Due to that, the scalability of mitigation systems, such as true micro-services or actor-systems, are inherently more dynamic and cause less latency in development. I don't understand your last statement. It seems to confirm my position: "... anybody who sits down is shouted at ... ". The process (standing up, not sitting down) is less important than good team dynamics (not getting shouted at). (edit: down-voters, please share why you down-vote! I'd like to know. Also, please don't down-vote based on opinion, but on weakness of argumentation instead.)
- tome 9y ago
  > edit: down-voters, please share why you down-vote! The one thing that I religiously downvote on HN is complaints about down votes.
  - edejong 9y ago
    Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.
    - tome 9y ago
      I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow-the-leader will soon be voted back up into positive territory. You just have to be patient :)
  - jrs235 9y ago
    I usually only down vote people who begin or include 'i know I'm going to get down voted...' in their original post. If someone edits asking for explanation I usually give them leeway... It tells me they are monitoring the conversation and willing to engage thoughtfully.
- jrs235 9y ago
  I think you are getting down voted for questioning TDD. TDD seems to be another religion. You're insulting a sacred cow for some. Anyways, I would really like the avenue of thought you've planted in me to flesh out: risk prevention vs mitigation and how it applies to software development.
- crdoconnor 9y ago
  >Take tests for example: blindly going for coverage metrics will be much less effective... I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes. >I don't understand your last statement. I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.
Clubber 9y ago
Waterfall hasn't really been used widespread in years (70s, 80s?), well before Agile in the aughts. It's more of a red herring to compare agile to something. It's like saying memory foam is way better than sleeping on the floor (completely ignoring traditional mattresses). We always used a pseudo waterfall but with much shorter iterations. We called it cinnabun. For example, we would cut 4 CDs a year so our iterations were about 3 months. We would plan what we wanted to do in the 3 months (bugs + features), code it, developer test it and throw it to QA. Once we had a good build, we would distribute it, have a small celebration the start over again. It's similar to agile, but with the 3 month cycles, you could actually plan and design a lot better because you could see out a little further. I suspect Agile is so popular because the business doesn't want to think of, make and stick to a decision for 3 months.
- crdoconnor 9y ago
  You just said that waterfall hasn't been widespread since the 80s and then basically admitted to using it :) These days it still happens, it's just that few people call it that unless they want to be rude. IMHO waterfall is a natural state to revert to if you have a test deficit, technical debt and you don't trust releases that haven't gone through a round of manual testing first. The level of faith you have in your code/tests basically dictates the length of the mini-waterfall iterations. Continuous delivery (the exact opposite of waterfall) comes equally naturally if you have no test deficit. It doesn't require some kind of paradigm shift or a special 'agile mindset', it just requires an automated regression test suite you can trust. (this usually only happens when you write the tests first, but it's not strictly 100% necessary)
  - Clubber 9y ago
    Well, the definition of waterfall I grew up with was that you plan the entire project end-to-end with MS Project or something similar, including requirements gathering, delivery milestones, timelines and resource allocation. This was mainly done when building massive, in-house mainframe or AS400 apps that were expected to keep running for decades. Waterfall, as described, carried on through the PC revolution but was falling out of favor to version scoping and planning (iterative). Iterations could be whatever you wanted. There were backlogs, usually a list of tickets in some software system like Start Team or whatever. I think Visual Source Safe had this as well. It's fairly simple, so our UI designer just build one in a week or so. Agile and it's short sprints (2-3 weeks) fits nicely with SAAS (websites) because their distribution costs (comparatively none) doesn't lend itself to versioning (or isn't encumbered by it). I just find that the short iteration isn't ideal because the short iteration, and lack of long-vision planning doesn't allow designers to develop in a "big-picture" way. >it just requires an automated regression test suite you can trust. Testing doesn't really fit anywhere in the equation as a differentiation. There was automated unit testing before Agile, there just weren't any common frameworks and it usually involved custom test harnesses (usually a console/terminal app to run and log stuff). It also requires automated deployment which can be tricky, especially when there is a single / clustered relational database involved. In conclusion, I like the Agile methodology, I just think the short 2-3 week iterations don't fit every organization and if you can handle 1-2 month sprints, you'll have better designed software because you can see further into the future.

taneq 9y ago

Translation: Any software development approach works if you have good people. No software development approach works if you don't have good people.

edejong 9y ago
It's not exactly how I interpret it. I believe a methodology functions due to proper embedding in the team. The embedding happens (or has happened) due to good personal interaction, shared beliefs and shared knowledge. In other words, the methodology is a result of the personal interactions of the team.