Veröffentlicht am

How Culture Influences Your Agile Change Effort

culture and agile teamwork

“Culture eats strategy for breakfast”

Although Peter Drucker never said this, many people still are convinced that culture does at least influence change and decision making within a company. How strongly is highly debated. As the effort we put into agility is all about facilitating change to improve outcomes for a company, it is important to deal with culture to be able to influence an organization.

If you look at the totality of all companies, you can observe many individual cultural phenomena. Since corporate culture was made the subject of research in the early 1970s, attempts have been made to systematically survey and categorize the factors that make up corporate culture.

The Competing Values Framework as a Model to Evaluate Culture

The “Competing Values Framework”1 formalized by Cameron and Quinn is one model that can help us to assess the culture that is dominant in our company. It can help us to understand, why applying Agile principles might be hard in our context and can so help us to derive measures to increase the chance to implement an Agile approach.

Let us consider the following image representing the frameworks basic components:

One thing I like about the framework is, that it does not put a company in only one bucket (quadrant). Instead it admits that every company will embody the culture mentioned in all four quadrants to a certain degree, although it might lean towards one or two quadrants more specifically.

I am discussing this framework and the impact of culture in greater depth in my upcoming book “Disillusioned by Agile? From Pain to Progress: Diagnose and Alleviate Agile Dysfunction – A Handbook For Practitioners*.

Let us briefly discuss how each culture type influences the implementation of Agile practices. This should help us practitioners to adapt our approach, as we try to introduce Agile ways into our context.

Hierarchical Culture

It is historically the oldest of the promoted corporate cultures. With the dawn of the industrial age (around 1900), German sociologist Max Weber observed companies and businesses in Europe and in 1947 recorded the attributes that what was then considered to be the ideal industrial company should have in order to operate as efficiently as possible. He proposed seven characteristics to which every company should aspire:

  • Rules
  • Specialization
  • Meritocracy
  • Hierarchy
  • Separated authority
  • Impersonal relationships
  • Accountability

This culture proved to be extremely successful in producing products of predictable quality in large quantities efficiently, reliably, and quickly. A high degree of uniformity and standardization in processes and procedures was intended to ensure that large numbers of workers could always produce the same goods according to clearly defined rules.

Characteristics of Hierarchical Culture

The hierarchical culture is characterized – as the name suggests – by a hierarchical structure. Responsibility increases with height in position within the corporate pyramid. Rules, guidelines and control are set from the top down. The goal of most employees is to work their way up within the hierarchy through merit.

The following values are important within this culture:

  • Efficiency
  • Obedience
  • Accuracy (in the execution of processes)
  • Consistency
  • Uniformity
  • Reliability
  • Precision (in doing the work)

Relationship to Agility

Agility is in clear contrast to the hierarchy culture, because it is not efficiency that agile teams propagate, but effectiveness in dealing with complex problems that are different and challenging from project to project and from iteration to iteration.

There are definitely values that both cultures have in common, but on different levels. Accuracy and uniformity are emphasized within agile teams, but at the micro level (e.g., in program code), not in following ordered development processes. Thus, great emphasis is also placed on a common language when formulating requirements (e.g., in user stories) and on the consistency of associated acceptance tests. However, agile approaches encourage creative problem solving and do not dictate what practices teams must live by. If a team finds a better way to meet the requirements, it is allowed to change the way it works in the interest of achieving the goals. Yes, it is usually given the opportunity to actively share its experience with other teams.

What about Efficiency?

Efficiency is found at the micro level in agile teams: for example, as far as possible, all simple, recurring processes that are not of a creative nature (or that could also be performed by a machine) are automated. Also, options are always examined as to what could still be automated in the future or where more human interaction is needed and rather less automation is required (e.g. when verifying releases together with the customer).

Hierarchical culture often hinders collaboration in teams that want to become agile, e.g., when decision paths are unnecessarily long or rules are defined that are valid throughout the organization, but which stand in the way of a results-oriented approach. Such conditions lead to teams that nevertheless try to proceed according to agile principles appearing to the outside world (the rest of the organization) as a normal business unit.

Covering Up Is Overhead

To be able to maintain such an image these teams they deliver all the required project documents at the interface with other teams, without deriving any internal benefit from this. This adds overhead for them that doesn’t always provide demonstrable benefit to the project and usually slows down the team’s productivity.

