3 ms·

Yes. You can't choose a methodology without considering the personalities and habits of the team members. Unless you have the luxury of replacing an entire tea

Yes. You can't choose a methodology without considering the personalities and habits of the team members. Unless you have the luxury of replacing an entire team with people who want to work with a particular methodology, dogma gets you nowhere. And I'm only talking about a team. Go up a level or two to the department or organization, and things get even harder.

HeyLaughingBoy 14y ago
My god, I wish people understood this. Process Methodology, by and large, exists to create a "quality floor." Follow methodology X and you are likely to have a product that is no worse than Y, for whatever set of metrics Y is. But process does not create skill. Process should exist to provide a framework or a set of limits to work within. It won't make a mediocre developer a superstar, but it will keep him from propagating dumb mistakes out to the customer. As a result, Process results in less improvement from good developers, because they're already operating at a level well above the quality floor. In the end, randomly choosing a methodology without considering the team's personality and culture is a recipe for frustration for some, apathy for others and maybe a small bit of product improvement.
- slantyyz 14y ago
  >> Process Methodology, by and large, exists to create a "quality floor." I agree. I have this saying that doesn't win me any friends: "Methodologies are for monkeys". (Keep in mind I use that term for project management methodologies and not so much for development methodologies) A lot of big companies want/like trendy methodologies because they assume it lets them to hire less skilled people (i.e., cheaper) and continue to produce quality work. It doesn't. What I have found is that when you have a team of quality senior people with good communication skills and throw them together, they will hash out what processes work best for that team without any need of formalizing their process. This way, everyone gets to work the way they want individually with some adjustments that allow them to work as a group.

HeyLaughingBoy 14y ago

My god, I wish people understood this. Process Methodology, by and large, exists to create a "quality floor." Follow methodology X and you are likely to have a product that is no worse than Y, for whatever set of metrics Y is. But process does not create skill. Process should exist to provide a framework or a set of limits to work within. It won't make a mediocre developer a superstar, but it will keep him from propagating dumb mistakes out to the customer. As a result, Process results in less improvement from good developers, because they're already operating at a level well above the quality floor. In the end, randomly choosing a methodology without considering the team's personality and culture is a recipe for frustration for some, apathy for others and maybe a small bit of product improvement.

slantyyz 14y ago
>> Process Methodology, by and large, exists to create a "quality floor." I agree. I have this saying that doesn't win me any friends: "Methodologies are for monkeys". (Keep in mind I use that term for project management methodologies and not so much for development methodologies) A lot of big companies want/like trendy methodologies because they assume it lets them to hire less skilled people (i.e., cheaper) and continue to produce quality work. It doesn't. What I have found is that when you have a team of quality senior people with good communication skills and throw them together, they will hash out what processes work best for that team without any need of formalizing their process. This way, everyone gets to work the way they want individually with some adjustments that allow them to work as a group.