Langweilige Zeiten?

Ehrlich gesagt ist mir gerade ein bisschen langweilig. Auch beruflich. Klingt überraschend? Nun, einerseits passiert sehr viel. Andererseits hantieren wir doch hauptsächlich mit Dingen, die es schon lange gibt: Elektromotoren gibt es seit 100 Jahren. Digitale Cockpits? Haben wir nicht erfunden, führen wir nur jetzt erst ein. Digitale Medien? Gähn. Vernetzung, Online Updates? Touchscreen? Digitalisierung?? Behauptet da jemand, das sei neu?

Neu ist, dass nun auch gelernte Maschinenbauer das in ihre Produkte einbauen und "integrieren" müssen. Neu sind die agilen Methoden (und Mentalitäten), die mit einem Bruchteil der früher hierarchischen, wie Behörden tickenden, Silos auskommen. Und das ist das einzige, was mir daran Spaß macht: Transparenz zu schaffen, im Ganzen zu denken, jeden zum Mitdenken aufzufordern und sich selbst aus dem Ziel abzuleiten, was er für seinen Beitrag tun muss.

Oh ja, es war (und ist) ein Kampf. Als ich das erste Mal eine Besprechung (mit Beschlüssen und Aufgaben) auf einem Confluence Wiki dokumentierte, und alle anschließend eine Email mit ihren Aufgaben vom Server bekamen, sprangen einige im Dreieck: Ich sei nicht befugt, ihnen Aufgaben zuzuteilen...

Wenn man da vorher in einem "Lab" gearbeitet hat, fasst man sich nur an den Kopf. Und ich hatte mehrere solcher Kämpfe. Und ich bin geblieben und sie sind gegangen. Und wir haben gemacht, was ich vorgeschlagen (und exerziert) hatte und ich bekam erst noch mehr "Eskalation" und jetzt machen wir, was ich von Anfang vorgeschlagen habe.

Ich erlebe das mit Genugtuung. Für Euphorie bin ich zu müde. Abgekämpft. Vor allem, dass ich da meist allein kämpfen muss - und viel Kommunikation in rückwärtige Absicherung stecken muss, kostet mich viel Energie. Es funktioniert am Ende, ja. Aber ich fühle mich auch ein bisschen ermattet.

Und ich merke, dass ich mich selbst nicht mehr mit glitzernden Innovationen motivieren kann. Sondern mit dem Erlebnis, dass Leute ihre Meinung ändern, ihren Widerstand aufgeben.

Andererseits habe ich da gerade einen interessanten Blog über Apple's erste Smart Glases gelesen. Und welchen Beitrag die Erfahrungen mit ihren Air Tods (den drahtlosen Kopfhören) machen. Wie diese auch als Geräuschfilter gegen die Außenwelt wirken, und eine Funkverbindung zu Kontakten aufbauen können. Wie man sich mit diesen Dingern im Ohr in einer Disco mit jemand anderem verbinden kann und gut verständlich telefonieren kann.

Das könnte noch aufregend werden. Aufregender jedenfalls als digitale Autos... ;-)

Manager im Digital Lab..

Die Welt der Autosoftware ist auf bestem Weg dorthin, wo sie keinen Erfolg haben wird: Ins Land der eitlen Könige und gefühlten Popstars.

Solche Projekte wie ein Betriebssystem für die eigenen Steuergeräte entwickelt man am besten von klein auf. Mit einem Kernteam, dem man einigermaßen planbare Randbedingungen gibt (wie z. B. eine künftige Hardware Architektur, Anzahl der Steuergeräte, Vernetzungsbandbreiten und -qualitäten).

Man muss ja erstmal vertraut werden damit, wie sich Zuliefererarbeit "von innen" anfühlt. Dann erstmal die Kernfunktionalitäten entwickeln und dann ausbauen.

