Das Management von Erwartungshaltungen

In Fachbereichen klassischer Industrieunternehmen herrscht nach wie vor fast vollständiges Unverständnis darüber, wie die Werkzeuge entstehen, die sie täglich benutzen.

Es dominieren unrealistische Vorstellungen davon, wie lange Softwareentwicklung dauert und warum. Sie rufen Dir heute eine "Anforderung" zu und fragen, ob Du es nächste oder erst übernächste Woche liefern wirst..

Das führt natürlich regelmäßig zu Enttäuschungen. wenn der Releaseplan "angepasst" wird. Schwierig ist es, wenn die Stakeholder ranghöher sind, als die Projektleitung des Softwareprojektes.

Man landet dann immer schnell beim "Management der Erwartungshaltung". Und es stimmt, dass man Erwartungen der Anspruchsgruppen besser selbst lenkt, als von ihnen gelenkt zu werden. Es ist aber fast immer schwierig, dies von Anfang zu tun. Denn meistens ist man selbst neu in einer eingespielten Szenerie. Man kommt gerade aus irgendeiner Art von Bewerbungsprozess und will nicht als erstes die zugesagte Leistungsfähigkeit zurücknehmen.

Was aber helfen kann, sind Analogien. Wie lange dauert es, bis SAP eine populäre Anforderung seiner Kunden umsetzt? Wie lange dauert es, bis Apple Betriebssysteme so aktualisiert, wie es sie auf seiner Entwicklerkonferenz gezeigt hat?

Manche Stakeholder haben in ihrer Jugend oder im Studium mal selbst programmiert. Hier ein Excelmakro, dort ein Fortran- oder C-Programm. Codiert, kompiliert, von Fehlern bereinigt, neu kompiliert, fertig. Alles auf ihrem PC. Von diesen eigenen "Programmiererfahrungen" schließen sie dann darauf, wie lange so etwas bei Unternehmenssoftware "dauern kann".

Außer Acht lassen sie: die Periodisierung von Anforderungen, die Verfeinerung, die Abhängigkeitsanalysen, das Testen.

Begründet wird der Druck meist mit: "Wir brauchen das jetzt." Wenn ich sie aber vor einem Jahr nach  ihren Prozessen oder Aktivitäten fragte, kam da nichts bis wenig. "Wir sind ja selbst neu, das Thema ist neu, wir müssen uns erst mal selbst finden. Aber fangt schon mal an. Wir brauchen ja nur eine editierbares Tabelle. Was wir machen ist nicht so kompliziert." Tja, und dann entstehen halt solche Außenwirkungen wie: Der Produktionsstart verzögert sich, wir wissen nicht, ob das Produkt überhaupt kommt usw.

Meine Erkenntnis ist: Es hat keinen Sinn, so zu tun, als sei es diesmal anders. Sage niemals zu, dass Du so schnell wie möglich, einen laufenden Prozess "schon bald" unterstützen kannst. Dass Sie Excel schon bald ablösen können. Sag ihnen zu, dass Du im danach folgenden Zyklus etwas liefern wirst. Nimm Dir und Deinem Team die nötige Zeit, tiefer zu verstehen, worauf sie eigentlich hinaus wollen. Gehe Top-Down vor, auch wenn sie Dir Bottom-Up oder nur Bottom anbieten. Frage nach den Topzielen, zu denen sie beitragen sollen (Was?) und den bestehenden Prozessen (Wie?). Du wirst dann die Frage beantworten "Womit?".

Obwohl Du ein "Lieferant" bist, muss Du die "Bestellungen" einfordern: Beschreibungen der Abteilungen, die Strategie, die Hauptprozesse. Welche Unternehmensziele wollen sie operativ wie erreichen? Erst dann kommt: Und wie kann IT dabei helfen?

Viele untere und mittlere Manager verstehen selbst nicht, wozu sie eigentlich beitragen sollen. Sie reichen Dir einfach das Genörgel ihrer Mitarbeiter weiter und nennen das "Anforderung". Wenn Du solche nach Prozessen fragst und als Antwort "Papierkrieg brauchen wir nicht" bekommst, weißt Du, dass der Weg bis zum ersten Sprint noch weit und steinig ist.

Wie auf einer Reise musst Du wissen, wo Du ankommen willst. Und zwischen A und B planst Du eine sinnvolle Route. Wenn man Dir das Ziel verschweigt und sagt "plane erst mal nur bis Wanne-Eickel, wir sind ja agil" muss die Warnlampe angehen.

Ferne musst Du die Systemstruktur kennen, in der Du Dich bewegen kannst. Rede mit dem oder den Architekten. Jeden Tag. Sitzt am besten im gleichen Büro und beschreibt die Whiteboards. Macht Euch alles klar.

Wenn Du das Ziel kennst und die Route, kannst Du das richtige Transportmittel auswählen.

Die Bedeutung der System Architekten

Eine der wichtigsten Erkenntnisse meiner Jahre in Labs und Beratung war die Bedeutung der System Architekten in Softwareprojekten.

