There is a lot of empirical knowledge available regarding teams, according to their proper working setup.
Scientific proof is a lot less available. So, I concentrate on what is experienced as working. By me and by others.

When do You need a Team?

First things first.

It is sufficient and indeed efficient, when You are working on complicated things with a group of people. You do that – instinctively or intuitively? You deal with it by sharing tasks and divide them into domains of responsibility. That works fine and made several organizations really big the last 100 years.

But there are moments in life, You face “the real Uncertain”. It is not a lack of personal knowledge or lacking ability. It is the bare Uncertainty of what others need and therefore might request.

You can solve it by asking them one after the other – see complicacy.
But there is the point, where You experience, the request of one will have an impact on the request of the others, You interviewed before. Now, You get an idea of complexity.

You need to identify all of the probably affected people, units or customer groups.
Now, You have Your bunch of stakeholders.
The good way would be, to interview them together in front of the people that are willing to create solutions addressing all aspects of the solution requests and their impacts.

You need a complex problem solving system. You need a Team!

Do not mess around with words!

So, where is the difference between a group of people and a team?

In sports, people acting together, are often called a team. But there is a difference.
Imagine an eight oars with a coxswain (rowing).
What You need are eight people of relatively the same physics (strength!) and one lightweight person to steer the boat and a fine feeling of interacting to get the stroke.
The grade of alignment defines their success. Their internal rhythm converts their combined strength into speed. Overall, that is an only complicated system – stupid.

There are other sports, where the team setup is a lot more diverse and therefore difficult. Remember rugby and imagine why the software development approach is called “Scrum”.

Or imagine American Football. There You have two complete different teams (“defense” and “offence”) for different situations of the game. Setting them up and using them tactically suiting is a matter of complexity, because the opponent will react and re-impact on You.

Thanks to Stephan Schwab, I got a deeper understanding of the difference between a group of people working together and a real team.

But now, let us begin with solving complex tasks with a complex problem solving system: a team.

Setup

For creating a team, You can use the power of auto-selection or You can specify by (external) definition.

From my experience, auto-selection (“who wants to be in this?”) works fine, if You can communicate the matter, the aim/s, intended benefits and the value originating from it. That generates attraction for “the right”.

Normal case instead is, someone (1 person) declares people (the “others”) to work with each other. Works also, but second-best.

The hardest fact of all: 7 +/- 2

You can watch people interacting. The switch from 4 to 5 makes a major step.
It is like magic. Regardless of the specific person, the change from 4 to 5 and back is as You switching a light on and off.

Why 9? When You add another person to a group of 9, they will split up into 2 groups of 5.

Best group size is between 5 to 7.

But be careful. If You have a team with 5 people in it and one is ill one day, the light keeps dark.

Odd numbers work better than even numbers. Do not ask me why – accept the fact.

Q-factor

There are some properties in people that need to be shared like believing in specific values. Which they are is mostly self-chosen. But beyond that, they can be kind of negotiated in ranking and documented in a team charta.

The Q-factor defines the bandwidth Your group can oscillate around the problem.

Diversity of Equals

You need diversity for proper working teams. This diversity defines the curve-length Your system can resonate to a specific situation.

Having people of the same kind, keeps the group weak and their outcome far under average. You will hardly experience them working as a team. It is because of they are just homogeneous. They think the same, act the same and therefore make all the same mistakes without even noticing.

On the other hand, too much diversity is harmful, either. If the members of the group do not share anything, there is no base of communication, no base to interact on.

If You need a team to start something “completely new” it is better to have more in common. 60%+ in common, 30%+ in diverse
– or even more simple: oscillating between 2/5 and 3/5 around the determined core of the task.

Which parameter You chose and measure is up to You and dependent of the task You have to solve. That might be language, gender, job experience, personal maturity, education, personality and certain skills.

If Your core product gets stable, it is time to extend. Then, it can be a good idea, to change the team to a 30/60 pattern in the end.

Limits are at 20/80. Remember V. Pareto …

Team assessment by the Riemann-Thomann-model

Sometimes, there are deviations in what someone is, someone wants to be seen and others experiencing that person.

One good tool to work that out is the Riemann-Thomann model of personality.
Done honestly, it is a great tool to gather insights on members and the team itself.

You can use it pro-actively to determine diversity You look for.
You can also get insights on how and maybe why people apply to specific tasks.

In an advanced level, You can use it to get the team diversity You aim for – in advance.

Start-up

Now, everybody is keen on starting. Time is ticking …

Do not let them work!

In the beginning, You find a group of people. What You aim for is a team!
There is a major difference in that.

