The Development Team - Just Developers or a Real Team?

Software developers are mostly guys, happy to work by themselves at night in dark rooms. And they turn coffee, cola and pizza into code. Right?

My experience so far

To be honest, the longer I have worked in software development the more wrong this stereotype feels to me. True, when I learned to code I enjoyed those solitary moments of puzzling out a solution to a tricky problem. I didn’t count the hours and proudly told my colleagues and friends about the nights I worked away.

The first years of my career as a software developer I worked in a small team of three people where everyone had their specific expertise. I was responsible for the client application we developed for an in-house application. I was the only one working with the specific technologies and libraries I used to create the UIs and so it was basically me and a mixture of Google and API documentations of sorts (it was way before stackoverflow.com was born). I sometimes asked my colleagues for help, but most of the time they were trying to solve their own problems and weren’t of much help to me.

After five years I left this company to start a job as an IT consultant. Over the next six years I worked in many different teams - together with my colleagues in our own office, as a small team at our customer’s office or alone inside a customer’s team. Some of those teams were people happening to work on the same problem, some were ‘real’ teams.

So, when is a group actually a team?

To me, a real team is not just people working on the same problem, but people having a common goal and collaborating closely.

The common goal is the overall problem we are trying to solve. We don’t develop software to satisfy our desire for shiny tech stuff - well, not only, at least. We try to make life easier for our customers and users.

Collaborating closely means working with others, not only near others. Over time I have identified several characteristics I deem necessary for great teams.

Autonomous

The best teams I have worked in were autonomous to a certain degree. Sure, some teams have very wide boundaries and can choose many things from the languages, libraries and tools they use to what problems they want to work on. Others have more restrictions.

While working as part of a team, one important thing to me was always to have clear boundaries that I know of and understand. Then I wanted to be free to decide inside those boundaries. This way I was able to feel lots of autonomy even in environments that were very regulated.

I think software developers need autonomy as a pre-condition to be creative in their finding of solutions, which brings us to…

Creative

“We have always done it like that.” This is one of the sentences I dread most. It strips me of all the creativity I have. Although we may have always done things like that - this doesn’t mean we can’t improve by trying something different.

Therefore I think that creativity - the intrinsic drive to find new (and better) solutions to existing problems - is key for software development. Technology and user needs change so quickly that yesterday’s solutions often aren’t fit for today’s challenges.

Creativity is an individual trait that can radiate into and stimulate a team. In my experience, creative teams are also…

Curious

I am a very curious person. I can’t count the side projects I have started because I was interested in learning something new - a new technology, a new problem domain, a new way of thinking.

Like creativity, curiosity is an individual trait. Curious people ask lots of questions. Those questions help finding out about the root cause of a problem. They also enable us to create more information about a specific context in which our solution might be applied. This helps prevent solutions that are clunky at best, and unfit for the problem at worst.

Now that we have talked about individual traits that help a Development Team become the best it can, there are a few team characteristics. Great teams are…

Diverse

Let’s look back at the stereotype that I started this post with. First of all, I think (hope) it is hard to find a team of people embodying this cliché. At least those teams that I like to remember for the fun and effectiveness we were able to have, were different.

They consisted of very different people. People of different gender, race, beliefs, age, etc.

This diversity made it possible to create a bigger context of experiences and knowledge. We have been brought up differently, lived differently and were able to work as a team nonetheless. Diversity induces tolerance.

Diversity as described here is one side of the coin. Great teams I have worked in were also…

Cross-functional

Diversity for me describes who someone is. When I talk about cross-functionality, I talk about what someone knows and is able to do - the type of expertise someone has.

In the complex environment of software development there are many different special types of knowledge that we need in order to solve a problem. From the business or problem domain via different parts of technology, systems and their dependencies to running, monitoring and maintaining the solution. One person can’t have all this knowledge in the depth needed.

Therefore we need individuals who are experts in one or more of those domains and who are…

Generous

Sharing knowledge and experience is key for a cross-functional team. It helps individuals to grow and the whole team to improve.

Software development is not a zero-sum game. This means that the benefit of one part of the system has to come with a loss for another part.

The more individuals share, the more the team members and the overall team improves. A colleague who benefits from my knowledge and experience doesn’t take anything away from me, on the contrary: by sharing with and learning from each other we all benefit.

How to get there?

While those traits are beneficial for the individual team member, they are also very much improving the overall team and its performance. In my experience the cost of trying to continuously improve a team in those and other aspects is more than outweighed by the long-time benefits the team and the company gain.

The question now is how can you create and grow a team with those characteristics? To be honest, I don’t know. I don’t even think there is a single recipe for creating great teams. What I have experienced in the past is that I can work with my teammates and colleagues, discuss where we are at the moment (and celebrate our successes so far) and what we can do to further improve.

Some concrete things that I have seen work in the teams I worked with were:

• Sharing knowledge within teams: brown bag lunches, tech talks, pair / mob programming
• Invite management to explicitly define the boundaries the team has to respect in their self-organisation and periodically review them, e.g. as part of a Retrospective
• When stuck with a problem, doing something completely different in order to get new insights and fresh ideas
• Trying to learn more about the business domains - maybe collaborating with a business user of your system for a few hours or days will help you understand what they are really struggling with
• Inviting other teams or colleagues not directly working with the system we create to reviews and ask for their feedback; sometimes just explaining what we have tried to do to someone unrelated helps create a better picture

This list is by far not complete. These are just some very few examples of things I did in the past.

I always enjoy meeting other software developers, discuss teamwork and exchange experiences. I think peer consulting is a great way to improve. It is not about finding the best way of working as a team. To me it is more about finding out what others do and how this might be applicable to my own situation.

What is your experience?

So what is your experience? What characteristics do you see that make up great teams? How to you (self-)improve in your teams? Do you disagree?

If you are a Scrum Master how do you or could you help your team improve in those aspects?

Send your feedback to peter@flowdaptic.de.