Davor waren IT-Architekten für mich als Fachprojektleiter oder Product Owner eher eine Hürde, die ich nehmen musste. Man buchte gemäß Projektplan eine Besprechung mit ihm und nahm seinen IT-Projektleiter und den Senior Entwickler aus dem Team mit. Man präsentierte sein Vorhaben und Implementierungsvorschlag. Dann nickte der Architekt oder schüttelte den Kopf - und legte ein oder zwei Implementierungsalternativen fest. Das war es dann. Man hatte gewonnen oder verloren und ging wieder und setzte seine Vorgabe um. Einen Nutzen sah ich in diesem Termin früher nie.

Inzwischen sehe ich das komplett anders.

Der System Architekt ist der ideale Sparringspartner für den (System) Product Owner für die Aufdeckung technischer Abhängigkeiten und Risiken. Ich saß als System Product Owner in einem Großprojekt mit dem System Architekten im gleichen Büro. Wir waren täglich in einem Dialog über die Zusammenhänge von Systemverhalten (funktionale Anforderungen) und der dafür nötigen Struktur (Architektur). Er lernte von mir, welches Systemverhalten ich morgen sehen wollte gemeinsam leiteten wir -zusammen mit den Subarchitekten und Product Ownern der Featureteams die nötigen Systemfähigkeiten ab. Der System Architekt leitete daraus dann eine übergeordnete System Architektur ab, bzw. erweiterte oder aktualisierte diese. Wöchentlich reviewte er mit den Subarchitekten deren Implementierungsvorschläge.

Die Architektur war DER Bezugspunkt, auf den sich alle Entwickler beziehen mussten. Für mich war die Systemarchitektur die Randbedingung, die ich akzeptierte, weil ich aus der Abstimmung darüber wusste, dass sie meine hochpriorisierten Anforderungen unterstützen würde.

Auch dritte Parteien, die die von uns entwickelten Services und Komponenten später nutzen würden, konnten sich früh auf die dokumentierte Architektur ausrichten.

Die beiden Rollen -Architekt und Product Owner- sind wie Gas und Bremse. Der eine sorgt für Traktion, der andere dafür, dass wir nicht aus der Kurve fliegen.

In den Gegenverkehr abbiegen

Ich habe damals bei der Bundeswehr einen LKW-Führerschein gemacht. "Das beste, was man da mitnehmen kann." sagten mir damals alle. Ich bin nach der Bundeswehr nie wieder LKW gefahren. Aber trotzdem habe ich aus dieser Fahrschule eine Lehre für's Leben mitgenommen. Und die geht so:

Während für PKW-Fahrer das Linksabbieger das schwierige Manöver ist, ist es für LKW-Fahrer das Rechtsabbiegern. Zumindest, wenn man noch einen Anhänger hinten dran hat. 

Aktuell haben wir ja in Berlin das Phänomen, dass rechtsabbiegende LKWs Fahrradfahrer und Fußgänger überfahren, die sich rechts von ihnen im toten Winkel befinden. (Wobei ich mich immer frage: Wie kann man als Radfahrer und Fußgänger LKWs übersehen? Als Schwächerer achte ich doch automatisch auf die Stärkeren.) Aber das meine ich gar nicht, sondern:

Wegen der Schleppkurve das Anhängers muss man beim Rechtsabbieger meistens bis zur Gegenfahrbahn ausholen. Ich habe da anfangs immer gewartet, dass mich der Gegenverkehr abbiegen "lässt". Mein Fahrlehrer lehrte mich aber: "Da lässt dich keiner. Dieses Recht musst du dir nehmen. Dann weichen die schon zurück."

Und genau so funktionierte es. Man muss zwar langsam, aber stetig abbiegen, um den anderen zu signalisieren: Ich ziehe durch, ich bin vorsichtig, aber wir müssen es alle hinter uns bringen. Wenn man es den andere unmissverständlich klar macht, weichen sie aus.

Das gilt inzwischen auch für den Bürgersteig. Vorbei sind die Zeiten, als man sich tendenziell rechts hielt. Vorbei also, dass man beständig vorwärts kam ohne ständig ausweichen zu müssen. Heutige Zeitgenossen kennen dieses praktische Regel offenbar nicht mehr. Jeder versucht seine Ideallinie zu laufen. Und das in der ständig überfüllten Stadt Berlin. Leute kommen aus dem Kaufhaus und müssen erstmal alle vorbei Strömenden kreuzen.  Leute wollen an der nächsten Kreuzung links, dann schneiden sie schon mal rechtzeitig. Viele schauen auf ihr Smartphone und wissen meistens nicht, wo sie gerade sind. Erst im letzten Moment schauen sie entrüstet auf und weichen dann aus. 

