Joshua Arnold

After the successful kickoff of a project, it’s often helpful to get a feel for how your team works together – rather than simply talking about it. While there are plenty of exercises you can use that focus on team building, I’ve often found it beneficial to use techniques that are specifically geared towards software development. I have several that I like to use but in this article, I’ll walk you through one of my favorites.

Before conducting any of these exercises, I strongly recommend having a kick off meeting and ensuring that the members of your team understand the roles that they will be playing.

Event-Domain-Model

This problem was specifically designed to utilize the paradigm of Test-Driven-Development. It’s a simple problem that is centered on security settings for Calendar Events. To read the problem in full detail, you can download it here.

I encourage you to change the problem and the process as needed to adequately fit your team but here are some steps that can help you get off on the right foot:

Step 0: Setting Up

You can rely on simply emailing files back and forth if you don’t have time to set up for this exercise. However, I would recommend setting up a simple source control repository to further expose your team to how they will be working with one another.

If your team does not consist of testing engineers, then identify one to two for the sake of the exercise.

Step 1: Start as a team

Begin by analyzing the problem as a team. Walk through the problem and assign one person to begin creating skeleton classes as they are identified.

Step 2: Make use of roles

Change the team’s seating arrangements to group certain members based on their roles. I find that teams of five are quite common so the team-lead (sometimes yourself) will oversee the exercise. The most common combination for the other members are:

• Paired testing engineers
• Paired developer and architect

The testing engineers then write tests against the code that was stubbed out in step one by reading through the requirements and clarifying with the team lead. Be careful to keep a consistent understanding of the requirements throughout the team during this exercise. It’s very easy to misunderstand the requirements as they have been designed to be ambiguous.

The developer and the architect then write the logic by filling in the methods stubbed out in step one. I find this pair to be particularly useful as the architect translates the requirements to code and guides the developer in creating the code that he/she has envisioned. This gives both the developer and the architect a good understanding of what they can expect from one another.

Make sure that everyone has committed their code.

Step 3: Regroup

This is the moment of truth. The goal here isn’t necessarily to have every single test pass the first time through, although there is something to be said about your team if they do! Instead, this is a great way to observe any inconsistencies in your understanding of the requirements, the planning that was involved, and the execution of that plan.

Emphasize to your team that failing tests does not mean that they have failed the exercise. In fact, having tests fail is a great opportunity for the team to work together to fix the problem. This helps illuminate the inconsistencies and potentially helps prevent them from happening in the future.

This is also a great time to do a quick code review and introduce any coding standards that the project requires. It’s one thing to throw a document containing these standards at your team and expect them to be followed, but it’s much more beneficial to walk through something that they’ve written and compare that to your expectations.

I think it’s safe to say that we’ve all had memorable group experiences. Some of them have undoubtedly been great while others were nothing short of ugly and unpleasant. Some of you have experienced the ever so popular “group think” or social loafing in some form, and others have been privileged enough to experience a well established community.

The transformation of a group of individuals to a community of learners is something I think everyone should experience. There comes a point within that transformation that the mindset of each individual shifts from “what can I take from this” to “what can I give”. It’s the most important part of the transformation and it’s the foundation of every learning community.

Why do I bring this up? In any project (unless of course you’re a one man team), you’re working with other individuals and you rely on each other to succeed. More often than not, you’re working with talented individuals that are constantly moving forward and climbing ranks. This motivation and passion can be harnessed to create some of the greatest teams you’ll ever be a part of.

The key to harnessing this power is to focus on team building from the very beginning and paying close attention to the dynamics of the group. More importantly, each member of the team should have a clear understanding of each other’s roles and strengths. These strengths can be combined with other strengths to complete tasks more efficiently. They can also be paired with weaknesses of others to grow the team.

This brings me to my main point: the important of a kickoff meeting. There are several things you can do to help create an environment that encourages collaboration and team learning. Here are the main ones:

Identify the strengths and weaknesses of your team

Depending on your work environment, you may have specific roles laid out for each member and/or roles that are required by policy. Whether you have these dictated to you, or you have your team help you create them, it’s important that each member understands the important of each role. More importantly, the members of your team should understand how each other’s strengths play an important part of their qualifications for that role.

Obviously you must take caution in discussing such information and depending on your work environment this may or may not be allowed. Nevertheless, it’s important that each member understands the importance of each role and how that role affects them.

Some people are very uncomfortable with explaining their weaknesses with other people. This is understandable but it’s important that as the leader, you’re well aware of them. You can use this information to pair them up with stronger team members on specific tasks.

Identify the hidden strengths of each member

I rarely encounter anyone that doesn’t have hidden talents that they can bring to the table. Some of these talents aren’t really applicable to the project at hand, but others can be invaluable. More importantly, since they don’t have the chance to apply these hidden skills on a daily basis their passion for doing so is even more invaluable.

It’s beneficial to the team to discuss these hidden talents or passions. You should make it your number one priority to find ways for your team to apply these whenever possible. Having the freedom to do more than their everyday tasks is an important piece in building a learning community.

Identify the goals of each member

Most likely the members of your team are a part of your project and their role on the project is described by their role in your company. In other words, they’re there because it’s their job to be and you’re going to have a hard time convincing them to go above and beyond without any form of incentives. It’s an understandable viewpoint but there is flexibility here that most leaders miss: the incentives don’t always have to be financial (not directly at least).

Work with your team to create goals that work within the confines of your budget and other external constraints. As the leader of any team, it’s your responsibility to keep the team’s best interest in mind – while following the instructions of anyone giving you orders of course. Try some of the following suggestions:

• Identify an area of weakness that a member of your team would like to strengthen
• Find areas of the project requirements that are flexible and may have room for innovation

Create opportunities for growth

Personal growth is a goal of every member of a learning community. By creating opportunities for the members of your team to grow their skills, acquire new ones, and refine others you create an environment that encourages this growth. Be mindful of your strategy for tolerating failure when assigning tasks that leverage a newly acquired skill.

Team building exercises are an excellent way to conclude any kickoff meeting. If you’re working in the software development industry, try some code-based exercises to establish the boundaries of roles within your team. It’s a great opportunity for your team to learn how to work with one another in a controlled environment and will give you an excellent start.