Aber nicht: Wir gründen eine neue Division mit 5.000 Leuten und bedienen alle Marken und ordnen uns sofort dem nächsten Serienstarttermin unter. Damit landet man wieder da, wo man mal abgesprungen war: Bei einem Softwarechaos, das der höchsten Priorität ("bringt es irgendwie zum Laufen") entspricht.

Meine Prognose ist: Das wird schief gehen, länger dauern. Und nach dem ersten Serienstart wird man das Gewerk eben nicht direkt weiterverwenden können, sondern weit zurück gehen müssen, um aus all den gemachten Fehlern zu lernen.

Zudem drängeln sich etliche Manager in die Sache, die man nicht braucht, aber die einen Versorgungsanspruch auf einen Rang haben. Und die sich die Sache gerne ans Revert heften würden. Räder, die nicht antreiben, sondern bestenfalls mitlaufen ("Schleppmoment") und nicht bremsen.

Schade. Wenn wir diese erste Welle dann hinter uns haben werde ich fast schon ein Kandidat für die Altersteilzeit sein ;-).

Lähmschichten im Scrum

Wohin nur mit all diesen angststarren mittleren Managern? Selbst wenn Du ein funktionierendes "Scaled Agile" Projekt am Laufen hast, und transparent berichten willst, was funktioniert und was nicht - dann grätschen Dir die kleinen Fürsten dazwischen und verschleiern wieder die Fakten. Das alte Denken, bei dem man darauf hofft, dass andere System-, Modul- oder Funktionsverantwortliche zuerst das Handtuch werfen, damit man es selbst nicht tun muss, sitzt so tief wie zu Kaiser Wilhelms Zeiten. Normalerweise solltest Du die Stände aller Teilprojekte transparent auf dem Wiki lesen können.

Aber wozu, so fragen untere und mittlere Leitende, "wozu haben wir denn das Rechtemanagement", wenn nicht dazu, den technisch abhängigen Kollegen die Sicht auf den Stand zu versperren?

Dazu kommt: Wenn man zu viele Schichten Lähmschicht hat, dann bekommt das Topmanagement nichts mehr davon mit - und engagiert Unternehmensberater (!). Die beherrschen dann auch beides: Die Wahrheit, und das was das Topmanagement hören will...

So wird das nichts werden. Die Transformation wird nicht ohne Ruppigkeiten und Regelverstöße ablaufen. Aber auch da hat man ja vorgesorgt, indem man ein Meldesystem installiert hat, in dem man anonym sofort pfeifen kann, wenn einem etwas nicht passt. Super.

Bin etwas skeptisch. Andererseits, andere Großunternehmen haben die Kurve auch schon mal gekriegt.

Aufgeblasene Organisationen

Bevor die Künstliche Intelligenz in Deutschland irgendwelche Arbeitsplätze für Menschen ersetzt wird eine andere Welle durch unser Land rollen. Und die heißt "Smart + Leon" - so nenne ich sie mal.

Fangen wir in Berlin an. Nicht bei den Digital Labs und Startups. Sondern in der Bundesverwaltung. Die Bundesregierung profitiert seit Jahren von Rekordsteuereinnahmen und verplempert sie. Anstatt ihre Pflichten zu erfüllen um den Laden am Laufen zu halten und die Einnahmen von morgen zu sichern, verschleudert sie die Milliarden an ihre Günstlinge. Abwechselnd bedient sie "neue" Wählergruppen und Parteimitglieder.

