Derjenige, der überzeugt ist, auf dem Königsweg zu sein, ist meist auf dem Holzweg.
Zwischengedanke: Alles beim Alten
Die alten Ideen in der Neuen Arbeitswelt sind schlechter als die neuen Ideen in der Alten Arbeitswelt.
Warum schätzen wir das Schätzen so?
Ich hatte kürzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem größeren agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Schätzungen“ und wie diese im Team angegangen werden.
Zunächst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem groß skalierten Scrum-Projekt, das für seinen Auftraggeber auch eine der ersten Berührungen mit agilem Vorgehen ist. Dementsprechend gibt es in dem Projekt und im Umfeld des Projektes eine bunte Mischung aus dem Wunsch, alles „richtig“ und „by the book“ zu machen und Erwartungen und Gewohnheiten, die sich noch sehr an dem bisherigen Vorgehen aurichten.
Eines der Rituale, das dort eingeführt wurde, ist auch das Planning Poker, mit dem den Sprint-Aufgaben Story Points gegeben werden. Daran störte sich nun mein Kollege sehr – von der Frage, warum man denn nun auf einmal Komplexität statt Aufwand schätzen sollte bis hin zu dem zähen Vorgehen, da man in Unkenntnis des Aufgabeninhaltes Zahlen „raten“ müsse.
Interessant war für uns im Gespräch darüber, dass sich einige Dysfunktionalitäten des Vorgehens genau an diesem Punkt heraus kristalisierten.
Der offensichtlichste Punkt ist der, dass es in dem Team aktuell kaum Teamarbeit gibt – im Endeffekt hat jedes Gruppenmitglied seine oder ihre Aufgaben und arbeitet diese innerhalb des Sprints ab, man kann kaum anderen helfen, da jeder ein Spezialgebiet bearbeitet. Das macht die Schätzrunden schwierig, da jeweils immer nur ein Teammitglied eine Aussage zur Komplexität machen kann, während die anderen versuchen zu „erraten“, was diese Person wohl schätzen wird.
Die eigentlichen Probleme im Team zeigen sich aber, wenn man beginnt zu hinterfragen, warum überhaupt Schätzungen gemacht werden. Wenn ja ohnehin jeder seine Aufgaben hat, wird die Schätzung dann benötigt um zu wissen, ob die Aufgaben in den Sprint passen? Soll mit dem Schätzen sichergestellt werden, dass alle im Team das gleiche Verständnis der Aufgabe haben?
Leider war die Antwort, dass das Schätzen benötigt werde, da das Projektcontrolling damit die Leistungsfähigkeit des Teams messen und überprüfen wolle. Darin sehe ich ein grundsätzliches Problem, das ich hier schonmal angesprochen habe, nämlich, dass ein Indikator zu einem (zumindest indirekten) Ziel erklärt wird. Schließlich soll sich – so die Erwartung des Controllings – der Output des Teams ja verbessern. Wenn das erwartet wird, so sorgt dies bestenfalls zu einem Drift der Schätzungen nach oben. Doch selbst, wenn das nicht der Fall wäre: Die Schätzung der Komplexität (meinetwegen auch des Aufwandes) der Aufgaben ist für diese Fragestellung eine absolut unbrauchbare Schätzgröße! Damit wird bestenfalls der konstante (oder steigende) Mittelabfluss sichergestellt, das sagt absolut nichts darüber aus, wie gut der Output des Teams ist! Dann sollte besser der Product Owner den Business Value der Features schätzen. (Und ja, auch da würde sich sicherlich die Schätzung verändern, wenn ich anfange, das zum Ziel zu erklären.)
Es gibt meiner Meinung nach einige Gründe, warum ein Schätzen durch ein Team sinnvoll sein kann. Beispielsweise, damit das Team weiß, wie viel Komplexität es im Sprint umsetzen kann. Hier kamen wir übrigens auf die Diskussion, warum dann nicht gleich Aufwand geschätzt werden sollte. Meiner Meinung nach deswegen, weil die Komplexität eine Einigung erlaubt, auch wenn die Skills im Team unterschiedlich verteilt sind. Es mag sein, dass ich für die Implementierung eines Features 5 Tage brauche, wenn ich mich in der Technologie nicht auskenne, eine erfahrenere Entwicklerin benötigt eventuell nur 2 Tage. So könnten wir uns nie auf einen Aufwand einigen, wohl aber darauf, dass eine CRUD-Applikation nicht allzu komplex wäre. Zudem kann ich mit der Schätzung von Komplexität auch belegen, dass zumindest ein ähnliches Verständnis für das Feature existiert. Nicht zuletzt habe ich damit einen Indikator, dass ein Team eine bestimmte Velocity hat und diese auch besser werden kann.
Das „Standardziel“ ist es, dass der PO mit den Schätzergebnissen eine Vorstellung davon hat, welche Features in einem längeren Zeitraum schaffen kann, diese Schätzungen helfen bei einer langfristigen Planung. Damit diese Schätzungen allerdings eine Aussagekraft haben, müssen eine ganze Reihe von Voraussetzungen erfüllt sein: Das Team muss relativ stabil sein, um seine Velocity kennen und halten zu können; die Schätzgrundlage muss stabil bleiben können, es darf also nicht durch falsche Zielvorgaben eine Veränderung der Schätzbasis belohnt werden; das Entwicklungsziel muss bekannt genug sein, um zukünftige Features sinnvoll und stabil beschreiben (und in der Komplexität kennen) zu können.
Kurz gesagt, Schätzen ist kein Selbstzweck. Bevor man eine Schätzmethode auswählt oder anwendet, sollte das Ziel der Schätzung klar sein, was in der Realität leider erstaunlich selten der Fall ist.
Lesestoff: Gruppenclown für Teamarbeit
Das fand ich einen sehr interessanten Artikel im Spiegel-Online:
Quintessenz: jedes funktionierende Team braucht einen Gruppenclown. Den Artikel drucke ich mir aus, falls mal wieder kemand meint, ich sei albern. 😉
Zwischengedanke: Managementstile
Walfisch-Management:
Auftauchen, Welle machen, abtauchen.
Digitalisierung – Was ist das?
Bei „Captain Power and the Soldiers of the Future“ war das mit der Digitalisierung noch ganz einfach: Ab und an kam der Antagonist, ein fliegender Roboter namens Soaron und digitalisierte Menschen, die dann zu Robotern werden sollten. (Okay, ich gebe es zu: Ich bin ein alternder Nerd.) Heute ist das etwas schwieriger – jetzt wollen alle digitalisieren und eigentlich wissen die meisten gar nicht, was sie damit überhaupt meinen.
Digitalisierung ist „Agilität“, „Schnelligkeit“, „Kundenzentrierung“… Ich weiß gar nicht, was ich alles schon an Erklärungen gehört habe, was Digitalisierung sei. Es scheint also in erster Linie zu sein: Ein Buzzword ohne Bedeutung.
Trotzdem wird jedoch versucht, mit dem Begriff ein Phänomen zu beschreiben, das uns und die Wirtschaft sehr betrifft.
Die ursprüngliche Bedeutung des Wortes ist übrigens ziemlich nahe an dem „Captain Power“-Beispiel: Dokumente werden beispielsweise mit einem Scanner digitalisiert, also in ein Dateiformat für den Computer verwandelt. Die „Digitalisierung“, die in der Wirtschaft oft gemeint ist, ist davon meiner Meinung nach gar nicht so weit entfernt, hier geht es um die Abbildung von Geschäftsprozessen und Vertriebswegen in der IT. Sicherlich begann nach dieser Definition die Digitalisierung bereits, als Mainframe-Computer mit COBOL-Programmen die Folianten in manchen Unternehmen ablösten – aber wenn man nur dies unter Digitalisierung verstehen würde, so wären sogar deutsche Amtsstuben schon vorbildlich digitalisiert.
Digitalisierung geht meiner Meinung nach insofern noch weiter, als dass die IT nicht nur unterstützende Funktion in einzelnen Prozessschritten hat, sondern indem der (Geschäfts-)Prozess an sich durch die IT verändert wird. Das mag nach einer etwas haarspalterischen Unterscheidung klingen, ist jedoch ein fundamentaler Unterschied, ob ich einen Computer verwende, um in einer Autowerkstatt die Fehlerbeschreibung eines Kunden zu erfassen, oder ob der Motor selbst per IoT-Technologie einen Wartungstermin ausmacht, zu dem die benötigten Ersatzteile bereits geliefert wurden.
Die Herausforderung besteht daher in der „Digitalisierung“ darin, dass Entwickler nicht mehr nur in der Umsetzung der Geschäftsprozesse zuarbeiten. Früher war es durchaus möglich, dass sich der „Fachbereich“, der die Geschäftsprozesse definierte, der IT nur als Unterstützung bedienen konnte. Durch die Digitalisierung ist dies nicht mehr ausreichend! Der Fachbereich braucht selbst tiefes IT-Wissen, da das Design des Geschäftsprozesses von der IT stark beeinflusst werden muss.
Gerade für große Unternehmen und Konzerne bedeutet dies meiner Meinung nach, dass einige bisherige Trennung von operativen Bereichen und der IT aufgehoben oder zumindest aufgeweicht werden muss; die Rollen von CEO und CIO müssen verschmelzen.
Entwickler dürfen auch mal kochen
Ich hatte dieser Tage die Gelegenheit, mit einem Kollegen über ein Thema zu sprechen, das mich hin und wieder beschäftigt, nämlich der Angewohnheit von Managern, die Arbeit in der Softwareentwicklung ständig mit anderen Branchen zu vergleichen.
Dieses interessante Gespräch brachte mich dazu, einen früheren Artikel zu dem Thema zu überdenken und meine Meinung (ein wenig) zu ändern.
Zunächst möchte ich klarstellen, dass ich nicht den Eindruck erwecken wollte, Softwareentwicklung sei etwas „absolut Einzigartiges“, was so besonders sei, dass die anderen Branchen keine nützlichen Erfahrungen für uns Softwareentwickler bieten.
Da setzte auch das Argument meines Kollegen an, das ich sehr gut finde: Manchmal hilft der Vergleich mit anderen Branchen oder Metaphern aus anderen Hintergründen, um das eigene, festgefahrene Denken zu verlassen. Nach dem Motto „Wenn Libraries und Frameworks Nahrungsmittel wären und ein Entwicklerteam ein Thermo-Mix, worauf müssten wir dann achten?“ Vielleicht darauf, dass die Nahrungsmittel nicht abgelaufen sind, Libraries also nicht veraltet, und darauf, dass Allergene angegeben werden, dass wir also die „Nebenwirkungen“ der Frameworks kennen.
Unter einem solchen Gesichtspunkt ist es denn auch in Ordnung, wenn ein Manager oder eine Managerin sagt „Nehmen wir an, ein Entwicklungsprojekt wäre eine Küche.“ So lange man ihm oder ihr abnehmen kann, genug Ahnung von der Softwareentwicklung zu haben, um die Unterschiede zwischen einer Herdplatte und einem Schreibtisch zu kennen. 😉
Gefangen im Zielsystem
Zielsysteme sind ein wichtiger Bestandteil in der Steuerung fast aller größerer Unternehmen. Manchmal ganz „klassisch“ mit vorgegebene Zahlen-Zielen, an denen noch irgendein Bonus hängt, manchmal etwas „moderner“ in der Form von OKRs.
Viele dieser Systeme sind meiner Meinung nach allerdings kaputt; sie sind in der Realität nicht so brauchbar, wie es die Theorie erstmal vermuten lässt. Darauf möchte ich in ein paar Artikeln hier eingehen, vorher möchte ich jedoch etwas Theorie stellen, da diese das meiner Meinung nach gängigste Problem von Zielsystemen erklären kann: das Gefangenendilemma.
Das Gefangenendilemma kennt vielleicht der ein oder andere aus der Spieltheorie. Die Geschichte in dem Modell funktioniert in etwa so:
Zwei Personen, die gemeinsam ein schweres Verbrechen verübt haben, werden verhaftet und einzeln verhört. Das schwere Verbrechen kann leider nicht zweifelsfrei bewiesen werden, wohl aber ein kleineres Verbrechen. Daher bietet der Staatsanwalt folgenden Deal an: Wenn Du gestehst, Dein Kollege aber nicht, so wirst Du als Kronzeuge frei kommen und der andere kommt für 20 Jahre ins Gefängnis. Gesteht ihr beide, kommt ihr beide für jeweils 15 Jahre in den Knast. Gesteht keiner von euch, so kommt ihr zumindest wegen des kleineren Vergehens für jeweils 5 Jahre ins Gefängnis.
Der rationale Verbrecher denkt nun so: Wenn mein Kumpel nicht gesteht und ich auch nicht, so muss ich für 5 Jahre ins Gefängnis. Wenn ich gestehe, dann gar nicht. Also wäre es in diesem Fall besser für mich, wenn ich gestehe. Wenn mein Kumpel uns aber verpfeift und ich nicht, so muss ich für 20 Jahre ins Gefängnis, es sei denn, ich gestehe auch, dann sind es nur 15. Also wäre es auch in diesem Fall besser, zu gestehen. In beiden Fällen wäre es also die rationale Entscheidung jedes Einzelnen, das Verbrechen zuzugeben. Am Ende werden also beide gegen den anderen Aussagen, womit insgesamt 30 Gefängnisjahre (15 für jeden) fällig werden.
Die optimale Lösung aus der Gesamtsicht (zumindest aus der Gesamtsicht eines Verbrecherkonsortiums) wäre es natürlich, wenn beide schweigen, da dann insgesamt nur 10 Jahre Gefängnis drohen. (Gesteht einer, so sind 20 Gefängnisjahre abzugelten, was auch schlechter ist.) Allerdings ist rein aus der Spieltheoretischen Sicht das Ergebnis „beide halten dicht“ nicht erreichbar, da es für den Einzelnen IMMER besser wäre, den anderen zu verraten.
Verallgemeinert man diese Geschichte, so sprechen wir davon, dass die beiden Verbrecher die „Spieler“ in diesem Spiel sind, wenn der Eine gegen den Anderes aussagt, so defektiert er. (Das ist das Gegenteil von Kooperation. Natürlich kooperiert der Verbrecher mit der Staatsanwaltschaft, aber hier geht es um die Kooperation der Spieler untereinander.)
Zusammengefasst: In einer Situation wie in einem Gefangenendilemma ist es für die Spieler immer rational zu defektieren. Das ist das sogenannte „Nash-Gleichgewicht“, das heißt, kein Spieler kann durch einseitige Abweichung seines Verhaltens (also Kooperation) sein Ergebnis verbessern. Im Gefangenendilemma ist das Nash-Gleichgewicht allerdings keine Pareto-optimale Lösung. Pareto-optimal wäre die Lösung dann, wenn aus Gesamtsicht das Ergebnis nicht verbessert werden könnte. Im Gefangenendilemma ist das grundlegende Problem, dass die Pareto-optimale Lösung eben kein Nash-Gleichgewicht ist und somit nicht erreicht werden kann.
Tiefer möchte ich auf das Gefangenendilemma an dieser Stelle gar nicht eingehen, es gibt außerdem Seiten, die das Thema umfänglicher und besser darstellen. (Zum Beispiel hier oder hier.) Insbesondere wird es interessant, wenn man das Modell auf mehr als 2 Spieler (n-Personen) ausdehnt oder sogar wiederholt (das iterierte Gefangenendilemma).
Allerdings möchte ich an dieser Stelle schon eine Feststellung in den Raum werfen, meiner Meinung nach das Grundproblem aller Zielsysteme:
Jedes hinreichend komplexe Zielsystem eines Unternehmens stellt ein n-Personen-Gefangenendilemma dar, wodurch die Kooperation der Bereiche effektiv verhindert wird.