The Human Factor in Software Engineering

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!

Dienstag 24.4. und Mittwoch 25.4. war ich in Düsseldorf auf der iqnite Konferenz.
Dort habe ich mein Tutorial "Komplexität in der Softwareentwicklung reduzieren" gehalten und mich auch selbst fortgebildet. Besonders spannend waren die Keynote Vorträge. Hier meine Key Learnings aus diesen:
- Harry Sneed ("40 Jahre Software-Qualitätssicherung im Rückspiegel: "Die Entstehung einer umstrittenen Disziplin") verkündet das Zeitalter der Tester. Die Zukunft gehört den Testern! Entwickelt wird heutzutage kaum noch, stattdessen werden vorgefertigte Komponenten integriert, z.B. Web Services. Anmerkung: Da mein Herz ja für das Requirements Engineering schlägt, möchte ich hinzufügen, dass natürlich vor dem Kaufen und Zusammenstecken von Komponenten das Requirements Engineering erfolgen muss. Requirements Engineering wird also auch wichtiger!
- Prof. Gunter Dück sprach über "Professionalität im digitalen Zeitalter". In der Zukunft werden alle Routinearbeiten und einfachen Probleme in die Cloud, an einen Automaten oder nach Indien geschickt und dort von Billiganbietern erledigt. Oder der Kunde hilft sich selbst, dank dem Wissen aus dem Internet. Dies führt zur zweiten Revolution im tertiären Wirtschaftssektor.
Ärzte, Apotheker, Professoren, Rechtsanwälte, aber auch Programmierer und Tester verlieren die gut bezahlte, leichte Arbeit und übrig bleiben nur noch die schwierigen Aufgaben und üblen Probleme. Das heißt, Dienstleister müssen in Zukunft richtig gut sein und sich auch mit exotischen Themen auskennen, wenn sie noch Geld verdienen wollen. Hinzu kommt, dass sie außer dem traditionell am höchsten gewichteten IQ noch weitere
Intelligenzen haben müssen, nämlich emotionale Intelligenz, Kreativität, Wille, Attraktivität, Sinn. Aber, so sagt Dück, 98% aller Menschen über 18 sind nicht mehr kreativ! Wir müssen uns also vollständig ändern oder untergehen, insbesondere im Vergleich zu einer jüngeren Generation, die bereits besser für die digitale Zukunft gerüstet ist.
- Joey Kelly ("NO LIMITS - Wie schaffe ich mein Ziel"): Um seine Ziele zu erreichen, selbst ganz hoch gesteckte Ziele, braucht man Biss, Disziplin, man darf nicht wehleidig sein und muss immer wieder über seine Grenzen hinaus gehen. Daraufhin habe ich meine Zieleliste für die nächsten Jahre nochmal um einige aberwitzige Ziele ergänzt. Es ist nicht völlig unmöglich, dass ich sie erreiche, aber der gesunde Menschenverstand würde mich für verrückt halten. Darum verrate ich sie auch erstmal nicht.
Und zu guter Letzt noch: J.K. meinte, dass er vielleicht irgendwann seine Deutschlandtour wiederholt. Wer mit will, solle sich melden. Er dachte wohl, wir sind alle abgeschlaffte Informatiker, die sich davor scheuen, in 17 Tagen Deutschland von Nord nach Süd zu durchqueren und nur das zu essen, was man in der Natur findet. Haha, nach dem Vortrag fragte ich J.K., ob er das ernst gemeint habe. Nee, war ein Scherz. Schade, ich wäre ernsthaft interessiert gewesen. Fasten kenne ich schon, das kann ich. Also, vielleicht mache ich demnächst meine Deutschlandtour ohne Joey. Schade ist nur, dass man über solche Wanderungen eigentlich kein Buch mehr schreiben kann. Selbst nicht, wenn man mit einem Kühlschrank reist!

Ooops, I am currently writing a publication about how to prepare and to perform a risk estimation workshop. I decided to replace my usual example of the power plant by a hospital example. I do this for two reasons. Firstly, I feel at awe to discuss about the cost of a power plant explosion. It feels like doing something nasty on a graveyard. (I think of Japan.) Secondly, I am not sure whether I am right with my argumentation.

This is what I wrote in an earlier publication:
"My favorite example of a risk event where the mere risk number does not make sense is the one of a severe accident at a nuclear power plant. Such an event´s probability is very low, but the damage can be so high that it cannot be quantified reasonably. When assuming numbers for probability and damage and multiplying them, you can obtain any arbitrary number, depending on the assumptions, and if you calculate that the risk is 1000€ per month, this is of no significance, because it is clear that such an accident must never happen, independent of whether the risk is 10€ per month or 1000€ per month. The argumentation of above works here also: If we knew for certain that a nuclear power plant explodes once a year, we would not build them."
Reads a bit like nonsense, because a lot of people still think that nuclear power plants are a safe (and cheap!) way of producing energy.

I know: Psychologists can explain this using terms like "risk perception" and "risk attenuation". It is known that risk perception is constructed by a social process, not by facts. Thinking about this is a bit scaring because this means that a lot of avoidable accidents happen while on the other hand people by risk amplification constrain their lifes and avoid doing things that are not so dangerous after all.

OK, I return to my numbers. They make feel safer, don´t they?