Was ist eigentlich Qualität?

An dieser Stelle sollte man sich als Leser hinsetzen und versuchen den Begriff für sich zu definieren. Nicht einfach, oder? Man könnte damit beginnen mögliche Qualitätsmerkmale zu definieren. Wartbarkeit, Funktionalität, Robustheit und Portabilität sind zu Beispiel welche, die im ISO-Standard benannt sind. Qualität einer Software könnte also über die Erreichung des Maximalwerts in den einzelnen Kategorien sein. Das Produkt ist maximal Robust. Super. Hohe Qualität. Wartbar ohne Ende? Hohe Qualität. Klingt jetzt recht einfach.

Leider gibt es bei diesem Weg Qualität zu bestimmen ein Problem. Manche Software hat gar nicht den Anspruch wartbar zu sein. Wenn ich dazu keine Anforderung besitze, muss es trotzdem die Möglichkeit geben hohe Qualität zu produzieren. Man kommt also schnell drauf, dass es gut wäre Qualität und Anforderungen in Zusammenhang zu setzen. Genau das machen auch viele Definitionen von Qualität.

In Gablers Wirtschaftslexikon wird Qualität wie folgt beschrieben “Übereinstimmung von Leistungen mit Ansprüchen“. Qualität ist also das, was man selbst drauf macht. Es geht um den Einhaltungsgrad der gesetzten Anforderungen. Und genau so definiert es auch die passende ISO-Norm (EN ISO 9000:2005):

„Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“

Ist ein wenig schwer als Deutsch zu erkennen, ist es aber und es sagt so ziemlich das gleiche aus, wie bereits unsere andere Definition.

Scrum ist einfach. Keine Frage. Es gibt nur eine Handvoll Meetings, Artefakte und Rollen. Alles kein Hexenwerk. Um alle Regeln aufzuschreiben, die es in dieser agilen Welt gibt, benötigt man nicht mehr als eine DIN-A4-Seite. Das können nicht viele Modelle von sich behaupten. Das ist aber auch genau das Problem. Man hat viel zu schnell den Eindruck, dass man Scrum verstanden hat. Klar kann ich es auswendig lernen. Vier Meetings kann sich auch noch mein Religionslehrer aus der siebten Klasse merken. Es sind sich also viele sicher, dass sie Scrum vollständig verstanden haben, weil sie alles, was offensichtlich ist kennen und vielleicht sogar beherrschen. Das Problem an Scrum ist aber, dass so viel unter der Oberfläche passiert, was mit Gruppendynamik und Psychologie zu tun hat. Um diese Dinge zu verstehen, muss man viel mehr erreichen, als die Arten der Artefakte auswendig zu kennen.

Ich arbeite jetzt seit ungefähr 5 Jahren nach Scrum. Ich war mir die ersten zwei Jahre sicher, dass ich das System verstehe. Trotzdem ist es bei uns immer wieder zu Problemen gekommen, die wir mit unserem agilen Wissen nicht lösen konnten. Jetzt, nach fünf Jahren in der Scrum-Welt weiß ich, dass ich damals einfach nicht genug über die Psychologie dahinter verstanden hatte. So langsam bin ich aber an einem Punkt, an dem ich erklären kann, warum es funktioniert. Ich glaube ab diesem Zeitpunkt kann man sich hinsetzen und erfolgreich nach dieser Methodik arbeiten. Vorher ist es schwer. Viel zu oft wird man Scrum dafür verantwortlich machen, wenn man nicht weiter kommt.

Wer also fünf Jahre und viele Diskussionen durchstehen kann, der wird in dieser Welt furchtbar glücklich werden. Ich war von Anfang an recht begeistert, was es für mich einfach gemacht hat am Ball zu bleiben. Im Nachhinein bin ich auch froh.

Fassen wir nochmal zusammen. Scrum wirkt einfach, ist es aber nicht. Genau das ist das Problem, mit dem man sich rumschlagen muss und vielleicht ist es auch der Grund, warum Scrum irgendwann wieder von der Bildfläche verschwinden wird.

Zum einen ist es klar, dass ein Junior jemand ist, der gerade in den Beruf eingestiegen ist. Dies kann dadurch bedingt sein, dass er die Uni gerade verlassen oder seine Ausbildung erfolgreich abgeschlossen hat. Ich glaube darüber kann man sich einig sein. Wann man diese berufliche Phase verlässt muss man für sich oder die Firma definieren. Mein Kollege hat von einem Bekannten erzählt, der so ziemlich das beste auf dem Markt ist, was es man an technischen Wissen in dem Gebiet finden kann. Ganz klar Senior.

Ok, bei dem ganz klar konnten wir uns nicht einigen. Ich finde es schwer den Junior- und Senior-Titel nur an dem fachlichen Wissen festzumachen. Ein Senior ist für mich eine Person die einen Junior anleiten kann. Dazu gehört auf jeden Fall viel fachliches Wissen, denn er muss nicht nur eine Ahnung haben davon, wie man ein Problem löst, sondern auch warum man den gegangenen Weg einschlägt. Nur so kann man als Lehrer erfolg haben. Über den fachlichen Teil kann man sich also einig sein. Was gehört aber sonst dazu?

Die Kunst anderen Personen etwas beizubringen. Um fachliches Wissen weiterzugeben gehört mehr dazu, als es zu besitzen. Kennen wir sicher alle auch aus unserer Schulzeit. Die besten Lehrer waren nicht unbedingt die, die alles wussten, sondern die es geschafft haben uns das auch beizubringen. Die Kunst zu lehren ist also ein weiterer Bestandteil.

Ich denke das reicht aber noch nicht. Ein Senior muss strukturiert arbeiten können und die richtigen Prozesse wertschätzen. Ein Hitzkopf, der immer wieder reagiert und nicht vordenkt und so unberechenbar wird ist schädlich für jede Projektkalkulation. Egal wie gut er fachlich ist.

