Montag, 29. Februar 2016

Kommentierte Links (X)

Grafik: Pixabay / Geralt - Lizenz

  • Agilemanifesto.org: Manifesto for Agile Software Development

    • Noch ein Jubiläum: 15 Jahre Agiles Manifest. Seine Entstehung im Februar 2001 ist auf fast schon provozierende Art und Weise unspektakulär gewesen. Keine große Konferenz, keine Ganztagesworkshops, keine ausufernden Strategie-, Selbstfindungs- oder Konsensdiskussionen, keine Manager, keine Unternehmensberater, nichts von allem was man rückblickend erwarten würde. Stattdessen fuhren 17 Software-Entwickler für ein Wochenende in einen Urlaubsort in den Rocky Mountains "um zu reden, Ski zu fahren, zu entspannen, Gemeinsamkeiten zu finden und gut zu essen". Das Ergebnis ist das Manifest mitsamt der dahinterliegenden Prinzipien, die noch immer unverändert ihre Gültigkeit haben.Was für ein Unterschied den vielen Konferenzen oder Gatherings heute.

  • Jason Taylor's Blog: Don't Blame Scrum

    • Ein Text der ziemlich genau das zusammenfasst was auch ich immer wieder erzählen muss: In fast allen Fällen in denen es heisst, dass "Scrum gescheitert ist", "Scrum bei uns nicht funktioniert" oder "Scrum sich überlebt hat" steckt in Wirklichkeit etwas Anderes hinter dem ausbleibenden Erfolg. Klassiker sind die fehlende Bereitschaft zusammenzuarbeiten oder Regeln zu befolgen, unrealistischer Planungsoptimismus, ziellose Produktentwicklung, unerfahrene Entwicklungsteams, defekte Firmenkultur, konfuses Management oder destruktive "Anpassungen" der Methode. Alles nichts Neues.

  • Lars Röwekamp, Arne Limburg: Der perfekte Microservice

    • Spätestens seit 2015 gehört der Begriff Microservice zu den Buzzwords die man in allen größeren Projekten immer wieder zu hören bekommt. Was darunter verstanden wird kann dann wieder erstaunlich weit auseinandergehen und zum Teil sogar kontraproduktiv sein. Lars Röwekamp und Arne Limburg machen sich vertiefte Gedanken dazu und gehen auch auf Probleme und Fragestellungen ein. Sehr informativ, aber etwas technisch. Den Artikel der das Thema für die Fachabteilungen dieser Welt verständlich erklärt ohne oberflächlich zu sein suche ich noch.

  • Mike Cohn: Applying Agile Beyond Software Development

    • Ein anschauliches Beispiel dafür wie man Agilität ausserhalb der IT anwenden könnte, in diesem Fall durch A/B-Testing von neuen Einrichtungskonzepten in Hotels. So gesehen wird Agilität auch bereits seit längerem erfolgreich in den verschiedensten Bereichen eingesetzt, etwa durch McDonalds, das neue Restaurant-Konzepte immer zuerst in einigen Filialen in Paris ausprobiert, oder durch Supermarktketten, die neue Produkte am Anfang nur in einigen Pilot-Filialen verkaufen. Eine Voraussetzung dafür, dass das Ganze auch wirklich agil ist, wäre neben dem "Ausprobieren" aber auch ein schnelles Sammeln von Feedback und ein schnelles Reagieren darauf.

Mittwoch, 24. Februar 2016

Group Think

Bild: Wikimedia Commons/Hubert Link - CC BY-SA 3.0 DE
Ein weiterer Throwback zurück ins Psychologiestudium - heute durfte ich eine längere Diskussion zum Thema Groupthink führen, also zu dem Phänomen, dass eine Gruppe von an sich vernünftigen Personen aufgrund gruppendynamischer Prozesse schlechte oder realitätsferne Entscheidungen trifft. Da das auch in dem einen oder anderen meiner vergangenen Projekte aufgetreten ist ein paar Überlegungen dazu. Zunächst das Grundlegende - was ist eigentlich Groupthink?