This also means that agile teams in such a culture may often act contrary to existing conventions. They may therefore also run into problems as they are seen as non-conformists. An example of this is when they try to keep the customer heavily involved throughout the duration of the project and even encourage them to question or even revise the requirements agreed six months ago.

Dangers for Agility

If the hierarchical culture is so strong that it acts like a corset that confines each team as a result of strict control mechanisms, this may lead to any advances to adopt an agile approach getting stuck in the early stages.

If the documentation to be produced is too voluminous and the team is primarily occupied with editing concepts and endless meetings just to satisfy some process template, then it will struggle to deliver production-ready software frequently, which contradicts one of the fundamental principles of the Agile Manifesto.

Long delays waiting for decisions to be made by someone higher up in the hierarchy, such as the architect, place a burden on the Agile team. Delays can also occur when, on the customer’s side, a question about a particular requirement is first passed up the hierarchy and only after many detours finds its way to the correct person, who is able to answer the question competently. On the part of the agile team, this leads to partially completed work that must be additionally monitored and represents a debt that can weigh heavily in the later course of the project. Many loose threads are only hesitantly woven into a tapestry that could provide an accurate picture of the current state of development. This makes it very difficult to determine where things stand within a project.

We can say that a hierarchy culture influences mostly negatively your Agile change effort.

Market Culture

With increasing competition (including international competition) in the 1960s, there was a call for a more dynamic alternative to the hierarchical structure of companies. It became increasingly important to maintain business relationships. Goods were exchanged across national borders. Competition – even for national companies – was increasing. Customers were no longer satisfied with a simple basic product, but were increasingly demanding.

Companies suddenly had to be much more outward-looking, and customer orientation became the mantra of the business world. This also had an impact on the companies themselves.

Profitability, results, and ever-higher productivity targets are of paramount importance here. A clear common goal and an aggressive strategy serve as drivers for effective work.

Characteristics of Market Culture

A market culture is results-oriented. Projects are judged on their marketing potential and unsuccessful projects are terminated abruptly before the damage becomes too great. There is also usually strong competition within the company when different business units are compared with each other.

This is usually done using typical key market figures, sales figures, profitability calculations and profit opportunities. This climate reveals that in this culture, the following characteristics are promoted above all:

  • Determination
  • Toughness
  • Demanding climate
  • Competition
  • Profit orientation
  • Polarization (“We are the good guys, the outside world (competition) is the enemy.”)
  • Cleverness
  • Customer orientation

Relationship to Agility

Agile is often welcomed in a market-oriented culture. This is because it promises to deliver in an uncomplicated way the features that the market, i.e. the customer, is most likely to need. Even short-term changes in the priority of requirements do not pose any problems for agile teams. Short iteration cycles enable them to quickly adapt the focus to the customer’s current needs.

Constant optimization of the approach is also generally welcomed as long as it meets the goals of the market-oriented organization. I.e., as long as it increases profitability, reduces costs, or even makes it possible to bring innovations to market faster and thus represents a competitive advantage.

Certain aspects of the agile approach, on the other hand, meet with less favor in this type of organization. For example, in some market-oriented companies (especially in the fast-paced Internet environment), iteration cycles are still too long. Rapid response to market opportunities as they arise and short-term profit-seeking cause some companies to constantly shift priorities so that they are sometimes not even constant for the duration of an iteration.

Dangers for Agility

Employees may be burdened with additional tasks (e.g., supporting marketing activities) that are topical at that moment and may no longer be able to focus exclusively on the goals agreed upon at the beginning of the iteration. This may result in delaying the delivery of features that have been tested and are ready for production.

Another danger is that the focus on achieving market goals and wins in the short term can lead to undermining the agile movement’s emphasis on integrated quality. The agile team might be accused of focusing too much on it and not delivering a sufficient number of marketable features.

When Heroes Become Competitors

The emphasis on and “hero-ization” of “doers” can also lead to unhealthy competition within the team. Teams tend not to work closely together. Instead they consist of a bunch of lone wolves who are primarily concerned with individual advancement and their own careers. This instead of a common goal that everyone contributes to achieving or – in the case of failure – everyone is held accountable for.

