The Human Factor in Software Engineering

"This will not work here" is a sentence I often hear from practitioners.
When I was young and naive, I trusted that my colleagues with their high experience can judge in advance what will work and what will not.
Meanwhile, I have seen that "This will not work here" is a sentence applied not only to highly sophisticated methods from University doctoral theses which cause more effort than they save. No, it is an almost automatic reaction to all types of changes proposed, even to lightweight methods which were developed and successfully applied by other practitioners. "This will not work here" in fact very rarely wants to say that this will not work here. This short sentence can express, summarize and hide a lot of other types of claims, such as:
- This method does not fit to our way of working / product / already applied methods.
- We have tried so much else before, we are tired of trying new methods.
- This was not invented here, therefore we dislike it. We want to realize our own ideas, not those of foreigners / those of you.
- If we use this method, then everyone can do good work. Currently, project success depends on the knowledge of one person only and I am this important person.
- I / we hate any type of change. We do not want to learn anything new and get upset at work. Life is too irritating anyway.
- We are past the life phase where one learns new things. It´s over, do not try to teach an old dog new tricks.
- You are not the person who has the right or competence to tell me how I should do my work.
- Are you dissatisfied with my work?
- You are not the first one who tries to mingle in our work style, but you will fail like the others before you.
- In this company/ team, nothing will ever work. New methods will simply enhance the chaos.

Whatever the real meaning(s) behind "This will not work here" is/ are, it touches the change management problem. A new method is not simply a new method. It can mean a new way of thinking, of seeing the world and oneself´s role, a new working style and working speed.

The first step for managing change here is to find out what the real meaning of "This will not work here" is. Asking directly "What does this mean?" can lead to further nebulous arguments that hide the real causes for resistance. Instead, you can ask the following questions to indirectly find out:
- This method is meant to solve the following problem... Do you know any other method that can solve this problem better?
- Could we simplify and adapt the method in a way that it works better?
- Why were the methods you tried earlier unsuccessful?
- What extra tasks would this method cause you to do and what risks do you see?
- Are there single persons who could, should and would use the method first as pilot users?
- Who of you can judge best whether the method makes sense in your environment?

When you know the reason for resistance, you can decide how to introduce the method or also can decide not to try it. There is nothing worse than trying to introduce a new method against the will of the stakeholders and to fail. It is better to propose a method and then to wait whether the seed will grow. It is possible that after some months, in a meeting, the team reanimates the idea and now likes it, after they have got used to it and thought about it.
At least, this is how I convince people. I never expect them to change their mind just because I give them arguments. And I dislike rhethorical tricks because intelligent people after some days realize that they have been tricked. Usually, I also give people time.
This is probably one major problem in change projects: They do not have time. They must force change upon their victims à la "Who is not for us, is against us". However, most people are just undecided or slow. Who of us likes it when someone comes along, points to an awkward self-organisation and tells you that you MUST change. For pure stubborness, the spontaneous reaction is "No!". One is currently struggling elsewhere, solving other problems. It is not so nice to be told that there are even more problems which need attention and action. One can solve only one problem after the other. Additionally to problem-solving, we are still busy doing the daily work.

Have you ever regretted any of your decisions? Or do you find it difficult to make decisions at all?
Let´s try a new way of learning - in life for life.

Every Monday, you receive a handy bit of knowledge about decisions (size of a calendar sheet) and your weekly exercise by e-mail. You learn succinctly the most
important facts about decisions and you practice making goal-oriented decisions, presenting and influencing decisions, and understanding your previous decisions in
life. Professional decisions as well as private ones. Every week, you can ask me questions and get individual feedback.

This course is based on my intense investigation of rational and gut decisions during the last years. Thanks to numerous ligh bulb moments, I now live in peace with my decisions. So can you!

The course starts Monday 30th July and runs for 10 weeks.
It is offered in English and German. For the first 20 subscribers, it costs 10€, for all others 20€.
You can register at: AndreaHerrmann3@gmx.de