Ich bin früher ausgewichen, heute ziehe ich durch. Ich gehe rechts und erwarte dass vom Gegenverkehr auch. Eine Zeit lang habe ich immer weggeschaut. Weil ich gemerkt hatte: Wenn der andere merkt, dass du ihn bemerkt hast, dann erwartet er, dass du ihm ausweichst. Nichts sehen, nichts hören war also eine Zeit lang meine bequeme Taktik. Inzwischen mache ich es anders: Ich schaue die auf meiner Spur Entgegenkommenden an und halte auf sie zu. Irgendwie aus den Knien heraus gehe ich bewusster. Und dann weichen sie aus. 

Ich bemerke bei jungen Männern unterschiedliche Reaktionen. Europäer weichen einfach aus, pragmatisch. Arabischstämmige junge Männer versuchen oft zusätzlich ihre gefühlte Niederlage zu überspielen, in dem sie ruckartig ihren Schritt ändern, so als hätten sie bemerkt, ohnehin in der flachen Richtung unterwegs zu sein. Zumindest aber, dass sie ihre Richtung eh gerade wechseln wollten. Offenbar ist ihnen das Wer-weicht-wem-aus-Spielchen eine wichtige Angelegenheit. Vielleicht ein Kampf um die Hackordnung auf der Straße? Dann würde es mich um so mehr freuen :-)

Aber auch im Berufsleben wende ich diese Vorgehensweise an: Als fachlich Verantwortlicher IT-Projektleiter oder Product Owner hört man von Anspruchsgruppen was sie wollen, brauchen, herbeisehnen. Darunter immer auch diejenigen, die sich über alle anderen priorisieren wollen und dafür eigentlich immer nur eine Begründung parat haben: "Das hat keinen höheren Zweck, das MUSS einfach." Weil es Gesetz ist, weil der Produktionsstart davon abhängt, weil wir sonst alle ins Gefängnis kommen und Gott weiß warum noch.

Inzwischen fahre ich beim Abbiegen in diesen Gegenverkehr einfach voll rein und sage: Sorry, solange ich keine Begründung höre, die ich verstehe, biegen wir weiter ab. Bitte gehen sie zur Seite. 

Diese Neinsager -Der Podcaster Phil McKinney nennt sie "Corporate Antibodies" - geben sich nie gesprächs- oder kompromissbereit. Manche, weil es ihnen ums Ego geht, sich einmal am Tag gegen irgendwen durchgesetzt zu haben. Manche, weil ihnen das Herumdiskutieren, Entscheidungen über Kompromisse treffen zu lästig ist, oder sie schlicht überfordert.

In solchen Fällen rate ich: direkt in die Augen blicken, und einfach ohne zu zögern abbiegen.

Gedanken am schönsten Tag der Woche

Halloweenwoche. Herbststürme fegen das letzte gelbe Laub von den Bäumen.  Der Weg am Landwehrkanal, auf dem entlang ich nach Feierabend zu Fuß Richtung U-Bahn laufen kann, ist leer. Keine Jogger und Hundebesitzer mehr. Der Regen fliegt waagerecht gegen meinen Schirm. Nach diesem trockenen Sommer genieße ich sogar den Regen. Den Geruch von Laub. Dass dass Wetter zur Jahreszeit passt.

Es war ein guter Freitag. Sprint Review Freitag. Und es war "das bis jetzt beste Review". Wir kriegen das Board gebootet und können jetzt die seit langem fertigen Komponenten darauf flashen und testen.  Man freut sich wie ein Kind, wenn nach dem Boot unser Testbild auf dem Display erscheint. Wie damals, als wir im WDR Fernsehen Computerclub geguckt haben und danach unbedingt einen Akustikkoppler zum Laufen bringen wollten.

Eine Sache komplett zu beherrschen ist ein gutes Gefühl. Man fühlt sich fähig und weniger abhängig von anderen. Innere Sicherheit gibt Freiheit.

Ich biege ab in die Marchstraße, Richtung Ernst-Reuter-Platz. Und komme vorbei an einem Start-up Event. Sektglasempfang. Das kann kein "richtiger" Startup-Empfang sein. Es sieht mehr nach Verwaltung aus, die Startup spielt. Der ausgehängten Agenda entnehme ich, hier geht es um "Coaching- und Förderangebote des Senats für junge Gründer". Ach so. Das einen Tag nachdem der grüne Kreuzberger Baustadtrat Florian Schmidt mit Siegfriedstolz verkündete, Google aus Kreuzberg vertrieben zu haben.

Ich fühle den Abstand zu den Achtzigern. Ich bin auf dem Weg ein alter, weiser Mann zu werden. Helmut Kohl rief einem linken Störer mal zu: "Ja, sie bestreiten das. Sie bestreiten ja alles. Nur nicht ihren Lebensunterhalt." Heute spricht er mir damit aus der Seele. Diese Linken und Grünen kennen das Gefühl nicht, ein Board zum Booten zu bringen. Etwas aus eigener Kraft zum Laufen zu bringen. Etwas zu schaffen, was von Wert ist, weil andere bereit sind dafür Geld auszugeben.