You have to build the team first.
If You think You can step over and making savings by immediately starting with the intended work, You will pay a multiple in future.

That is because of complexity. Things will interact exponentially on each other.
Small problems unsolved will let Your project explode … later.

You need to build the team first

Best way to build a team is letting them do something completely different.
Like playing games.

If You ignore that, You find their first outcomes to be rubbish. Remember why.
If You want it fast – go slow.

They need to find out for their setup, who is leader and who follows.

First, the team has to find out who is right. Afterwards, this person/s grant rights.
Remember Mr. Alpha and Ms. Alpha 🙂

Tune-up

You need around three iterations (aka “Sprints”) to get in the swing. The more Uncertainty there is, the shorter Your iterations should be.

Two weeks are most common in environments experienced by me. But there is no rule except “no longer than one month“.

The more certainty and familiarity the team gains, the more You can reduce meeting overhead.

The retrospectives are the best chance to tweak upon the team.

Love it, change it, leave it

There are lots of tools to make retrospectives working great.

One of the most powerful set of “questions” I learned from Alexander Krause.

I love/like  ________________

I learned    ________________

I wish        ________________

… that’s all.

But there are situations where people are attracted by another challenge even more.
Or, the current setup does not fit the environment anymore.

The product gets mature and needs different solution impacts.
Or, the team is weak, because one is too strong.

Then, it is time to change the setup … someone needs to go.

Yoghurt-principle

If You start working with complex solution systems, aka “Team”, You might wish to scale.

It is very hard to start on the greenfield.
There might be some ideas, but very small experience about what a team really is.

You can read books or blogposts like this. But it is always condensed knowledge.
What You need is ability, shared and handed over by the more experienced.
Good news: You can buy that in – just search and ask.

Once, You have a team of 5 or more people that have an emotional anchor, a feeling, how agile team work is like, You can utilize it to spread that feeling within an organization or by scaling up a project.

But be careful! The secret is the right volume of ingredients in relation to each other.

If You place one experienced team-fellow in another group of 4 unexperieced senior, alpha, group workers, they will kill the bacterium.

If You place one newbie in a working team, that can be a hard time for the youngster to keep up.

Dividing in the half is a good idea, working well.
Nobody is alone and that stabilizes the complete group.

Attention!
The group has to team again. 
Return to ../setup and >start from the beginning. 

Do not forget starting with something completely different.

Lifecycle

You need a complexity solving system as long as You deal with complexity.
Remember, the real Uncertain …

As Your project matures and Your product gets more and more stable, complexity will be reduced and replaced by encapsulated complicacy.

That might be “units” or “services” or other domains that are linked by interfaces.
These interfaces expect defined input and put out value
(parameters, conditions, answers etc.)

In this maturity stage, it could be a good idea to change Your approach from Scrum to Scrumban.

The orchestration of these encapsulated complicacy might end up in a process or a product or a provided service that needs to be operated.

The good thing is, that encapsulated complicacy has a defined status quo against a current status can be proven.

If it deviates, the status quo ought to be restored.
… as long as this encapsulation is valid by producing benefits in use.
Operating complicacy is well done using Kanban.

The sad thing is, the justification for using a real team fades away and ends completely as the project result is handed over “to the line”.

Now, the team member can follow their project result into the line and fade away in a group of co-workers.

Or, the organization utilizes the benefits of having experienced team-workers, confronting them with a completely different complex problem to solve.

/etc

Here You find additional tools which generate some benefit for You as they did for me.

The Tree of High Performance

Same idea, different presentation.

“Everyday Agile”

I developed two games to work out, what is the essence of acting as a team. First game is “Everyday Agile“.

This game generates Teambuilding in fast motion.
You need only one hour of time to build up a team or to gain insights why this group will not work as a team.
Currently, only available in German and in English, if You need. Just ask.

“Watch Your Wingman!”

This game is for the more advanced team workers. It lets people experience common patterns and anti-patterns of co-working by solving riddles, guided by questions, embraced in fun-stories from animal kingdom.

As I learned from “Everyday Agile”, I now started in English. You can request it in German, also. Just ask.

Currently it is late Beta-state. As soon as I have permission to use certain pictures and got an idea, how to produce the story cards, I tend to publish it as a commercial product.

Meanwhile, just ask if You are interested.

Famous last words

My intention writing this, was to have a reference, someone (me in the first row) can refer to.

It is also intented to attract the interested.
So, if You are one of these, please contact, i.e. by commenting or just “Like”.

Feel free to make Your life great!

Enjoy, and share if You like …