If the competition between several teams is fueled, this can lead them to spur each other on to top performance – freely following the credo of the free market economy. But it can also easily lead for the company as a whole to have teams start working against each other in order to be favored in management’s favor. This can undermine the principle of close collaboration.

A market culture influences your Agile change effort in significantly, as it has a strong customer focus and prefers short cycles.

Clan Culture

In the late 1960s and 1970s, researchers increasingly looked at Japanese companies and found that, unlike American and European companies, a very different spirit prevailed there. They observed a clan-like structure, almost as if the companies were family businesses.

Companies with a clan culture are characterized by an atmosphere of shared values and goals. Individuals are encouraged and organizational cohesion is one of the most important features.

Unsurprisingly, a clan culture views its customers as partners. It makes every effort to provide its own employees with a work environment in which they can collaborate productively and in which they can actively participate. Loyalty to the company is strongly encouraged.

Characteristics of Clan Culture

The typical characteristics of a clan culture can be summarized as follows:

  • Friendly
  • Supportive
  • Cooperative
  • Loyal
  • Participatory
  • Harmonious
  • Human

The role of a manager in a company with this culture is that of a mentor. He or she is concerned with creating the most ideal working environment possible for employees to collaborate productively. He leads not by rules or regulations, but by instilling shared values and goals.

In a clan culture, collaboration, sharing, and caring are not empty words; they are evident in the close bonds that connect employees – sometimes even personally.

As such Clan culture tends to look inward and wants to closely integrate outsiders into its own structures. As such it is quite supportive of an Agile change effort. It influences the choice of strong teams that are cooperating frequently.

Relationship to Agility

Clan culture exhibits many attributes and usually promotes values similar to those favored and promoted by agile teams. The emphasis on a partnership-based relationship within the team and the organization, which sometimes even extends to the customer, leads to close collaboration where everyone pulls together.

It’s no surprise, then, that advocates of agile approaches borrow heavily from Japanese management and philosophy. Just think of the pronounced affinity to the principles of the “Toyota Production System”.

Just as many operations in 1970s industry looked east and admired Japan’s technological boom, many proponents of the agile movement have taken ideas from Far Eastern approaches and applied them to the discipline of software development.

This resulted in techniques and practices such as “Value Stream Mapping”2, “Kanban”3, “Just-in-Time Production”4, “Built-in Quality”5, and “Sashimi”6 that found their way into software development – in modified form, of course.

Promoting individual competence instead of imposing rigid rules, participating in decisions instead of a top-down commanded approach, are all qualities of the Clan culture that also accommodate the agile approach.

Dangers for Agility

The Clan culture is closest to the agile way of working together and agile approaches thrive in such an environment. Nevertheless, the strong need for harmony can sometimes get in the way of the agile team. Agile teams thrive on the fact that problems and obstacles in the course of a project are first made visible, “brought to light”, so that they can subsequently be cleared out of the way.

Now, if the problems are personal, then it can happen that in the interest of harmony, problems might be swept under the rug and therefore continue to get in the way. This means that the need for harmony and loyalty must have a counterpart in openness and goal orientation so that it does not become a danger.

Ad-hoc Culture

In connection with the increasing fast pace and globalization of markets and the ever shorter product life cycles (let’s just think of the Internet era), a new type of culture has emerged in recent years. Let us call this type the ad-hoc culture. In this type of culture, contacts in companies are very dynamic and limited in time. The aim is to launch an innovative product on the market within the shortest possible time. This to open up new markets quickly, and to achieve and, if possible, maintain a position at the top of the industry through constant further development.

Consequently individuality and innovation are emphasized in this culture. Responsibility is distributed across all employees and not centrally coordinated. Creative chaos prevails. Ideas are generated and discarded. Everyone shares almost all roles: from conception to development to marketing of a product.

Characteristics of Ad-hoc Culture

What characteristics are upheld in an ad-hoc culture? It is driven by the market as much as the market culture. But the focus is primarily on creating new markets, occupy market niches, and possibly move on just as quickly to “greener pastures.”

The characteristics that make up this type of culture are:

  • Innovative
  • Fast
  • Temporary
  • Short-lived
  • Creative
  • Inventive
  • Dynamic
  • Flexible
  • Adaptable
  • Organized Anarchy