Eine weitere Eigenschaft eines Seniors ist sicher die Kompetenz sich mit dem Management unterhalten zu können. Also auf eine Metaebene zu wechseln, die von anderen Nicht-Informatiker verstanden wird.

Das war meine kurze Definition von Senioren und Junioren. Ihr habt sicher ganz andere und ich bin mir auch sicher, dass wir in einer Diskussion weitere Eigenschaften finden. Deswegen würde ich mal sagen, dass ihr jetzt dran seid.

Jetzt aber wieder zum eigentlichen Artikel. Ich habe das Glück momentan in einem Projekt zu arbeiten, in dem wir eine sehr hohe Prozessreife haben. Dass heißt wir haben uns Standard geschaffen, wie man mit Themen umgeht und sie löst. Was aber mit einer hohen Prozessreife immer auch mit einhergeht sind Verantwortungen. Igitt, dass ist ja mal gar nicht was man haben will. Auf einmal kann man mir ans Bein pinkeln, wenn etwas schief geht? Jap genau. Prozessreife bedeutet, dass man auch mal zur Sau gemacht wird. Oder besser für etwas gerade stehen muss, was man selbst verbockt hat. Es bedeutet aber auch klar definierte Ansprechpartner, klare Aufgaben einzelnen Personen zugeordnet. Natürlich ist es einfacher im großen Wirrwarr eines Projektes unterzugehen, für den Erfolg ist es aber nicht zuträglich.

Das Verantwortung nicht immer angenommen wird, kann man mit einem einfachen Experiment mal ausprobieren. Wobei das wohl jeder schon mal erlebt hat. Eine E-Mail mit bitte um Feedback an alle Kollegen senden. Wer wird antworten? Sicher nicht jeder, es gibt so Tage, da ist man froh, wenn sich überhaupt jemand angesprochen fühlt. Wenn man zu einem späteren Zeitpunkt direkt die Namen der Kollegen mit in den Mail-Text packt, wird es schon besser aussehen. Dediziert an die einzelnen Kollegen zu schreiben wird den größten Erfolg versprechen.

Sicherlich sinnvoll bei der Vergabe von Verantwortlichkeiten ist das Aufstellen einer RACI-Matrix (was ich die nächsten Tage mal erklären werde). Zumindest ist es der erste Schritt zu erkennen, wer eigentlich was macht und wer im Zugzwang steht.

Verantwortung bringt aber zum Glück auch viele Leute dazu kreativ zu werden. Wenn man Erfolge aus einem bestimmten Bereich mit ihnen verbindet sollte dies nicht zu ihrem Schaden geschehen.

Wie der Titel schon sagt, geht es heute um Kinderlieder. Nicht. Es geht vielmehr um ein Experiment, welches mit Affen durchgeführt wurde. Ich versuche es mal wissenschaftlich korrekt wiederzugeben, aber die Idee dahinter ist das Wichtige.

Man nehme einen Raum bzw. Käfig voller Affen. Jetzt hängt man eine Banane mitten in den Raum und stellt die passende Leiter inReichweite. Klingt jetzt alles erstmal recht nett. Das gemeine ist, wenn ein Affe versucht die Banane zu zu pflücken wird von denWissenschaftlern eine Sprinkleranlage mit Eiswasser angeschaltet. Nicht mehr ganz so nett. Was kurz darauf passiert ist einfach. Jeder Affe weiß, dass die Banane eine Gefahr ist und wird sich nicht mehr bemühen, sie zu bekommen. Dumm sind die süßen Tiere ja nicht.

Im nächsten Schritt nimmt man einen Affen aus dem Käfig raus und setzt einen neuen rein. Der weiß natürlich nicht von der Eisfalle und versucht die Banane an sich zu nehmen. Da die anderen aber wissen, was passieren wird halten sie ihn auf und hauen ihn auf die Finger. Wahrscheinlich bewerfen sie ihn mit Kot, soll ja so eine Art Geheimwaffe der Affen sein. Das Ganze wiederholt man jetzt, bis kein Affe mehr im Eisregen stand und durch neue ausgetauscht wurden.

Was jetzt passiert ist interessant. Obwohl keiner weiß, dass es den Eisregen gibt, verteidigen sie trotzdem die Banane gegen die anderen Affen. Was die Wissenschaftler jetzt machen ist die Sprinkleranlage auszuschalten. Ab jetzt ist es keine Gefahr mehr sich einen Bananenmüsli zuzubereiten. Trotzdem wird sie nicht angefasst.

So jetzt wieder in den Büroalltag zurück, bei dem es ja häufig auch nur so von Affen wimmelt. Meine Kollegen natürlich ausgenommen (und das meine ich sogar ehrlich, ist aber wahrscheinlich tagesabhängig). Wie oft hat man eine tolle Idee, die man vorbringen will und irgendein Kollege sagt, dass man das vor langer Zeit schon einmal probiert hätte und es nicht geklappt hat. Diese Leute laufen rum und greifen alle an, die etwas versuchen, was früher schon mal probiert wurde. Erinnert uns an die Affen, oder?

Es ist wichtig aus Erfahrungen zu lernen. Es ist aber auch wichtig Änderungen im Unternehmen zu erkennen. Auch Firmen reifen und etwas das früher keinen Erfolg hatte, muss heute nicht auch daneben gehen. Wichtig ist es zu wissen, an welchen Stellen damals angeeckt wurde und wie sich diese Bereiche entwickelt haben.

Mir hat das Gleichnis mit den Affen in Diskussionen immer geholfen, weil sich keiner gerne auf eine Stufe mit den Primaten stellen will.