Es werden Behörden gegründet, was das Zeug hält. Und da man leicht den Überblick über das Bundesdickicht verlieren kann, gründen die Minister auch Behörden, die den Zweck haben, andere Behörden zu "koordinieren". Ich kannte das vor 15 in der Landesverwaltung von Berlin/Brandenburg. Gründernetzwerke und so. Dauernd gründete sich irgendwo ein "Netzwerk", und lud zu Häppchen in einer IHK oder sonstigen öffentlichen Einrichtung ein. Gerechtfertigt wurden diese Ausgaben immer damit, dass man junge Unternehmen zusammenbringe und über Fördermöglichkeiten informieren wolle. Also, man stellte nicht nur Mittel in den Haushalt, die an Unternehmen als Kredite oder Coförderung weitergereicht werden sollten. Sie waren obendrein so komplex und bedingt, dass man zusätzlich einen Berater brauchte, der es ihnen erklärte. Und da das immer noch nicht funktionierte, machte man zusätzlich "Events". So belohnt sich die Verwaltung für ihre eigenes Versagen und das ihrer Regierung. Sylvana Koch-Mehrin hatte eine Beratung für EU-Förderung, in der sie ihr Wissen über den EU Förderdschungel einer Zweitverwertung zuführte.

Kein Mensch braucht Wirtschaftsförderungsgesellschaften etc. außer um als Standort um ansiedlungswillige Unternehmen zu werben. Das wiederum war den Angestellten von Berlin Partner und Invest-in-Brandenburg meist zu mühselig. Wowereit und Strauch kokettierten im kleinen Kreis stets damit, dass sie von Wirtschaft nüscht verstünden, aber das sei auch nicht nötig, denn man renne ihnen die Türe ohnehin ein.

Aber jetzt bin ich abgerutscht. Halten wir fest: Diesen sich selbst unterhaltenden Zirkus braucht kein Mensch.

Aber auch in den großen Verwaltungen der Aktiengesellschaften könnte es demnächst merklich schlanker zugehen. Zum Beispiel in der technischen Entwicklung.

Die Vorstellung, dass ein Autohersteller tausende von Leuten braucht, um zu beschreiben, was entwickelt werden soll, und um zu testen ob es funktioniert, ist falsch. Aber sie ist auch Realität. Zu erkennen an den in der Vergangenheit gewachsenen Koordinatorstellen. Unnötige Produktkomplexität (insbesondere die Disziplinlosigkeit bei der Vermeidung von Varianten) in Kombination mit dem Need-to-know-Prinzip ("Wir sagen dir nur, was du wissen musst.") schafft schnell Bedarf an Koordinatoren, die den Wasserkopf durchblicken sollen. Und für alles, was man schafft, braucht man irgendwann noch mehr Infrastruktur. Abteilungen, Leitende, Budgets.

Die Unterabteilungs- und Abteilungsleiter werden sich aber noch wundern, mit wie wenig Leuten die Entwicklung von Plattformen für autonomes Fahren und Infotainment im Kern braucht. Man braucht nach wie vor die Verantwortlichen die Design, Funktionen und innere Struktur vorgeben. Und man braucht die Codierter. Aber die Umwandlung des Quellendes in Objektcode, das Flachen auf die Platine und die Tests kann man automatisieren.

Aber wie gesagt: Es braucht Disziplin, Entscheidungsfreude und -sicherheit. Komplexität entsteht auch durch "Im Zweifel machen wir beides", wenn der Entscheidet nicht mehr versteht, was er entscheiden soll.

Ich bin z. B. ein Befürworter davon, Bluetooth rauszuschmeißen, wenn wir WLAN im Auto bekommen. Zuhause brauchen wir kein Bluetooth um zu telefonieren oder Musik zu hören, weil wir WLAN haben. Es ist zudem breitbanniger. Und es verbindet bekannte Geräte automatisch. Sollen Kunden ihr Smartphone (oder Smart Glass) im Auto 2x anmelden?

Ich hörte 10 Gründe, es drin zu lassen. "Oder wenigstens dieses eine mal noch drin zu lassen." Weil der Kunde es so wolle. Na klar. So wie 2008: "Unsere Kunden googeln nicht."

Aber auch in der Unternehmens-IT brauchen wir weniger Leute. Dafür mehr Kompetenz. Gott sei Dank sind diese alten SAP-Projektschlachten vorbei. Wo sich IBM und wie sie alle hießen mit ungelernten SAP "Fachberatern" ins Renne warfen und es dann nicht hinbekamen. Und dann "Schnellboote" gründeten..