Ich gehe weiter und überlege, was die Mitarbeiter der PTB-Außenstelle in ihrer schönen Villa auf ummauerten Grundstück hier wohl erleben? In dieser Ecke von Charlottenburg. Mit der TU Berlin, dem Heinrich-Hertz-Institut und anderen Instituten war mal eine Hochburg von Forschung und Entwicklung. Hier wurde Spitzentechnik geschaffen. Der Senat ließ sich vor zehn Jahren von einer Mc Kinsey Beraterin namens Kathrin Ruder erklären, dass Berlin mal Gründerstadt war und es wieder werden könnte. Die SPD hat seitdem etwas weniger verhindert, dass Leute hier Unternehmen gründen. Michael Müller, regierender Bürgermeister, ist sogar Sohn eines Druckereiunternehmers. Aber er hat nichts davon abbekommen. Aber in den Bezirken wo die Grünen regieren, wie Monika Herrmann in Kreuzberg, da laufen sie jedesmal Sturm gegen neue Unternehmen und neue Wohnungen.

Der Gehweg wird schmaler. Wir müssen uns die 2,50m mit rasenden Radfahrern teilen. Irre. Warum fahren die nicht auf der Straße?

Am TU-Hochhaus am Ernst-Reuter-Platz dann herrscht Wochenendstimmung. Wenige Studenten sind noch hier um diese Zeit, aber die Verwaltungsangestellten machen Feierabend. Ich stelle mir vor, wie es wohl gewesen wäre, wenn ich im Herbs 1989 tatsächlich hier angefangen hätte zu studieren. Ich war zu bequem, um es gegen die Gegenredner durchzuziehen. Ich will über die heutigen Studenten nicht schärfer richten, als ich damals selbst bereit war, Entscheidungen zu treffen. Ich muss aber mal meine Kamera mitnehmen um vom obersten Stockwerk des Hochhauses ein paar Fotos aufzunehmen...

Tja, der Board-Bringup. So einfach und doch so kompliziert. Alle Treiber müssen passen, alles muss zu allem passen. Unser Architekt nennt das "hardware-agnostisch". Ja klar :-)

Meine Aufgabe ist es ja eher, die 300 Features und Enablers zusammen zu halten, damit wir die Entwicklungsarbeit der elf Teams sinnvoll planen und niemand wegen einer nicht erfüllten Abhängigkeit blockiert ist. Wenn die Product Owner etwas nicht verstehen, z. B. weil sie neu sind in der Eingebetteten Welt, kommen sie zu mir und fragen nach Details, nach den Geheimnissen der "Verticals". Guter Witz. Ich kann auch nur beschreiben, wozu das System anschließend in der Lage sein soll. Aber mit den Einzelheiten von Komponenten kenne ich mich nicht aus. In den Kommentaren von Jira und Confluence führe ich gefühlt endlose Debatten. Darüber, dass Entwicklungsarbeit nicht nur aus Programmierung besteht, sondern auch der Planung. Wenn Ihr etwas nicht wisst, dann besteht der erste Sprint darin, es zu eruieren und dann zu planen. Man muss von sich selbst abstrahieren können, die eigene Gruppe aus der Metaebene betrachten können. Und aus dem Nichts eine Planung und dann Implementierung schaffen. Ist das nicht das Wesen eines Startups?

Mich halten diese Fragen nach den Details von meiner eigentlich Arbeit ab. Von der Vorausplanung, der Anregung von Innovationsworkshops. Wozu wollen wir übermorgen in der Lage sein? Eine Plattform zu planen ist nicht dasselbe, wie sich neue Apps auszudenken, die von den Features einer Plattform Gebrauch macht. Ich verstehe inzwischen besser, worin die Leistung eines iOS besteht. Wie Du aus den Ankündigungen der Hardwarehersteller Potenziale für die eigene Plattform ableiten musst. Du stellst Dir die Endbenutzer vor. Szenarien, Use Cases. Probleme, mit denen die Anwender zu lernen gelernt haben, aber die morgen lösbar werden.

Und wenn wir einem Feature zustimmen, was müssen wir Appentwicklern bereitstellen, um sie zur bestmöglichen Endnutzererfahrung zu befähigen?

Diese wichtigen Ideen, Geistesblitze, Dialoge, innere Monologe, Diskussionen mit Architekten. Die entstehen immer nur zwischendurch. Zwischen zwei anderen eng geplanten Meetings. Manchmal entstehen sie auch zu Hause, unter der Dusche oder beim Rasieren.

Innerlich sträube ich mich dagegen, mit soziologischen Debatten und Befindlichkeiten von Entwicklern ("ich will was anderes machen!") befasst zu sein. Warum spüren sie nicht selbst die Sehnsucht nach der Weite der Meere und wissen, was zu tun ist?

Mir dauert das immer zu lange und ich fühle mich nur aufgehalten. Genau so wie von unserer immer noch nicht flutschenden IT-Infrastruktur. Ich rase innerlich, wenn während einer Videokonferenz unser WLAN zusammenbricht oder der Confluence Server für die Erfassung des Protokolls streikt. Diese tausende "Can you hear us?", die Dich völlig aus Deiner Konzentration bringen. Die den Gedankenfluss abreißen lassen und Du findest nie wieder zurück zu was zum Greifen nah war. "I think we are running out of time." sagt der Projektmanager dann und wieder ist eine Gelegenheit, unsere geballte Kompetenz für eine gute Idee zu nutzen, vergeben.

