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 will appear in Spring 2023

Aagile Practitioner Handbook

Be informed and join the waiting list:

Please type your eMail and confirm
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.

Conclusion

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.

 

Veröffentlicht am Schreib einen Kommentar

KI im agilen Recruiting

Online Teams

Am 9.9.2021 fand das Event “KI im agilen Recruiting – ein Realitätscheck” der Fachgruppe Lean, Agile and Scrum der swissICT statt.

Prof. Dr. Ana Fernandes (BFH) eröffnete die Vortragsrunde und präsentierte die Ergebnisse ihrer Forschung in ihrem Vortrag “Conscious and Unconscious Discrimination in Hiring: Fertility, Gender and Ethnicity Bias“. Ihre Untersuchungen zeigen, dass Frauen, bei denen davon auszugehen ist, dass sie in naher Zukunft schwanger werden, bei Bewerbungen um Teilzeitstellen diskriminiert werden.

Ursula Deriu (Tirsus) führte in ihrem Vortrag “Von der Allmacht der künstlichen Intelligenz” kurz in die technischen Hintergründe der KI ein. Prof. Dr. Mascha Kurpicz-Briki (BFH) stellte die Synthese her, und präsentiert die Ergebnisse ihrer Forschung im Vortrag “Gesellschaftliche Stereotypen in der KI – wie kommt es dazu?“. Anders als allgemein erwartet, ist KI heutzutage nicht immer nicht in der Lage, vorurteilsfreie Entscheidungen zu treffen. 

Die anschließende Diskussion mit den etwa 30 Teilnehmenden wurde von Jiri Lundak (Red Pill) moderiert und  zeigte auf, dass im HR bei der Auswahl der Kandidaten:innen auch Risikoüberlegungen angestellt werden. Zudem kristallisierte sich die Hoffnung heraus, mit Hilfe geeigneter automatischer Verfahren nicht nur zielsicher die besten Kandidaten:innen zu finden sondern auch Instrumente an die Hand zu bekommen, um die bestehenden Mitarbeiter:innen halten zu können. Die Ergebnisse der Forschung zeigen jedoch deutlich, dass die Realität diese Hoffnung noch lange nicht erfüllt. Außerdem herrschte bei den anwesenden HR-Spezialist:innen Einigkeit, dass KI-Tools dann schwieriger einzusetzen sind, wenn es darum geht, für Kandidat:innen einen Team-Culture-Fit herzustellen.

Veröffentlicht am Schreib einen Kommentar

How can you increase trust in a remote work setting?

How can you increase trust in a remote work setting?

A recent article in the Harvard Business Review backed with some numbers that “Thirty-eight percent of managers agreed that remote workers usually perform worse than those who work in an office, with “ an additional “22% being unsure”. That means that nearly 60% of managers do not have much trust regarding their workforce performing equally well in the home office.

Sure there is a good deal what managers can do to increase trust in a remote setting. It is easy to point fingers and say that they should first trust their employees and then good things will follow. Unfortunately reality does not work this way. The distrust is omnipresent and we must cope with it.

What you as a remote worker can do

So instead of pointing fingers, here some hints on what any individual remote contributor can do to most likely improve the situation:

1. Keep promises

Trust builds over time. Any stranger will first observe how we work, before he will trust us. Think of a letter of recommendation: it might be chock-full of technical abilities you have as a software engineer. How can I as a potential employer know for sure that you are a capable person?

It is simple: My trust increases when I read about past accomplishments in your letter of recommendation, and even more so, when I talk to a past employer of yours. But when I am interested in the very best talent, then I will put you to the test. Only seeing how you program will instill in me the right amount of trust to hire you.

With the letter of recommendation starts a little journey of trust between you and me. Through it you promise me something. I will check if you can keep your promise and then move on, when I have enough trust in you.

But it does not stop here. During the first months I will keep in touch with you to see if the promises were not overblown. As time goes by and I get to know you better you become a person I trust deeply. I will not need to check so often what you are exactly doing, because I put trust in you (that you will ask, when there is need, that you have good judgement, that you would never promise too much, etc.).

In a remote situation, when I can not observe closely how you work from the beginning, then I have a more difficult time to trust you. So you as a new employee should try to make your work more visible to me as an employer. Show what your challenges are and how you react to them. Manage my expectations. Make promises you can keep and show the achieved results without the need that I query you.

2. Be responsive

Working remotely means usually more autonomy for an employee or a contractor. With more freedom comes more responsibility.

It is good practice to be as responsive as possible in a remote situation. When working in an office physically collocated with your colleagues, anybody can overlook the room and perceive your presence at a glance.

In the virtual space this is not the case. You can chime in to online meetings, say hi in the beginning and then turn off your camera and mic and think, that you show presence this way. You might even listen with one ear and on the side do something else. Would it not be better to be really present in the room, contributing? And if it is a meeting, where you can not contribute, then do better not participate.

So when you show your presence online, then be as sincere as possible. Be in the virtual room with your mind and do not multitask. Should you not be available for a longer period of time then inform your peers about your whereabouts.

