Happy Teams

Software is developed by people working in teams, and there’s a certain correlation between a team’s level of happiness and the quality of their work. I doubt if one can provide a statistics-based proof for that assumption, although many would agree with it based on their personal experience. Since the start of the agile movement and development with Scrum or XP, a lot has been said and written on why cross-functional teams do better than teams grouped by their skills. In some companies they still have teams named after the programming language in which they code e.g. “PHP team”, “.NET team” or whatever team. This is an obsolete trend, at least, for app development companies. The goal of a feature team in an app dev company is not to code in a specific programming language, but to develop and to release a functional feature.

So, what makes a team happy? Doing the work they like, and doing this work together with the people they like. Let’s look at how the team happiness dynamics might fluctuate at an app dev company. Teams are not set in stone, they form and dissolve, depending on what gets done and released, and one of the prerequisites for a happy team is to let the team live, breathe and work once it is formed. It is essential both for the quality of work and for the happiness of the team, that team mates stay together as one unit, all the way to the release. Tossing people from team to team at random once they get down to work is a no no. So, obviously, the first stage of a team’s happiness can be described as follows: “That’s great! We are now working as one team, no one will set us apart, and we will do our best to develop and to release a feature that adds value to our app, and we are going to be proud about our work!”

For one app, several features are normally in development, and the count of feature teams is not a steady constant. It varies. As to the size of the teams, and to the ratio of developers and QA in the team, it depends as well. The UX and product people might not be permanently stationed with any given team. They might join in at the start of a feature development, and then step out.

The level of happiness in teams is not a steady constant as well. When several features are released, and it’s time to reassemble the teams, a certain turbulence over how the teams would get rearranged might ensue. Who will be doing which feature next, who will join which team, and who will move in with whom in the office space, things like that. This process might bear a certain measure of chaos with it, but, one way or another, the chaos would settle down somehow, and by the time a freshly formed team starts working on a new feature, they are happy. The graph below shows the happiness level of a team that is excited at the start of the work, bored in the middle, and happy as it gets closer to a release.

An organic team can not be steadily happy about everything. The graph above looks like a natural happiness curve. The team is excited at the beginning because they are up to a new interesting work, and they are starting out with the UI and coding. By the middle of the dev span the work pace gets steady, and the team might get bored. Then as it gets closer to a release, the happiness level goes up. The team is now excited about having their baby feature say “hello, world”. It would be a disaster to observe the happiness level drop by the time of a release; this would mean that a team is totally pessimistic about their work. Another disaster would be to have the happiness curve look like that:

This line looks as flat as a cardio pulse line when someone dies, showing the lowest happiness point in the curve. It’s safe to assume that the flat happiness line can be observed if the team is working on some menial tasks. In human terms, such a team would be permanently bored with the work. If the latter graph is what you have in your team, ring the bell and create some tumult. The line might drag along steadily low for quite some time, but if people are always bored like that, they are likely to be looking for happiness elsewhere.

There are other teams at app development companies that are busy with a different kind of work, unrelated to software development per se. I will take a look at their happiness dynamics another time.

This story is based on an earlier article.