Employees in such a culture take risks and dare to do new things. They push ideas forward and try to inspire like-minded people to do the same. Any way to achieve the goal is fine, as long as it generates a new, innovative product.

Teams merge as quickly as they disband. Since each employee is considered an entrepreneur, there is an expectation of great autonomy and self-reliance for the individual.

Relationship to Agility

The ad-hoc culture emphasizes agility and sometimes even assumes it in its employees and teams. It sometimes even strains agility to the extent that it threatens to slide into chaos. Creative solutions to problems are allowed to come from all corners of the company. There are very few rules. The agile approach principle of doing what works and leaving what gets in the way is encouraged.

Employees in a company that emulates an ad-hoc culture are often generalists. They are capable of stepping into many roles, depending on the shortcoming at the time. Even when employees are highly specialized, they are willing to work closely with specialists in another field to dream up new, creative and sometimes even surprising solutions and products.

The straightforward nature of agile approaches is appreciated. This is because it propagates little administrative ceremony and places goal achievement ahead of adherence to precise procedures.

Also valued is the ability to adjust iteration cycles according to project needs. Short, intensive or high-risk projects can work very well with one-week cycles. If projects are of a different nature, there is nothing to be said against a different iteration length.

Dangers for Agility

Sometimes you hear complaints from companies with an ad-hoc culture that even agile approaches encompass processes that are too formal, impose too many rules, and thus get in the way of creativity.

However, this attitude ignores two things:

  1. Agile approaches prescribe only a minimum of ceremony and even allow it to still be adapted to the circumstances of the organization, the project and even the current situation in the project.
  2. There is a thin line between self-organization and chaos. Approaching chaos may well be liberating for creativity, but it can just as well have a negative impact on productivity. Agile teams don’t actually want to slip into chaos, they just want to stay close to it so that change is enabled while still allowing for purposeful work.

The emphasis on individual freedom and independence can make it difficult for employees to fit into a team. Although agile teams encourage self-competence, they also want team members to be strongly supportive of each other. They encourage team members to find a common work rhythm. This helps them deliver an increment of functionality at regular intervals (iterations). This requires that team members bring a certain level of discipline. They are also encouraged, in some circumstances, to define and adhere to common standards of approach so that a consistent, quality deliverable can be created.

An ad-hoc culture can have a strong influence on Agile change efforts by fostering a results-oriented environment.


Any prevailing culture influences heavily the way we work, think and also how we handle change. Any Agile change effort that does not take into account the prevailing culture in a company will encounter significant resistance without having a means to interpret and understand observed behavior.

To be able to influence the environment positively we need to inform our interventions with cultural awareness. This can not happen acting from afar, but we need to dive into the culture, work closely with people and leverage the existing culture to move forward.


  1. Kim S. Cameron & Robert E. Quinn, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, 3rd Edition, Jossey-Bass, 2011↩︎
  2. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 3 ↩︎
  3. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 9 ↩︎
  4. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 2 ↩︎
  5. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 11 ↩︎
  6. Peter DeGrace & Leslie Hulet Stahl, Wicked Problems, Righteous Solutions, Yourdon Press Series, 1990 ↩︎

  • The Practitioner's Handbook Early Edition is available now

Veröffentlicht am

Welcome to Member’s Area

Membership Area: Disillusioned by Agile

Hello and welcome to our membership area,

Congratulations on your purchase of The Agile Practitioner’s Handbook. Although the book is still a work in progress, a significant portion has already been written and reviewed.

While the first four chapters are nearly finalized, Chapter 5 is currently under development, and we have plans for Chapters 6 to 10 in the works.

As a member, you will receive timely updates on the book’s progress, all of which are included in your membership. These updates will be sent to you via email.

Interested in contributing? Become a valued reviewer for the project. Your feedback is incredibly valuable and will be duly recognized in the book.

Join us in our mission to revolutionize the comprehension of agile methodologies for a more sustainable and effective approach to modern business challenges.

How to contact us: Simply respond to the emails you received upon subscribing to this membership.

We look forward to hearing from you.

Yours sincerely,

Jiri Lundak

Disillusioned by Agile? From Pain to Progress: Diagnose and Alleviate Agile Dysfunction. A Handook for Practitioners
Veröffentlicht am

ChatGPT for Agile Software Development – Boost or Risk?

