Montag, 30. Mai 2016

Kommentierte Links (XIII)

Grafik: Pixabay / Geralt - Lizenz
  • Mike Cohn: Don’t Estimate the Sprint Backlog Using Task Points

  • Eines meiner ersten Teams hatte ebenfalls die Idee eine Schätzung nach Task-Points zu machen, und dort habe ich es auch für einen sinnvollen Ansatz gehalten. Die Situation war allerdings eine besondere: alle Teammitglieder waren große Fans von Mob- oder Pair-Programming. Aus diesem Grund wurden fast alle Tasks gemeinschaftlich bearbeitet, weshalb es (analog zur Story) Sinn machte, eine neutrale Bewertungsmetrik zu haben. Dort wo es eher die Entwickler mit Schwerpunkten für Frontend, Backend, QA, etc. gibt, die auch alle in erster Linie ihre Spezialtasks bearbeiten, da macht es weit weniger Sinn.

  • Nature: A platform for the discovery of newmacrolide antibiotics

  • Vermutlich würden die sechzehn Verfasser dieses Nature-Artikels ihr Vorgehen nicht als agil bezeichnen (ich unterstelle einfach mal, dass sie den Begriff gar nicht kennen), letztendlich ist es aber genau das. Ausgangsproblem ist, dass Bakterienstämme durch Gewöhnung immer wieder gegen Antibiotika immun werden. Die neue Methode erlaubt es jetzt, die grundlegenden Moleküle nach einem Baukasten-System auseinanderzunehmen, zu modifizieren und wieder zusammenzusetzen. Der so enstandene Wirkstoff wird anschließend gegen die bekannten Bakterienstämme getestet. Ist er wirksam kann er in die Produktion gehen, ist er es nicht wird er erneut modifiziert und getestet, so lange bis das gewünschte Ergebnis erzielt ist. Build, inspect and adapt in der Chemie.

  • Verena Töpper, Leo Widrich: "Wir veröffentlichen alle Gehälter im Internet"

    Irgendwie ist es ein journalistischer Reflex geworden, auf jede Firma anzuspringen, die ihre Gehälter transparent macht. Was ich an diesem Interview mit Leo Widrich interessant finde ist aber etwas völlig Anderes: ganz im Sinne der Idee selbstverwalteter Teams wurde in seiner Firma das Management abgeschafft - nur um ein halbes Jahr später wieder eingeführt zu werden. Das deckt sich mit meiner Erfahrung, dass viele Teams mit zu viel Freiheit schnell überfordert sind. Das heißt übrigens nicht, dass das so nicht geht, es geht eben nur seltener als erhofft. Leider.

  • Mark Poppenborg: Überwachung am Arbeitsplatz - wie sie in sechs Phasen entsteht [Edit: Link ist mittlerweile tot]

  • Treffend beschrieben von Mark Poppenborg. Was mir zusätzlich dazu von Zeit zu Zeit begegnet ist ein noch bemerkenswerteres Phänomen: selbstverwaltete Teams begeben sich selbst ohne Not in derartige Überwachungen hinein. Ähnlich wie in diesem Beispiel sind es zu Beginn durchaus rationale Beweggründe, zu denen allerdings bald etwas Verheerendes hinzukommt - das Bedürfnis nach Einzelfallgerechtigkeit. Sobald dem nachgegeben wird verstricken sich auch gute Teams in den absurdesten Regelwerken, denen irgendwann nur noch wie dem gordischen Knoten beizukommen ist: alles in Stücke hauen und wegwerfen.

Donnerstag, 26. Mai 2016

Personality Poker


Für alle, denen Retrospektiven immer gleich vorkommen: eine mögliche Variation ist es, eine Runde Personality Poker zu spielen, so wie ich es im letzten Sprint mit einem meiner Teams gemacht habe. In Kürze erklärt: das Spiel besteht aus 52 verschiedenen Karten, die den üblichen Pokerkarten entsprechen. Zusätzlich dazu steht auf jeder Karte eine Eigenschaft, z.B. diszipliniert, skeptisch, loyal oder impulsiv.

