Getting a performant team needs an investment into the team. Agile inspect and adapt is meant to do the trick. Instead of frantically or stoically pulling a cart with square wheels, a team should be able to spot the fault in the system and improve. Observation: teams surprisingly often do not do so. 

Just throwing people together does not make an effective team. It needs a real investment into the team (see also Collaboration – Buy or Lease?) so that team properties can strengthen and the team can manifest as an entity.

Team properties emerge

Team properties emerge first of all through intensive collaboration, i.e. when the team really tries to create something great for their users and customers. It needs bonding, finding a common goal, i.e. a  powerful story, building a common culture, common knowledge and processes, establishing a healthy team spirit and so on.

Teams also need to adapt to an ever changing situation: a new sponsor arrives, team members leave and others join, the product vision shifts, the team learns about new ways of working together, and while the product matures new skills are needed along the way.

Do – Feedback – Learn

The agile inspect and adapt principle is a great 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. By the way, before a team should do the learning, getting feedback to the result is crucial.

A cart with square wheels

Even though teams implement inspect and adapt, they stil tend to stick to a mediocre mode of working. Here are some typical patterns:

• Work as before: Team members set the initial structure up as they can envision it. Namely, they create an generally acceptable mix of how they worked before and stick to this.
• Focus on 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. Improvements needing some iteration easily drag along for three or four iterations. For two weeks sprints, that would be two month 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.
• Subjective self-assessment: There is no obvious best way of working together. Teams usually rely on subjective self-assessment only. Thusly, even ineffective modes of collaboration are acceptable.

Seeing such patterns may explain quite a few observations from day to day team work.

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.

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

Design processes for collaboration

The more the team members commit to the story, the conceptual solution and the fundamentals of working together, the easier it is to collaborate and to split up work. 

It is also an interesting observation, that the more intensive the collaboration between team members becomes, the more the team members align their commitment. On the other hand, the more team members split up work, the more divergent it gets.

Combining these thoughts leads to the conclusion, that the more fundamental the decision, the more intensive team members need to be involved in the decision process.

Thus it is probably a good idea to:

• start with known patterns of how to work together: e.g. Scrum, SAFe, XP,  or any other good practice in your context.
• work closer together as a team whenever big changes need to be absorbed so the team can quickly do the change.
• split up work, once the team has become proficient so the team can deliver more.
• run a speed creation workshop or similar whenever you start a real big chunk of work. This allows the whole team to agree on the fundamentals of what to achieve by when and how to organize themselves as a team.
• use a team wall, even for individual work, so that whatever conceptual work is done becomes visible for the whole team.
• 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 particpants 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.
• let team members discuss their decisions and designs with others, thus implement some good practices like code reviews, dev exchanges etc.

Non-linear investment into teams

Investment into a team is thus not a linear thing. 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 team members need to focus more on adapting to a new situation.
• add some reserve for future team changes. The velocity measured during stable team phases will be too high.

Focused interventions for change

Team membes usually form their position within the team based on their abilities and preferences. A bigger change in the team usually results in a significant personal change, also in regards to skills and attitude.

Take for example a situation where software team realizes that they are underperforming in regards to delivering quality software. The simple fix where one person in the team works out a solution, tells the others and done, does usually not work very well. Some team members might need to change their attitude towards testing, other team members might lack the skills to design quality code that can be easily tested, 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 so at least a few team members can get a hands-on experience of the value and the costs.
• do a short (one or two days?) 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.

Challenge the team

Team members usually get little acclamation for creating a great team. Praise and blame are given for the results. Of couse 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.

Looking closer a few things stand out: 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 problably a good idea to 

• get ouside 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 praciticioners 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 organisation 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, Learing to collaborate well needs time! It seems that an organisation needs long-term investment into team work and structures that allow spreading new and better ways of working through the organisation.