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!



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.


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.


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! 🙂

Today I have learned about Ishikawa diagram (AKA fishbone diagrams, herringbone diagrams, cause-and-effect diagrams, or Fishikawa). And I started to wonder whether it makes sense to use it to diagnose the issues related to the production of software. (I will not explain Ishikawa diagram in this post, so please have a look at Wikipedia description if it does not ring any bells for you).

I wanted to try it myself, so I choose an arbitrary (but quite common) problem – “low quality of software” – and tried to use Ishikawa diagram to find the causes.

I have to say that I’ve enjoyed this little experiment. At first I thought that I will have to modify the original categories, but after a while it occurred to me, that no major changes, but rather a refactoring of names is required (the descriptions were copied from Wikipedia article):

  • People Anyone involved with the process – no need to change, there are many people-related problems in IT.
  • Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws – I think the “Process” term is better suited for software development.
  • Machines: Any equipment, computers, tools, etc. required to accomplish the job– I would suggest to use the “Tools” term which includes both the hardware (devs machines, CI server) and software (i.e. IDE)
  • Environment: The conditions, such as location, time, temperature, and culture in which the process operates – maybe not so important in case of software development than in factories, but also worth analyzing. No name change here.
  • Materials: Raw materials, parts, pens, paper, etc. used to produce the final product – this made me think for few seconds. Then I realized that the material we work is, is simply the software. I have left the “Materials” term unchanged, but other names (e.g. Application or System) would be also fine.
  • Measurements: Data generated from the process that are used to evaluate its quality – hmmm…, I think that would be various metrics like code coverage etc.

So the starting point is this:


(HINT: click to enlarge)

I spent like 10 minutes drawing a diagram for a hypothetical team (definitely NOT the one I currently work with!). And this is the result.

DISCLAIMER: I do not claim this diagram to be complete, or very smart, or that it solves any real issue. This was only my attempt to see how this tool – Ishikawa diagram – could be used. Got it?

BTW. I have used XMind (free version) to prepare the diagrams. In reality that would be probably pen & paper (a very large paper!).

Here is an “overview” (with only first-level causes visible):


The beauty of electronic version is that you can hide some parts of the picture and analyze a selected branch or two. Below an example example of single category analysis in all its glory:


As you can see you go as deep as it is required to find the causes which cause other causes 🙂 “5 whys” is the technique you would probably use for this.

The whole picture could look like this (it doesn’t matter that you can’t read the small fonts, really):


Now the team could look at all the issues described and decide which of them are of the main importance (“root causes”) and should be fixed.

Yes, I like it

Ok, to conclude, I would say that I like the idea of using Ishikawa diagram for finding the major problems of software development. I could imagine a team working with this diagram.
The fact that you have 6 different categories there would make team consider a vast range of factors, which could result in finding not-so-obvious stuff. Having so many perspectives makes it harder to stop right after finding the first possible cause (e.g. someone says “it is all because testers are lazy!” and the rest agrees and the discussion is over).

So now it looks like I’m now in a “solution-looking-for-a-problem” situation. I have this nice tool (Ishikawa diagram), I have an idea what problem could be solved with it (finding most important issues for team in troubles), but I have no team that would need such analysis. 😉

And what about you?

…and maybe you have used this diagram (or a different one?) to find/solve some issues within your team? I would be happy to learn about it!
Or maybe you have your ideas about when/how to use it? Do not be shy, share them with the world! 🙂

Source file – xmind

You can download the original xmind file here.

Code reviews. Very helpful if done right, completely useless if done recklessly.

Below you will find a mindmap of “code review” (using Xmind). I simply sat down and tried to gather everything related to code reviews. Hopefully you will find some food for thought here.


Some comments:

  • I knew one team lead (hello Marcin! 🙂 who had a very nice system of publishing code reviews by email to project’s mailing list. He believed (and had some good results to support this belief) that by doing such “public” code reviews he educates the whole team, and not only the author of the particular code. It worked for him and his team pretty well!
  • Marking code with TODO and FIXME during the review works pretty well for me. Nope, I haven’t used gerrit or any other tool like this yet.
  • IMHO code review should be a part of Definition of Done – no task is finished until someone else checked the code.
  • I don’t like the idea of team lead doing code reviews for the whole team. He has probably no time for this. The other thing is that some people find it hard to discuss with your “boss” (so they will follow blindly what the reviewer says). I like much more the idea of peer reviews. Even if some junior guys are not capable of performing code reviews properly (at least from the very beginning).
  • There is a great discussion regarding code reviews here.