In einer ersten Runde durfte jedes Teammitglied (insgesamt waren es sechs) jedem anderen eine frei ausgewählte Karte zuordnen. Die Ergebnisse wurden notiert und die Karten zurückgelegt. In einer zweiten Runde bekam jeder fünf neue Karten, die er durch ablegen und neu ziehen so lange modifizieren konnte, bis das Blatt der eigenen Selbstwahrnehmung entsprach. Anschließend wurden die eigene Bewertung und die Fremdbewertung nebeneinandergelegt. Allein das ergab bereits interessante Differenzen und Übereinstimmungen.

Um weiter ins Gespräch zu kommen überprüften wir als nächstes die Schwerpunkte der einzelnen Bewertungen. Grundsätzlich sollen rote Farben (Herz und Karo) emotionaler sein, schwarze Farben (Pik und Kreuz) dagegen rationaler. Die Karten ausserdem sind so konzipiert, dass den einzelnen Farben bestimmte Idealtypen entsprechen: ein Pik kennzeichnet analytische, datenorientierte Charaktere, die mit Schwerpunkt Karo sind flexibel und kreativ, die mit Herz sind empathisch und kollaborativ, wer mehrheitlich Kreuze hat erstellt und befolgt gerne Pläne. Das erscheint zwar zunächst klischeehaft, war aber erstaunlich nah an der Realität.

Kurze Retrospektiven (1 Stunde) dürften alleine mit den bisher genannten Schritten bereits ausgefüllt sein, da wir zwei Stunden hatten gingen wir auch weitere Auswertungsmöglichkeiten durch, in denen zusätzlich zu den bisherigen Kriterien auch weitere (z.B. positive oder negative Wertung der jeweiligen Eigenschaften) zu Hilfe genommen wurden um noch komplexere Persönlichkeits- und Wahrnehmungsprofile zu erstellen, deren Realitätsnähe wir dann besprechen konnten.

Mein Fazit: dieses Spiel mitsamt der damit verbundenen Diskussionen unterscheidet sich deutlich von den sonst üblichen Retrospektiven-Formaten und kann daher sehr gut geeignet sein um Abwechselung in dieses Event zu bringen. Wegen der negativen Wertung einiger Karten (u.a. existieren besserwisserisch, unorganisiert und überempfindlich) würde ich es allerdings nur mit Vorsicht einsetzen wenn in einem Team Spannungen bestehen oder die Mitglieder sich noch nicht gut kennen. Grundsätzlich kann ich es aber nur empfehlen.

Montag, 23. Mai 2016

Unternehmensbewohner

Bild: Wikimedia Commons/John Oxley Library - Public Domain
Stellen wir uns vor, wir würden in eine neue Wohnung ziehen. Am Anfang wäre das eine Gelegenheit zum kreativen Austoben: Neue Farben, neue Bilder, neue Möbel. Nach einiger Zeit beruhigt sich das. Es muss nichts neues mehr gekauft werden, es wird aber noch optimiert: der Fernseher kommt an eine andere Wand, damit das Sonnenlicht nicht mehr auf ihm reflektiert, der Tisch wird mehr in die Mitte gerückt, die Blumenvase kommt in den anderen Raum. Auch das ist irgendwann vorbei, alles ist jetzt so wie es sein soll. Von jetzt an muss nichts mehr geändert werden, alles ist gut.

Einstellungen wie diese findet man nicht nur in der eigenen Wohnung sondern auch in der Arbeitswelt. Die Angestellten haben sich ihre Position erarbeitet, verdienen genug und sind glücklich. Das große Problem - diese Menschen wollen im Regelfall keine Veränderungen in ihrer Umgebung mehr. Da sie den gegenwärtigen Zustand als optimal empfinden sehen sie es nicht ein, warum man etwas anders machen oder etwas Neues ausprobieren sollte. Abgeleitet von dem Wohnungs-Beispiel nennt man diese Gruppe "Unternehmensbewohner". Sie lassen sich als zufrieden aber unmotiviert charakterisieren und machen in Deutschland etwa ein Viertel der Angestellten aus.

