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 will agree with it, from their personal experience. Since the start of 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 product companies. The goal of a feature team in a product dev company is not to code in a specific language, but to develop and 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 the team happiness dynamics in our company. At the moment we have 3 feature teams, and each of them develops a new functional feature (the Team card is on the left, the TP3 Project card is on the right, and it includes sparkline graphs):
There are usually about 5 people in a feature team, 4 developers and 1 QA. UI designers are not stationed with any team, they join in at the start of a feature development, and then step out. Note the weird names these teams call themselves. It's for a reason. First, only a team of confident professionals with a good sense of humor can bear the name "Dead End" or "Exploited". The Dead End name is a reflection of a relative boredom (from the point of view of other teams) of the work that this team is currently doing. The Alaska team emerged as it was bitterly cold and snowy outside early last year as we moved into the new office.
The level of happiness in our teams is not a steady constant. When several features are released, and it's time to reassemble feature teams, there's a huge tumult over how the teams will rearrange, who will be doing which feature next, who will join which team, and who will move to which room. This is a chaotic process, but it always settles down somehow, and by the time a freshly formed team starts working on a new feature, this team is 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 in the beginning because it's 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 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 is as flat as on a cardio oscilloscope when someone dies. It matches the lowest happiness point in the curve for a healthy feature team. One can make an assumption that a flat happiness line can be observed with some routine menial tasks. In human terms, such a team is always 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 will look for happiness elsewhere.
We have several other teams that are busy with different kind of work. I will dissect their happiness dynamics some other time.
You can subscribe to our monthly newsletter here:
Сheck out latest blog posts:
Or start your
Get a live
Let one of our product specialists create your account
and shape Targetprocess for your company needs.