Ich prognostiziere einen Personalabbau in der technischen Entwicklung von Autoherstellern von mind. 50% in den nächsten 10 Jahren allein aufgrund des beschriebenen Effekts und er Softwareentwicklung. Dazu kommen die Vereinfachungen im Antrieb, vor dem die süddeutsche Metallindustrie schon zittert.

Neue Arbeitsplätze entstehen beim Autohersteller, aber auch in der neuen Peripherie des Autos. Backendfunktionen und vor allem Datenmanagement für Verkehrsinfrastruktur und Verkehrsteilnehmer.

Auch die Mentalität von Leitenden, ihre Motivation, muss sich ändern. Kopfzahlen können nicht länger das Ziel eines Leitenden sein. Sondern er sollte auf Ergebnisse verpflichtet werden und Potenziale ausschöpfen. Ich habe Zweifel, dass alle gegenwärtigen Leitenden das können oder wollen.

Scaled (Fr)Agile

Mit einem Tropfen Öl kann man so und so viele Liter Trinkwasser vergiften. So ähnlich ist das mit dem "Firnis der Zivilisation", der ausgerechnet von Linken wie Wolfgang Schäuble betont wird, wenn man über Weltkriege spricht. Firnis ist der farblose Schutzanstrich, der den wahren Kern zwar zeigen aber auch schützen soll.

So ähnlich ist es aber auch mit agilen Methoden für die Softwareentwicklung. Es funktioniert nur, wenn alle eine positive, eigene Motivation haben.

Weder funktioniert es mit Leuten, denen man jeden Tat jede Woche sagen muss, was sie als nächstes tun sollen. Das müssen sie selbst erkennen. Sie müssen auch von sich selbst wissen, welche der Aufgaben im Arbeitsvorrat sie am besten umsetzen können. Wenn der Rhythmus aus Sprints und Meilensteine nicht anspringt und läuft wie ein 12 Zylinder sondern man in jedem Arbeitstakt auf die Einhaltung des Taktes achten muss, wird es nicht laufen.

Wenn Du 10 Product Owner mit Epics versorgst, und sie haben Rückfragen, die sie nie in der Gruppe sondern nur unter 4 Augen zu stellen wagen, ist Dein Zeitkontingent für die Woche schnell verfrühstückt.

Ja, man darf einwenden, dass es auch an mir liegen könnte. Dass ich die Episch nicht klar genug beschreibe. Die Trennlinie der Verantwortung liegt in der Tiefe: Ich beschreibe von allem den Umfang und das gewünschte Verhalten. Einzelheiten der Umsetzung müssen mit dem Architektenteam und/oder dem Technikteam auf Kundenseite besprochen werden.

Und wo wir gerade Missverständnisse aufklären: Der Sprint Review ist keine Verkaufsveranstaltung. Nein, sie ist nicht DIE Gelegenheit, sich von anderen Product Owner abzugrenzen. Sie ist der Ort an dem Du vor "Mächtigen" die Wahrheit sprichst -als Teil eines Teams.

Und hey, Kundenrepräsentanten: Sprint Review ist auch nicht der Ort, über Arbeitszeiten und Überstunden zu diskutieren.

Was sagst Du? Nein, mich interessiert nur, dass alles rechtzeitig fertig wird. Wann die Teams etwas beginnen, ist Prio 2.

Wenn Du dem Projekt signalisierst "Hey, ich lasse mich gerne als Hipster eines coolen Startups feiern und präsentiere gerne in Turnschuhen und T-Shirt, dann signalisierst Du den Entwicklern: Ich bin ein Teil von Euch. Vision und Ziel sind alles, Hierarchie und Druck ist etwas für Ewiggestrige."
Und wenn Du dann beim ersten Status "Nicht erreicht" sofort nervös wirst, weil Du nicht einschätzen kannst, wie kritisch das jetzt ist, dann solltest Du besser beim vertrauten Schmerz bleiben.

