I've worked in team-based environments most of my career, but not as a programmer. (I am trained as a musician/composer.) I'm becoming aware of programming specific team-based concepts, though--slowly but surely--such as Version-Control, SDLC, documentation, etc. I'm getting a certain theoretical understanding, but not really feeling confident about it. I'd like to practice anything I can to help me learn how to work more effectively in a team. ...before I actually go and bother someone with my heavy-handedness or ignorance.
I'm not sure if it's possible or even recommendable to attempt to 'practice' team-based methodologies privately. Maybe the only way to really learn how to work in a team is to just experience it. Likewise, I wouldn't know how to explain teamwork to another musician, but as musicians we don't really have codified methodologies in the same way that programmers do, and I think that could make all the difference. In music there are certain conventions and inflexibility due to the mechanical nature of the instruments/recording equipment (akin to hardware/language, I suppose), but otherwise we kind of make it up as we go along (and I assume programmers do a little bit of that, too, depending on the context--I wouldn't know. That's kind of what I'm trying to figure out).
I'm pretty sure that the inevitable answer is that I should work on something open-source; the world is flat, after all, and it's not difficult to communicate across great distances as a programmer (like it often is with musicians). But my feeling is that I'm not ready for that. I would feel safer learning how to approach teamwork with programmers before just diving in, because programmers can perhaps be a little persnickety. I'm trying to avoid a trainwreck-type of experience that might cause some irrational fear.
So is there anything I can study beforehand, and if so, is there a generally accepted way to go about it? Like mock-teamwork, team-related practices that can be practiced privately; is any of this making sense?