I heard that Rousseau - while believing that humans are born as good beings - claimed that humans can not be good in society. Society´s rules are made in a way that damaging others always brings more benefit than helping others. I wonder whether this is also true for one section within human society: a software project.
The word "team" is in fashion not only for project teams but also replacing other terms like the department. Nevertheless, most so-called teams are no teams according to the definition of Humphrey. According to Humphrey, a team is made up of at least two persons who work towards a joint goal, where each person has a defined responsibility and defined tasks.
However, project success is not always the main objective of all team members and even less of all stakeholders. Competition is very high in German enterprises. People do not aim at team success, but always their own success, according to their own criteria. This can mean they want to get home at a defined minute. Then, it is better for them that tasks are not clearly defined and not clearly attributed to the persons. Then, they can "forget" some work and still are not responsible for it. Helping others causes them extra work but no profit. Arranging misunderstandings and forgetting tasks helps them to work slowlier and go home earlier.
Others want to show that they are better than the colleagues and must therefore be promoted faster than these. For these, helping others can also cause damage. If they help someone, this makes him look more competent and efficient than he is. Therefore, it is important for them to help others only under the condition that everyone knows it. Like this, they can establish as an expert AND can establish the other as an idiot by telling everyone how stupid he is. He would never have managed to do his work, without help. I have experienced colleagues telling me simple truths which I already knew and then they ran around and told everyone that I did not even know such simple things. Damaging others is beneficial in software development.
There should be mechanisms and rules which make that it is more profitable for each individual to help the others than damaging them. Team success is not made up of successful sub-projects but of synergy effects, of using all the knowledge available in the team. Damaging a colleague finally means damaging the project and damaging the company. When I was a project manager, I tried to establish such a team culture. Especially, the company culture demanded that at each error the person had to be found who is guilty and must be punished. I refused to do so because I said that in a team, an error is not made by one person alone, but by several. For instance if someone forgets to tell a fact to someone, this someone also might have asked. Who works, makes errors. This is a well-known truth. However, in this company I was told that we want to achieve that no-one makes errors. This is an interesting statement in a company where people get no training for being competent enough for working error-free. They seemed to believe that publicly punishing those who made an error makes them work better, more efficiently than a training. Well, cheaper at least. When an error happened, I looked for causes and solutions. I often said "we". "If you help X, then work package Y finishes earlier and we can deliver earlier all together." (This proposal was the result of a critical path analysis of our network plan.)
Of course, I was not successfull with this strategy. It did not fit into the company culture. I was called a person who avoids conflicts and strives for perfect harmony. Well, yes, avoiding unnessary and destructive conflicts is not so bad, but adds to efficiency. Struggling and fighting detracts energy and time from the productive work. As for the perfect harmony: Solving real problems is fun, therefore I liked the management job. But it is no fun to see adults behave like kindergarden children!

Even the reproach that I avoid conflicts speaks in favour of my assumption that a software project and software company is also made in a way that damaging others is more beneficial than helping others.

Source of the team definition:
W.S. Humphrey: Introduction to the Team Software Process, Addison-Wesley 2000

Regelmäßig finden sich in den Fachmedien Berichte über gescheiterte Projekte. Ein wesentlicher Grund für das Scheitern liegt in unzureichenden Anforderungsdefinitionen. Je komplexer die Projekte sind und je dynamischer sich die Umwelt darstellt, desto wichtiger wird gutes Requirements Engineering und Requirements Management, um systematische Entscheidungshilfen zu geben und ein beschleunigtes Time-to-Market und folglich Wettbewerbsvorteile zu erreichen. Dieses Buch beschreibt für verschiedene Aktivitäten des Projektmanagements, wo und wie Methoden und Verfahren des Requirements Engineering und Management im Projekt zur Anwendung kommen wo überkommene Vorgehensweisen erweitert bzw. verändert werden sollten, wie Projektmanagement bereits (unbewusst) Requirements Engineering und Requirements Management an vielen Stellen einsetzt und dessen Ergebnisse nutzt. Durch bewussten Einsatz dieser Methoden kann das Projektmanagement verbessert werden. Eine Darstellung der Rahmenbedingungen für den optimalen Einsatz von Requirements Engineering rundet das Buch ab.

