4 ms·

My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're goin

My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Agile, in general, is a collection of those patterns.

PeterisP 8y ago
The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?
- vannevar 8y ago
  How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.
  - Retric 8y ago
    Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone. That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.
    - jon-wood 8y ago
      Those people, in those positions, probably don't need much in the way of process. If you really can just sit down with the owner of the business, hash things out with them, and then go build something that does what they need then you're golden. And guess what, you're probably doing agile without even knowing it, because agile is attempting to reproduce that in organisations where you can't just put a single developer and a the CEO in a room and expect that to happen.
    - vannevar 8y ago
      They also regularly "recruit good people and leave them alone" and they fail. And then we look on those people as "bad" people. Which was my original point above.
- GFischer 8y ago
  Look at sports... I've seen both cases, players that are good within one system horribly underperforming in others, and players that don't look that great meshing with other castouts and creating a surprisingly good team. I suspect the same can happen with software developers. Of course, there are people that will be bad anywhere and top guys that will be great anywhere.
- tonyarkles 8y ago
  I wrote more in my sibling comment. I generally agree that there aren't any strict guidelines for becoming a good team, but I disagree that replacing most of the team is the solution in any but the most extreme cases. I would venture a guess that, most of the time, there's one person to remove and one person to add: a new leader. If that doesn't solve the problem, potentially looking at developer contributions and seeing if there's someone who isn't pulling their weight and has no interest in learning how to. (I've only encountered these types of people a handful of times in my career. Most of the time it was shoddy leadership)
- lmm 8y ago
  Then it would be good to figure that out, measure that, and then at least we can put the best people on the most important projects. It's perfectly possible to imagine a world where e.g. developer IQ was the only thing that mattered and the quality of software that got produced was simply proportional to the average IQ of the developers who worked on it, sure. I don't think that's the world we live in though. I've seen smart, sociable, effective developers fail in misorganised teams, and I've seen teams of ordinary people produce very good software by getting their processes right.
tonyarkles 8y ago
I accept that he's polarizing to some, but Jocko Willinck's book "Extreme Ownership" has some interesting stories on this topic. One of them is at Navy Seal training camp, where there's 6 teams involved in a multi-stage boat race exercise. Half-way through, team 2 is destroying everyone and team 6 is losing pretty badly. So, to teach a leadership lesson, the instructors decide to switch the leaders from teams 2 and 6. At the start, team 2 continues doing awesome, and while team 6 doesn't win, they improve. Next round Team 2 isn't doing quite as well, but still good. Team 6 has improved a bunch. After a couple of rounds, team 2 is falling apart and team 6 is now winning (or 2nd place, I forget). My experience, admittedly anecdata, is that great teams perform well when they're in an environment where they're allowed to succeed. I've worked with great teams who did terrible work, and it was pretty much always due to a bad environment (e.g. an owner who would redirect their efforts every few days, so no feature ever got to done-done). I've also seen (but not personally led) teams that I had originally somewhat written off, who under good leadership managed to do some pretty damned impressive work. And don't get me wrong, I'm not devaluing the potential contribution from a single amazing person, or a team full of amazing people. My clients hire me because I have a (locally) rare set of skills that their team doesn't have, and help them get over hurdles that their team can't (currently) tackle on their own. But if you take a great set of individuals and put them together in a shitty environment with a shitty leader, you're going to get what you get.

PeterisP 8y ago

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

vannevar 8y ago
How do you know they are coming from "good" teams? And if so, isn't it reasonable to suppose that they might carry over good practices in their new environment? I don't doubt that there are bad developers---I've definitely encountered them. But software development is a team sport, and it makes no more sense to just "recruit good people and leave them alone" in software than it would to do the same in basketball. Great teams have both talented people and winning strategy.
- Retric 8y ago
  Because people regularly do "recruit good people and leave them alone". At my first job I was the only developer working on the project and I rarely spoke with my boss. He came back from a month long vacation and I had not noticed he was gone. That's surprisingly common across the field. Most developers work on small teams doing small but often very long lived projects. Code staying in production for 30 years is surprisingly common outside of SV.
  - jon-wood 8y ago
    Those people, in those positions, probably don't need much in the way of process. If you really can just sit down with the owner of the business, hash things out with them, and then go build something that does what they need then you're golden. And guess what, you're probably doing agile without even knowing it, because agile is attempting to reproduce that in organisations where you can't just put a single developer and a the CEO in a room and expect that to happen.
  - vannevar 8y ago
    They also regularly "recruit good people and leave them alone" and they fail. And then we look on those people as "bad" people. Which was my original point above.
GFischer 8y ago
Look at sports... I've seen both cases, players that are good within one system horribly underperforming in others, and players that don't look that great meshing with other castouts and creating a surprisingly good team. I suspect the same can happen with software developers. Of course, there are people that will be bad anywhere and top guys that will be great anywhere.
tonyarkles 8y ago
I wrote more in my sibling comment. I generally agree that there aren't any strict guidelines for becoming a good team, but I disagree that replacing most of the team is the solution in any but the most extreme cases. I would venture a guess that, most of the time, there's one person to remove and one person to add: a new leader. If that doesn't solve the problem, potentially looking at developer contributions and seeing if there's someone who isn't pulling their weight and has no interest in learning how to. (I've only encountered these types of people a handful of times in my career. Most of the time it was shoddy leadership)
lmm 8y ago
Then it would be good to figure that out, measure that, and then at least we can put the best people on the most important projects. It's perfectly possible to imagine a world where e.g. developer IQ was the only thing that mattered and the quality of software that got produced was simply proportional to the average IQ of the developers who worked on it, sure. I don't think that's the world we live in though. I've seen smart, sociable, effective developers fail in misorganised teams, and I've seen teams of ordinary people produce very good software by getting their processes right.

tonyarkles 8y ago

I accept that he's polarizing to some, but Jocko Willinck's book "Extreme Ownership" has some interesting stories on this topic. One of them is at Navy Seal training camp, where there's 6 teams involved in a multi-stage boat race exercise. Half-way through, team 2 is destroying everyone and team 6 is losing pretty badly. So, to teach a leadership lesson, the instructors decide to switch the leaders from teams 2 and 6. At the start, team 2 continues doing awesome, and while team 6 doesn't win, they improve. Next round Team 2 isn't doing quite as well, but still good. Team 6 has improved a bunch. After a couple of rounds, team 2 is falling apart and team 6 is now winning (or 2nd place, I forget). My experience, admittedly anecdata, is that great teams perform well when they're in an environment where they're allowed to succeed. I've worked with great teams who did terrible work, and it was pretty much always due to a bad environment (e.g. an owner who would redirect their efforts every few days, so no feature ever got to done-done). I've also seen (but not personally led) teams that I had originally somewhat written off, who under good leadership managed to do some pretty damned impressive work. And don't get me wrong, I'm not devaluing the potential contribution from a single amazing person, or a team full of amazing people. My clients hire me because I have a (locally) rare set of skills that their team doesn't have, and help them get over hurdles that their team can't (currently) tackle on their own. But if you take a great set of individuals and put them together in a shitty environment with a shitty leader, you're going to get what you get.