Die Nachwuchskatastrophe - 0% der Mädchen wollen in die Softwareentwicklung

Der Nachwuchs für die Softwareentwicklung ist männlich. Zu 100%. So scheint es derzeit nach einer Umfrage des Allensbach-Instituts.

0% der befragten Mädchen zeigte Interesse daran, einen Beruf im “Computer, IT-Bereich” zu wählen. Das betrifft auch die Softwareentwicklung.

Das ist eine Katastrophe!

Gründe zur Sorge

Warum ist das eine Katastrophe? Ich sehe da mindestens zwei Gründe:

• Software ist der “Treibstoff” der Zukunft. Ohne Software geht nichts mehr und zukünftig noch weniger. Wir haben heute schon zu wenige Softwareentwickler. Das Verhältnis kann dann nur noch schlechter werden, wenn morgen der Bedarf an Software weiter steigt und gleichzeitig - zumindest in Deutschland - der Arbeitskräftemarkt in den nächsten 10 Jahren um bis zu 15% schrumpft. Offshoring ist doch keine wirkliche Lösung. Auch Flüchtlinge der einen oder anderen Art zu Softwareentwicklern fürs homeland umzuschmieden, ist doch auch keine Lösung. Wir brauchen schlicht mehr an dieser Arbeit interessierte Menschen beiderlei Geschlechts aus und in unserer Gesellschaft. Das ist schwierig genug. Wenn sich jetzt aber herausstellt, dass 50% des Potenzials schlicht verloren ist… Dann ist das eine Katastrophe. Uns geht der “Treibstoff” für unsere Unternehmen aus.[1]
• Softwareentwicklung ist schon lange keine Sache mehr für einsame (männliche) Hacker. Jedenfalls nicht, wenn man nachhaltig Software bauen will. Softwareentwicklung braucht ein Team. Und Team braucht Vielfalt. Mehr Vielfalt als ein Fußballteam. Denn die Sache, um die es geht, ist komplexer und es hängt mehr von ihr ab. Zu Vielfalt gehört selbstverständlich, dass beide Geschlechter vertreten sind. Manager rufen gern Kriegsmetaphern auf, um ihre Arbeit zu beschreiben und sich zu rechtfertigen. Doch schon lange ist klar, dass der Erfolg für alle größer ist, wenn man nicht im Kampf miteinander steht, sondern kooperiert. Kooperation, gemeinschaftliches Schaffen, d.h. auch Empathie sind jedoch eher mit einer weiblichen Sicht der Dinge verbunden als mit der männlichen. Bei aller Gleichberechtigung, die wir schon erreicht haben mögen, ist eine Ungleichheit in der Herangehensweise ans Leben zwischen Frauen und Männern nicht wegzudiskutieren. Und warum auch? Warum soll alles gleich sein, nur weil alle gleichberechtigt sind? Lassen wir zu, dass Frauen und Männer unterschiedlich sind - und zusammen ein Ganzes ergeben.[2] Softwareentwicklung ist eine Arbeit, die solches Ganzes braucht. Denn es geht nicht um Maschinen, die nach Plan von muskelbepackten Männern im Schweiße ihres Angesichts zusammengeschraubt werden müssen. Es geht um sich ständig ändernde Prozesse, es geht um Komplexität, es geht um Verständnis (mindestens des Kunden) uvm. Das alles profitiert davon, Weiblichkeit im Team zu haben. Mehr Weiblichkeit als bisher jedenfalls. Wenn sich 0% der Weiblichkeit für die Softwareentwicklung interessieren, dann ist das also eine Katastrophe.

Was tun?

Die Katastrophe hat natürlich schon begonnen. Eine Generation ist bereits verloren. Und kein Wunder: Wenn ich mir das Gymnasium meiner Tochter ansehe, dann weiß ich, warum weder sie noch ihre Freundinnen für Softwareentwicklung interessieren. Es wird nichts dafür oder sogar alles was möglich ist, dagegen getan. Fächerkanon wie vor 50 Jahren. Bis zu diesem Jahr keine Erlaubnis, den Girls Day zu besuchen. Da hilft auch kein Studiensaal mit Laptops und Powerpoint-Präsentation in Geografie. Verständnis für den “Treibstoff” wird nicht geweckt. Nirgends.

Dabei ist dort mit Sicherheit Potenzial. Neulich habe ich meiner Tochter mal Lightbot aufs iPad geladen. Das hat sie besser gespielt als ich. Man(n) muss halt Angebote machen… Aber das ist natürlich schwer, wenn schon männliche Lehrer sich vom normalen Curriculum überfordert fühlen und ansonsten mindestens 7 Jahren Bildungsvermittlung in formativen Jahren (Kindergarten und Grundschule) zu min. 85% durch Frauen stattfindet.