http://www.springer.com/computer/swe/book/978-3-642-29431-0
http://www.amazon.de/Requirements-Engineering-Projektmanagement-Xpert-press-Fahney/dp/3642294316/ref=sr_1_1?ie=UTF8&qid=1339019854&sr=8-1

Wenn Sie Fragen zu diesem Buch haben: Ich bin Mitautorin und Mitherausgeberin dieses Werks und freue mich über Diskussionen.

Eine Frau, ein Wort... Die letzten Tage war ich auf Trainingslauf. Allerdings habe ich ein Picknick mitgenommen, Schlafsack, Blasenpflaster und all diesen zivilisatorischen Ballast. Wir starteten an der Neckarquelle und wanderten den Fluss entlang, der sich zunächst etwas umständlich durch den schwäbischen Dschungel schlängelt. Ein ausführlicher Reisebericht ist in Arbeit. Nur so viel für dieses Kurz-Text-Medium: Wandern mit 10kg auf dem Rücken ist auch Sport. Die anvisierten 50km pro Tag habe ich leider wegen Materialermüdung nicht so ganz geschafft. Entsprechend bin ich nun ein wenig ramponiert mit Stichen im Knie und Blasen an den Fersen. Aber das motiviert mich nur dazu, in Zukunft noch etwas mehr zu trainieren. Von der Stubenhockerei bin ich ja ganz verweichlicht!
Außer Blasen an den Füßen brachte die Tour mir auch stählerne Muskeln ein und hat den Blick geweitet. Das Wandern erinnert wieder daran, dass jede weite Reise und jede Bergbesteigung aus sehr vielen einzelnen Schritten besteht. Entschleunigung, Weite des Horizonts und Eigenverantwortung sind weitere Stichworte des Wanderers.
Um auf den Auslöser der Tour zurück zu kommen: Dort ist das Ziel, hier stehe ich, mit dem Trainingsplan in der Hand. Was sollte mich aufhalten? :-)

Using the data about accidents that have taken place, the risk of the maximum accident has been corrected. The research group of Jos Lelieveld (Max-Planck-Institut für Chemie in Mainz, Germany) counted 14.500 years of nuclear power plant operation so far and 4 worst case accidents (one in Tschernobyl, three in Fukushima). Multiplying this frequencies with the number of active nuclear power plants (440 currently active, 60 further are planned), they obtained an average mean time between two such accidents of 10-20 years. South-western Germany is the region with the highest risk, because the density of nuclear power plants (German and French) is highest here. We (me!) can expect one accident in 50 years. The probabilities had been assumed to be 200 times lower so far! This study has recently been published in the journal "Atmospheric Chemistry and Physics".

Die Frage "Was braucht die Einführung von Software Engineering Methoden?" beschäftigte mich weiter. Da es sich bei der Einführung letztlich um nichts mehr und nicht weniger handelt als um das Einführen von organisationalen Veränderungen, las ich mehrere Bücher über Change Management. In dieser Disziplin weiß man, wie man Veränderungen einführt. Davon können wir lernen. Ich habe dabei zweierlei gefunden: Die fünf Phasen eines Veränderungsprojektes und was dabei wichtige Prinzipien sind. Meine beste Quelle war das Buchkapitel von Axel Kaune "Moderne Organisationsentwicklung – ein Konzept zur mitarbeiterorientierten Gestaltung von Veränderungsprozessen" (in: Axel Kaune (Hrsg): Change Management mit Organisationsentwicklung - Veränderungen erfolgreich durchsetzen. Erich Schmidt Verlag, 2. Auflage, 2010, S. 11-66).

