Getting a performant team needs an investment into the team. Instead of frantically or stoically pulling a cart with square wheels, a team should be able to spot the fault in the system and change. This however proves difficult in practices. The good news is: collaboration creates the team and thus providing room for collaboration is an easy way to nurture the team.

The term team is far from clear and agreed. You might even use several different definitions of team without realizing it. But a football team has completely different setup and dynamics than a software team. This is totally reasonable: different task, different type of team. However, when forming a team, people are not aware that their notion of how people work best in a team comes from a different situation and does not fit well with task and situation at hand. Here are three prototypical teams.

Different situations require different teams

Workflow teams: In administration, similar to an assembly line in manufacturing, requests are handed over from one “station” to the next, every station adding their bit to fulfilling a request. Cleverly designed and agreed workflows hold everything together. Teams gather employees working at one station. These teams handle things like allocating requests, planning vacations, optimizing output, ensuring quality, providing a social space, introducing new employees and more. However, the bulk of their working time employees spend at their station doing their individually assigned tasks. These task are mostly routine work that follow well defined rules, only few require problem solving and this problem solving is usually restricted to the narrow scope of the station. Workflows efficiently coordinate the work the individuals do.

Squads: To e.g. extinguish a blazing fire, several persons need to make a joint effort. In these dangerous and time-critical situations, a command structure has been a successful pattern. Decisions are taken in minutes or even seconds and everybody in the squad can act immediately in a coordinated way. Of course only, if there is accurate and clear communication within the squad. Through training, the members of the squad learn how this cooperation works and to rely on the others. In such a model, the squad members efficiently cooperate and can thus master highly dangerous situations.

Interdisciplinary teams: When creating innovative and complex products, several persons need to combine their different expertise (see Know how to shape the future). The success pattern for such situations is the interdisciplinary team. This allows to solve a problem too complex for any of the individuals alone. Even in an interdisciplinary team, many tasks can be done individually in a coordinated way. Some tasks however require the whole team to combine their expertise and integrate their ideas into a comprehensive solution. Here, team members form a super brain where thoughts and ideas from one person inspire others and different perspectives combine. The more difficult and innovative the product, the more often the super brain needs to be in action. Team members collaborate.

Developing software systems or products has little to do with a dangerous mission and can profit only to some degree from workflows. It is a creative process where different expertise has to be combined and even new expertise acquired. The most profit can be gained from interdisciplinary teams.

Do they do everything together?

In an efficient team, different work structures are used flexibly:

• individual working: team members individually do a task.
• cooperative working: team members break up one task in several sub-tasks and work individually on the subtask. They coordinate who does what by when and thusly optimize team output.
• collaborative working: several team members combine their brain power to complete one task together.

These working style also match with different problem types:

• Routine work and simple tasks can be easily done individually. Reduce disruptions and focus on one task at once so you can concentrate your efforts.
• Cooperative working is well suited for basically simple tasks that need many hands to complete them. Stand-up meetings like the daily in Scrum are very well suited to coordinate such work.
• Collaborative working is especially helpful for complex problem solving: the super-brain of a strong team can solve more complex problems than individuals could.

Strong teams exhibit strong team properties

When individuals interact, an entity, a “We”, starts to emerge. It sets these individuals apart from the rest of the world. While at the beginning, such a “We” might be frail, it can grow and even dominate the individuals it is composed of. When such a “We” has reached some quality, people will call it team.

Note: What level of quality distinguishes a team from not a team is not well defined. For example, it is generally agreed that a team should have a shared goal. Something the individuals try to achieve together. Still, at any time the individuals in the team will have their personal goals as well, things they want or have to achieve. For some individuals, a team goal just gives a frame, a directional drift, a field to pursue individual goals. Others set their personal goals aside to focus, for now, on the shared goals. Yet others adopt the team goals as their own goals, replacing former goals. Given any team, expect quite a mix!

A shared goal is just one of the properties a “We” can exhibit. For the sake of simplicity, I clustered the many different properties into the following ones:

