Team Building: The software development way

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.