Ich habe es über die Bismarckstraße geschafft. Diese Baustelle hier mit den hässlichen Absperrungen nimmt auch kein Ende. Wann sieht Berlin endlich mal so aus, wie es sich alle wünschen - ohne Baustellen. Es ist dunkel geworden, wir schreiten zur U-Bahn. Die Treppe ist voller rutschigem Laub.   Das ist der Herbst. Das Dröhnen der einfahrenden U2 wird lauter. Wir müssen sprinten. Aber wir schaffen es. Wochenende!

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.

Lächle, wie die Comicfiguren auf dem Konferenz-Flipchart :-)

Auf Fachkonferenzen über Anforderungsmanagement, Architekturmanagement oder agile Methoden irritiert mich seit längerem diese dargestellte Verspieltheit der Protagonisten.

Bei denen das Projektleben eine Art Comic aus lächelnden, einfachen Akteuren ist. Die Kunden bzw. Anwender als "Reisende" ansehen, unterwegs auf dem Globus wie Jim Knopf und Lukas, der Lokomotivführer.

Die Botschaft (die bei mir ankommt): Probleme kennen wir nicht. Wenn du welche kennst, muss das an dir liegen. Mach dich locker.

Ich habe diese Lockerheit erst einmal in eigenen Projekten erlebt. Und dieses Projekt war auch prompt erfolgreich. Wir konnten locker sein, weil unsere Klientel nach mehreren Misserfolgen so verzweifelt war, dass sie sich hüteten, uns unter Druck zu setzen. Diese Freiheit nutzten wir, um das System so nützlich wie möglich zu machen.

Und Erfolg ist eine Aufwärtsspirale. Hast du Erfolg und gibt man dir Freiheit, aktiviert das immer mehr Ressourcen in dir und erweitert deinen Blick. Du verstehst immer mehr und das Produkt wird immer besser. So will man arbeiten.

Aber nach meiner Überzeugung gibt es noch weitere wichtige Erfolgsfaktoren. Und dazu gehört das gute Zusammenspiel von Anforderungsmanager (Product Owner) und Architekt. Unsichere (alte und junge) Akteure neigen bei Unsicherheit zu Rückzug und Distanzierung. Anstatt "ans Netz" zu gehen, versteifen sie sich auf Grundlinienduelle und warten auf die Fehler des "Gegners". Aber so kommt das Projekt nie vernünftig in Gang.

Vielmehr müssen beide ihre Rollen und Aufgaben anerkennen und ihr Zusammenspiel verstehen. Das "Was?" (Anforderungen) und das "Wie?" (Architektur) müssen auf einen gemeinsamen Nenner kommen. Dabei müssen sie die Randbedingungen des anderen verstehen und in die Lage kommen, vernünftige Kompromisse zu schließen. Keiner sollte seinen Stakeholdern Versprechungen machen, die der andere nicht einhalten kann.

In der öffentlichen Verwaltung läuft dieses Spiel noch überhaupt nicht. Der Grund dafür ist -nach meiner Beobachtung und Erfahrung- das unterentwickelte Anforderungsmanagement. Aber auch populäre Missverständnisse von "Architektur".

IT ist in der Verwaltung gewachsen wie in jedem komplexeren Unternehmen: Dezentral. Jeder Bereich hat über die Jahre sein Ökosystem entwickelt. Fachbereiche haben bestellt und installiert oder gar selbst entwickelt. Die Begründung war stets: Keiner versteht uns. Und wenn, liefern sie zu langsam. - Das Ergebnis: Mit der Zeit gibt es für gleiche Aufgaben immer mehr verschiedene Systeme.

Und der CIO beschließt: Standardisierung!

Das Ziel: Aus 16 mach (maximal) 2 Lösungen.
Die Aufgabe: Finde heraus, welche 2 das Optimum für die 16 bilden.
Die Vorgabe: Mach es ohne Anforderungsmanagement.

Inzwischen kenne ich mehrere Projekte die für die gesamte Verwaltung (Bundesressorts, Länder, Kommunen) eine Lösung gestalten sollen und die in Frage kommenden Lösungen werden gleich mit vorgegeben. Und was immer mit vorgegeben wird: Du kannst keinen Standard durchsetzen oder beschließen - sondern du musst dir die Zustimmung von allen Beteiligten abholen.

