Friday, July 30, 2010

Are You Really a Team?

These days, many of us work in Agile teams or in integrated SCRUM teams. We're no longer the development team and the test team and the design team. Instead, we're one team working together to ship product. At least, that's what we tell people.

If this is you, though, are you really a team? Is this really all one group going toward a single goal?

Three simple questions will help figure this out:
  • Do you assign tasks to individuals?
  • Do developers do test tasks when the team is crunched? Do testers help with system configurations when the team is trying to get set up for new development?
  • When a bug is found in the field, who gets yelled at and tries to figure out how to prevent that kind of problem from making it out to customers again? Your testers? Or your team?
If you're still playing "developer" and "tester" roles, then it doesn't matter whether you call yourself one team or two, you're still restricting yourself. You're still saying that you do your bit, the other guy will do his bit, and if we're all good and lucky, then good things will happen. That's not a team. That's a group of people.

A team is a group of people working toward the same goal. Some have more experience than others in different things, but if you're really a team, then each member will happily do whatever is standing between the team and release.

The difference between a group and a team is very simple:

Teams succeed together and teams fail together.
Groups pass or fail, each individual alone.

If you want to be a team, be a team, not a group.
Posted by at 11:53 AM

6 comments:

  1. I guess I disagree. Not everyone on ever team needs to be capable of fulfilling every task. Teams have distinct roles.

    NFL Football is a team sport. Few would expect the Quarterback to be able to jump in and play Linebacker.

    I do agree that "Teams succeed together and teams fail together." That's true in software as much as any team sport.
    ReplyDelete
  2. Well, sure, Joe. There is a place for specialization. At the same time, if a left tackle winds up with the ball near the end zone, he's probably gonna go for it, even if that's not traditionally what a left tackle does.

    I think of it as the difference between "having more experience" and "being unwilling to do". Having more experience is fine. Being unwilling is a problem.
    ReplyDelete
  3. Perhaps. And perhaps it's a question of do you want developers doing testing tasks? I suppose it depends on which particular testing task is at issue.

    So do testers do development tasks when the team is crunched? I suppose it depends on the development task as well as the abilities of the testers.

    In general, I want developers concentrating on development, and testers concentrating on testing. On good teams, all roles are important, and everyone knows their role.

    I might argue that picking up a fumbled ball is everyone's traditional role. (Go Pats!)
    ReplyDelete
  4. If people share and believe in the goal, they will generally try to do what they think should be done towards that. If there's a shared goal, that means everyone is pulling towards the same thing.
    Some people might be better at certain tasks, that doesn't stop the team (and everyone) from doing what's needed.
    ReplyDelete
  5. The roles on a good software team are essentially the same sort of work as playing in a band. As a bass player, it is my job to make whoever is in front sound as good as possible. If they make a mistake, I cover it. If they're playing well, I make sure not to step on them, while still working hard in the background. Testers do this too. So do sysadmins, DBAs, etc.

    Even though I am not a very good programmer, it is my responsibility to be able to discern good code and good design from poor code; my job depends on it. Likewise, even though I am a poor saxophone player, it is important to my work (and my income!) to be able to tell good saxophone playing from bad.

    I do truly think that the work is essentially the same. In the software world, concepts like continuous deployment and real-time upgrades are becoming more and more conventional. We are approaching a time when software development will obviously be an artistic performance.

    Just as we say "do you want to go hear my favorite band at 8 PM on Thursday?", in the very near future (if it is not already happening) we will be saying "my favorite programmer is in the office on Friday, let's go see what new features she's going to give us".
    ReplyDelete
  6. I'll see you with your, "Do developers do test tasks when the team is crunched?" and raise you with developers reviewing their team's bug fixes.

    This is something that is being tried on a team where I work. I *wish* I could take credit, but I can't. The developers are reviewing fixes that are not their own and it's taking them just enough outside of their comfort zone to give them a completely new perspective on their work. It's great learning and is giving the test team some much needed help.

    Really enjoyed this post.
    ReplyDelete

Subscribe to: Post Comments (Atom)