Really good teams in project business

Good teamwork is important. That is a no-brainer and not only since “agile” has become THE THING.

Especially in IT consulting, requirement and projects change at short intervals. Therefore, teams constantly face new challenges on the technical side as well as in understanding the business side. The tasks are usually very complex. Here, really good teamwork can become crucial for success especially in the development team.

In addition to technical requirements and other basic conditions, intensive cooperation in the development team not only influences HOW something is built, but also WHAT is built.

“Good teamwork” is just not enough. Go for “really good teamwork”

The question arises: Is the pursuit of good teamwork an end to itself? What does good mean? And what does the customer (internal or external) actually get out of it?

Working at a project-focused IT sercive company I often see development teams dissolve at the end of the project. At the beginning of a new project they have to establish a Team in a new constellation. In the past years I worked for our customers in project differing regarding composition, team size or project duration. I learned a lot about factors for team work by these changing condition:

A newly assembled team goes through various phases. The team members need some time to establish themselves as a team. It usually takes some time until the team reaches its full potential. A simplified form of the phases to be passed through according to Tuckman [1] are: Forming, Storming, Norming, Performing and Adjourning.

First of all the team has to get to know each other while forming. Roles and areas of responsibility are taken and explored, conflicts arise and are finally settled, a phase called storming. When the group becomes aware of the common goal, and the strengths and characteristics of the individual team members are perceived and accepted, we see a team evolving. This last step of “getting to know each other” is called norming. The intensity and duration of the individual phases vary from group to group. In the now ensuing performing phase, the team masters the set tasks and possible conflicts most effectively. The motivation is enormous. We often see a tremendous flow. Needless to say, this phase should last longest. When the project ends, the team often dissolves. The members can feel a kind of loss here. this is called adjourning in the sense of closing.

Make teams as stable as possible

In the last two years coincidentally some colleagues and me formed a stable core team for a series of projects (insted of being allocated to different projects within the company). Thus, we were able to start as an established team with a new project and new tasks.

From these lucky circumstances I gathered some insights on the factors relevant for a really good team – especially in a project-focused service company.

• The initial effort for team building, initially done during forming, storming and norming, is reduced to a minimum
• Right from the start the teams buils on mutual trust. This is a gamechanger since trust cannot be postulated. It has to be built, developped and nourished. That takes time and effort.
• Trust leads to more effective communication and transparency. The team is able to identify problems or impediments more quickly. And it can solve them or prevent them from arising in the first place.
• The team is a safe environment to experiment, own mistakes or admit to unfamiliarities (e.g. with a technology).
• A common understanding of purpose and taks is essential for communication with stakeholders and project managers. Team members are thus able to accurately assess the current project status.
• Agile methods, practices and approaches are already deeply rooted and well practiced. This leads to a high degree of self-organization from the start.
• The team had already established shared views on quality and the question “what makes good software”. This helps to live up to them, which in turn helps nourish mutual trust.
• Values and practices based on the Agile Manifesto [2], Software Craftsmanship [3] or DevOps [4] are well-established. These values are part of the teams’ DNA. They create a common mindset.
• Constant changing of programming partners leads to intensive exchange of knowledge. This is sufficient to cover the (most) specialisations the team as a whole needs.
• Even if the original skill sets of team members do not cover all given requirements, a self-organized team can solve comprehensive problems extremely efficiently, not at least by effective communication. In our case, we faced an enterprise technology stack including programming language, frameworks and libraries unknown to most team members. The cloud platform vendor was uncharted territory; so were many infrastructure and operations activities. The team accomplished to build the required knowledge. Also, every devteam member dealt with the infrastructure, in the end we all performed in a true DevOps mindset without explicit roles.
• The software development set up as pair programming from the beginning and (sometimes) as mob including processes for code quality and test automation. Here, too, the team performed in a holistic orientation.
• Even during the first iterations, the retrospectives showed a high degree of self-reflection and a problem-solving mindet.

Stable teams are the key

You could put it that way: Don’t bring the team to the project, bring the project to the team!

This way of thinking is also reflected in the MaibornWolff-Teambox [5] and so a reference should not be missing at this point. The Teambox format makes it possible to implement the digitisation ideas of our customers in a targeted manner through explicitly reserved teams and close cooperation.

For me, a team feels really good when one of these three developments happens:

• A good team is able to help itself. Each team member brings different skills and competencies to the task, which contribute to the solution of the tasks. It is advisable to have a balanced mix of generalists with a focus on a partial aspect, such as test automation. This reduces the time required for the team as a whole to acquire certain topics. A team consisting exclusively of specialists is more of a hindrance here.
• A good team shares the goal. Everyone has it in mind. Everyone knows how to contribute to the achievement of the overall goal.
• A good team lives by values as trust, transparency, openness, quality and responsibility.

For this to happen, a few basic conditions are needed: Emotionally stable teams need time to evolve. Once sucessfully establlished, teams should ideally have a chance to work together for a longer duration of time, even in a next project.

Of course, the opposite can also become true. Beware of overly stable development teams that operate without realizing their blind spots. Teams that e.g. no longer have their decisions questions or that neglect established practices of software crafts(wo)manship.

And of course it should also be possible for teams to grow over time. And of course, if people want to leave the team to pursue other interests and acquire new skills, they should be able to.

What insights would you like to share? Which qualities do see as mandatory in a really good team?

Links

[1] Tuckman’s stages of group development: English Wikipedia or project-management.com

[2] Manifesto for Agile Software Development

[3] Manifesto for Software Craftsmanship

[4] DevOps Culture

[5] Teambox from MaibornWolff

---

About the author