Aber genug der Klage. Was könnten wir denn tun, um Mädchen für die Softwareentwicklung zu begeistern?

Am besten beginnen wir mit dem Verstehen. Quasi Anforderungsanalyse. Das können wir doch, oder? ;-)

Laut Studie ist es

[f]ür fast die Hälfte der befragten Mädchen […] wichtig, anderen Menschen zu helfen […]

Außerdem

[…] wollen [Schüler] sich in ihrem späteren Beruf vor allem selbst verwirklichen (87 Prozent), das steht noch vor dem Wunsch nach einem gut bezahlten (75 Prozent) und sicheren (71 Prozent) Arbeitsplatz.

Das wollen Mädchen? Anderen helfen und sich selbst verwirklich bei ordentlicher Bezahlung in realistischer Arbeitsplatzsicherheit?

WTF! Das können sie doch in der Softwareentwicklung haben. Oder nicht?

“Anderen Menschen helfen” bedeutet für Mädchen offensichtlich nicht, dass sie alle Krankenschwestern und Pflegerinnen werden. Sonst hätten wir da keine Nachwuchsprobleme. Sie ergreifen also andere Berufe. Sie werden Verkäuferin, Bankangestellte, Busfahrerin, Steuerberaterin usw. usf.

Aber, Leute, ehrlich, das sind doch keine Berufe, in denen man sehr speziell “Menschen hilft”. Klar, Frauen gehen in solche Berufe. Lehrkräfte sind zu 67% Frauen. Sie sind auch Sozialarbeiterinnen und Hebammen. Doch sie arbeiten eben auch in ganz anderen Berufen. Das Motiv “Menschen helfen” zieht für mich also nicht so ganz. Denn dann müssten viel mehr Mädchen auch Bestatterinnen werden wie meine Ex-Frau. Da kann man Menschen sehr unmittelbar helfen.

Oder es müssten mehr Mädchen Softwareentwicklerinnen werden. Denn da können sie auch Menschen helfen. Da sind Kollegen, denen immer wieder geholfen werden muss. Gerade in cross-functional Teams. Da sind Kunden, denen man im unmittelbaren Kontakt helfen kann, indem man sich um Verständnis bemüht und dann auch noch nützliche Software herstellt. Und da sind Anwendungen in der Medizintechnik oder für Behörden, die den Menschen helfen, für die die Anwender da sind.

Und wie steht es mit der Selbstverwirklichung, den Verdientschancen und der Arbeitsplatzsicherheit? Angesichts der Automatisierungsrevolution die in den nächsten 10 Jahren anrollt, sollte klar sein, dass Softwareentwicklung ein relativ sicherer Hafen sein wird. Es geht nicht mehr nur um Roboter, es geht um Expertensysteme aller Art. Die bringen Berufe in allen Teilen des Spektrums unter Beschuss: vom Taxifahrer bis zum Bankangestellten und darüber hinaus.

Bei der Softwareentwicklung hingegen sehe ich da noch keine große Gefahr. Auch neue Tools werden unsere Köpfe nicht ersetzen. Der Bedarf an Software wird den Produktivitätsgewinn mehr als auffressen. Die Softwarekrise ist nicht vorbei. Sie fängt womöglich sogar erst an.

Das kann sich auch nur positiv auf Gehälter und “Selbstverwirklichungsmöglichkeiten” auswirken, würde ich sagen.

Wo ist also das Problem? Softwareentwicklerin ist ein für Mädchen attraktiver Beruf. Jedenfalls, wenn man die angegebenen Motive für die Berufswahl ernst nimmt. Wir müssen nur lernen, das darzustellen. Wir müssen uns bemühen, an die Vorstellungen von Mädchen anzuschließen. Es braucht Rollenmodelle, es braucht eine Imagekampagne.

Da muss man sich ein bisschen Mühe geben. Mehr als bei dem grauslichen Barbie-Comic, der gerade durch die Medien geistert. Aber das sollte doch zu machen sein, oder? Warum nicht die Frauen fragen, die schon Softwareentwicklerinnen sind?

Nur wer ist für soetwas der Ansprechpartner? Große Firmen - aber nur in einem Zusammenschluss, sonst kommt etwas zu sehr auf ein Unternehmen Zugeschnittenes heraus. Ein Verband fehlt leider bisher. Medien? Ein Ministerium? Am besten wohl alle zusammen.