Für Firmen in einem sich stark ändernden Umfeld (vor allem in der IT) ist das hochproblematisch - wenn die Entwickler keine neuen Programmiersprachen mehr lernen wollen, oder wenn die Tester nur manuell und nicht automatisiert testen wollen, dann sieht die Zukunft düster aus. Es bleibt die Frage: wie bekommt man die Mitarbeiter aus ihrer verhängnisvollen Komfortzone wieder heraus? Die schlechte Nachricht: eine einfache Antwort darauf gibt es nicht. Die gute Nachricht: es gibt verschiedene Ansätze die man in Erwägung ziehen kann und die auch bereits erprobt sind.

Lösungsansatz 1: Fluktuation

Unternehmensbewohner treten erfahrungsgemäss besonders dort auf, wo Teams schon seit Jahren, mitunter sogar Jahrzehnten zusammenarbeiten. Neue Ideen und Blickwinkel fehlen, stattdessen entstehen die beschriebenen eingefahrenen Routinen. Wenn die vertikalen und horizontalen Karrierepfade mit Wechseln in andere Abteilungen verbunden werden, dann kann die notwendigen Anreize setzen, um die geistige Beweglichkeit zu erhalten.

Lösungsansatz 2: Abschaffung der "Wohnzimmer-Büros"

Wenn ein Büro mehr einer Wohnung als einem Arbeitsplatz ähnelt ist das ein starker Indikator für Unternehmensbewohner. Palmen, Kakteen, Goldfische, Sofas, Kühlschränke, Mikrowellen, Modelleisenbahnen und ähnliche Dinge können für sich genommen unproblematisch sein, wenn sie gleichzeitig auftreten geht jedoch irgendwann der Arbeitscharakter des Raums verloren. Und noch schlimmer als das: Arbeitszeit und Kreativität fließen irgendwann vor allem dorthin, und nicht mehr in den Job. Die "Wohnzimmereinrichtung" auf ein gesundes Mass zurückzufahren kann daher sehr sinnvoll sein.

Lösungsansatz 3: Gruppenbüros und Desk-Sharing

Eine Kombination aus zwei Ansätzen: Gruppenbüros in denen ein Team oder mehrere Teams zusammensitzen sind (so lange sie nicht zu groß werden) grundsätzlich eine gute Sache. Sie fördern Zusammenarbeit, erleichtern Kommunikation und bringen die Mitarbeiter näher zusammen. Auch Desk-Sharing hat bereits für sich genommen Vorteile. Statt immer an einem Platz zu sitzen kann man sich jeweils mit den Kollegen zusammensetzen mit denen man gerade an einer Aufgabe arbeitet. In Kombination sorgen sie darüber hinaus für eine physische und geistige Beweglichkeit, die Unternehmensbewohner-Einstellungen entgegenwirkt.

Lösungsansatz 4: Wissen und Verantwortung an die Mitarbeiter weitergeben

Ein häufiger Grund dafür, dass für die Mitarbeiter eine wohnliche Atmosphäre wichtiger wird als die Weiterentwicklung der Firma und der eigenen Person, ist die fehlende Kenntnis größerer Zusammenhänge. Es mag sich merkwürdig anhören, aber vielen Angestellten ist gar nicht klar warum Stillstand und fehlende Weiterentwicklung für das Unternehmen und für ihren Arbeitsplatz gefährlich sind. Wenn ihnen diese Zusammenhänge aufgezeigt werden und sie dazu noch den Freiraum und die Verantwortung erhaltn dem entgegenzuwirken, dann kann das zu erstaunlichen Verbesserungen führen.

Es gibt sicher noch zahlreiche weitere Möglichkeiten mit dem Typus des Unternehmensberaters umzugehen, und wie gesagt - nicht jede funktioniert überall. Auf jeden Fall ist es aber empfehlenswert bereits seiner Entstehung entgegenzuwirken. Wenn er einmal da ist entwickelt er mitunter erstaunliche Widerstandskräfte gegen jede Veränderung des Status Quo.

Donnerstag, 19. Mai 2016