Es kommt auch vor, dass dir der CIO gerade erst die Lösung vorgeschrieben hat. Und er wendet sich von dir ab und der Presse zu und verkündet, wann die Sache produktiv gesetzt werden wird. Und weil er so ehrgeizig ist, legt er noch eins drauf und verkündet einen Leistungsumfang, der über die gesetzlichen Anforderungen hinausgeht. Er wird vor der Presse von modernen Lösungen und agilen Methoden sprechen. Aber für die entscheidende Frage, was das System können muss, um die Aufgaben des Fachbereichs für die Erfüllung des Gesetzes umsetzen zu können, wird keine Zeit eingeräumt.
Und hinter den Kulissen werden sich Fürsten um ihre Einflussnahme kloppen und deine dringenden Entscheidungen bis in den roten Bereich rauszögern. Am Ende wird sich einer durchsetzen und die Verlierer nicht mitspielen.

Was hat das mit den lächelnden Comicfiguren auf deiner Konferenz zu tun? Was leistet der Comic anderes als ein Klima von Konformismus, in der alle so tun als wären sie frei und glücklich aber an ihrem Schreibtisch haben sie keine Ahnung, wie sie ihre Vorgaben umsetzen sollen? Sollst du die Konflikte und Widersprüche ansprechen, sobald du sie erkennst?

Ich war neulich in einer großen Runde, in der ein Staatssekretär ausdrücklich dazu aufforderte, mal "offen aus der Praxis" zu berichten, was wir in den Projekten so erleben. Und keiner traute sich. Doch, einer traute sich dann schon. Und das war ich. Ich benannte die Hindernisse der Hierarchie, die Fokussierung auf Vorschriften statt auf Ergebnisse. Die Unmöglichkeiten, moderne und bewährte Methoden umzusetzen mit Rollen, die sich nicht jede Entscheidung einmal im Quartal genehmigen lassen müssen.

Der StS. nickte und sagte, dass es so sein könne, dass Gesetzesänderungen dafür nötig seien - und das s auch das möglich sei. Ich war ihm schon dankbar, dass er auf meine Worte einging. Was mich aber irritierte war das völlige Desinteresse der großen Runde. Während und auch nach der Sitzung. In diesem Moment verstand ich, wie tief der Konformismus inzwischen sitzt. Und zwar selbst dann, wenn zu Non-Konformismus aufgerufen wird. Die Comicfiguren auf den Flipcharts sind am Ende freiwillige Konformisten. Sie bekennen sich nicht nur zu äußeren Zielen und "Werten". Inzwischen lebt der Konformismus in den tieferen Schichten der Psychologie - im Prinzip so, wie von Huxley in der "Schönen neuen Welt" beschrieben. Wer nicht lächelt, hat ein Problem. Und Probleme wollen wir auf der Bühne nicht sehen. Hinter den Kulissen aber und unterm Tisch tragen wir sie um so härter aus.

modernRE

Zurück auf den Boden der Tatsachen. Zurück ins IT-Geschäft. Zwei Tage Konferenz "Modern RE" (Requirements Engineering) liegen hinter mir. Mein Versuch, ein Fazit für mich zu ziehen:

1. Motivation zur Teilnahme
Wie machen es die anderen? Was erleben andere, welche Probleme müssen sie lösen und wie tun sie es? Seitdem es jede Rolle in einer Organisation nur noch einmal gibt, ist man mehr denn ja auf Austausch mit Externen angewiesen. Und dafür hat sich die Teilnahme gelohnt.

2. Triff die Experten, die Autoren, die Berater
Auch im Anforderungsmanagement gilt: Sich auf die anerkannten Experten zu berufen, bietet Sicherheit. Wehe dem, der so denken muss anstatt selbst zu denken.
Von der Prominenz habe ich hier am wenigsten gelernt, außer, dass es ok ist, ruhig einmal Tacheles zu sprechen. Tacheles wirkt echt.
Am meisten lernte ich von den Product Ownern und Scrum Mastern, die diese Rolle im (Kunden-) Unternehmen ausüben, gerne übrigens seit länger als einem Jahr. Mit denen kann man ganz konkret Dinge besprechen.

3. Mentalität
Deutschland ist gut im Maschinenbau und in Fabrikarbeitsketten. Aber wehe, man braucht Leute für einen Invest, um mal auszuprobieren, wie es besser gehen könnte. Die Wissensträger, die verfügbar und zusätzlich bereit sind, repräsentativ für ihre Gruppe zu sprechen, sind sehr rat gesät. Lieber spricht man nach der Umsetzung hundertmal über Schuldzuweiseungen, als einmal einen Experten für 1 oder 2 Wochen herzugeben.

"Flache" Hierarchien sind nur mit fachlich qualifizierten und selbstverantwortlich denkenden Kollegen möglich. Das gilt noch mehr in Projekten mit vielen Externen. Projekte, in denen externe Berater und Dienstleister gegeneinander ankonkurrieren funktionieren nicht. Manager, die sich für "Strategen" halten, weil sie weder operativ noch fachlich etwas beitragen können, wirken bremsend und stiften Verwirrung. Hingegen Kollegen, die echte Expertise und Erfahrung beisteuern und mit Unsicherheiten und Unkenntnis offen umgehen, wirken beschleunigend, risikosenkend und qualitätstreibend.

