T-shaped skills and diversity appreciation

Scrum Teams have a privilege to be cross-functional and self-organizing. These traits are proudly manifested by such teams. However, this becomes more complicated when it comes to implementation. One challenge it to get approval and empowerment from organization to act as a real Scrum Team. The second is Scrum Teams believing and determination in behaving accordingly to their agreements. Teams are build from people with unique talents and different preferences. Ultimately, the team has to be solid and consistent in its activities and results. The internal teams diversity and external consistency gives an opportunity to create innovations, and creates a challenge too.

People and roles

Let’s assume we’re building a team now. Should we look for people matching certain roles or create roles basing on people abilities? The Scrum GuideTM[1] says about the Developer role. We do not have to necessarily hire QA engineer or Junior Software Engineer only because there is a free headcount for such roles. However, we do it often this way following predefined jobs structure and free headcounts. Again, Scrum says there is the Developer role among Product Owner and Scrum Master. Companies tend to have a rigid jobs and positions structure. The structure may not be compatible with teams composition following frameworks like e.g. Scrum. In result people are hired for concrete positions. In Scrum, the whole Scrum Team is expected to deliver certain results. There is no responsibilities for one exact person. Ideal empowered Scrum Team is able to plan tasks and distribute them in the Team in order to fulfill business or technical requirements. In the Agile Project Management[2], Jim Highsmith encourages to create roles open for people with useful and unique skills. In the book[2], in Chapter 6 – The Envision Phase we can find:

Although role boundaries are important, in practice a role should be flexible, adapting to the specific person who fills it.

Roles are finite. People are infinite.

Trying to force people into a fixed role description is not only ultimately impossible, it is counter to agile principles.

People are not only more important than process, they are more important than roles.

In best case, role should be created for people with extra skills. When looking for people for a well defined role, we can find them, indeed. Unfortunately, only small part of their abilities can be a full set of the role’s requirements. The rest of their talents becomes unused.

T-shaped individualists

The Development team is created by Developers. Developer is considered here accordingly to definition from The Scrum GuideTM[1]. He or she is the Scrum Team member who develops a value. This is a position of software developer, information developer, software architect, QA specialist or someone else. In my eyes software development industry is changing not only in technologies and business models but also in defining positions and roles. The position definitions may vary from company to company. Position of a pure programmer translating prepared algorithms and analysis into code is fading out. Developer job is getting more and more popular position. Developer role has a broader meaning than programmer. Developer with an ability to understand (or even define) complex domain requirements and ability to translate the domain into technical solution is a very creative and intensive job. People practicing these activities are not average. They are interested in complex business domain and complex technical solutions. Strong, unique skills originate very often from individualists, in software development it happens too.

Smart and ambitious companies attract smart and ambitious Developers. Even though smart Developers are able to be good in various areas, they stay as experts in selected fields and undertake tasks they prefer. Edge cases are usually not preferred. Developers extremely focused on one area may become silos. On the other side, Developers with no expertise may become too average and not be able to complete independently their work. Teams internal diversity is recommended. In the Jurgen Appelo’s book – Management 3.0[3], in Chapter 4 – The information-innovation system we can read:

Diversity in a complex system is important because the many benefits far outweigh the costs.

Scientists have found that diversity can stabilize a system and make it resilient to environmental changes.

It increases flexibility and feeds innovation.

Diversity also means that in complex system, you cannot use averages.

They recognized that diversity is a good way to stimulate innovation and the ability to find solutions to problems.

The sentences confirm that Development Teams should not be internally unified. Unique personalities, talents and skills are strongly desired. These individuals have to finally integrate their forces to create a consistent result. People in the Development Team have to be aware of activities undertaken by other members. They also have to be able to do things other than they prefer to do. Those auxiliary skills are called T-shaped.

According to Wikipedia, T-shaped skills are:

The concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one’s own [4].


There are two main objectives taken into consideration in this publication: T-shaped skills and diversity appreciation. The first supports mutual understanding and fluent teams work. The latter boosts individuals in pursuance of their capabilities. Roles should be created to people when only possible. It basically gives an opportunity to activate people talents. Complex software is developed in nonlinear process. Individual skills combined with T-shaped skills allow Development Teams building innovative products.


[1] http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
[2] http://jimhighsmith.com/books/
[3] https://management30.com/product/management30
[4] https://en.wikipedia.org/wiki/T-shaped_skills

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>