ChatGPT sample code generation dialog

Agile software development is a widely adopted methodology that emphasizes flexibility, collaboration, and iterative progress. As software engineers strive to optimize their workflow, the use of ChatGPT can offer numerous benefits to enhance their agility. However, it is important to be mindful of potential risks that could hinder the agile process. Let’s explore both the advantages and potential pitfalls of incorporating ChatGPT into agile software development.

Ways ChatGPT Could Help

There are some ways ChatGPT could help software engineers be more Agile:

      1. Improved Communication: Effective communication is a cornerstone of agile development, and ChatGPT can facilitate this by providing real-time feedback and suggestions during team discussions. It can analyze code snippets, offer syntax recommendations, and even assist in identifying potential vulnerabilities. This could streamline the development process and fostering collaboration among team members.

      1. Rapid Prototyping: ChatGPT can aid in generating code snippets and prototypes, which can accelerate the development of minimum viable products (MVPs). This allows software engineers to quickly iterate and gather feedback from stakeholders. Doing so could lead to faster decision-making and validation of ideas, a core principle of agile development.

    1. Enhanced Documentation: Documentation is vital in Agile development to maintain transparency and knowledge sharing among team members. ChatGPT can assist in generating documentation templates, code comments, and other technical write-ups, saving valuable time and effort, and ensuring that project documentation remains up-to-date and accessible to all team members.

But… where there is light there is shadow.

Dangers to Agile Development with ChatGPT

A few points com to mind, when we want to highlight the risks:

      1. Over-reliance on Automation: Relying solely on ChatGPT for code generation and suggestions can potentially lead to a decrease in critical thinking and creativity among software engineers. Agile development values the human element, and excessive reliance on automation could result in a loss of innovation and diversity of ideas, which are essential for creating robust and unique solutions.

      1. Quality Control Challenges: While ChatGPT can provide suggestions for code snippets, it may not always guarantee the best practices or optimal solutions. If not thoroughly reviewed and validated, code generated by ChatGPT could potentially introduce bugs, security vulnerabilities, or violate coding standards. This may result in increased technical debt and rework, contradicting the principles of Agile development.

    1. Ethical Considerations: As a language model, ChatGPT can potentially generate biased or unethical code, especially when trained on biased data. This could result in unintentional propagation of bias or unethical practices in the software being developed, which could have ethical, legal, and reputational consequences, posing a risk to the integrity and fairness of Agile development.

Mitigating the Risks

There are though some things we can do to mitigate the risks:

      1. Strike a Balance: Software engineers should strike a balance between utilizing ChatGPT as a tool for assistance and leveraging their own expertise and creativity. It is essential to maintain critical thinking, innovation, and human decision-making in the agile development process.

      1. Validate Generated Code: Code generated by ChatGPT should be thoroughly reviewed, validated, and tested to ensure it adheres to coding standards, follows best practices, and meets quality requirements. This includes thorough testing, code reviews, and validation against project specifications to identify and fix any potential issues before deploying the code.

    1. Ethical Considerations: Be mindful of the ethical implications of using ChatGPT in software development. Training data should be diverse, inclusive, and free from bias. Review the code generated by ChatGPT for any potential biases or unethical practices, and take necessary steps to mitigate them. It’s important to have a strong ethical framework and guidelines in place when incorporating ChatGPT into the Agile development process.

An Experiment

My personal (admittedly still limited) experience using ChatGPT to generate and explain code confirms the risks associated using the tool (at least in its current state).

Actually, when using it intensely and double checking its output, one can still see its limits.

The code it generates looks mostly clean, but it does not follow a specific coding style. Actually the temperature setting of the ChatGPT dialogue engine is set to give “creative” answers. So you will get different variants on how you could implement an idea. If you have no personal idea on how a solution should look like you can go with any proposed code. But if you try to stick to a specific coding style, you oftentimes find yourself second-guessing what it proposes.

How far ChatGPT’s understanding of the code goes can be easily challenged doing these few steps:

      1. Let it generate some code (for a problem domain, you might be familiar with).
        → I let it generate code to calculate the distance between two planets at any point in time.

      1. It usually gives a verbal explanation on what the code does.
        → It explained to me, that it was using a Euclidean formula to calculate the distance.

      1. Then modify the generated code slightly (like a programmer would do, when moving it to an IDE and evolving it over time).
        → I just changed the calculation of the Euclidean formula slightly.

    1. Paste the modified version of the code back into ChatGPT and ask it to explain the code.
      → ChatGPT explained to me that the code used the Euclidean formula. But this could not be true, as I changed the formula to be invalid.


