3 ms·

How, exactly, is embracing and responding to change going to happen if there's not frequent communication? What form of agile methodologies have the developers

by vacri 10y ago

How, exactly, is embracing and responding to change going to happen if there's not frequent communication? What form of agile methodologies have the developers going off on their own for weeks without oversight? How do they 'respond to change'? A strict literal reading of the agile manifesto doesn't include daily standups, yes, but if you read it at anything other than the most superficial level, frequent communication is necessary.

dragonwriter 10y ago
> How, exactly, is embracing and responding to change going to happen if there's not frequent communication? Frequent communication doesn't have to be synchronous, prescheduled, or in-person, though, and it doesn't have to be through a heirarchy (team lead). Also, the phrase "Agile methodology" is almost an oxymoron (and absolutely incorrect in terms of most of the methodologies it is applied to); a development methodology in the usual sense cannot be Agile, though a team's higher-level methodology that controls choice of and change to the development methodology can be.
- vacri 10y ago
  I didn't say it had to be any of those things, and mentioned ticketing as well, which is none of those things. The comment I was responding to was about being checked-up on frequently. And regarding tech leads, once you get above the size of a single very small team, how many of those don't have some form of technical lead? Besides, the Agile Manifesto explicitly states at least one form of daily interaction: Business people and developers must work together daily throughout the project. Having this in the list and then pretending that having standups are the functional opposite of "what Agile really means" is just nonsense. Every time I see one of these "Ah, but Agile doesn't have to be that way", it makes me think of lynx and w3m. There's the way the majority of browsers work, and then there's ones like these. Yes, you can make the correct technical argument about what a web browser is, and then there's the way that almost everyone thinks of when the word 'browser' is used. File a bunch of bugs about how your front-end is failing in w3m, and then sit back and watch the WONTFIXs roll in.

by vacri 10y ago

dragonwriter 10y ago

> How, exactly, is embracing and responding to change going to happen if there's not frequent communication? Frequent communication doesn't have to be synchronous, prescheduled, or in-person, though, and it doesn't have to be through a heirarchy (team lead). Also, the phrase "Agile methodology" is almost an oxymoron (and absolutely incorrect in terms of most of the methodologies it is applied to); a development methodology in the usual sense cannot be Agile, though a team's higher-level methodology that controls choice of and change to the development methodology can be.

vacri 10y ago
I didn't say it had to be any of those things, and mentioned ticketing as well, which is none of those things. The comment I was responding to was about being checked-up on frequently. And regarding tech leads, once you get above the size of a single very small team, how many of those don't have some form of technical lead? Besides, the Agile Manifesto explicitly states at least one form of daily interaction: Business people and developers must work together daily throughout the project. Having this in the list and then pretending that having standups are the functional opposite of "what Agile really means" is just nonsense. Every time I see one of these "Ah, but Agile doesn't have to be that way", it makes me think of lynx and w3m. There's the way the majority of browsers work, and then there's ones like these. Yes, you can make the correct technical argument about what a web browser is, and then there's the way that almost everyone thinks of when the word 'browser' is used. File a bunch of bugs about how your front-end is failing in w3m, and then sit back and watch the WONTFIXs roll in.