'Aber Sie müssen schon mal implementiert haben!'

Bild: Unsplash / Dias - Lizenz
Eigentlich freue ich mich ja immer über Projektangebote. Manchmal ist es aber zu skurril. Beispielsweise in diesem Fall, der sich genau so zugetragen hat:

Anruf 1

"Guten Tag" schallt mir die Frauenstimme aus dem Hörer entgegen. Sie sei die Frau X von der Personalberatung Y und ich sei ihr aus ihrem Netzwerk empfohlen worden. Sehr interessante Informationen wären das, die sie über mich hätte. Ob ich an einem Projekt bei einer bekannten Firma aus meiner Region interessiert wäre? Ja? Wie schön! Sie würde meine Unterlagen sofort weiterreichen, nur eines wäre da noch - ich müsste belegen, dass ich schon einmal implementiert hätte. Okay, fragte ich, was genau sollte ich denn implementiert haben? Eine Software? Eine Methode? Etwas anderes? Hm, das könnte sie jetzt auch nicht sagen. Aber sie würde sich erkundigen und wieder melden.

Anruf 2 (3 Tage später)

"Hallo", Frau X noch einmal, von der Personalberatung Y. Sie hätte jetzt nochmal mit ihrem Kunden gesprochen, über die Implementierungserfahrung. Ich müsste schon einmal Software implementiert haben, das wäre ganz, ganz wichtig für den. Kein Problem, sagte ich. Software-Projekte hätte ich schon einige hinter mir. Was für Referenzen sollte ich denn schicken - die vom Online-Shop? Vom Data Warehouse? Von der Banking-Anwendung? Vielleicht sicherheitshalber alle? Oh je, meinte Frau X, da würde ich sie jetzt auf dem falschen Fuß erwischen. Sie sei aber sicher, dass der Kunde sehr konkrete Vorstellungen hätte. Sie würde lieber nochmal nachfragen und sich bei mir zurückmelden.

Anruf 3 (5 Tage später)

"Ich grüße Sie, noch einmal Frau X von der Personalberatung Y." Nach einem weiteren Gespräch mit dem Kunden hätte sie jetzt die Information. Die Leute dort wären langsam etwas ungeduldig und die Zeit würde ja auch drängen, aber die Anforderung wäre jetzt eindeutig: die Software bei deren Implementierung ich Erfahrung nachweisen müsste wäre Standardsoftware. Da würde großer Wert drauf gelegt. Aha, sagte ich, Standardsoftware also. Ob ihr denn bewusst wäre, dass das ein sehr allgemeiner Begriff ist? Aber egal, Erfahrung damit hätte ich. Shop, CMS, CRM, könnte ich alles belegen. "Aber so einfach ist es nicht!", durfte ich mir anhören. Der Kunde sei da wirklich speziell in seinen Anforderungen. Schon klar, meinte ich. Wie machen es wie gewohnt: Sie rufen da an und melden sich wieder.

Anruf 4 (nochmal 4 Tage später)

"Guten Tag, ich bin es wieder, die Frau X." Nach einem letzten Gespräch mit dem Chef der Einkaufsabteilung des Kunden könnte man vermutlich doch auf den Nachweis einer Implementierungserfahrung verzichten, man habe da wohl aneinander vorbeigeredet. Ob ich denn möglichst schnell zu einem Gespräch dort erscheinen könnte? Ach, nicht mehr? Schon bei einem anderen Projekt zugesagt? Wie ärgerlich! Es wäre im Moment aber auch wie verhext auf dem Markt für IT-Fachkräfte. Keiner wäre zu bekommen, und es sei unerklärlich woran das wohl liegen könnte.

Naja, ich hätte der jungen Dame vermutlich einige Gründe dafür nennen können, zumindest dafür, woran es in ihrem speziellen Fall liegt. Aber ich war in diesem Augenblick einfach nur noch sehr, sehr müde.

Montag, 16. Mai 2016

Ein Bild sagt mehr als 1000 Worte (XI)