Just this little experiment shows the danger of relying too much on ChatGPT’s help, at least in its current state. There actually is no reasoning behind what it spits out. Unfortunately for many people that do not take its output with a grain of salt its convincing authoritative tone will produce lots of non valid output.

So yes, validating, testing and questioning its output is essential. We as developers need to step up our game, by knowing what the expected results should be, before asking ChatGPT. So Agile development skills will be in high demand more than ever before.

In the coming weeks I will have a look at various practices from Agile software development (like test automation, evolutionary software design, etc. ) and how they are impacted by the use of artificial intelligence tools.

If you are interested in improving your Agile implementation, then check out my upcoming book.

Note: My experiments were done using ChatGPT version 3.5. As soon as I can get my hands on ChatGPT 4 I will do a follow-up to this post.



  • The Practitioner's Handbook Early Edition is available now

Veröffentlicht am

We Agile Developers Lost Our Customers

Yes, it’s convenient to think up your own requirements. No annoying second opinions. No superfluous intervention by a person who has no idea anyway. When has the customer ever known what he wants?

Misconception 1: The Customer Is Stupid

As a developer we sometimes think, we know what the customer wants. Especially when we are working in a domain that is slightly familiar to us. It is not the first time that we overestimate our knowledge. The path of product development is peppered with the carcasses of self-overestimation and know-it-all attitude.

We do not develop products to satisfy our personal needs, but the needs of our customers. Having the wrong attitude with not help us conquer the hearts and minds of our customers decreasing the potential for a successful product substantially. That does not mean that we can not help the customer to understand technical limitations or consequences of certain choices. But in the end the customer has to have the feeling of having gotten the best possible solution to his problem.

Misconception 2: The Customer Can’t Say What He Wants

There is a communication problem between developers and customers. And it is not on the customer’s side. I know I might be a little controversial here. But think about it: Is the customer able to express his ideas for a product in layman’s terms? Usually he is. But sometimes he is more comfortable speaking in business jargon.

Can the customer understand developer language? Not really. So who should go the extra mile to get an understanding of the business domain, when both try to talk to each other? I would say the developer. Maybe we developers need to master the art of talking to the customer in his language, to get a viable result.

Misconception 3: The Product Owner Knows the Customer

This is a subtle one. We preclude that a Product Owner is in direct contact with customers. It is supposed to work that way. The Scrum Guide and other sources of agile wisdom expect the “customer” in the same room as the developers or at least as the Product Owner.

But where in big enterprises is this really the case? Oftentimes there are layers and layers of middle-men and -women between the customer and the developer. This situation is unfortunate. What can we do about it? Help the Product Owner to get closer to the customer and you as a developer will be closer to him, too.

Misconception 4: The Organization Is Hiding the Customer from Us

This misconception actually is partially true. But only to the extent that the organization actually does not know any better. As the organization is no uniform individual with its own will, it can not deliberately hide a customer from us.

The problem often is that the organization actually wants to optimize operations, making processes and people within the organization more efficient. Unfortunately this often leads to the side effect that nobody aspires to in the first place: the direct access to customers is obscured and hindered.

Do not blame individuals that they are hindering your effort to get in contact with real customers. Use them instead to find out who in the organization is closest to them.

Who has to go over the books now?

We developers often think that the surrounding people have to pave our way to be able to work in an agile manner. I doubt this is the case.

Instead we need to model and mold the environment we are working in. We have to put in the unpleasant and tedious work ourselves. We get no gifts or free-bes.

Are you ready to roll up your sleeves?

Fancy some other nuggets of wisdom on making agile implementations work? Sign up to the book I will be publishing soon on the topic.


  • The Practitioner's Handbook Early Edition is available now

Veröffentlicht am Schreib einen Kommentar

Are machine learning systems too biased for Agile teams?

Are machine learning systems too biased for Agile teams?