Denn was Du mal eben heraus posaunst das kannst Du nur schwer wieder zurücknehmen. Das bleibt dann uns überlassen. Die Sandwichposition gibt es auch in der agilen Welt.

Komplett vertikal!

Agile Vorgehensweisen für große Softwareprojekte nennt man auch "Scaled Agile". Es drückt die Hoffnung aus, das was im kleinen Projekt gut funktioniert, "skalieren" zu können.

Eine besondere Spezialität entsteht, wenn man "skaliert agil" Software für eingebettete Systeme entwickeln will. D. h. wenn man sich auch um die Hardware kümmern muss. Prozessoren, Speicher, Board Support Package etc. müssen entweder spezifiziert werden oder bei einem Zulieferer angefordert werden.

Und weil das immer noch zu einfach ist, darf die Hardware nicht "zu früh" verfügbar sein. So dass man sich mit Ersatzhardware begnügen muss.. 

Gut, denkt der Product Owner. Dann müssen wir eben einplanen, dass wir nicht alles immer sofort komplett testen können. Wohl aber entwickeln wir trotzdem"complete vertical". Und "hardware agnostic". 

"Sounds good, doesn't work."
Donald Trump

Moment, sagt der Zulieferer: Einen festen Termin für die Hardwarelieferung geben wir Dir aber nicht. Wir sind ja auch auf Zulieferungen angewiesen. Und der von Euch benannte Lieferant hat Produktionsschwierigkeiten.

Wenn das so ist, sagt dann der Endkunde, dann überlege ich mir noch mal, welche Hardware ich von wem brauche. Und wenn wir schon sprechen, können wir ja auch den Releaseplan noch mal besprechen.

Fragt der Product Owner: Wogegen soll ich planen, wenn Ihr sogar die Termine beweglich haltet, zu denen wir die Zielhardware bekommen sollen?

Antwort: Seit doch froh, wenn Ihr mehr Zeit bekommt.

Ja schon. Aber drei mal drei Monate dazu zu bekommen ist nicht das gleiche wie von Anfang an 9 Monate zu haben. Wir laufen drei mal Spurt statt einmal Marathon. 

Komplett vertikal verstehe ich inzwischen so: Mit den Füßen stehen wir in der Hölle und spüren die Hitze. Mit dem Kopf sind wir über den Wolken und mit den Händen greifen wir nach den Sternen.

Aber noch ist alles möglich...

German Engineering

German Engineering - es kämpft immer noch mit den "Geheimnissen" der Softwarewelt und der Benutzerfreundlichkeit.

Dialog mit einem Altsystembetreuer:
Ich: "Haben Sie eine aktuelle Anforderungsbeschreibung mit Geschäftsprozess und Anwendungsfällen?"
Er: "Nein. Wozu?"
Ich: "Na, damit wir nicht blind nachbauen, was sie heute haben sondern Prozesswissen und Anwenderpräferenzen mit reinnehmen."
Er: "Das ist in diesem Fall unnötig, denn wie der Prozess läuft, ergibt sich ja aus meinem System. Woher sollen die Anwender etwas über den Geschäftsprozess wissen?"

So läuft es in vielen hierarchischen Organisationen - von der Verwaltung bis zur Automobilindustrie. German Engineering weiß alles und was es nicht weiß, das überlegt es sich.

Über Technik weiß German Engineering auch alles. Aber speziell bei Software ist das Problem, dass man sich über Inhalte abstimmen muss, mit sehr verschiedenen Gruppen. Und anders als im Maschinenbau oder einer Platine sieht man Software erst beim Ablauf -also hinterher- an, was sie tut. Und wie gut ihre innere Struktur ist, weiß man wenn man das Produkt weiter entwickeln muss.