Ich arbeite nun seit einem Jahr als Berater für Anforderungsmanagement in einer Bundesbehörde und kann nur ein ernüchterndes Fazit ziehen: Mir ist sonnenklar, warum in der Verwaltung IT-Projekte grandios scheitern.

"Bedienfreundliche Oberfläche" - aber für wen?

Bedienfreundliche Oberflächen wollen alle. Allerdings heißt das für jeden etwas anderes. Beispiele:

- Der gelegentliche oder erstmalige Besucher einer Website (Inter- oder Intranet) will sich schnell orientieren und finden, was er sucht. Bzw. ersteinmal herausfinden, wie das heißt, was er sucht.

- Der häufige Anwender, der fallabhängig unterschiedliche, komplexere Arbeitsflüsse im System abwickelt, braucht gut gestaltete Menüs und Dialoge.

- Wer häufig viele Daten erfasst, braucht eine sehr schnelle Reaktionszeit und kurze Fingerwege. Die Vorgabe für "schnell" gibt die Großrechneranbindung: "quasi ohne Verzögerung". Kurze Fingerwege heißt: schon der regelmäßige Griff zur Maus und die Mausfahrt zu einem Menüpunkt wäre zu zeitraubend. Tastenkombinationen müssen her.

- Anwender, die viel unterwegs sind, benutzen Laptops oder Tablets. Sie erfassen nur wenige Daten (höchstens Mitschriften) und brauchen vielleicht gut verständliche Berichtskonfigurationsmöglichkeiten. Sie brauchen gute Menüstrukturen, angepasstes Layout etc.

Wer diese Unterschiede übersieht und die Oberflächengestaltung nur für die Teilnehmer eines Lenkungskreises "stylt" wird später keine Akzeptanz bei den Anwendern finden (und im Lenkungskreis ein "Akzeptanzmanagement" vorschlagen...).

Was bedeutet das für die Technologieauswahl bzw. Architektur?

Auch hier kann man sich vertun. Wer als Datenerfasser schlechte Erfahrung mit langsamen Intranetseiten hat, wird sagen: Keine Weboberflächen!
Ein erfahrener Architekt wird erwidern: Gegenvorschlag - wir minimieren die Nachladeobjekte für Dialoge und bestellen ausreichend Netzbandbreite beim technischen Architekten bzw. bei Corporate Network.

Auch wenn das Konzept auf dem Papier überzeugt, man sollte testen, ob man vor Ort das bekommt, was man braucht und ob alles wie gedacht funktioniert.

Brauchen Methodiker Branchenwissen?

Große Diskussion: Muss ein Methodikberater etwas von der Branche verstehen, für die er seine Methodik nutzbar machen will?

Manche sagen: Nein. Was man nicht weiß, kann man sich herleiten. Und: der Kunde muss das Potenzial erkennen, wenn er die Methodik studiert.

Ich sage: Ja. Methoden müssen -ebenso -wie Technologien- erst nutzbar gemacht werden. Sie sind es nicht a-priori.

Begründung:
Das Nutzenpotenzial hat in jeder Branche, vielleicht bei jedem Kunden, ein anderes Profil. Man bringt -abstrakt gesprochen- das Nutzenprofil der Methodik mit dem Schwächenprofil der Kundenorganisation zusammen.

Beispiel Anforderungsmanagement:
Organisationen, die einfach drauflos entwickeln (a), können von der Einführung eines Anforderungsmanagement anders profitieren, als Organisationen, die zu lange an ihrem Lastenheft arbeiten (b).
(a) braucht ein Verständnis, warum Anforderungen überhaupt dokumentiert werden können: Damit man sie besprechen, priorisieren, klären - ja überhaupt Dritten zugänglich machen kann.
(b) braucht ein Verständnis dafür, dass es sinnvoller ist, unklare Anforderungen und stillschweigende Annahmen VOR dem Entwicklungsstart zu klären.

Inwiefern benötige ich hier Branchenwissen, um die Methodik nutzbar machen zu können?

Antwort:
Ich muss eintauchen in die Welt des Kunden und das spezifische Problem, an dem man den Hebel ansetzen kann, verstehen lernen. Dieses Problem kann typisch für die Branche sein, oder eine Gattung von Unternehmen in dieser Branche.

Dem Methodiker geht es da nicht anders als dem Technologen: Gibt es neue Durchbrüche in Basistechnologien, braucht man auch Branchenverständnis um die Chancen für eine Branche zu erkennen.

Bekanntes Beispiel: Die Mini-Festplatte von Intel, die für Apple das fehlende Puzzlestück für die Entwicklung des ersten iPod war. Intel wusste nicht, was Apple braucht. Und Apple wusste nicht, was die Forschungsergebnisse von Intel bedeuten. Das Potenzial wurde erst im gemeinsamen Gespräch erkannt.

Man muss also Anforderungsmanager und Architekten miteinander ins Gespräch bringen. Der Anforderungsmanager befragt den Architekten gezielt nach dem MÖGLICHEN. Der Architekt befragt den Anforderungsmanager nach dem BEDARF. Beide müssen zur Sprache bringen, was sie durch falsche Annahmen zu verschweigen neigen.

