4 ms·

There's "Agile", the buzzword that all sorts of advice-givers have capitalized on commercially, and then there's the Agile Manifesto [1]. The Agile Manifesto ha

by jcrites 10y ago

There's "Agile", the buzzword that all sorts of advice-givers have capitalized on commercially, and then there's the Agile Manifesto [1]. The Agile Manifesto has merit and is a set of values, not a methodology - it would precisely agree with your advice to chiefly "use your brain". It's unfortunate that the latter has been turned into a Frankenstein's Monster of the former. [1] http://agilemanifesto.org/ http://agilemanifesto.org/

jheriko 10y ago
I hate to disagree since you support me, but thats not true. The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights (but even then, only if you haven't thought about the problem very much and tried to approach it in reality). I shipped software very quickly before learning much about agile at all... I ship it even faster afterwards, but not because I agree with it all... in fact I am convinced I am better off for ignoring the more harmful aspects and selectively choosing the ones that have a measurable benefit.
- jcrites 10y ago
  > The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights Are we talking about the same document? What are the problems and harmful aspects that you're referring to? (Please quote the relevant part) This comment feels either a bit like a content-free middlebrow dismissal, or we're referring to different documents.
  - jheriko 10y ago
    http://agilemanifesto.org/ http://agilemanifesto.org/ http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html From the very first. > Individuals and interactions over processes and tools Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contradictory given that a lot of the agile manifest essentially describes process or a strategy for creating one... and as for ever relegating the importance of good tools.... ick. ? (p.s. thanks for calling it out, its good to take these things seriously imo. its shows passion and care. :) )
    - jacques_chester 10y ago
      > That is, while there is value in the items on the right, we value the items on the left more. That sentence is important for interpreting the statements.
    - terryf 10y ago
      > ... and it varies a lot by personality ... But that is the point of the sentence. A process does not care about individual variation. What the manifesto is saying is exactly what you are saying.
      - TeMPOraL 10y ago
        Yeah, and that's a difference between a mature engineering discipline and software development. Though one could argue that software is so young as an industry that we have no clue what processes could be actually effective, so it's too early to set up one.
    - timv 10y ago
      I think one's assessment of the manifesto is largely dependent on how generously you read it. > Individuals and interactions over processes and tools needs to be read in conjunction with: > while there is value in the items on the right, we value the items on the left more Which means I can interpret it a way that is true, but not that interesting. That is, I believe that a great developer with crappy tools will produce better software than a crappy developer with great tools But I'm not sure what that really tells me other than "hire great people". I guess, to some extent, it means "if the process says I should do X, but the team thinks it's a bad idea, then I should listen to them", but even that's is not a necessary conclusion from the statement. In the non-software world, you only need to spend a little bit of time looking at workplace deaths to see that many of them are caused by teams that decided to ignore safety protocols. Ultimately the only thing I really take from the agile manifesto is that doing the exact opposite is bad, but so what? I don't want to ever work in development team that: - Thinks that "following a process" trumps "investing in good people" - Prioritizes writing documentation for software rather than making it work - Has watertight contracts but ultimately disappoints the customer - Sticks to "the plan" even when it's obvious that the circumstances have changed. But I didn't need a manifesto to tell me that.

by jcrites 10y ago

jheriko 10y ago

I hate to disagree since you support me, but thats not true. The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights (but even then, only if you haven't thought about the problem very much and tried to approach it in reality). I shipped software very quickly before learning much about agile at all... I ship it even faster afterwards, but not because I agree with it all... in fact I am convinced I am better off for ignoring the more harmful aspects and selectively choosing the ones that have a measurable benefit.

jcrites 10y ago
> The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights Are we talking about the same document? What are the problems and harmful aspects that you're referring to? (Please quote the relevant part) This comment feels either a bit like a content-free middlebrow dismissal, or we're referring to different documents.
- jheriko 10y ago
  http://agilemanifesto.org/ http://agilemanifesto.org/ http://agilemanifesto.org/principles.html http://agilemanifesto.org/principles.html From the very first. > Individuals and interactions over processes and tools Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contradictory given that a lot of the agile manifest essentially describes process or a strategy for creating one... and as for ever relegating the importance of good tools.... ick. ? (p.s. thanks for calling it out, its good to take these things seriously imo. its shows passion and care. :) )
  - jacques_chester 10y ago
    > That is, while there is value in the items on the right, we value the items on the left more. That sentence is important for interpreting the statements.
  - terryf 10y ago
    > ... and it varies a lot by personality ... But that is the point of the sentence. A process does not care about individual variation. What the manifesto is saying is exactly what you are saying.
    - TeMPOraL 10y ago
      Yeah, and that's a difference between a mature engineering discipline and software development. Though one could argue that software is so young as an industry that we have no clue what processes could be actually effective, so it's too early to set up one.
  - timv 10y ago
    I think one's assessment of the manifesto is largely dependent on how generously you read it. > Individuals and interactions over processes and tools needs to be read in conjunction with: > while there is value in the items on the right, we value the items on the left more Which means I can interpret it a way that is true, but not that interesting. That is, I believe that a great developer with crappy tools will produce better software than a crappy developer with great tools But I'm not sure what that really tells me other than "hire great people". I guess, to some extent, it means "if the process says I should do X, but the team thinks it's a bad idea, then I should listen to them", but even that's is not a necessary conclusion from the statement. In the non-software world, you only need to spend a little bit of time looking at workplace deaths to see that many of them are caused by teams that decided to ignore safety protocols. Ultimately the only thing I really take from the agile manifesto is that doing the exact opposite is bad, but so what? I don't want to ever work in development team that: - Thinks that "following a process" trumps "investing in good people" - Prioritizes writing documentation for software rather than making it work - Has watertight contracts but ultimately disappoints the customer - Sticks to "the plan" even when it's obvious that the circumstances have changed. But I didn't need a manifesto to tell me that.