Ein derartiges Bild verzierte eine Zeit lang einen Flipchart in einem meiner Projekte. Ich weiß zwar nicht mehr ob es genau so aussah wie meines hier, die Aussage war aber die selbe: Wasserfall funktioniert in der Theorie anders als in der Realität.


Was dieses Bild nicht darstellt ist, dass seine untere Hälfte eigentlich eine Schleife sein müsste. Obwohl die Dysfunktionalität offensichtlich ist wird es wieder und wieder und wieder versucht.

Donnerstag, 12. Mai 2016

Subsidiarität

Bild: Wikimedia Commons/Salerna - CC BY-SA 3.0
Wenn die Verfasser des Manifests für agile Softwareentwicklung sich seinerzeit mehr Gedanken über Skalierung gemacht hätten, hätten sie in ihre Prinzipien auch eines aufgenommen, das (meiner bescheidenen Meinung nach) heute dort fehlt - die Subsidiarität. Sie lässt sich zwar indirekt aus einigen der anderen Prinzipien ableiten, explizit genannt wird sie aber nicht. Aber zuerst kurz zum Verständnis: Was soll das überhaupt für ein Konzept sein?
Subsidiarität (von lat. subsidium „Hilfe, Reserve“) ist eine politische, wirtschaftliche und gesellschaftliche Maxime, die Selbstbestimmung, Eigenverantwortung und die Entfaltung der Fähigkeiten des Individuums anstrebt [...].

Die jeweils größere gesellschaftliche oder staatliche Einheit soll nur dann, wenn die kleinere Einheit dazu nicht in der Lage ist, aktiv werden und regulierend oder kontrollierend oder helfend eingreifen.

Hilfe zur Selbsthilfe soll aber immer das oberste Handlungsprinzip der jeweils übergeordneten Instanz sein. Aufgaben, Handlungen und Problemlösungen sollten so weit wie möglich vom Einzelnen, von der kleinsten Gruppe oder der untersten Ebene einer Organisationsform unternommen werden.
Mit anderen Worten: So viel wie möglich soll auf der untersten möglichen Hierarchiestufe entschieden und umgesetzt werden. Das ist zunächst einmal nichts Neues - die evangelische Kirche organisiert sich seit dem 16. Jahrhundert so, die katholische seit dem 19. Jahrhundert, der Staat seit dem ersten Weltkrieg. In der Wirtschaft dagegen ist diese Idee eher neu - bis heute sind Konzerne und Mittelständler überwiegend zentralistisch organisiert, die unteren Ebenen (quasi die Basis der Pyramide) führen dabei nur das aus was die oberen anordnen. Und diese Struktur verursacht heute Probleme.

In einer Zeit immer schneller werdender Innovationszyklen und Marktveränderungen würde es viel zu lange dauern, wenn jeder Änderungsbedarf von der Basis (wo er auftritt) zuerst nach oben kommuniziert, dort geprüft, bewertet und entschieden und die Entscheidung dann wieder nach unten durchgereicht und dort umgesetzt werden würde. Ich habe solche Prozesse erleben dürfen, sie haben z.T. sechs bis zwölf Monate gedauert. In dieser Zeit ist die Konkurrenz längst davongezogen. Wer das nicht will muss zulassen, dass Entscheidungen weit unten getroffen werden, und zwar Entscheidungen aller Art: technische Entscheidungen, Marketing-Entscheidungen, Produktentscheidungen, etc.

Natürlich hat das auch Konsequenzen: einheitliche Markenführung, einheitliche Kommunikationsstrategien oder einheitliche IT-Architekturen sind so nur noch schwer durchzusetzen, und wenn überhaupt, dann nachträglich. Ein eingängiges Beispiel daür sind die Logos der Untergesellschaften der Firma Google gewesen - bedingt durch das schnelle Wachstum war für ein einheitliches Corporate Design lange keine Zeit. Stattdessen herrschte lange ein dezentraler Wildwuchs vor. Und hätte man den nicht zugelassen sondern die neuen Dienste so lange zurückgehalten bis irgendjemand Styleguides entworden und abgestimmt und ein den Standards entsprechendes Logo entworfen oder genehmigt hätte - vielleicht wären Microsoft oder Yahoo mit ihren Angeboten dann schon lange vorher am Markt gewesen. Da ist Uneinheitlichkeit das kleinere Übel.