Was Mädchen wollen - Ein Versuch

Aber vorher müssen wir wohl noch besser verstehen, was Mädchen wirklich, wirklich wollen. Denn ich glaube, das drücken die genannten Motivbeschreibungen nur ungenügend aus.

Ich versuche mal, hinter die Begründungen zu schauen und spekuliere auf der Basis dessen, was ich so von außen in der Welt erkennen kann:

• Mit “anderen Menschen helfen” ist nicht gemeint, echt Bedürftigen zu helfen. Ich glaube, es geht um etwas viel Allgemeineres: Beziehungen. Mädchen ist der direkte Umgang mit etwas Lebendigem (Mensch, Tier, Pflanze) wichtig. Ihr Interesse ist insofern eher nach außen gewandt, umweltbezogen. Männer die auf Maschinen starren, Frauen die mit Menschen reden. So könnte man es vielleicht überspitzt ausdrücken. “Helfen” ist also nicht so wichtig wie Dialog.
• Mit “sich selbst verwirklichen” ist gemeint, sich immer wieder neu zu entscheiden. Mädchen wollen sich nicht auf eine Berufskarriere festlegen. Sie sind natürlich nicht mehr zufrieden mit “Hausfrauendasein”. Aber sie möchten die Idee einer Familie auch nicht dem Beruf opfern. Dazu braucht es Flexibilität: Der Beruf muss ermöglichen, eine Zeit lang zu arbeiten und dann zu pausieren und dann auch wieder anzufangen, womöglich in Teilzeit. Arbeitgeber und Metier müssen das hergeben.

In “manifest speak” ließe sich das vielleicht so zusammenfassen:

• Communication over technology
• Flexibility over career

Ha! Das ist knackig.

Und ließe sich das denn nicht einrichten? Keine Chance, dass sich Softwareentwicklung so darstellen bzw. sich dahin entwickeln ließe?

Wenn es da Schwierigkeiten geben sollte, dann nicht, weil die Softwareentwicklung so nicht sein kann. Nein, Schwierigkeiten sehe ich nicht im Metier, sondern nur im Willen von Unternehmen (und vielleicht einzelner Entwickler, die um einen Nimbus fürchten).

Die Nachwuchskatastrophe lässt sich also abwenden - wenn wir wollen. Ich denke, die Softwareentwicklung kann für Mädchen mindestens so attraktiv sein wie das Bankenwesen oder die Betriebswirtschaft oder das Behördenwesen. Wenn nicht sogar attraktiver, oder? Das können wir doch hinkriegen, my fellow men.

---

1. Unternehmen mögen noch nicht glauben, dass Software so wichtig ist. Aber das wird sich noch verändern. Selbst der letzte mittelständische Maschinenbauer wird verstehen, dass der Milliardenumsatz seines 700 Mitarbeiter Unternehmens von den 15 Leuten in der ungeliebten Softwareabteilung abhängig ist. Man könnte fasst revolutionspoetisch werden: “Alle Räder stehen still, wenn der Programmierer es so will.” Der Hebel, den die Softwareentwicklung hat, ist sehr lang. ↩

2. Was nicht bedeuten soll, dass irgendwelche Attribute zwanghaft irgendeinem biologischen Geschlecht zugeordnet werden sollen. Männer dürfen, nein, sollen natürlich auch empathisch sein und Frauen tough. Je nach Neigung und Situation. Das ändert jedoch nichts daran, dass im Durchschnitt gewisse Eigenschaften eben doch nach biologischem Geschlecht unterschiedlich verteilt sind. (Womit ich keinen Kausalzusammenhang unterstellen will, sondern nur beschreibe, was ich sehe. In die nature vs nurture Debatte möchte ich hier nicht einsteigen.) ↩

Praktische Führung

Es wird ja viel über Führung und Management geschrieben. Die einen sind dafür, die anderen dagegen. Aber was ist eigentlich die Aufgabe von Führungspersonen?

Eine sehr gute Erklärung liefert aus meiner Sicht Reinhard K. Sprengers Buch “Radikal führen”. Danach hat Führung fünf Kernaufgaben:

• Zusammenarbeit organisieren - Klar, das ist der Ausgangspunkt. Verschiedene Aktivitäten müssen so “verdrahtet” werden, dass ein Gesamtergebnis entsteht. Dazu gehört natürlich auch die Zielsetzung.
• Transaktionskosten senken - Für die Zusammenarbeit müssen günstige Rahmenbedingungen geschaffen werden. “Irgendwie” kann man sich auch ohne Führung zusammenraufen. Mit Führung soll es ökonomischer sein.
• Konflikte auflösen helfen - Irgendwas ist immer. Dann muss Führung helfen, wieder Kohärenz herzustellen.
• Zukunftsfähigkeit sichern - Heute gut zusammenarbeiten, bedeutet nicht, dass das auch noch morgen funktioniert. Innen wie außen können sich Verhältnisse verändern; darauf muss Führung (proaktiv) reagieren.
• Mitarbeiter führen - Nicht nur die Zusammenarbeit will geführt werden, auch der Einzelne. Immer geht es ja um Ziele, die erreicht werden sollen. Hilfe kann da nicht schaden. Und schließlich müssen auch noch Stellen in der Zusammenarbeit geeignet besetzt werden, damit es bei guter “Verdrahtung” auch wirklich fließen kann.

Wenn ich durch diese Brille auf Unternehmen schaue, dann verstehe ich sehr gut, was funktioniert und was nicht - und warum. Ein Schema, das mir schon sehr geholfen hat.

Aber trotzdem: Irgendwas hat mir noch gefehlt beim Verständnis. Und das ist mir heute klar geworden, als ich mit meiner Tochter einen Nähkurs bei Zick und Zack in Hamburg besucht habe.

Dort wurde uns nämlich gesagt, dass eine Nähmaschine Führung brauche.

Der zu nähende Stoff muss unter der stationären automatischen Nadel entlangbewegt werden, um eine Naht zu produzieren. Das übernimmt der Transporteur unterhalb der Nadel.

Er zieht den Stoff, den der Nähfuß auf ihn drückt, an der Nadel vorbei. Die Richtung ist einstellbar; normalerweise bewegt sich der Stoff weg vom Näher, aber der kann ihn auch zu sich hin wandern lassen.

Der Stoff ist also grundsätzlich in Bewegung, die Naht entsteht von allein. Irgendwie. Denn bisher ist da sozusagen nur “rohe Kraft am walten”.

Was jetzt noch fehlt, das ist… Führung.

Die “rohe Kraft” des Transporteurs muss auf ein Ziel ausgerichtet werden. Und zwar immer wieder.

Hier sehen Sie, wie ich zur Übung entlang auf den Stoff gezeichneter Linien nähe. Der Stoff bewegt sich zwar von allein - nur nicht unbedingt “linientreu”. Ich muss ihn immer wieder nach-führen.

Dazu gehört, dass ich die Richtung korrigiere, indem ich den Stoff unter der Nadel drehe. Wenn die Richtungsänderung zu krass ist wie bei einer Zickzack-Linie, muss ich den Nähvorgang dafür sogar unterbrechen.

Darüber hinaus muss ich die “globale” Geschwindigkeit regulieren. Das tue ich über einen Fußschalter. Der bestimmt, wieviel “Input” sich die Maschine zum Nähen holt. Der Transporteur zieht sich ja den Stoff selbst.

Das ist aber noch nicht alles. Mein Aha-Moment bestand darin, dass ich fühlen konnte, was Micro-Management bedeutet.

Micro-Management entsteht nämlich immer dann, wenn zusätzlich zum allgemeinen Arbeitsfluss noch versucht wird, im Detail zu optimieren. Man überlässt das Resultat nicht dem Prozess, sondern greift lokal immer wieder ein.

Das führt bei Menschen zu Unmut. Die fühlen sich bevormundet; man lässt sie ja nicht die Arbeit tun, für die sie einmal kompetent gehalten wurden, sondern greift ein. Wer micro-managet, der vertraut nicht.

Daraus resultieren in Bezug auf den Produktionsfluss Stockungung und Qualitätsverlust.

Und genau das habe ich eben spüren können: Sobald ich anfing, den Stoff in Transportrichtung auf die Nadel noch zusätzlich zu zu schieben (Druck, push), war das Ergebnis schlechter. Dito, wenn ich anfing, den Stoff in Transportrichtung noch zusätzlich hinter der Nadel zu ziehen (pull).

Die Naht war sofort ungleichmäßig und die Ausrichtung entlang einer Linie fiel sofort schwerer.

Führung bedeutet mithin, einen Prozess aufzusetzen - und sich dann weitgehend rauszuhalten. Wer über die im Prozess wirkenden Kräfte noch drückt oder zieht… der betreibt Micro-Management. Das Ergebnis sind Stauungen oder Risse. In jedem Fall gerät etwas aus dem Gleichgewicht und der Arbeitsfluss wird gestört.