Obwohl so viel über Anforderungs- und Architekturmanagement, über Projektmanagement und agile Entwicklung geschrieben wurde, bis heute ist das in Deutschland nur wenig verstanden. Es gibt auf der einen Seite die bereits Überzeugten. Mit denen ist sofort alles klar. Und mit den anderen kann man reden "bis die Kühe zurückkommen" - es nützt nichts. Diese in der Hierarchie und im Konformismus verstrickten -oft auch klassisch ambitionierten- Projektkollegen hören im guten Falle zwar noch zu. Aber es genügt eine Email vom Management und sie schmeißen alles über den Haufen und fragen nach dem Jetzt-mal-ernsthaft-Projektplan.

Es fehlt der Mut an die eigene Fähigkeit, es überwiegt die Sehnsucht nach Ansage von oben und Planerfüllung.

In der Projektanfangsphase sind diese vergraben in ihren neuen Stoff - nicht ansprechbar, nicht kommunikativ, nicht kooperationsfähig. Wenn sie dann etwas verstanden haben und dem Management vermitteln können, sie wüßten nun, wie es geht, beginnen sie den Konkurrenzkampf. Und dann ist es aus mit agiler Arbeitskultur.

Deutsche Manager und auch Staatssekretäre erzählen gerne und viel vom Silicon Valles, wenn der Tag lang ist. Aber sie sind in ihre Positionen in Deutschland nur gelangt, weil sie NICHT so sind wie die Leute im Silicon Valley.

Auslegungsvarianten der Product Owner Rolle

Wer im Anforderungsmanagement "groß" geworden ist, wundert sich bisweilen über die sehr unterschiedlichen Auslegungsarten seiner neuen Rolle "Product Owner" in agilen Projekten.

Product Owner kompilieren aus dem Bedarf ihrer Anspruchsgruppen Anforderungen und kommunizieren sie in geeigneten Formen an das Entwicklungsteam. Insofern muss ein Product Owner mindestens zwei Sprachen sprechen:

- Die seiner Anspruchsgruppen, z. B. Geschäftsprozesse oder Produktfunktionen.
- Die der Softwareentwickler und Architekten. z. B. funktionale und nicht-funktionale Anforderungen

Ein Product Owner muss nicht alles wissen, aber er muss alles Wichtige in Erfahrung bringen und Klärungspunkte erkennen können. Wer muss was wann wissen und wann klären diesen Punkt - nicht unnötig früh, nicht zu spät?
Es entstehen zwei Kommunikationsrichtungen: eine von oben nach unten, die die Vorgaben und Richtungen festlegt. Und eine von unten nach oben, die die Machbarkeiten prüft und Einwände kommuniziert. In der Mitte entsteht das sinnvoll Machbare.

Da ich beide Welten kenne - Unternehmenssoftware und Steuergeräte- würde ich sagen, die Welt der Unternehmenssoftware ist hier weiter als die der Steuergeräte. Mit Ökonomen und Informatikern kommt man schnell in ein methodisches Fahrwasser und legt erst einmal einen sinnvollen Arbeitsfluss fest. Mit Steuergeräteingenieuren geht es oft sehr schnell in Richtung technischer Details - ohne die Perspektiven anderer Gruppen -zum Beispiel Anwender- einzunehmen. Damit meine ich nicht, dass Usecases unter den Tisch fallen. Sondern dass man glaubt, diese selbst ohne Rücksprachen festlegen zu können.

Ich bin jedes mal sehr dankbar, wenn es im Projekt einen guten, erfahrenen Systemarchitekten gibt. Mit ihm kann ein Product Owner "über alles reden". Am besten sitzt man mit ihm oder ihr Tür an Tür oder im selben Raum.