Als Begriff geprägt vom Psychologen Irving Janis verbirgt sich dahinter das Phänomen, dass negative Effekte auftreten können sobald die Mitglieder einer Gruppe einander zu ähnlich in Alter, Herkunft, Überzeugungen, etc. sind. Zustande kommt es dadurch, dass die Gruppenmitglieder sich (bewusst oder unbewusst) in ihren gleichen Eigenschaften gegenseitig bestärken, wodurch gleichzeitig auch die Wahrscheinlichkeit, dass es zu neuen Ideen und Impulsen kommt zurückgeht.

Die Erscheinungsformen:
  • überzogener Optimismus in Bezug auf die eigene Offenheit
  • Überzeugung immer im Recht zu sein (sachlich oder moralisch)
  • Stereotypisierung von Außenstehenden oder Konkurrenten
  • Beschönigung schlechter Entscheidungen und Ergebnisse
  • extremer Konformitäts-Druck innerhalb der Gruppe
  • Druck, die Gruppe vor abweichenden Ansichten zu schützen 
  • Tendenz, den Informationsfluss nach 'draußen' zu zensieren 
  • innerer und äußerer Druck zur einstimmigen Entscheidungsfindung

Die begünstigenden Faktoren:
  • fehlende Erfahrung mit unterschiedlichen Kontexten
  • (zu viel) Routine
  • Gruppenkohäsion (Ähnlichkeit und Zusammenhalt in der Gruppe)
  • Abschottung nach Außen (oder von Außen kommende Ablehnung)
  • Neigungen zu Subjektivität/fehlende Objektivität
  • schlechte oder fehlende Feedback- oder Lernprozesse
  • Erfolgsdruck und Angst vor Fehlern
  • Stress

Die Folgen:
  • nur wenige, ausgewählte Alternativen werden betrachtet
  • die Meinung von Experten oder Außenstehenden wird ignoriert
  • von der gewünschten Welt abweichende Informationen werden ignoriert
  • es findet kein aktives Bemühen um zusätzliche Informationen statt
  • die Gruppenmitglieder bestätigen sich nur gegenseitig ihre Theorien 
  • Alternative Handlungsoptionen werden nicht (oder nur pro forma) erstellt
  • → Vorhaben scheitern oder halten die Rahmenbedingungen (Zeit, Kosten, Qualität) nicht ein

Aufbauend darauf - in welchen spezifischen Erscheinungsformen kann Groupthink in (agilen) Software-Projekten auftreten? Ich glaube, in drei verschiedenen Gruppen:

Groupthink in Entwicklungsteams
Bedeutet vor allem, dass eine dogmatische Festlegung auf bestimmte Programmiersprachen oder Architekturmodelle stattfindet. Ebenfalls häufig sind eine Ablehnung von Regeln, Vorgehensweisen, Qualitätskriterien, Coaching und Management-Entscheidungen sowie "innere Emigration". Ein verbreitetes Ergebnis sind vor dem Management versteckte Uboot-Projekte.

Groupthink im (Produkt-)Management
Eine typische Erscheinungsform sind irrationale, im "Hinterzimmer" entstandene Entscheidungen, an denen die Fachleute bewusst nicht beteiligt werden und die auch nicht mehr ernsthaft zur Diskussion gestellt werden. Der dadurch meistens ausgelöste Aufschrei aller Betroffenen wird als Infragestellen der eigenen Autorität empfunden und kann zu Trotz und Einigelung führen und den Effekt sogar noch verstärken. Ebenfalls häufig ist der Versuch, das gewünschte Ergebnis zu "erzwingen". Ein verbreitetes Ergebnis ist Geldverbrennung in großem Ausmaß.