Um es mit den Worten eines entsetzten Managers aus einem Dax-Konzern zu sagen: "Aber dann kann da unten ja jeder machen was er will!" Nun ja, das ist stark vereinfacht, aber grundsätzlich richtig - und es macht Sinn. "Dort unten" ist der Kontakt zur Realität schließlich am intensivsten und die Fachkenntnis am größten. Oft können die Entscheidungen dort am schnellsten, am besten und am effektivsten getroffen werden. Das wäre tatsächliche Subsidiärität, und agil wäre es auch. Und solche Sachen wie z.B. die genannten Logos - so wichtig wie häufig getan wird sind die anscheinend gar nicht. Oder hätte irgendjemand auch nur gewusst, dass es diesen Wildwuchs mal gab?

Montag, 9. Mai 2016

Re-Estimation


Sollte man die Komplexitätsschätzungen von User Stories nachträglich ändern dürfen, also nachdem sie bereits abgeschlossen sind? Etwa wenn eine ursprünglich als trivial eingeschätzte Story sich während des Sprints als doch sehr komplex herausgestellt hat? In fast allen Teams die ich bisher betreut habe (oder in denen ich Mitglied war) hat sich diese Frage früher oder später gestellt, und praktisch jedesmal hat sie zu kontroversen Diskussionen geführt. Früher oder später landete das Thema dann bei mir: "Was sagt der Scrum Master/der Team Coach dazu?" Meine Antwort: "Das kommt ganz darauf an." Story Point-Estimations kann man aus unterschiedlichen Gründen machen, und je nachdem welcher es ist macht eine nachträgliche Neuschätzung Sinn oder nicht.

Fall 1: Estimations als Diskussionsgrundlage

In manchen Teams werden Estimations nur genutzt um die Diskussionen während der Refinements oder Plannings voranzutreiben. Jedes Teammitglied begründet seine Einschätzung und ermöglicht den anderen dadurch neue Blickwinkel oder macht sie auf neue Aspekte aufmerksam. Wenn eine Schätzung signifikant von den anderen abweicht geht die Diskussion tiefer ins Detail, wenn nicht, dann nicht. Ein Team das so vorgeht braucht meiner Meinung nach keine nachträgliche Neuschätzung. Über die Lessons learned sollte man sich schon unterhalten, das reicht dann aber auch.

Fall 2: Estimations zur Berechnung von Aufwänden oder Preisen

Auch das habe ich schon erlebt. Teams benutzen Story Points um Zeit oder Kosten zu berechnen, etwa so, dass ein Story Point einem Sprint-Tag entspricht, oder so, dass dem Kunden pro Story Point 10.000 € in Rechnung gestellt werden. Solchen Teams kann man nur raten in sich zu gehen und zu erkennen, dass sie kein Scrum, bzw. Agile betreiben sondern lediglich Cargo Cult. Ich würde an dieser Stelle dazu raten, die Estimation-Probleme vorerst zurückzustellen und sich anderen, drängenderen Problemen zuzuwenden. Zum Beispiel der Frage "Was mache ich noch alles falsch und wie kann ich damit aufhören?".

Fall 3: Estimations zur Messung der langfristigen Velocity

Für mich der einzige Fall in dem eine Re-Estimation Sinn macht. Wenn die Story Point-Summen der vergangenen Sprints nebeneinander gelegt werden und daraus ein Durchschnittswert ermittelt wird, dann kann man eine (vorsichtige) Prognose abgeben, wie lange es noch dauern könnte, die verbleibenden User Stories zu vervollständigen. Dafür sind allerdings drei Voraussetzungen erforderlich: zum einen stabile Teams, zum anderen eine ungefähr gleichbleibende Menge externer Störungen (etwa durch Linien-Aufgaben) und zuletzt eine ausreichende Menge noch kommender Stories die schon (vorläufig) geschätzt werden können.

Donnerstag, 5. Mai 2016