Führung bedeutet, in Kontakt bleiben mit dem Prozess. Immer wieder schauen, ob der noch fließt und auch noch auf das Ziel ausgerichtet ist. Falls nicht, muss nachjustiert werden - aber vorsichtig. Und eher nicht an den einzelnen Prozesselementen (lokale Optimierung), sondern am Ganzen (globale Optimierung).

Wenn es mit der Naht bei mir nicht geklappt hat, dann aufgrund von Micro-Management und zu wenig Blick auf das Ganze. Schlechte Führung also.

Es schien einfacher, nah an der Nadel den Stoff zu ziehen/drücken, als die Gesamtgeschwindigkeit zu regulieren. Und es war attraktiver, überhaupt mit der Maschine zu nähen, statt das Nähen vorzubereiten. So habe ich zum Beispiel ein Band, das ich auf eine Tasche nähen wollte, nicht vorher mit Nadeln ausreichend fixiert. Ich dachte, ich kriege es durch Eingriffe nahe an der Nadel während des Stoffdurchlaufs hin, das Band gerade drauf zu nähen. So musste ich auf die harte Tour lernen, dass gute Vorbereitung hilft, den Durchsatz zu erhöhen.

Auch das gehört zu Führung: Bewusstsein dafür vermitteln, dass zu guter Zusammenarbeit auch darin besteht, auf Qualität von Input und Output zu achten. Systeme definieren sich ja durch das, was zwischen ihren Bestandteilen fließt.

Aber auch das ist eine Sache, die eben nicht während der Produktion geschehen sollte. Da müssen die Prozessschritte schon gut “verdrahtet” sein. Führung ist eine Sache des Rahmens, in dem Produktion stattfindet.

An der Nähmaschine habe ich ja auch nicht selbst die Naht hergestellt. Dazu greifen die Teile der Nähmaschine ineinander. Vielmehr habe ich in guten Moment einfach nur “sanft” geführt.

Das Ergebnis war dann doch passable und nützlich. Ich habe bei der Führung die Kurve gekriegt. Aber wie ist das im Tagesgeschäft? Kriegt Management da auch immer die Führungskurve? Das scheint mir nicht der Fall zu sein.

Da ist Micro-Management an der Tagesordnung - insbesondere, wenn irgendetwas sowieso nicht rund läuft. Da wird gedrückt und gezogen, statt auf den Gesamtprozess zu schauen. Wie sind die Prozessbeteiligten eigentlich grundsätzlich zueinander angeordnet? Wie ist die Qualität des Input? Wo gibt es einen Engpass?

Vielleicht würde ja mal ein Nähkurs für Führungskräfte helfen? Da kann man eine Menge lernen, nicht nur über Führung. Und Spaß macht es obendrein, mal wieder etwas Anfassbares mit den Händen hergestellt zu haben.

Hacker-Tool für Gedanken

Wie soll ich wissen, was ich denke, solange ich es nicht aufgeschrieben habe? So geht es mir oft. Deshalb schreibe ich Blog-Postings und Zeitschriftenartikel und auch Bücher. Das Schreiben hilft mir beim Denken.

Aber welches Werkzeug benutzen für das Schreiben? Für den Zeitschriftenartikel ist MS Word der Standard. Aber muss das so sein? Wie könnten Redaktion und Autor vielleicht noch besser zusammenarbeiten? Oder was ist “Gedankensammlungen” in Unternehmen? Oder mit selbstverlegten Büchern oder eben Blog-Artikeln, wo noch mehr Feedback gewünscht ist?

Für manches haben sich Wikis sehr empfohlen. Die Materialsammlung für Clean Code Developer haben wir auch in einem Wiki vorgenommen. Für ein Buchmanuskript schien mir das bisher jedoch nicht passend. Da setze ich auf Markdown-Texte, die ich in meiner Dropbox verwalte und per Leanpub veröffentliche. Alternativ könnte ich aber auch ein Git-Repository benutzen. Nur für Kommentare von Lesern nah am Text ist das noch nicht das Richtige.

Aber jetzt bin ich auf hackpad.com gestoßen. Das sieht irgendwie cool aus. Artikel, genannt Pads, lassen sich dort so einfach wie in einem Wiki bearbeiten und verlinken. Man kann sie mittels Tags und sog. Collections organisieren und unter dem Dach eines Workspace veröffentlichen.