Groupthink bei Scrum Mastern/agilen Coaches/etc.
Tritt meistens in Form eines "Troubardix-Syndroms" auf, d.h. man fühlt sich als unverstandener, letzter Hort der Vernunft. Ähnlich wie beim Management werden abweichende Meinungen als Infragestellen der eigenen Autorität empfunden, allerdings mit anderer Konsequenz: die Betroffenen neigen in starkem Ausmaß zu Ironie, Sarkasmus und Zynismus, womit andere Personen vor den Kopf gestoßen werden. Ein verbreitetes Ergebnis ist eine beschädigte Reputation agiler Vorgehensweisen und Rollen.

Gegenmaßnahmen
Sind nur sehr schwer durchzuführen, da sie von den oben beschriebenen Einigelungs- und Abwehrreflexen behindert werden. Sehr hilfreich sind frühzeitig festgelegte verbindliche Definitionen (v. A. Definition of Ready und Definition of Done) die bei konsequenter Befolgung viele Fehlentwicklungen eindämmen können. Auch das regelmäßige Feedback von Kunden und Stakeholdern kann hilfreich sein, genau wie das Durchführen moderierter Retrospektiven. Einen allgemeingültigen Lösungsansatz dafür gibt es nicht, da er immer eine starke Anpassung auf die jeweilige Situation haben sollte. Praktisch nicht mehr korrigierbar ist die Fehlentwicklung wenn nicht nur Gegenargumente sondern auch Moderation und Vermittlung abgelehnt werden. In diesem Fall bleiben eigentlich nur noch drei Möglichkeiten: die Gruppe trennen, gehen oder Popcorn holen.

Montag, 22. Februar 2016

Finger weg vom roten Knopf

Bild: Flickr/Włodi - CC BY-SA 2.0
Zu den verhängnisvollsten Missverständnissen im QA-Bereich gehört die Annahme, dass es möglich wäre automatisierte Testfälle "aufzunehmen". Die Aussicht klingt aber auch zu verheißend: man drückt auf einen roten Aufnahmeknopf und führt z.B. auf einer Website eine Aktion durch. Diese wird von einem Computerprogramm aufgezeichnet und kann jetzt beliebig oft "abgespielt" werden, wodurch sehr schnell eine Testsuite mit hoher Abdeckung entsteht - und für deren Erstellung braucht man nicht einmal ein besonderes IT-Verständnis. Verschiedene Test-Tools verfügen sogar über eine solche Aufnahmefunktion, etwa HP Unified Functional Testing oder Selenium IDE. Ich durfte auch bereits miterleben wie versucht wurde darauf eine Teststrategie aufzubauen. Mit verheerendem Ergebnis. Und für dieses Scheitern gibt es auch Gründe, von denen ich hier einige aufführen möchte1.

Dynamische und verschlüsselte IDs, Klassen, etc.
Auf vielen Internetseiten werden die IDs von Elementen nicht fest vergeben sondern bei jedem Aufruf dynamisch generiert. Der Compose-Button mit dem man bei Gmail Emails erstellt hat zum Beispiel eben nicht die ID id=composebutton sondern je nach Aufruf eine zufällige wie id=:gz, id=:dc oder id=:dn. Wenn dieser Button jetzt während der Testaufzeichnung mit einer dieser IDs identifiziert wird, beim nächsten Aufruf aber eine andere generiert wird, dann schlägt der Test natürlich fehl - obwohl das Element da ist und funktioniert wird es nicht erkannt. Der gleiche Effekt tritt auf wenn der HTML-Code verschlüsselt ist, was etwa bei Banken ein Sicherheitsstandard ist.