1. Team story: Shared purpose, common goals and an agreed approach gives teamwork a clear direction and a sense of purpose. In a strong team, team members identify strongly with the team story.
2. Team know how: A shared language of the why, what and how; understanding of the others, their skills, perspective, motives and reactions; and a balanced set of skills, suitable for the task ahead: In a strong team, the individuals are well attuned to each other and form a super-brain that achieves much more than the individuals would ever be capable of.
3. Team culture: A shared set of values, principles and behaviors guides the individuals activities and especially provides a shield in case of stress, conflict or crisis. A strong team rewards interaction, learning, respect, trust, and helping each other.
4. Team spirit: The current mood of a team drives the individual motivations and bonds the individuals together. A strong team has a healthy and motivating spirit.
5. Team processes: A shared set of roles, responsibilities and work procedures allow a team to efficiently collaborate and work together. A strong team constantly adapts roles, structure and processes to the changing circumstances and to the needs of the individuals in the team.

Developing team properties

To develop team properties, teams have a couple of different levers. They will need a good combination of them all.

Set the frame for collaboration: Team properties emerge first of all through collaboration, i.e. when the members together achieve something great for their users and customers. In fact, the closer the team members collaborate, the more they elaborate the team properties. As soon as they start working individually, the team properties wane down.

Think about whom to involve for what decision: The smaller the team, the easier and faster a decision can be taken. The bigger a team, the more people have understand and adopt the decision. Therefore it is probably a very good idea to involve the whole team in the fundamental decisions (level story and concept) and split up the team the less impact the decision has.

Good ideas are thus to:

• Provide a team space with loads of walls, whiteboards etc. where team members naturally interact with each other. Use a team wall, even for individual work, so that conceptual work becomes visible to the whole team.
• Work closer together as a team whenever big changes are implemented or big decisions are be made so the team is well aligned and can quickly do it.
• Work-out a topic with the team or sub-team. Discuss the solution as a whole e.g. business change, user experience, technical solution, and testing. The participants gain a holistic understanding and come to an agreement what to build. 
• Omit letting somebody specify a solution and someone else implement it.
• Create collaboration points while a story is implemented, e.g. by pair or even mob programming, quick story reviews, stand-up presentations and more.
• Split up work, once the team has become proficient so the team can deliver more.
• Let team members discuss their decisions and designs with others, thus implement some good practices like code reviews, dev exchanges etc.
• Setup processes so that team members get first hand feedback from those who really matter (you would expect this to be customers and users and of course some VIPs).

