As Harold F. Dodge said:

You can not inspect quality into a product.

He meant that the system should be designed to produce a quality product.

This article is about team design: principles of team construction that will allow the team to produce a quality product.

We know what ‘product’ is: an information system allowing the client to do something.

Are you aware of the team & process design aspects which influence the quality of the product your team builds?

Let’s dig in and start with the definitions.

What is quality?

Two standards are defining the quality:

General one (for products) — ISO 9000:

quality degree to which a set of inherent characteristics fulfils requirements

And the one talking specifically about the software quality — ISO 25000:

software quality — capability of software product to satisfy stated and implied needs when used under specified conditions

Both talk about a "match" between what the client desired and what's present (produced).

We want to produce exactly what's needed or wanted, so the match is "maximised", i.e., the quality is at its highest.

A few areas of problems related to quality might occur when you create a team.

Information loss in conversion

The idea or desire can never be fully expressed: idea-to-language transformation yields information loss. Consider it similar to digital -> analogue transformation.

Then the idea (transformed to language) during the perceiving process will have even more information lost; consider this analogue -> digital transformation.

The reason for the loss is simple:

• the language itself is ambiguous
• the language can only provide us with a symbolic representation of the meaning
• the symbol is perceived differently, so the meaning is not constant but temporally, contextually, and individually bound

The picture above illustrates the ambiguity of the symbolic system caused by the interpeters’ different perspectives (viewpoints).

There are two areas of science studying this particular set of problems: Semiotics and Semantics.

Very simply put, "chess" can be describing "the board of chess" or "the game of chess", "green" can't be explained to a blind person, "salty" can be perceived differently not only by different people but by the same person at different times.

Broken telephone experiment illustrates how the information loss is increased: the more links in the information flow chain we have, the more times the information undergoes perceiving/verbalising transformation, the more information loss we have.

1. The less links in the information processing chain, higher the quality.

This principle has four implications:

• teams should be sitting closer to the client
• teams should be as small as possible
• teams should be crossfunctional (no silos)
• teams members’ knowledge should overlap

1.1 Team should be sitting closer to the client

The client is the source of information, the closer the team sits with the client, the better the quality is: simply less information loss. Ideally, the client representative should sit right with the team.

Also, if the client representative sits with the team, the team can show the interim results more often and get more feedback.

This is very important simply because the client might not even fully understand the need, or the first way their desire is implemented might not be satisfactory for the client. The shorter the feedback cycle, the less unnecessary work is performed.

1.2 Team should be as small as possible

If just one engineer is helping the client to achieve what they need, the information loss is minimal — there are just two links in the chain: client -> engineer.

If the information follows the client->business analyst->architect->system analyst->engineer->QA flow, there are six links, six times the conversion is done, the information is lost significantly.

There are only two ways to overcome the inherent information loss: specify everything in more detail or reduce the number of links in the chain.

Specifying everything in more detail requires time, which is of essential value (the world changes too quickly). The whole Agile movement started with the goal of delivering clients what they wanted but faster and better.

Studies prove that the smaller the team is, the higher the quality.

One should also note that the more developers the team comprise, the higher the chance of ‘ownership blurring’ where individuals see less obvious results from their efforts.

This might result in people losing motivation or having ‘this can be done by someone else’ attitude.

Managers should ask themselves: what is the bare minimum of people required to produce what the client wants?

Is it possible to produce the software product with just 1 employee talking directly to the client (or their representative)? If not, can we get away with 2? Or 3?

1.3 Team should be cross-functional (no silos)

Social psychology has multiple studies on a concept called In-group favoritism:

the tendency to respond more positively to people from our ingroups than we do to people from outgroups.

Minimal group paradigm describes:

Experiments using this approach have revealed that even arbitrary distinctions between groups, such as preferences for certain paintings, or the color of their shirts, can trigger a tendency to favor one's own group at the expense of others, even when it means sacrificing in-group gain

Basically, people easily form groups and instantly start prejudice against the outgroup members or even discriminate against them.

As shown, the reason for the separation might be as insignificant as the colour of the shirt.The reason for this, as studies say, is:

Because our ancestors lived in small social groups that were frequently in conflict with other groups, it was evolutionarily functional for them to view members of other groups as different and potentially dangerous. Differentiating between “us” and “them” probably helped keep us safe and free from disease, and as a result, the human brain became very efficient in making these distinctions

Knowing this particular social dynamic that people have in groups, it seems evident that there’s no place for separating teams based on specialisation.

That’s exactly why the concept of an interdisciplinary (or cross-functional) team was created.

The cross-functional team comprises a number of people of all specialisations required to deliver value to the client.

Do not separate team members working on a product into sub-teams based on specialisation, and you won’t get negative social dynamics of intergroup discrimination or prejudice.

1.4 Team members’ knowledge should overlap

When your team comprises people specalising only in a very narrow field of expertise, each act of communication will require additional ‘bridging’ efforts to overcome the information loss.

Generally speaking, if your iOS developer understands backend development, their communication will be easier.

This is one of the reasons for such concepts as T-shape, Devops and TestOps emerged.

To summarise the outcomes of the ‘less links’ principle:

• get a client (or their representative) right in the team
• figure out what minimal amount of people with what specialisations your team needs
• don’t separate specialists into sub-teams, have them focused on delivering what the client needs
• make sure their knowledge overlaps

This will reduce the information loss and therefore reduce ‘waste’:

Waste is any activity that produces no value for the customer or user. This depends on the product you’re building.

In the following article, I will cover the concept of quality loss due to system design peculiarities.