Ingenieure bestätigen einander gerne und suchen selbst für sich die Bestätigung ihres Expertenwissens. Das gilt auch für solche, die sich agil nennen. Ein Product Owner schätzt Experten, braucht aber keine Domänen, die nach außen nicht gut kommunizieren. Dieses Risiko besteht oft in Steuergeräteprojekten, aber man bedenke, dass auch sehr alte Softwaresysteme in Unternehmen und Verwaltungen von Programmierern mit Ingenieursmentalität geschrieben wurden. Hier lauert eine Fußangel und Falle nach der anderen. Auch Verunsicherungsangriffe auf den Anforderungsmanager oder Product Owner lauern hier. Es kostet viel Kraft, aber Ausdauer und Durchhaltevermögen werden am Ende (ca. 1 Jahr) belohnt. Obwohl ich das weiß, kostet es auch mich immer wieder Überwindung, mich nicht irre machen zu lassen. Weil ich mich ja nicht abschotten will, sondern mich bewusst dem Kommunikationsstrom aussetze. Und mit Annahmen arbeite. Und erst einmal Vertrauen bei den Meinen aufbauen muss. Die vielleicht selbst anfällig für diese Expertenkultur sind.

Somit komme ich zu dem Schluss, dass ein Product Owner auch das benötigt was früher im positiven Sinn unter Beratungsmentalität lief: Sensibilität, Hellhörigkeit, plus innerer Kompass plus dickes Fell.

Die meisten Anforderungsprofile an Product Owner stimmen deshalb m. E. nicht. Sie sind zu einseitig auf technische Expertisen ausgelegt.

Ich sehe hierin auch einen tief sitzenden Grund dafür, warum deutsche Startups nicht so erfolgreich sind, wie z. B. US-amerikanische. Es fehlt die Perspektive des Produktmanagers, der aus Endkundensicht Anforderungen beschreibt und priorisiert.

Anforderungserhebung in hierarchischen Organisationen

IT-Projekt
Phase: Anforderungsmanagement
Anforderungsquelle: Mitarbeiter
Anforderungserhebung: Geschäftsprozess-Workshops

Lektion:
Je hierarchischer die Organisation, desto mehr tendieren die Mitarbeiter dazu, ihre Tätigkeit anhand des Altsystems zu beschreiben.
Mitarbeiter: "Ich tue im System XY dies und das."
Product Owner: "Und zu welchem Zweck?"
Mitarbeiter: "Damit die Daten im System sind."
P.O.: "Ja, aber zu welchem Zweck. Und was bedeuten die Daten?"
Mitarbeiter: "Da müssen Sie den Chef fragen."

Daraus folgen Anforderungen, die sich sehr nah am Altsystem orientieren. Genauer: An dessen Design, Bedienoberfläche usw. Nicht an dem Zweck, der mit der Systembedienung erzielt werden soll. Auf diese Weise entstehen weder aussagekräftige Prozesse noch Datenmodelle.

Anders in Organisationen, in denen die Mitarbeiter nach Zielen geführt werden:
Mitarbeiter: "Ich als Kampagnenplanerin aktualisiere die xy-Daten mit den Eingaben von xy, um für die nächste Marketingkampagne aktuelle Adress- und Profildaten zur Verfügung zu haben."

Aha! Damit lässt sich schon wesentlich mehr anfangen. Hieraus kann man im weiteren Verlauf einen Prozess und ein Datenmodell ableiten.

Nebenbei: Die agile Methode nimmt Anforderungen ja in dieser Syntax auf: "Ich als ROLLE will TUN um ZWECK zu erreichen."

Diese Formulierung fällt um so leichter, je selbstverantwortlicher bzw. zielorientierter die Mitarbeiter geführt werden.

Shiny happy colleagues

Ich komme inzwischen selbst in die Jahre, die ich früher für alt hielt. Ich vermisse die Rastlosigkeit und Unsicherheit früherer Jahre überhaupt nicht. Inzwischen weiß ich "wie es geht" und ich kann locker auf die meisten Showtimes verzichten ohne Angst etwas Entscheidendes zu verpassen. Ich bin eher zurück zu mir selbst gekommen. Nichts geht über Erfahrung sage ich heute,  denn ich habe welche. Ohne Substanz geht es nicht. Und die Substanz ist auch in unseren akademischen Jobs etwas Greifbares. In meinem Fall: Softwareprodukte. Nicht Powerpointfolien, nicht Papiere, nicht Meetings. Nur Produkte und lächelnde Anwender.