An interesting tool to help you is delegation poker (see https://management30.com/blog/delegation-poker-gamification/). The idea, you discuss with the team on how certain decision will be taken. The options vary from a dictatorial approach (e.g. software architect or a product owner decides and tells) to full democracy (i.e. discussed until consensus is reached).

Invest into the team: To set collaboration, team members need to discuss, goals, values, ways to achieve the goals and more. Explicitly investing into team properties seems like a great idea to me. You could:

• Run regular inspect and adapt meetings, aka retrospectives in Scrum and manage the improvements.
• Setup team workshops where the team can have an in-depth discussion about roles, processes, values, their needs and expectations etc. and discuss more fundamental changes. You might do this regularly with the team.
• Let the team experience other ways of working to reflect on how they work and what they can improve.
• Don’t forget social events, coffee breaks, lunches and all the other activities that bring people closer together and provide a social space.

Work with the individuals in the team: We as individual differ highly in our skills, needs and behaviors. For a team to work well, some social and communication skills are required and some behavior is better suited than others. Thus you can for example:

• Provide education and coaching around conflict management, workshop facilitation, and more
• Work with the individual and help them to develop the skills needed to collaborate better.
• Listen to employees, their needs and problems and discuss with them options within the team and expectations from the company.

Work with the context: Quite a lot of issues within the team are induced by the context around the team: Conflicts of interests; company politics; tightly fixed Bermuda triangle (budget, time and scope); or counterproductive company values. Some of these issues can be resolved by the team or at least escalated to someone who can resolve them. For others, the team could at least decide on a common position. Here, teams profit from strong personalities in roles like product owner or system architect: Such persons have been empowered by the organization to decide and should be respected when promoting the position taken by the team.

How information flows – about information loss

Ideally, information flows directly between stakeholders and team

• SH <–> team

What to communicate

• why, what, how

The challenge

• who has what knowhow and skills –> more complex team structure
• time to market –> parallel work

Information that should flow: Stakeholder requests (business drivers, context of use, usage, issues, constraints, options –>

• issues
• information flow in the team: from stakeholder to those in the team
• –> speaking the languages, cultural clashes –> translator, facilitator skills?
• –> non-aligned information needs (user <–> dev, FHSG slide)
• –> information filtering, interests
• –> roles: translator or facilitator vs. technical guy
• –> scarce staff: devs and sme

How work flows – scheduling issues

• work flow in the team: from new to done
• overcapacity, bottlenecks
• specialists

How to efficiently kill team work

As may have become quite obvious, there are many many really efficient options to hamper teamwork and make teams basically ineffective. Coming up now: some very popular ones.

Most companies tend to demand too much and induce the Team disorder: Featuritis. The team tries to quickly deliver the visible stuff and delays quality, architecture, team, individual growth, and organizational impact to later, i.e. never. This is the ideal soil for a burn-out machine and it scales to the company level as teams look for themselves, do not communicate well enough and define products and timelines that do not fit together. Agile Frameworks like SAFe try to solve this problem by introducing a system of backlogs and synchronizing teams.

Some sophisticated reward systems create high incentives for individuals. Such a system needs an assessment of the individual performance of a person. However, in a strong team, the individual performance is highly dependent on the team performance and the opportunities available in the team. A strong incentive will usually make persons work for themselves and against the team and the others in a team.

A frequent strategy is to assemble teams with loads of specialists. They represent their discipline in a the team and are only partially working for the team. Everyone has more than one and different bosses and is mostly focused on their contribution rather than the overall success. This juggling of bosses fosters an opportunistic working style. Whoever shouts the loudest gets the most attention.

Unspoken requirements for teams

Interdisciplinary teams are generally established to solve a complex problem. However, the organization expects the team to achieve other things as well – sometimes without ever mentioning it and sometimes even without being aware or it:

Individual growth: While working in a team, the team members develop their skills, acquire know how, refine their personalities – they grow. A team can and should provide opportunities for the team members to grow. Therefore, a couple of things need to take place:

• A discussion within the team about personal growth: What individuals strive for and what can be made possible in this team.
• Creating opportunities for people to grow. E.g. rather than assigning a task or a responsibility to the most skilled person, find ways to assign it to those who want to grow into it.

Social space: Most humans can only thrive in a good social space. Teams are very important social spaces when it comes to our work environment. However, social spaces go beyond a strictly professional relationship. Teams should become a place where team members are welcomed and valued. Teams should make room

• for building up trust, learning and helping each other.
• to share personal moments and feelings and to create fond memories of shared moments within the team.
• to turn conflicts within the team into a win for the team.
• to discuss how the individuals can and should contribute to this social space.

Organizational impact: When thinking about change in organizations, one thinks about the big reorganizations, the highly visible tipping points of change. There however is a lot change happing all the time. Teams are and should be making such change happen. Therefore they need to become active and e.g.

• interact with others to share insights and know how.
• align goals and improve collaboration with those around the team.
• use and especially contribute to company assets, so more can profit.

Reviewing such expectations sheds some light on the difficulty a person faces who takes on a leading role in a team. This is just too much for most! Especially if team members just care for their own job. Developing complex products needs persons who act responsibly. Leading is about enabling them to do so.

Taking responsibility

When feeling responsible for something, we take care of it and also feel accountable for what we achieve. Feeling responsible takes us beyond just doing an assigned job. It will make us think and act for the good of the person or thing we’re caring for. As we are acting beyond job specification, we judge our actions and achievements against a set of principles and values from a guiding authority like religion, morals, science, laws, aesthetics and more.

If people are consistently able to take responsibility and achieve results up to their and other standards they can take control, gain confidence, grow and become more resilient in difficult situations. Others can trust them and this strengthens their relationships. It also changes how the members of a team can work together. When the team members take responsibility for their tasks and for what the team tries to achieve together, this creates a more productive environment. At least, in an ideal situation.

However, just designating someone responsible does not imply that this person will feel responsible. We also develop a feeling of responsibility for something that we were never asked to. We even go as far as to redefine our job so it matches what we feel responsible for. We are bound to invest much more energy into what we feel responsible for than for other things. We have to interact with others and they only grant us limited responsibility. They restrict the actions available to us and evaluate our achievements against their standards.

As you might have already spotted, there is a huge potential for conflict in this system of responsibility. See UX in a burn-out system: at the heart of this conflict is one person who is taking responsibility for UX against all others in the team! You have probably seen many other difficult situations, like someone feeling responsible for something but the bosses rewarding the opposite? Or the person lacks options and skills to achieve a “good” result?

Taking responsibility can be everything from highly rewarding to burning out. Here summarized the crucial elements to consider:

• The person’s willingness to take responsibility;
• rewards for taking responsibility;
• a safety net in case of a perceived failure;
• good amount of room given for decision, taking actions and to focus one’s energy;
• an appropriate difficulty to grow without being demanded too much;
• alignment about what people feel responsible for;
• alignment on how people evaluate their achievements; and
• an ongoing discussion about the conflicts stemming from not doing all of this to perfection.

Compare the list with your situation at work. What do you feel responsible for? Do you have enough room and is the difficulty appropriate? Does this align with the others around you and do you all agree about the authority for evaluating the achievements?

Adding balloons – a team’s blind spots

The agile inspect and adapt principle is a well established mechanism to improve team work and to adapt to changes. In Scrum, during the retrospectives held once every sprint, the team reflects on their collaboration and decide on improvements to be implemented in the next sprint.

However, assessing own strength and flaws is not so easy. Some teams are great at accepting major flaws because they learnt to live with them or nobody knew of a better way. Therefore, even though teams implement inspect and adapt, they still tend to stick to a somewhat flawed mode of working. The typical story of inspect and adapt is the following:

• Work as before: Team members set the initial structure up as they can envision it. Namely, they create a generally acceptable mix of how they worked before and stick to this.
• Self-assessment: There is no obvious best way of working together. Teams usually rely on their own assessment. Thusly, even ineffective modes of collaboration are acceptable when nobody knows of a better one.
• Reward for delivery: The team is rewarded for delivering a product, not for building a high-performance team. Investing into the team is thus easily put off for later. Increasing pressure on features makes this effect even stronger.
• Coupled cycles: Retrospectives are usually tied to development sprints. A team improvement iteration thus lasts one sprint. More difficult improvements drag along for three or four iterations of ineffective team work.
• Ad hoc conflict resolution: Team members do not necessarily have refined skills in conflict resolution. More difficult conflicts thus flare up ever so often and are dragged along through the development, never quite resolved.

Overall, teams tend to start with what the members can perceive as potential ways of working together – usually how they worked the last time – and then slowly do some minor improvements while developing more and more blind spots for flaws in their collaboration. Team members may even proudly point to some nifty work-around they invented to cover the flaws.

Teams used to pulling a cart with square wheels are likely to do so the next time as well. The inspect and adapt cycle allows them to e.g. attach some balloons.

Closed loops

Inspect and adapt as such promotes a closed loop principle for developing products. In a software development team, this closed loop consists of four elements:

The first element is the story team members and stakeholders share and agree upon. A story is concise and precise summary of the what the software is all about and for what purpose. This story serves as the target of the closed loop system. Such a story is much more effective when

1. team members and stakeholders take responsibility to realizing it;
2. everyone can assess and agree upon the current state and progress made towards realizing the story; and
3. everyone relates their tasks to the story and can easily decide which tasks to prioritize and which to drop .

The second element is the external feedback loop between team, customers and users. Getting feedback from real life usually drastically changes the perception of what is important (see meet with users to create great products). This external feedback loop works much better when

1. the team can quickly get feedback to new ideas, first implementations as well as to the current product;
2. the feedback is reliable, i.e. it predicts the usefulness of ideas or states real issues or opportunities customers and users have; and
3. the team can easily judge the importance of the feedback.

The third element is an internal feedback loop, where teams assess the quality attributes of the product itself, e.g. bugs, response times, cleanliness of code, attractiveness and more. The internal feedback loop works much better when

1. the team uses a risk based approach to balance investment into manual and automated testing versus untested gaps;
2. the team has prioritized targets to evaluate against; and
3. building quality (as opposed to rushing to the market) is valued by stakeholders.

The fourth element is the conversation in the team and with stakeholders to figure out, what to build and what not, in what order and how. This includes a development strategy, the scope, the conceptual structure as well as making all details from processes to UI to code and tests work together. The conversation works much better when

1. team and stakeholder agree upon the fundamental of how they want to work together;
2. the team invests into strong team properties; and
3. team and stakeholder work on the conflicts.

When looking how to improve team work, the team should therefore cast a critical glance at the story, the feedback loops and how they lead the conversation with stakeholders.

Feedback, feedback, feedback!

It should have become obvious by now: the feedback loops make the difference. A team needs feedback loops

• for the individuals in and around a team, their contribution, professional skills, expectations, career goals, behaviors and values;
• for the team and how they lead the conversation, their processes, structure, strategy, and know how
• about the social space provided by the team,
• about the product they create, its function and quality, the vision behind and priorities;
• about the team’s impact on the company; their contribution to values, assets, know how, etc.

Investment into teams

Just throwing people together does not make an effective team. It needs an investment into the team (see also Collaboration – Buy or Lease?).The investment into a team is not constant. At the beginning of team work and upon major changes (vision move, team change, other needed adaptation), a higher investment into the team is needed.

Thus, it is probably a good idea to:

• adapt the frequency of the retrospectives depending on the demand of change from the team.
• make room for team development and plan with fewer story points when a team needs to adapt to a changed situation.
• plan in some reserve for up-coming team changes. The velocity measured during stable team phases will be too high.

A bigger change in the team usually results in a significant personal change. Tasks, skills and even attitude may need to change. Take for example a situation where software team realizes that their software just has too low quality. The simple fix to assign one person to work out a solution and tell the others what to do may not really work well. Some team members might need to change their attitude towards testing, other team members might lack the skills to design easily testable code, other team members need suddenly to play an active role to set a culture of quality rather than a culture of feature creation and finally team processes change so that testing actually happens.

Such situations ask for a focused change. It is thus probably a good idea to:

• run time-boxed experiments of new modes of working where team members can get a hands-on experience of the value and the costs.
• do an intervention, where the team adopts a new way of working and makes a kick-start in acquiring the needed skills, mainly by doing it. Brief retrospectives during the intervention allow to adapt and learn. At the end of the intervention the team can decide what to adopt immediately, what later and what not at all.

Reward team building

Team members usually get little acclamation for creating a great team. Praise and blame are given for the results. Of course people in principle know, that the better the team members work together, the better the result is going to be. It is nevertheless just an indirect consequence. Thus having found a generally acceptable way of working together is good enough for most teams.

Team members have little vision of a how great team work actually is; inspect and adapt does not include external feedback, groupthink is to be expected; and nobody demands good team work.

Given these points: it is probably a good idea to 

• get outside feedback by e.g. inviting other teams to the retro, or even going to other teams. 
• get to know different ways of working, e.g. from other companies, related jobs and more. A software team could have a closer look at how designers, mechanical engineers or even a team of doctors collaborate.
• use moderators so the team can question already accepted rules and work procedures. 
• regularly replace some team members. New team members are by nature more likely to ask the “silly” questions needed so a team starts changing stuff.  
• show how you do it to the world (or some part of it). Post an article, a video, a picture, go to a conference and more. This invites discussion and insights.

Long-term investment

The amount of learning in a project is limited. In the end, the team has to deliver a product and cannot devote too much time into forming the perfect team.

Given this we need to strive for an organization where teams identify and try out new ways of working, talk about them with other teams so the successful patterns spread through the organisation.

Replacing the square wheels

Back to the initial question: how to achieve that teams do not pull a cart with square wheels any longer?

It seems quite clear, that there cannot be a silver bullet but many small improvements and loads of work. 

First of all, it seems a good idea to setup a team so that team members actually collaborate.

Second, it investing into team development and set aside time for this is a must. The time needed is cannot be constant but needs to adapt.

Third, some things can profit from a focused intervention (aka flipping) where a team acquires the needed skills, processes and attitude so a change can be realized. 

Fourth, teams profit when they are challenged by seeing other ways of working, new team members and moderators so they can detect their blind spots.

Fifth, Learning to collaborate well needs time! It seems that an organization needs long-term investment into team work and structures that allow spreading new and better ways of working.