Einfache Refaktorisierung wird unterstützt (“extract pad”), Verlinkungen wie in Wikis sind mühelos, Medien können eingebettet werden. Und: Mehrere Benutzer können am selben Text arbeiten. Gleichzeitig. Man sieht, welche Teile von wem stammen. Explizite Kommentare sind auch möglich. Das finde ich cool für Texte, die “work in progress” sind oder eben das Werk einer Gruppe.

Aufsetzen lässt sich ein Workspace bei Hackpad leichter als ein Wiki, finde ich. Deshalb überlege ich mit Stefan Lieser, ob wir unsere nächste Initiative nach Clean Code Developer dort hosten. Zu klären ist dafür jedoch noch, ob Google die Pads von öffentlichen Workspaces ordentlich indexiert.

Allemal, so glaube ich, lohnt Hackpad aber einen Blick für alle, die ein Unternehmenswiki einrichten wollen.

Hier als Beispiel eines Pads ein Text aus meinem englischen Blog. In dem Pad hier können Sie auch schreiben. Mit “//” beginnen Sie eine Kommentarzeile.

Viel Spaß beim einhacken von Gedanken! :-) Hackpad sozusagen als “thought IDE”.

Wunderlist für Personal Kanban

Ein Tool ist kein Selbstzweck, sondern soll dienlich sein. Das trifft auf Software zu wie auf Methoden.

Um meine Arbeit zu organisieren, wenn es mal wieder etwas mehr wird, habe ich vor einiger Zeit Personal Kanban eingeführt. Naja, “einführen” kann man da nicht viel ;-) Ich habe also angefangen, nicht nur eine Aufgabenliste zu führen, sondern die Aufgaben über ein Brett zu ziehen.

Das funktioniert - aber irgendwie, irgendwie fand ich es zu aufwändig. Die Software KanbanFlow stand mir im Weg. Es fühlte sich umständlich an. Und so schlief die Methode immer wieder ein.

Doch nun bin ich wieder dabei. Neues Tool, neues Glück. Hier fühle ich mich freier. Irgendwie. Und das eherne Gesetz des Personal Kanban “Transparenz” wird immer noch erfüllt.

Mein neues Tool heißt Wunderlist. Das gibt es auf allen Geräten und im Browser, selbstverständlich synchronisiert.

Es ist viel einfacher. Nix Kanbanbrettspalten. Keine Kärtchen. Einfach nur Listen.

Aber genau das macht den Unterschied für mich. Die Bedienung ist mehr auf den Punkt, finde ich.

Mein “Backlog”, das, was zu tun ist, pflege ich in verschiedenen Listen. Hier eine als Beispiel geöffnet, weitere sind darunter links zu sehen:

Das, was ich gerade tue, markiere ich als wichtig, so dass es herausgestellt in einer eigenen Liste steht:

Das ist mein WIP (work in progress). Wunderlist bietet da zwar keine WIP-Begrenzung, aber das ist auch nicht so wichtig. Es ist halt meine Verantwortung, nicht mehr als 1–2 Einträge über die Listen hinweg jeweils bis zur Erledigung als wichtig zu markieren.

Und am Ende kommen alle Aufgaben ins Archiv. Sie sind dann done:

Termine, Notizen, Teilaufgaben, Kommentare… das alles gibt es auch. Gelegentlich nutze ich es. Für den häufigsten Fall jedoch, die Abarbeitung von ständig einfließenden Aufgaben, reicht es mir völlig, schnell einen Eintrag in einer Liste machen zu können.

Wer sich noch überwältigt fühlt von zu erfüllenden Wünschen, der kann ja mal versuchen, mit Wunderlist etwas Systematik reinzubringen.

Die vielen Gesichter des Product Ownership

Wie sollte, wie kann Product Ownership aussehen? Stefan Rook hat dazu einen Vortrag gehalten:

Product Ownership hat also viele Gesichter. Diese Botschaft hat mir an dem Vortrag gefallen. Mir hat allerdings auch etwas gefehlt. Nämlich die Abstraktion. Was ist das Muster? Worum geht es im Kern?

Mag sein, dass das schon allen klar ist. Meine Erfahrung ist jedoch, dass die meisten Unternehmen genau da jedoch herumeiern. Denn wäre es ihnen klar, würde sich die Ermunterung von Stefan Rook, Product Ownership durchaus unterschiedlich zu leben, erübrigen.

Hier mein Versuch einer Abstraktion:

Die Hauptaufgabe des Product Owners (PO) nach Anschauen des Vortrags ist… die Priorisierung von Anforderungen.

Bei Wooga haben die Teams in einem Rahmen alle Freiheit und tun das selbst; in den Teams ist es der Product Lead, denke ich mal, der dafür verantwortlich ist, aber wohl sehr eng mit seinen wenigen Teamkollegen in dieser Hinsicht zusammenarbeitet.