When somebody asks you something, and you are not able to respond immediately, then respond giving a probable time frame when you can come back to that person. Nobody likes to write messages to a black hole, where no response can be expected.

Conclusion

These were just two possibilities to build up trust, when working remotely. Building trust starts with the small things. A consistent and sincere effort to be responsive and to manage expectations wisely, is the basis for a beneficial long-lasting work relationship.

More tips on building trust will be coming your way next time.

Veröffentlicht am

Does Surveillance Increase Remote Employee Productivity?

Does Surveillance Increase Remote Employee Productivity?

Employee surveillance is on the rise, as the BBC reported. The article noted, that “More than half of companies with over $750m (£574m) in annual revenue used ‘non-traditional’ monitoring techniques on staff…” in 2018 and further it states: “These include tools to analyse emails, conversations, computer usage, and employee movements around the office. Some firms are also monitoring heart rates and sleep patterns to see how these affect performance.”

The article shows clearly that the pros and cons of such software are controversially discussed.

With the spread of remote work (like in these days following the Covid19 pandemic outbreak), the call to control employees has become louder.

The  producers of surveillance and monitoring software claim that productivity of employees rises up to 32% when using their software.

Why this thinking is really backwards

Here are some thoughts I would like to share with you on why I believe the business world at large has it really backwards on this issue:

1. Definition of productivity

This Harvard Business Review article summarizes perfectly some of the points that many people find confusing or at least do not fully understand.

Firstly, individual productivity and company productivity are not directly linked. Individuals can be very productive in what they do every day, yet the company as a whole may have no productivity (or even a negative one). So being efficient in what individuals do during the day does not necessarily translate into creating more value for the company.

Secondly, individual productivity is difficult to capture. For a factory worker, who manufactures screws, for example, it is comparatively easy to assess his productivity: The number of screws he is able to produce (hopefully of the variety that can also be sold), with a decent quality (so they will not be thrown away), at a reasonably low cost, is a good enough measure. So measuring the number of hours he works correlates quite well to his productivity.

With a knowledge worker the case is much more complicated! Worked hours do not correlate directly to productivity. Why?

2. Type of work people are doing

Firstly, knowledge workers often produce output that is not countable. You might count the number of lines programmed by a software engineer, but different programming languages used produce different line counts even if you solve the same problem. And even using the same programming language you can come up with thousands of different creative ways to accomplish a task. If we take as example the software industry, then defining what really creates value is a hard thing to do.

But the problem is even bigger. When domain experts and IT engineers do not communicate well, like in most bigger companies, then software is often created that the customer does not want. So you can work for months, and pay people for producing the wrong thing, because you defined it the wrong way. So what point is there to monitor your employees, when they might not produce anything meaningful even when they perfectly follow the process? No surveillance will help you in this case.

Secondly, there is confusion between being efficient and being effective. Being effective means creating  value for the company and trying to minimize producing waste (discarded output). If I do my job efficiently, I could very efficiently produce waste in large quantities.  How about creating products that are so self-explanatory  and of such high quality, that there would be no need for a call center in the first place, instead of optimizing the time that call center staff spends on the phone?

We have created a lot of low wage and low qualification jobs, where many people do repetitive tasks with no customer orientation whatsoever, and at the same time we expect them to remain highly concentrated, focused and motivated.

This brings us to the reasons why people do work.

3. What motivates people

There are different views on when people do good work.

Some think most people are lazy and want to cheat their employer. They can quote figures that can prove, for example, how long people do something at work that has nothing to do with their job. They might surf the Internet, play games, read newspapers, chat with friends and family. And the numbers do not necessarily lie.

But let me give you just some thoughts regarding this perception:

Firstly, imagine you are doing some work, like cleaning your cellar, something you really do not like to do. Any distraction or excuse is welcome, so you can delay it. Now imagine you would do it for a good purpose. Would it be hard for you to motivate yourself for the job?

Some managers doubt the work ethics of their employees. But when we think about the private lives of those people: Most of them do not have any problem doing work for themselves and their families. They take responsibility and behave in an appropriate manner, without being monitored. So why is it that we need to question their work ethic in the company? Should we not better ask for the possible reasons they lack motivation and passion? May the work in itself be dull, uninspiring, underwhelming and even useless? Could we change something about the work they are doing?

Although many have already read Dan Pink’s book “Drive” and seen the accompanying video “Drive: The surprising truth about what motivates us”, the message has mainly gone lost. The message has four parts:

  1. Pay people enough, to take the money question off the table. This is one thing many businesses struggle with in the first place. But without this prerequisite the following three points will not work.
  2. Autonomy. Knowledge workers prefer to have the liberty to decide themselves when, how much and in which way they want to tackle a given task.
  3. Mastery. We want to become good at anything we do, given the freedom to be able to influence the way we go about things. So, if there is not just a predefined 5-step process to follow, but I get the possibility to improve what I do and how I do it, I will try to improve. This benefits me and my company.
  4. Purpose. We touched on this already. Give people a good reason for what they do. Explain the greater good they are contributing to, and their motivation will grow beyond measure.