Ich weiß, dass im selben Maße wie meine Erfahrung wächst ich darauf achten muss, nicht unkreativ zu werden. Deshalb schätze ich ergänzende Leute in meinem Team sehr. Junge Kollegen, gerne aus anderen Berufen, gerne aus anderen Ländern, gerne vom anderen Geschlecht. Aber immer mit dem gleichen Grundverständnis, dem gleichen Ziel. Diversität ist für mich kein Selbstzweck und in dem Moment in dem ein Unternehmen es zu einem seiner Ziele erhebt ist es auch schon vorbei mit dem Nutzen von "Diversität". Denn, was einer behauptet zu sein, das ist er nicht. Das ist mir verdächtig.

Wo Diversität drauf steht, da kann es vor Minen nur so wimmeln. Vorbei die Zeiten, in denen man "Diversität" gar nicht wahrgenommen hat, in denen man einfach zusammen gut arbeitete. Bei IBM fand ich es sehr inspirierend, in Wien mit österreichischen, ungarischen und britischen Kollegen und Kunden zusammen zu arbeiten. Nie wären wir auf die Idee gekommen, uns selbst dafür zu glorifizieren.

Heute diskutiere ich darüber, ob wir für die Darstellung von Rollen, Strichmännchen mit Krawatte oder Zopf nehmen. Das macht die Aufgaben für Projektmanager nicht einfacher. Die Begriffswelt wird um eine Dimension "reicher", wenn man alles gendern muss oder in der Verlaufsform darstellen muss. Wenn wir miteinander korrekt reden weiß ich nicht mehr, ob das Ausdruck von Überzeugung oder Konformismus ist. Konformismus ist ein Ausleseverfahren, bei dem man gewinnt, wenn man keine formalen Fehler macht. Und der öffentliche Raum von Politik und Verwaltung ist ganz besonders anfällig dafür.

Man kann den Spieß aber auch umdrehen und jede "diverse" Karriere auf Quoten zurückführen und sich ganz einfach weigern, solche Leute in den eigenen Verantwortungsbereich zu holen.

Der Bürokonformismus hat aber noch weiter reichende Folgen. Ich erlebe auch ein schrumpfendes Urteilsvermögen bzw. wachsende Verweigerung, Dinge zu beurteilen oder einzuschätzen. Da werden entscheidende Dokumente einfach "Zur Info" weiterverteilt - ohne eigene Einschätzung, ohne Hinweis, vielleicht ohne sie selbst gesichtet zu haben. Ich kenne Leute, die fragen andere gerne nach ihrer Einschätzung vermeiden es aber tunlichst selbst eine abzugeben. Selbst in Runden, die extra für Feedback oder Retrospektive vorgesehen sind. Sie tun es höchstens unter vier Augen, dann aber umso heftiger. In der Runde geben sie sich "team-" und "erfolgsorientiert". Man lächelt, man gibt sich abgeklärt, ironisierend überlegen, aber halt auf niedrigem Niveau. Etwa so wie in einer Jan Böhmermann Show.

Das ist keine gesunde Entwicklung. Wo nicht mehr offen gesprochen wird, da wächst der Raum für Intrigen. Da wird abgewartet, aufgelauert und zugeschlagen. Da wächst das falsche Leben in dem es kein richtiges geben kann.

Hören wir auf, Selbstverständlichkeiten auf Plakate zu schreiben. Diese Selbstverständlichkeiten sind Teil unserer Kultur. Man tut sie einfach und erwartet keinen Applaus dafür. Am Ende zählt nur die Substanz, das Produkt, die bezahlte Rechnung.