Verifizierungsschritte
Im Grunde können nur zwei Arten von Aktionen aufgenommen werden, nämlich Mouseclicks und Tastatureingaben. Für einen brauchbaren Testfall sind die aber nicht ausreichend, es fehlen die Verifizierungsschritte. Wenn beispielsweise eine Datei erstellt und abgespeichert wird muss auch überprüft werden ob sie danach tatsächlich vorhanden ist. Bei manueller Durchführung muss man nach dem Speichern nur nachsehen ob sie angezeigt wird, da das aber lediglich mit dem Auge geschieht kann das Testprogramm das nicht nachvollziehen. Stattdessen müssen Befehle wie |ensure|do|verifyElementPresent|on|id=product| (Selenium IDE/Xebium) oder Browser("x").Page("y").WebEdit("z").Waitproperty "visible", True, 5000 (HP UFT) separat eingegeben werden. Von Hand.

Parametrisierung
Um einen wirklichen Nutzen aus automatisierten Tests zu ziehen müssen diese auch in verschiedenen Kontexten wiederverwertbar sein, etwa in verschiedenen Entwicklungsumgebungen, die über unterschiedliche URLs aufgerufen werden. Im Fall von HP UFT müsste dazu zunächst über den Befehl Dictionary.Add "LoginURL", Environment.value("LoginURL") der URL-Parameter in die Ausführungsinstanz geladen und dann mit SystemUtil.Run "C:\Programme\Mozilla Firefox\firefox.exe", Dictionary.Item("LoginURL"),"","",3 in einen Ausführungsschritt eingesetzt werden. Auch das kommt nicht über die Aufnahmefunktion in die Testskripte sondern nur manuell.

Aber warum?
Diese kurze Liste hier ist natürlich nicht erschöpfend und könnte sicher erweitert werden, aber um Vollständigkeit soll es hier gar nicht gehen. Interessanter wäre die Frage warum trotz der offensichtlichen Unzulänglichkeit und Unmöglichkeit noch immer das Phantom des reinen "Testfälle Aufnehmens" durch manche Projekte geistert. Ist manchen Managern und Testern der Unsinn dieses Vorhabens nicht bewusst? Die wahrscheinliche und erschreckende Antwort ist: Leider nein, dafür fehlt ihnen häufig die IT-Affinität. Das zu besprechen würde jetzt aber zu weit führen.


1Genannt werden im Folgenden die Gründe gegen die "Aufnahme-Illusion". Dass Oberflächentests alleine keine ausreichende Testabdeckung ergeben ist nochmal ein gesondertes Thema.

Freitag, 19. Februar 2016

Estimation

Zu den großen Schmerzpunkten vieler agiler Entwickler gehört die Frage, wie sie im Planning Poker die Story Points ihrer User Stories einschätzen sollen. Der erste und beste Ratschlag ist immer der, in Relationen zu schätzen1 ("Wenn die letzte Story eine 5 war, ist diess hier eher eine 8 oder eine 3?"), was vielen aber nur bedingt weiterhilft - auch dieses Vorgehen wird oft als zu unkonkret empfunden. Die Relationen sind zwar hilfreich, allerdings braucht es auch für sie eine initiale Schätzung, und wo die herkommen soll bleibt unklar. In Zukunft kann ich an dieser Stelle allerdings mit weiteren guten Ratschlägen dienlich sein, denn auf dem letzten Scrumtisch Köln haben zwei Kollegen meines aktuellen Projekts ein bisschen an diesem Problem herumdiskutiert und dabei das folgende Modell entwickelt:
Man sieht - der eher abstrakte Wert der Story Points wird zunächst in vier verständlichere Bereiche unterteilt: Kompliziertheit, Dauer, Ungewissheit und Bauchgefühl. Diese sind für sich sehr viel besser einschätzbar und liefern Teilergebnisse die sich nebeneinanderlegen lassen. Ermittelt man aus diesen einen Durchschnittswert kann dieser im Planning Poker benutzt werden2. Zusätzlich dazu existiert bei dieser Methode auch noch ein weiterer "Kollateralnutzen" - wer den Wert auf diese Weise ermittelt, betrachtet die Story gleich von Beginn an aus verschiedenen Blickwinkeln und entwickelt dadurch ein besseres Verständnis für sie. Nur Kopfrechnen muss man können.