Bei Jimdo ist es der Manager mit dem PO-Hut auf.

Bei der Zeitung gibt es dafür die Berechnungsvorschrift im Tagesgeschäft, die vom PO verwaltet wird.

Immer gibt es eine Reihe von Stakeholdern mit Wünschen; immer müssen diese Wünsche mit begrenzten Ressourcen erfüllt werden; also muss immer priorisiert werden. Ohne Priorisierung gibt es keine geordnete, verlässliche Umsetzung.

Ziele

Die besprochenen Szenarien unterscheiden sich darin nicht, sondern in der Zahl der Ziele, auf die hin die Wunscherfüllung priorisiert werden muss. Bei Wooga gibt es viele gleichzeitige Ziele; jedes Projekt hat seines. Bei Jimdo und der Zeitung hingegen gibt es nur eines.

Jedes Ziel hat viele Stakeholder und braucht daher einen PO der deren Wünsche auf die eine Umsetzungsressource hin priorisiert.

Wenn Sie Ihre PO-Strategie nun überdenken wollen, dann fragen Sie sich: Welche Ziele gibt es? Jedes verdient einen PO.

Gewichtung

Der PO hat in Bezug auf ein Ziel hin die Kompetenz (und Erlaubnis) zur Priorisierung. Und wie macht er das? Bei Wooga und Jimdo erfahren wir nichts darüber. Das kann “nach Gefühl und Wellenschlag” gehen. Bei der Zeitung hingegen, wird eine Formalisierung angedeutet. Dort wird “ohne Zorn und Eifer” priorisiert; alle Stakeholder stehen “im fairen Wettstreit”. Solange sie ihre Wünsche ehrlich in verschiedenen Kategorien bewerten, ergibt sich eine vorteilhafte Hitliste von Wünschen.

Dieser Unterschied ist für mich deutlich genug herausgekommen: Priorisierung kann mehr oder weniger formal geschehen. Jedes Unternehmen muss sich also fragen, wie nachvollziehbar die Priorisierung sein soll (oder auch kann).

Noch betrüblicher fand ich dann, dass die Bewertung bei der Zeitung so stehengelassen wurde. Als seien die Bewertungen gleichzeitig die Prioritäten.

Der PO als Herr über den ROI. Das wurde schon am Anfang gesagt. Kann er diese Aufgabe mit den Bewertungen in der Hand aber erfüllen? Nein.

Die Bewertungen, also Wertzuschreibungen die mehr oder weniger direkt auf erwartete verringerte Verluste oder vergrößerte Umsätze/Gewinne verweisen, sind nur ein erster Input für die Priorisierung. Schön, wenn Anforderung A bei Umsetzung 100.000 EUR einbrächte. Aber über welchen Zeitraum – und vor allem: mit welchem Aufwand?

Leistung ist nicht Arbeit und auch nicht Arbeit mal Zeit, sondern Arbeit pro Zeit. Die Aufgabe des PO bei der Priorisierung ist es, die Leistung zu optimieren. Die besteht darin, möglichst viel Wert mit möglichst wenig Aufwand zu schaffen.

Dieser Gedanke steckt auch in der Priorisierung mit “Weighted Shortest Job First” (WSJF). Einem Wert wird dort ein Aufwand gegenübergestellt, so dass sich ein Gewicht ergibt. Je gewichtiger dann ein Wunsch, desto eher sollte er umgesetzt werden.

Ein Wert von 100, der mit einem Aufwand von 10 realisiert werden kann (Gewicht: 100/10=10), hat ein geringeres Gewicht, als ein Wert von 50, der mit einem Aufwand von 4 realisierbar ist (Gewicht: 50/4=12,5).

Wie Wert und Aufwand ermittelt werden, ist von Ziel zu Ziel verschieden. Das finde ich wichtig herauszustellen. Um die Priorisierung gewissenhaft vornehmen zu können, muss ein PO also Wertmaßstäbe und Aufwandsmaßstäbe definieren.

Wer dann entscheidet, “das mache ich aus dem Bauch heraus”, muss nicht falsch liegen. Nachvollziehbar ist das jedoch kaum. Und was das für flüssige Kommunikation und Vertrauensaufbau bedeutet, kann man sich denken.

Aber… warum soll es nicht Situationen geben, wo das (zunächst) ausreicht? Entscheidend ist, dass man sich einmal dazu Gedanken gemacht hat – und in Retrospektiven die Annahmen immer wieder überprüft.