Und für dieses Gespräch brauchen beide Seiten Verständnis für die jeweils andere Seite. Sie repräsentieren aber eine der beiden Domänen.

IT-"Modernisierung"

"Mach neu!"
Peter Fox

Auslöser für die Modernisierung einer IT-Landschaft kenne ich nur zwei:
- Die Systembetreuer gehen bald in Rente oder Pension.
- Jemand hat nachdem etwas passiert war, angeordnet, dass jetzt "etwas passieren" muss.

Gründe für eine Modernisierung kann es noch viel mehr geben, aber die lösen nichts aus.

"Landschaft" heißt, da müssen mehrere zusammenspielende Komponenten angefasst werden. Und sofort entstehen Fragen wie:
- Ist die Anzahl der Komponenten fachlich oder technisch begründet?
- Allgemeiner gefasst: Wie begründet sich die heutige Architektur?

Solch ein Vorhaben ist ein Aufbruch ins Ungewisse, machen wir uns nichts vor. Was aber gewiss ist: Für alle demnächst startenden Aktivitäten und vor allem Dokumentationen sollte sich das Programm eine Basis in Form von Standards geben:
- Klärung der Vorgehensweise, Standards, Tools, Ablage etc.
-- Dies ist um so dringender, je arbeitsteiliger das Projekt organisiert wird.
--- Insbesondere zwischen extern und intern.
--- Insbesondere wenn agil entwickelt wird (gemeinsame Anforderungsklärungssitzungen)
- Zentrale Stellen für zentrale Fragen die immer wieder hoch kommen werden:
-- Anforderungsmanagement
-- Architekturmanagement

Sollte jemand auf die Idee kommen, diese zentrale Stelle bräuchtet Ihr nicht und Ihr könntet auch ohne dies "schon mal" starten, werdet Ihr schnell merken, wo Ihr da hinkommt:

- Jede Stelle benutzt ihre Tools und Standards.
- Jedes Teilptojekt nutzt Vorgehensweisen, die es kennt oder ihm am besten passen.
- Am Ende wird nichts zusammen passen und kann nicht übergreifend analysiert und gestaltet werden.

Das klingt trivial und muss man niemandem mehr sagen? Habt Ihr eine Ahnung..

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.

IT-Modernisierung

Wer früher (70er) gut in Mathe und Physik war, beschäftigte sich auch gerne mit Computern und Taschenrechnern. Der Zusammenhang war klar: Informationstechnik beschleunigt das Rechnen, bzw. nimmt es dem Menschen ganz ab. Der Mensch muss nur wissen oder herausfinden, was berechnet werden soll. Einige dieser Schüler wurden später Programmierer. Sie entwickelten Großrechnerprogramme, mit denen Telefonrechnungen und Rentenansprüche berechnet werden. Bis heute.

Die Programmiersprachen entwickelten sich weiter, weil Innovationen die IT-Architekturen weiter entwickelten. Wir bekamen Hochsprachen, in denen es weniger ums richtige Rechnen ging, als um eine kluge Begriffsbildung für Objekte und Methoden und um benutzerfreundliche Dialoge und Oberflächen. Man muss eher ein guter Philosoph oder Linguist sein, um auch gut mit objektorientierten Sprachen umgehen zu können.

Diese Leute versuchen heute, die Altsysteme der Großrechnerprogrammierer durch moderne Architekturen abzulösen. Und stoßen gegen Decken und Wände.

Über die Gründe kann man genug im Social Web nachlesen und hören:
- Die Altsysteme, insbesondere die Anforderungen die sie erfüllen, sind nur in den Köpfen der damaligen Programmierer "dokumentiert".
- Dokumentation, die "nur" dem Teilen von Wissen dient bzw. jemand anderen als den bisherigen Eigner zu einer Neuentwicklung zu befähigen, gilt bei den Althasen als nutzlos, oder als Risiko.
- Arbeitsteilung zwischen Auftraggeber (Fachbereich) und Auftragnehmer (IT) gab es in den 70ern nicht. Man hatte eine Abteilung, die sich vom Nachbarbüro erklären ließ, was das System können soll.

Die heutige Generation denkt komplett anders:
- Arbeitsteilung heißt für sie: jeder macht, was er oder sie am besten kann. So macht es Spaß.
- Für Arbeitsteilung muss man Wissen teilen. So kommt man als Team voran in Richtung eines gemeinsamen Zieles.
- Anwendungen müssen dem Anwender nützen, nicht den Programmierer auszeichnen.
- Kompliziertheit ist kein Hinweis auf Genie sonder auf kompliziertes Denken.

Das Problem ist: Die Altsystemprogrammierer sind die Chefs. Die Jungen werden sie in absehbarer Zeit beerben. Sie erben dann Objekt- und Sourcecode und müssen sehen wo sie bleiben. Das ist in etwa so, als würden einem die Eltern als Testament ein unleserliches Notizbuch hinterlassen.