1Das Antipattern der Schätzung in Stunden oder Tagen lasse ich jetzt mal unerwähnt.
2Natürlich mit Auf- und Abrunden, in dem hier gezeigten Beispiel (Durchschnittswert 13,5) würde man also die Karte mit der Nummer 13 hochhalten.

Nachtrag 10.01.2023
Mit der Zeit wird man älter und weiser. Heute würde ist diesen Text anders schreiben. Siehe hier.

Montag, 15. Februar 2016

(Kein) Sprint-Abbruch

Bild: Wikimedia Commons/Jocelyn Augustino - CC0 1.0
[Edit: aktualisiert um den aktuellen Stand des Scrum Guide abzubilden]
Sprint-Abbrüche sind in Scrum ein Mythos. Manche kennen sie gar nicht, viele haben nur eine ungefähre Vorstellung gesehen hat sie fast niemand. Das hat mich zu ein paar eigenen Überlegungen zu diesem Thema inspiriert. Tatsächlich ist mir nämlich aufgefallen, dass ich in den hunderten von Sprints die ich als Scrum Master, Teammitglied, Scrum Coach oder sonstwas erlebt habe kein einziger dabei war, der abgebrochen worden ist. Ich habe darüber noch nie nachgedacht, frage mich aber gerade warum das wohl so ist.

Zunächst das Grundlegende: einen Sprint abzubrechen ist möglich und unter bestimmten Voraussetzungen sogar sinnvoll, weshalb der Scrum Guide diese Möglichkeit sogar explizit erwähnt:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Man sieht - das Vorgehen ist klar geregelt. Ich war auch bereits mehrfach in Situationen in denen ein Abbruch Sinn gemacht hätte und meine mich erinnern zu können, dass ich meinen Product Ownern auch zum Abbruch geraten habe. Dazu gekommen ist es nicht.

Rückblickend würden mir mehrere Gründe einfallen, aus denen sich die Product Owner vermutlich dagegen entschieden haben1:
  • Unkenntnis der Scrum-Regeln
    • Dass ich zum Abbruch geraten habe meine ich zu wissen, aber habe ich auch erwähnt, dass das in Scrum möglich und geregelt ist? Kann ich jetzt nicht mehr sagen, es wäre aber eine Möglichkeit. Nicht alle POs die ich hatte kannten sich mit der Methode wirklich aus.

  • Angst vor Strafe oder Gesichtsverlust
    • Ein Klassiker in der deutschen Firmenkultur. Fehler dürfen nicht sein und werden bestraft, und auch ein Verlust an Prestige kann eine Strafe sein. Wenn jetzt das Starten eines später abgebrochenen Sprints als Fehler gewertet wird, dann wird das niemand zugeben wollen und darum nicht abbrechen. In solchen Firmen scheitert Scrum meistens.

  • Falsch verstandenes Eliminate Waste
    • "Wenn wir den Sprint abbrechen war die ganze Arbeit umsonst." An den Spruch kann ich mich tatsächlich erinnern. Sie war natürlich auch so umsonst (sonst hätte sich der Abbruch nicht angeboten), aber mir saß da ein Betonkopf gegenüber.

  • Einheitlicher Sprintrhythmus
    • Der irgendwie noch nachvollziehbarste Grund. Wenn mehrere Teams synchron sprinten sollen, dann muss auf einen abgebrochenen Sprint ein verkürzter oder verlängerter folgen, oder eine sprintfreie Zwischenphase. Alles nicht wirklich ideal.

  • Faulheit
    • Der vermutlich menschlichste Grund. Ein abgebrochener Sprint bedeutet mehr Arbeit: Aufräumarbeiten, mehr Meetings, Rechtfertigung beim Management, etc. Das will sich nicht jeder antun, selbst wenn es eigentlich sinnvoll wäre.
