Recently I have spent some time thinking about teams. How it happens that few people become a team? What factors are at play? This is pretty important to me right now because few weeks ago I moved to a new team. And I want this team become fantastic. So there is plenty to think about and plenty to do.

As usual, when the topic is broad and vague I created a mindmap to put some structure around my random ideas. Here is the result.

I have shared and discussed this mindmap with my teammates during one of the first meetings we had. It somehow helped us to realise that this is not about just sitting together. To become a team, a really successful team, we need much more.

In case you use XMind you can download the original file here.

So obviously such things need time. Group of people doesn’t become a team just like that. Unless they go through some pretty intense stuff like volcano eruption, Sharkando, or Amazon S3 breakdown. Since such things do not happen everyday (with the exception of S3 failures) there is fat chance that you will need few months till a team is formed.

What you can do is to create an environment to make things happen faster. Let us see what we can do for various aspect of “being a team”.

There is also a question of decisive power that your team has. Probably not everything is under your control. Your organization might impose some things on you. For example, there could be a rule that each team should organise retro every 2 weeks or that we all use XYZ as your build server. Also team structure might be imposed. Thanks God this is not the case for us, as we have a lot of freedom in how we arrange our working environment.

And last but not least: some of the things won’t ever happen if you have wrong people on your team (meaning you will never really be a team). As always: hiring is the king!

Structure

Roles might be imposed by your organization. Or not. What you can do here is to have a discussion. Like what roles do we need to fulfil our goals?. This leads to further discussion – do we really need a devops or can we handle the deployment on our own? Do we need a QA or can we keep the quality of the product ourselves?
Then comes more personal questions, i.e. what roles do you think you could take? or more generally what do you bring to the team? (what skills).

Such discussion might sound boring but it is not. If the environment is right and people are in good mood then there is some laughter and fun involved. It works. At least, it worked for us. We learned that some of team members would be very happy if we let them code and left them alone 🙂 Others do not mind configuring production environment and writing end-to-end tests. Good. At least we know what can be expected of whom. It is good to know it beforehand.

Skills and roles are obviously connected, but there is no simple one-to-one mapping. I see skills as a very broad term: it could be Java mastery as well as staying calm even in case of cryptic JavaScript errors.

Sharing

Obviously we share a lot of time and space. Let us see about other topics.

Goals are interesting. Why do we exist (as a team)? What is the purpose? Where are we going? Would be nice to see if people see things similarly.

We talked about it with my peers. I asked everyone to write down the goals as he/she sees it. Not much discussion on the topic because it occurred we all see our team goals similarly (which is probably good). What was unexpected is that we added one more goal to our list: “have fun and write good code”.

As for the values we plan to discuss it as well. I guess this is a standard team-building-retro-exercise. What do we value? Speed? Code coverage? Fun? No-IDE development? Respecting each other? Whatever – would be nice to discuss it.

Exchanging knowledge is our daily bread. We talk, we talk a lot. In fact, currently we are rather talking than coding. Or talking while coding. Or coding while talking. Hard to say. Anyway. We are on the same boat now as we inherited some old projects to maintain (and new exciting features to develop). So sharing of knowledge happens all the time. And I hope we keep it this way.

And BTW. obviously one of the best ways of knowledge passing is pair programming. Or rather doing stuff together. Some time ago I assisted Łukasz deploying one of our applications to production. OMG, I tell you, I haven’t expected it at all, but I’ve learned a lot! It occurred Łukasz uses shell scripts to perform tasks that I used GUI for. Nice, really nice.

We also hope to share a similar coding style. We already started by discussing our DDD approach so that we all keep it consistent. One day probably you won’t be able to tell which one authored which part of code. Right now different styles of coding are probably easy to spot.

Feelings

Hm, you can’t make people like each other. But if you haven’t hired some assholes it will eventually happen. Same with respect or understanding.

What you can do is to help by creating opportunities. For example go to a pub or eat dinner together so people learn/like each other. Or encourage to do intensive pair programming – it always induces some discussion, which usually entails understanding, which usually entails respect, which sometimes entails friendship, which sometimes entails love… errr… well, understanding and respect should be enough.
Anyway, even simply meeting and talking is a good start. Yes, it is. Find some excuse to move people away from their laptops and have some discussion.

Feedback is something we all crave. We have already established some strict rules regarding code reviews so we expect to get (and give) a lot of feedback.
I also hope one day to have a kudo box so we can compliment each other. And later on we will probably try some form of peer-reviews.

As for pride I hope we will be very, very proud of our code we write. Being proud of what we do and who we are means also that we will be willing to share our experiences with other teams.

Separate / mark out

This also requires time. We do not have any custom habits yet. Some artifacts are ours (e.g. kanban board) while other (e.g. build server) we share with others. And this is fine. Sometimes it is simply easier to use some common resource. What we did in the case of build server is that we have our own view which presents us only jobs that we are interested in. A small step but it makes the build server more as if it were ours, even if it is still the same machine shared by many teams.

As for meetings we already have them set. Regular daily meetings and retrospectives, and (not so regular) planning sessions.

Doing things together

It is all about experiencing things together. Will see what the future brings.

Reasons to celebrate? I hope so. The thing is not to miss the opportunity to celebrate. Oh, you can celebrate even small things. I need to remember about this.
Production issues so we have to work overtime? I hope not, even though that would probably make us stronger (as a team). But it is not really something I’m looking forward, you know.

We definitely share a passion for clean code. What is left is that we need to agree what do we all understand by this. 🙂 But it will eventually happen as we code together and review what we have previously done.

This is it for now

This is not the end, but this is it for now. I hope you find some inspiration here. Good work building your super team! 🙂