Agile Begriffe leicht erklärt: Das Planning Poker⌗

In unserer Reihe „Agile Begriffe leicht erklärt“ widmen wir uns der Welt der Agilen Entwicklung. Längst versuchen viele Firmen neue Mitarbeiter mit dem Wort „Agilität“ zu locken. Wir haben uns diese Welt aus der Perspektive der Informatiker mal genauer hingeschaut. Und waren entsetzt.

Worum geht es beim Planning Poker?⌗

Auftraggeber stehen heute unter immer höherem Kostendruck. Gleichzeitig haben Portale wie Ebay der breiten Bevölkerung Bieterverfahren zugänglich und verständlich gemacht. Heute hat die ganze Weltbevölkerung verstanden, wie Angebot, Nachfrage und die Preisgestaltung zusammenhängen.

Mit dem Planning Poker haben Betriebswirte zusammen mit Agile Coaches ein Auktionsverfahren für Arbeitspakete in der Software-Entwicklung etabliert. Vermeintlich viel zu teure Informatiker sollen sich dabei unter dem Deckmantel der Gamification und der Story Points im Preis unterbieten und damit den Kostendruck mildern.

So funktioniert Planning Poker⌗

Wir vom ICCB.dev als aufklärende Bildungsorganisation im Bereich IT sehen uns zur Wahrheit verpflichtet. Deswegen haben wir eine transparente Schritt-für-Schritt-Darstellung des Verfahrens ausgearbeitet. Hier die Details:

Schritt 1: PO stellt Arbeitspaket vor⌗

Der PO stellt zunächst das Arbeitspaket vor. Dies passiert in der agilen Welt in Form von User Storys aus der Benutzerperspektive. Hier ein Beispiel aus einem Projekt eines namhaften Automotive- Zulieferers:

As a

Car Owner

I want

a CAN message containing the braking force available from memory-mapped 4-bit
sensor data at 0x400024 as unsigned short, shifted left by 4 bits XOR-ed
with 0x0070 so that the CAN transceiver can send the packet via CAN-bus
transceiver 2 with ID 0x07.

so that

ECU transm_auto_2 can react accordingly.

Schritt 2: Entwickler stellen Fragen⌗

Im nächsten Schritt bekommen die konkurrierenden Entwickler die Gelegenheit, Detailfragen zur Umsetzung und zu Randfällen zu stellen. Da das Planning Poker als Online- oder Präsenzverfahren veranstaltet wird, liegt hier ein gewaltiger Zeitdruck auf den Entwicklern. In einem Zeitraum von nur wenigen Minuten sollen alle Details geklärt werden, während jeder Bieter souverän als Profi auftreten muss. Nicht selten entscheidet sich der Auftraggeber schon in dieser Phase gegen jene Entwickler, die dümmliche Fragen stellen. Sie werden schon vor dem ersten Bieterverfahren ausgeschlossen.

Schritt 3: Erste Bieterrunde⌗

Die Gebote werden durch Auktionsregeln auf feste Preiskategorien festgelegt. Dies wird zusätzlich durch Story Points (Fibonacci-Zahlen), Tiere, Shirt-Größen oder Früchte verschleiert. Im Zweifelsfall greift der Entwickler besser zur kleineren Preiskategorie, um die Option auf das Arbeitspaket nicht zu verlieren.

Die Details zur Umrechnungtabelle ist hier zu finden [1]

Jeder Entwickler bekommt bestenfalls 60 Sekunden Zeit, um ein Gebot zu platzieren. Nach jenen 60 Sekunden werden alle Gebote zeitgleich aufgedeckt. Die günstigsten Gebote kommen in die nächste Bieterrunde.

Schritt 4: Klärung des Lieferumfangs⌗

Zur Absicherung der Lieferung bekommen die verbleibenden Bieter nun die Gelegenheit, den Lieferumfang, den Liefertermin und die Produkthaftung zu erklären. Der Auftraggeber stellt damit sicher, dass am Ende des Bieterverfahrens derjenige Entwickler den Zuschlag bekommt, der seiner Verantwortung am besten gerecht wird. Durch die Offenlegung der Gebote soll gleichzeitig sichergestellt werden, dass sich die günstigsten Bieter weiter unterbieten und die Kosten für den Auftraggeber noch weiter sinken.

Schritt 5: Zweite Bieterrunde⌗

In der zweiten Bieterrunde kennen die Entwickler bereits die Gebote der anderen Entwickler. Aus Auftraggebersicht optimieren die Entwickler dabei die Kosten. Im Hintergrund haben Betriebswirte bereits Umrechnungstabellen von Story Points mit den Auftraggebern ausgehandelt. Unter dem Deckmantel der Gamification und kindischen Punkten, Tieren oder T-Shirts glauben die Entwickler, dass das Bieterverfahren eine lustige unverbindliche Veranstaltung sei.

Jeder Entwickler muss nach nur wenigen Sekunden Bedenkzeit sein finales Gebot platzieren. Der Auftraggeber vergibt den Entwicklungsauftrag für das Arbeitspaket an den Niedrigstbietenden. In der Realität merken die Entwickler dabei nur selten, dass das Arbeitspaket im Hintergrund direkt an den Niedrigstbietenden vergeben wird. Fakturiert werden darf selbstverständlich nur, wenn das viel zu niedrig bepreiste Arbeitspaket vollumfänglich geliefert wurde. Gebote, die wegen des Drucks viel zu optimistisch platziert wurden, liegen dabei voll im Verantwortungsbereich des jeweiligen Entwicklers.

Bewertung des Verfahrens⌗

Durch das drückende Bieterverfahren torkeln die Umsätze der Entwickler in den Abgrund. In der jährlichen Gehaltsverhandlung kommt der geringe Umsatz zur Sprache, womit Informatiker in ihren Gehaltsforderungen kleingehalten werden.

Der Ansatz, per verkappter Auktion die Entwickler unter Druck zu setzen, ist ein weiterer perfider Versuch der Betriebswirte, Agile Coaches und Vertriebler, sich das Leben leicht zu machen. Die Wertschöpfung des Informatikers wird verkehrt in ein Lohn-Dumping. Betriebswirte, Agile Coaches und Shareholder der Auftraggeber stopfen sich derweil die Taschen voll. Wir können daher vor „Planning Poker“ nur warnen und abraten.

[1] Hintergründe zu Story Points https://iccb.dev/posts/story-points/