Vom Gefühl her müsste ich jeden dieser Gründe mindestens einmal erlebt haben, könnte aber nicht mehr sagen wie die Verteilung war. Sollte es in Zukunft wieder auftauchen mache ich vielleicht Notizen.


1Natürlich werden wir uns über die Entscheidung unterhalten haben, allerdings habe ich an der Stelle Erinnerungslücken.

Donnerstag, 11. Februar 2016

20 Jahre Extreme Programming

So wie die meisten Scrum Master (zumindest wie die meisten die sich tiefer mit ihrer Materie beschäftigt haben) lebe ich mit der mehr paradoxen Situation, dass mir ein anderes agiles Framework mindestens genausogut gefällt wie Scrum, wenn nicht sogar besser. Die Rede ist von Extreme Programming (XP). Da das mittlerweile auch schon erstaunliche 20 Jahre alt ist bietet es sich daher an hier etwas zu diesem Thema einzubinden: eine Rede von seinem Erfinder Kent Beck, gehalten anlässlich des gerade genannten Jubiläums.



Wie bei vielem anderen das im Rückblick offensichtlich und zwangsläufig ist scheint auch der Ursprung von XP von Zufällen, kurzfristigen Notwendigkeiten und Ausprobieren geprägt gewesen zu sein. In gewisser Weise konsequent agil - entstanden durch Inspect & Adapt und durch Responding to Change. Und wer hätte es gedacht, dass eine der einflussreichsten agilen Methodiken zu einem wesentlichen Teil in einem Zug zwischen Zürich und München entstanden ist?

Dienstag, 9. Februar 2016

Handeln in Unbestimmtheit und Komplexität

Bild: Flickr/Image Catalog - CC0 1.0
Zu den Artikeln die in den letzten Tagen (Alaaf!) in meiner Timeline auftauchten gehörte auch dieser hier von Christian Jakubetz, der an meiner alten Universität Journalisten ausbildet. Verkürzt gesagt schreibt er, dass das, was seine Studenten dort lernen, ihnen im Berufsleben nicht viel bringen wird. Angeregt davon habe ich überlegt, welcher Lehrstoff aus meinem Studium wohl Bezug zu meiner Arbeit hat. Als Quereinsteiger aus den Geisteswissenschaften bin ich eigentlich davon ausgegangen gar nichts zu finden, aber tatsächlich war da doch etwas: in einem Psychologieseminar (Vertiefung Organisationspsychologie) ging es ca im Jahr 2001 um fast genau das was ich auch heute mache - das Managen komplexer Situationen. Der Titel: Über Fehler und deren Ursachen beim Handeln in Unbestimmtheit und Komplexität.

Der Dozent, Dr. Harald Schaub (mittlerweile Professor Schaub), begann wie in der Wissenschaft üblich und definierte zuerst die Merkmale unbestimmter und komplexer Situationen, um von dieser Grundlage aus fortzufahren. Merkmale laut Schaub waren:
  • Vielzahl der Faktoren - es gibt nicht nur eine Ursache und Auswirkung sondern viele
  • Vernetztheit - die vielen Ursachen und Auswirkungen beeinflussen sich gegenseitig
  • Eigendynamik - selbst wenn man nichts tut entwickelt die Situation sich weiter
  • Intransparenz - Ursachen, Auswirkungen und Entwicklungen sind nicht immer klar zu erkennen
  • Polythelie ("Vielzieligkeit") - es gibt nicht nur ein Ziel auf das man hinarbeitet, sondern mehrere, die sich auch widersprechen können
  • Zieloffenheit - es ist nicht ganz klar wo man hinwill, oft sind nur ungefähre Vorstellungen wie "leistungsfähiger" oder "schneller" vorhanden
  • Neuartigkeit - da man noch nie in einer solchen Lage war gibt es kaum nutzbare Erfahrungswerte