About a month ago, the virtual swissICT event “AI in Agile recruiting – a reality check” (in German) took place. It got me thinking whether machine learning systems are too biased to be helpful for Agile teams.

Author: Jiri Lundak

How biased are machine learning systems?

The event gave me the impression that even in our modern times, we are not immune to prejudice. It showed, that this world has its roots in the prejudices of each and every one of us. On the other side, we ourselves are also influenced and shaped by the society that surrounds us. Accordingly, we personally also adopt the prejudices of those around us (whether in the company or the wider society).

At the event, Dr. Prof. Ana Fernandes, in her presentation “Conscious and Unconscious Discrimination in Hiring: Fertility, Gender and Ethnicity Bias”, clearly demonstrated, using specific examples, that bias is already a problem in recruiting not assisted with machine learning.

Machine learning systems are designed by humans and fed data. The lecturing experts made it very clear to us that machine learning systems cannot be trusted unconditionally. This is because we, as humans, carry our prejudices, consciously or unconsciously, into the database of machine learning systems. Ursula Deriu showed in her talk “Von der Allmacht der Künstlichen Intelligenz” (in German), that machine learning software – as it presents itself today – is inherently vulnerable to be biased. Also Dr. Prof. Mascha Kurpicz-Briki, in her presentation “Social stereotypes in AI – how does it happen?” (in German), vividly demonstrated how prejudices can become embedded in machine learning systems.

Often enough, the pool of raw data is not broad enough to counteract biases. A conscious effort must be made to train the models underlying machine learning to provide a good foundation for bias-free recommendations and autonomous decision making by automated systems.

Using machine learning – for what?

The event participants considered the use of machine learning to be particularly sensitive in the following areas of application: during job interviews, in finding out reasons for dismissal, and in assessing social skills. Additionally they concluded that “hire for cultural fit” is hardly conceivable due to an automatic assessment of CVs. It was also emphasized that humans should have the final say in assessing candidates. Machine learning systems should thus only make recommendations.

Machine learning support was particularly desired by HR managers in the pre-selection of candidates and in predicting employees who might leave the company. At the same time repetitive work and reviewing qualitative responses from surveys and comments, were also mentioned as potential uses of machine learning.

Uncertainty prevailed regarding the quality of automated scanning of resumes.

On the other hand, participants emphasized that attributes such as age, gender, race, nationality and sexual orientation should be deliberately excluded from assessment criteria. This would be breeding ground for bias in the models.

Machine learning in Agile recruiting – are they compatible?

In the past, I had the opportunity to sift through hundreds of CVs and conduct many interviews. The company I was working for at the time was a pioneer regarding agile approaches. This experience makes me skeptical about the use of machine learning in recruiting.

From my point of view as an agile coach and as a team member of agile teams, what is written in a CV is only partially decisive. Sure, it’s good to be able to read from it whether a programmer has already worked with Java when looking for people with such experience in the company. Of course it is good to know if a person has a lot or little experience in certain areas when it comes to hiring a person with a certain seniority.

To find this out, it is certainly useful to have a way to get an overview of the available candidates and to be able to select a subset of them (e.g. with the criterion “experience Java > 4 years”). If a searchable database helps you do that, all the better (AI is not necessarily required for this). The beauty of this approach is that it can even eliminate the need for pre-selection by HR staff, as members of an agile team can query the database themselves.

What really matters to agile teams

Machine learning systems – in their current state – are not able to analyze a candidates behavior to counter potential bias, when just feeding off of CVs and job reference letters. Let’s see why this is the case.

The event left me thinking for a few days. What do agile teams want? In my experience, they usually insist on selecting their future colleagues independently, “handpicked” so to speak.

Why do they insist on this? Because they have found that the CV only hints at what is really in a person in terms of skills and potential. Since they want to be as sure as possible in their choice, they will subject each candidate to a practical test, which involves observing them at work, thinking and behaving.

For agile teams, it is thus important to achieve a “culture fit”. But not only that! A “skill fit” is definitely important as well, but unlike what you might expect, it’s not about whether a Java developer knows library X or is familiar with technology Y. It’s more about whether she knows how to work. It is rather about whether she…

  • …is able to approach problems systematically and not hastily
  • …has acquired sensible programming habits (e.g. refactoring strategies, red/green testing, small changes, etc.) and knows when to use which technique
  • …is willing to take advice and learn from others
  • …can communicate in a targeted and understandable way.