Abnahme

Am bedauerlichsten fand ich, dass der Vortrag nichts über die Aufgabe des POs als schließende Klammer der “Wertproduktion” gesagt hat. Es wurden nur Varianten der öffnenden Klammer gezeigt. (Was allerdings in der Tradition der Scrum-Darstellungen ist, die vor allem Backlog und Planning betonen – das Review bzw. die Abnahme demgegenüber jedoch vergleichsweise schwach ausleuchten.)

Das halte ich für einen Kardinalfehler, weil sich genau hier nämlich immer wieder das größte Problem von POs zeigt: Sie glauben, sie könnten Anforderungen “über den Zaun kippen” und bekommen dann “wie versprochen” Wert geliefert.

Das  ist der Ansatz “Stopfgans”. Da hilft auch nicht, am Anfang in schönem Einvernehmen mit Entwicklern über User Stories zu diskutieren.

Wenn der PO nicht an der “Wertschöpfung” zieht, entsteht kein rechter Fluss.

Hier spekuliere ich mal in Bezug auf die vorgestellten Szenarien: Bei Wooga und Jimdo ist das kein Problem, weil der PO besonders eng-agiert an den Entwicklern dran ist. Abnahme passiert hier ständig. Das große Ziel ist auch allen klar. Hohe Kohärenz der Energie aller Beteiligten. Bei Wooga nehme ich sogar an, dass die Entwickler wie bei Open Source Projekten z.T. ihre eigenen Kunden sind.

Schön, wenn das so ist – nur muss man eben wissen, warum es funktioniert. Co-location reicht da nicht aus. Es kommt auf den Willen des PO an.

Wie es bei der Zeitung ist, kann ich nur ahnen. Die Priorisierung ist explizit. Schön. Aber wie ist die Abnahme? Zieht da jemand an Wert? Wie groß sind die Brocken, die in die Entwicklung hineingekippt werden? Nach meiner Erfahrung mit größeren Unternehmen vermute ich, dass das nicht so einfach fließt wie bei Wooga und Jimdo. Man glaubt eher, dass “Reinkippen” schon ein Garant dafür ist, dass auch etwas rauskommt.

Aber ich kann nicht beurteilen, wie es dort ist. Ich kann nur betonen, wie wichtig eben die schließende Klammer Abnahme bei der Softwareentwicklung ist. Automatisierte Akzeptanztests sind nicht genug. Ein Mensch auf 2 Beinen erzeugt viel mehr Zug als ein paar Tests, die auf grün gehen müssen.

Der PO ist für mich die wichtigste Rolle in der Softwareentwicklung. Angesichts dessen, welch feste Strukturen in der Codierung entstehen und wie schwer es ist, dafür gute Leute zu finden, ist die Qualitätssicherung bei den Anforderungen immens wichtig. Vor der Codierung und nach der Codierung. Einen PO einzusetzen ist eine Maßnahme im Sinne des 3. Fokussierungsschritts der Theory of Constraints (TOC).

Ohne PO ist die Codierung der Engpass der Softwareproduktion. Mit PO… wird allerdings schnell der PO zum Engpass. Daher bin ich nicht überzeugt, dass das Jimdo-Modell oben auf der Liste zur Nachahmung stehen sollte. PO sein ist ein Vollzeitjob (außer bei trivialen Zielen). PO+Entwickler oder PO+Geschäftsführer sind für mich Anti-Patterns.

Bottom line

Ich stimme Stefan Rook zu, dass Product Ownership viele Gesichter haben kann. Welches zu einem Unternehmen passt, muss sich jedoch aus der Beachtung von Prinzipien ergeben:

• Anforderungen im Rahmen eines Ziels müssen auf dem Weg zu den “Transformatoren” durch 1 Instanz gehen, den PO. Er ist die “single source of truth”.
• Der PO priorisiert durch Gewichtung in angemessener Nachvollziehbarkeit. Er stellt dafür Wert und Aufwand gegenüber.
• Was im System zur Umsetzung ist, muss möglichst schnell aus dem System herausgezogen werden. Erst dann entsteht Wert. Die vornehmste Aufgabe des PO ist daher der Zug am Ende der Produktionskette, die Abnahme. Die muss ab-so-lut verlässlich geschehen.

Im Rahmen dieser Prinzipien können Sie jede Form des Product Ownership wählen. Form Follows Function. Oder sie fragen sie mit diesen Prinzipien in der Hand, was Ihrem heutigen Product Ownership womöglich noch fehlt.