In dieser Situation gäbe es zwar naheliegende und zielführende Vorgehensweisen, als schwache Wesen verfallen die Menschen allerdings häufig in Fehlverhalten. Auch von denen nannte Schaub einige:
  • Methodismus - ein (früher erfolgreiches) Vorgehen wird in jeder Situation angewandt
  • Unrealistischer Planungsoptimismus - ausgehend vom günstigsten Verlauf wird weit in die Zukunft geplant, was selten realistisch ist
  • Thematisches Vagabundieren - es wird immer nur zum aktuell dringendsten Thema gesprungen und keines wird bis zum Ende abgearbeitet
  • Ballistisches Entscheidungsverhalten - Entscheidungen werden so getroffen, dass (analog zu einem abgefeuerten Projektil) Kurskorrekturen nicht mehr möglich sind
  • Einkapselung - die Komplexität wird (scheinbar) dadurch reduziert, dass man bestimmte Aspekte einfach ausblendet
  • Dogmatische Verschanzung - "Es kann nicht sein was nicht sein darf", bzw. die Wahrnehmung der echten Welt wird dem Modell einer wünschenswerten Welt untergeordnet

In einem dritten Schritt erfolgt jetzt die Auflistung möglicher Gegenmaßnahmen, die sowohl bei der Bewältigung der Komplexität als auch bei der Vermeidung von Fehlverhalten helfen sollen:
  • Zielbildung und Zielelaboration - was genau will ich, und bei widersprüchlichen Teilzielen: welches davon ist wichtiger?
  • Absichtsauswahl und Schwerpunktbildung - was sind die wichtigen Teilziele und was muss ich wann für sie tun?
  • Informationssammlung - nicht nur vor dem Beginn des Vorhabens sondern auch ständig während der Durchführung
  • Informationsintegration und Modellbildung - welche Auswirkungen, Nebenwirkungen und Fernwirkungen haben die aktuellen Entwicklungen?
  • Prognose und Extrapolation - nicht nur ein (gewünschtes) Ergebnis sondern alle theoretisch möglichen Ergebnisse sollten berücksichtigt werden
  • Planen und Entscheiden - welchen Weg durch das "Labyrinth der Möglichkeiten" nehme ich mir vor?
  • Umsetzung der Entscheidungen - welche Handlungen zu welchem Zeitpunkt muss ich umsetzen?
  • Kontrolle und Modifikation - läuft alles wie geplant, und wenn nicht - was muss ich als Konsequenz dessen tun (und wann)?

Das alles ist jetzt ca. 15 Jahre alt und man kann es heute noch so stehen lassen. Da es sinngemäß genau das ist, was ich meinen Kunden predige, stellt sich vielleicht sogar die Frage, wieviel davon ich unbewusst aus meinem Studium übernommen habe. Was aus meinen Unterlagen nicht hervorgeht ist allerdings, ob auch damals schon ein Focus auf der Agilität lag, also darauf, Kontrolle und Modifikation möglichst schnell und unbürokratisch durchzuführen, um so Zeit und Geld zu sparen. Letztendlich dürfte das eher unwahrscheinlich sein, schließlich ist das Agile Manifest damals gerade erst verfasst worden, und der Anwendungsbereich der agilen Vorgehensweisen lag noch ausschließlich in der Softwareentwicklung. Es wäre aber interessant zu wissen ob Schaub damals schon von Scrum, XP und Kanban gehört hatte.

Mittwoch, 3. Februar 2016

Die Baumschaukel-Analogie (verfilmt)

Das Plakat auf dem anhand einer Baumschaukel ein ausser Kontrolle geratenes Projekt erklärt wird ist zu Recht eine Ikone der modernen Arbeitsgesellschaft. Dankenswerterweise hat eine phillippinische IT-Firma das Ganze auch verfilmt und vertont. Jetzt schon ein Klassiker.