Die fünf Phasen eines Veränderungsprojektes sind:
1. Auftragsphase: Hier wird geklärt: Ziele, Kompetenzen, Kapazitäten, Zeiträume, Vertraulichkeit, Vorgehen bei Widerständen.
2. Diagnosephase: Analysiert wird die Ist-Situation: Probleme, Fakten, Emotionen; darauf aufbauend werden Hypothesen entwickelt.
3. Planungsphase: Geplant werden Maßnahmen + Plan, Zeitpläne, Verantwortlichkeiten, Kriterien für Erfolg
4. Durchführungsphase: Der Umsetzungsprozess erfolgt so plangemäß wie möglich, so flexibel wie nötig.
5. Auswertungsphase: Führten die Maßnahmen zur Zielerreichung? Ggf. werden nun Folgemaßnahmen geplant.

Die SWE-Einführung braucht...
- klare Ziele und Kennzahlen, z.B. weniger Fehler/ Missverständnisse, Zertifizierung
- Einbeziehung und Beteiligung der Mitarbeiter, z.B. bei Zieldefinition, Prozessentwurf und Auswahl der Notation
- viel offene, klare Kommunikation
- Rückhalt durch die gesamte Organisation, d.h. es muss klar sein, wer wie vom SWE profitiert, und welche Rolle sie spielen im Einführungsprozess
- Identifikation von und Umgang mit Widerständen
- gutes Timing
- Training, Moderation
- Coaching, Feedback

Das ist nun natürlich recht abstrakt. Wenn ich es mir konkret vorstelle, klingt es nach vielen Meetings, viel Vermittlungsarbeit, bis man genau die Software Engineering Methode gefunden hat, mit der alle leben können (=Kompromiss). Schulungen sind nur ein Teil des ganzen großen Einführungsprojektes. Oder der Anfang.

Prof. Dr. Jochen Ludewig: "Software Engineering: Von der Theorie in die Praxis - Von der Praxis in die Theorie"

Gestern Abend hielt Prof. Ludewig bei der GI-Regionalgruppe Stuttgart-Böblingen (http://rg-stuttgart.gi.de/) einen Vortrag mit obigem Titel. Die Schwierigkeiten beim Transfer von Forschungsergebnissen in die Praxis und auch umgekehrt die Schwierigkeit von Forschern, überhaupt über die Schwierigkeiten der Praxis zu erfahren, sind hinlänglich bekannt. U.a. gibt es nur wenige Forscher mit Praxiserfahrung, insbesondere unter den Doktoranden. Dieser Vortrag ging aber noch weiter und zeigte auf, in wie fern Software Engineering Forschung anders ist als die Ingenieurwissenschaften und der Rest der Informatik. Das Software Engineering entwickelt nicht Problemlösungen, sondern Modelle und Techniken, die man auf die Problemlösung anwenden kann. Hierfür braucht es in den Firmen einen Wissens-Scout, der Tagungen und Zeitschriften nach nützlichen Ansätzen durchsucht. Leider werden sogar bei den ganz großen Firmen genau diese entsprechenden Abteilungen und Stellen immer weiter eingespart.

Prof. Ludewig betont, dass Software Engineering nur dann erfolgreich ist, wenn es das Denken und Handeln von Menschen verändert. Das Software Engineering darf sich daher nicht damit zufrieden geben, Modelle und Techniken zu entwickeln, sondern muss sich auch beschäftigen mit der Einführung eines Verfahrens im Zusammenspiel von Randbedingungen, die Veränderung des Selbstverständnisses der Beteiligten und wie man Widerständen und Problemen umzugehen ist. Hierzu ist mehr empirische Forschung nötig und auch die kritische Erprobung von Techniken. Obwohl der Befund, dass eine Methode praktisch nicht anwendbar ist, auch ein wichtiges wissenschaftliches Ergebnis darstellt, findet man doch in wissenschaftlichen Veröffentlichungen fast nur Erfolgsberichte.

Mir spricht dieser Vortrag voll aus dem Herzen!