The 12 enemies of adaptability
And weapons to kill them…. Enemy 9: Lack of diversity
Marty de Jonge
In “ the 12 enemies of adaptability” series different angles that influence adaptability within organisations are discussed. All articles have this theme but can be read on their own.
One of the main reason for organisations to start a transformation is to (re)structure the organisation in order to improve their ability to respond to a fast changing environment.
Only, to be a smooth adaptable organisation in the world around you, first you’ll have to make sure you have an internal environment that is supporting this objective. In this series of articles I will describe 12 enemies of internal adaptability. Kill these inside enemies and you will smoothen the way to reach your objective towards the external adaptability as an organization.Enemy number 9. Lack of diversity
White House Internship program under Trump. A good illustration of his vision on the value of diversity.
Management systems that prefer conformity and cohesion at the expense of diversity and divergence, limit the ability to generate the rich variety of ideas and opinions that are necessary to have real adaptability and achieve change.
We all immediately have an unconscious opinion about another when we meet him/her first time. In fact, this intuition is very old. Something that even seems to be recorded in our DNA and originating from our distant distant ancestors who travelled into the wide world out of the horn of Africa some 60,000 years ago.
Those of them who could decide in a split second whether someone belonged “to us” or “to the other” had a strong evolutionary advantage and survived. In contrast to our ancestors that had to think about it a bit longer and received a blow on their heads before they made up their minds…
Very useful back then and we should be thankful they had those qualities, otherwise, you and I would not have been here to read this.
We no longer have to compete with each other to have the best and fattest part of the bison to feed our children. Yet that urge is still with us. That’s one of the reasons some managers instinctively tend to select people who are like themselves and thereby gain one-sidedness.
The danger of this lack of versatility and having only “jay” sayers around you is that when solving problems or answering issues, they will mainly look at ways that are known or will be appreciated by the managers. With this you not only limit your chances of finding the best solutions but with this, you also limit the adaptability of the organisation. The best solutions are often found at the heart of a discussion.
Identical twin guys hitched identical twin gals
How to kill ‘lack of diversity’?
Diversity can be fun, and working with people from other cultures or backgrounds is very interesting. Many people find it fascinating to work abroad and to travel for work or pleasure to explore other cultures. To bring diversity to your team and you bring the world into your team.
With this, I acknowledge you also bring some new challenges in your team since multi-cultural, multi-gender, multi-skilled, e.g. team compositions all bring their own dynamics. However, when approached with the Scrum values of Courage, Focus, Commitment, Respect and Openness in mind these only more deepen the mutual understanding and value for this diversity.
To make organizations function better and to have more fun with each other, you need good leaders to shape that process. People who understand the differences between people, who know where those differences come from and how to gain benefit from it.
although the founding fathers of the Scrum Guide probably did not do that with the intent to solve the worldwide gender and racial differences when they wrote the first version in 2010*, they did provide us with some guidelines to give substance to the value of diversity within teams.
Development Teams have the following characteristics:
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Scrum Guide 2017 — part of the Development team characteristics
by emphasizing that maximum value is achieved by bringing different knowledge areas together that were separated in traditional organizations, they have unintentionally contributed to the increase of diversity in teams.
In recent years I have seen that, especially in IT / software projects, these changes have become increasingly visible. Where this used to be primarily an environment of white men, you see that this is changing step by step.
- More and more often I see female Scrum Masters, developers or coaches in the workplace. I have experienced that having more women in these projects provides such great value that I can hardly imagine how we have been able to do it all this time without their insights and skills.
- By bringing both front-end and back-end activities together in 1 team, I see, for example, that activities that are traditionally done by an offshore party in India also become part of the team’s scope. This increases cultural diversity.
- Because knowledge areas such as marketing communication or UX design are increasingly part of, among other things, design sprints, insights and contributions are included in the scope even before the start of a project that was never previously part of IT / software deliveries.
The Scrum Guide nowhere mentions the terms ‘component teams’ or ‘feature teams’ those are terms from the LeSS framework. However,
Ken Schwaber and Jeff Sutherland have laid the foundation for this with their work.
What are the differences between component and feature teams?
Feature teams are multidisciplinary teams that have all the skills needed to deliver complete functionalities on all layers of the architecture. This is in contrast to component teams that specialize in one particular technical skill such as developing for iPhone, or an architecture layer such as a middleware solution.
To explain it with a recognisable example; if you go to McDonald’s and buy a complete product like a Big Mac, that would be the complete product.
Components of that complete product are:
- Cheddar cheese
Features are the bites you take, parts of the complete working product. What tastes better? Eating your burger component by component of eating it feature by feature?
By bringing different knowledge areas together and working on T shaping you ensure that cross-functional working provides mutual understanding. Not only does this make work much more interesting for many members of a team.
People also feel more that the result delivered is a joint presentation and being more multi-skilled makes teams much better equipped to respond to changes. A win-win outcome for both the people who work in your organization and for the organization as a whole
Marty de Jonge
As an agnostic change agent, I am constantly amazed at what happens in organizations and learn every day. Enthusiastic writer and always open for discussion.