Why CVs say so little about candidates

You can’t read these skills out of a CV. Why not? Because the CV hides the most important things. I remember a case when a candidate seemed to have been involved in many projects and was familiar with many technologies. Nevertheless, he was not able to put a simple piece of program code into a better form.

Does the potential future colleague have a lot of programming experience, but is unable to admit that she doesn’t know something? Does the candidate’s way of working consist of delving into a problem and not asking for help when it comes up? Is a programmer quick to develop but gives little thought to design or quality assurance?

Even if you look closely at a person’s references, you always have doubts about whether the person who wrote the reference really worked closely with the candidate to make a nuanced assessment.

It becomes clear that machine learning systems can only evaluate what is written. Unfortunately what is not written might be even more important to a person assessing the value of a candidate for one’s team.

Job references are misleading

Some think that for a good assessment job reference letters are needed. Actually they where invented to give an accurate view of a candidate. Ideally they would be well suited as raw data for machine learning systems, so they can make a good choice without being biased. Unfortunately this is rarely the case.

One always imagines the writing of a job reference to be so direct, immediate and truthful. Finally, it is said about job references that they must be “true, benevolent, complete, consistent and clear” [1]. The figure below represents the ideal world. A small team. The line manager is close to the team and works closely with the employee he or she must evaluate.

Team embedded in a small company
Team embedded in a small company

Considering that certain large companies have outsourced the writing of job references to external service providers who work on the basis of some quickly clicked together text modules, doubts about the quality of the references are reasonable. See the next figure:

Team embedded in a large company
Team embedded in a large company

This drawing shows that nowadays it is not at all self-evident to get a job reference issued by a person who knows you intimately. This example shows, that because of increasing distance and several participants in the process, it can be doubted, that a reference is produced that gives a good, well-rounded picture of the employee.

Job references and machine learning systems

But there is another problem that amplifies the the woes machine learning systems have to make decision without becoming biased.

As someone who has been allowed to write references myself, I know how difficult it is to write a reference that meets the requirements of being “true” and “benevolent” at the same time. Actually formulaic formulations, which contain hidden insinuations about the actual performance of an employee, have developed over time. This because the issuer of the reference must not block the chance of a new job for the former employee. Fortunately, such formulations are increasingly being dispensed with in the meantime.

But this does not simplify the problem of job references for people who have not done a good job. The balancing act is very difficult. This leads to the question: What corresponds to the – sometimes harsh – truth, and what I am actually allowed to write in a job reference without it harming the employee’s career? In such cases, we as human beings have the tendency to write too positive a reference, thereby glossing over the statements to be made.

This is another reason to question job references as a central basis for decision-making in the application process.

Development teams take too little responsibility

Development teams (certainly agile ones) like to welcome highly productive new employees in their midst. At the same time they often like to delegate the task of selection to third parties (be it the internal HR department or an external headhunter). Although, Proper employee selection should be a core competency of any team. This process is time-consuming and requires in-depth engagement with candidates.

The dream of delegating or even automating this process is tempting. However, the proper selection of team members is so important that it cannot actually be delegated. Although some administrative support (e.g., in writing job ads) can be obtained, the good impression, from direct interaction with candidates, should help the team make an informed decision in the selection process.

In the end, the team has to live with the outcome of the selection.


With the use of machine learning in recruiting, we hope to see a more streamlined hiring process.

As we’ve found, machine learning systems today are still biased because of their developers and data providers. This is not going to change anytime soon. But initial efforts (in research) are underway to actively counteract biases.

Of course, biases can also come into play when an agile team itself selects team members. Nevertheless, putting the responsibility of selection on the team helps to make a better team decision.

Machine learning can help in peripheral areas of the recruitment process. However, the selection of suitable candidates should be based on hands-on collaboration with them and the team.

In this way, biases will not influence the selection. We certainly can’t expect that. However, we must tackle the problem with prejudices at its root, where it originates, namely in people’s minds.

The author: Jiri Lundak has been working independently as an Agile coach at the intersection of people and technology for many years. He has held many roles, including recruiting.

[1] “Creating job references” (in German), Weka, retrieved 21.09.2021.



  • The Practitioner's Handbook Early Edition is available now