Noch mehr Cargo Cult (Gunter Dueck auf der re:publica 2016)

Passend zum Eintrag vom letzten Montag macht sich Guenther Dueck ebenfalls Gedanken zum Thema Cargo Cult. Genau wie bei seinem Schwarmdummheits-Vortrag im letzten Jahr wieder sehr unterhaltsam, und ab und zu geht es sogar um Design Thinking, agile Softwareentwicklung und ähnliche Sachen..

Montag, 2. Mai 2016

Cargo Cult

Das Unpraktische an Cargo Cult ist - wenn man es anderen Menschen vorwirft muss man es meistens im Anschluss erklären, weil niemand von selbst darauf kommt was genau damit gemeint ist. Und die wenigen, die den Begriff kennen verbinden damit nicht etwa ein Antipattern im (IT-)Projektmanagement, sondern Eingeborenenvölker von der Südhalbkugel der Erde. Nun ja. Letztendlich stimmt auch beides, weshalb eine Erläuterung vermutlich dort unten beginnen sollte, an den warmen Stränden der Südsee.

Über Jahrhunderte hinweg haben die Naturvölker in Amerika, Afrika und im Pazifik europäische Entdecker und Armeen für Götter gehalten. Sie erschienen aus den Weiten des Meeres (später aus der Luft), vollbrachten Wunder (Technologie, Medizin) und verteilten Kleidung, Konserven und Glasperlenschmuck aus ihrer Ladung (englisch: Cargo) als zauberhafte Geschenke. Nach ihrer Abreise versuchten die Eingeborenen sie zurückzulocken indem sie das nachbauten, was ihrer Meinung nach die Götter gerufen hatte: Landestege, Leuchttürme, Rollbahnen und Funkmasten - allerdings aus Holz und Steinen, ohne Strom. Natürlich erfolglos, neue Schiffe und Flugzeuge voller Cargo kamen nicht.

Dieses Grundmuster (man scheitert am Nachbau von etwas, dessen Aufbau und Funktionen man nicht versteht) wurde später auch in der westlichen Welt identifiziert und nach den Südseekulten benannt, namentlich Cargo Cult Science und Cargo Cult Software Programming sind in die englische Alltagssprache übergegangen. Auch in den Bereich der agilen Vorgehensweisen ist der Begriff übernommen worden, man spricht hier von Cargo Cult Scrum, Cargo Cult XP oder Cargo Cult Agile. Diese liegen jeweils dann vor wenn die Methoden lediglich imitiert werden ohne zu erkennen warum es Sinn macht sie anzuwenden (bzw. warum es Sinn gemacht hätte das zu unterlassen, auch das kommt vor).

Übliche Fälle dieser Art von Cargo Cult sind zum Einen das bloße Umbenennen bestehender Rollen und Regeln (aus dem Projektleiter wird der Scrum Master, Kapitel der Lasten- und Pflichtenhefte werden zu User Stories), zum Anderen aber auch das standardisierte Ausrollen auf alle Unternehmensteile, unabhängig davon ob das Sinn macht oder nicht. Ein Beispiel dafür wäre eine Anforderungs- oder Testmanagement-Abteilung, die plötzlich "Requirement Sprints" oder "Test Sprints" durchführt, obwohl sie in dieser Methode eigentlich gar nicht mehr als von der Entwicklung getrennte Organisationseinheit existieren dürfte.

Ähnlich wie im Fall der Eingeborenenkulte können agile oder Scrum-Cargo Cults übrigens ein erstaunliches Eigenleben entwickeln. Genau wie in der Südsee aus diesen Ursprüngen ganze Religionen entstanden sind, haben viele Unternehmen (pseudo)agile Cargo Cult-Methoden entwickelt und zum hauseigenen Standard erhoben. Und während diese Methoden von aussen genauso absurd wirken wie aus Bambus und Erde nachgebaute Flughafentürme ohne Stromanbindung, werden sie im Inneren mit heiligem Ernst befolgt. Und alle glauben ganz fest daran - wenn man sich nur daran hält, dann wird am Ende wundersamerweise alles gut.