Montag, 29. Juni 2015

Kommentierte Links (II)

Grafik: Pixabay / Elisa Riva - Lizenz

Bloomberg: What is code?

Ein sehr, sehr, sehr, sehr langer Artikel den Paul Ford da geschrieben hat. Über 30.000 Wörter. Die meisten Leute finden ihn gut, weil er relativ einfach und anschaulich erklärt was Code und Programmieren so sind. Ich mag vor allem die zwischendurch immer wieder eingestreuten (erfundenen) Anekdoten aus dem Leben einer Konzern-Managers, der zum ersten mal mit Scrum konfrontiert wird, es nur halb versteht aber auch nicht ganz verstehen will. Diese Sicht der Dinge ist in Literatur, Coaching, etc. noch viel zu wenig berücksichtigt.

Personalmarketing 2Null: Software-Entwickler schreiben lieber Codes

Ein aktuelles und schwerwiegendes Problem: Personalabteilungen scheitern heute regelmässig daran, die richtigen Leute zu sich ins Unternehmen zu holen. Dass das häufig an der fehlenden Qualifikation der Personaler liegt (wer bemerkt die feine Ironie?) hatte ich auch schonmal aufgeschrieben, Henner Knabenreicht fügt noch ein paar weitere Aspekte hinzu.

Agile is the limit: Das geht so nicht! „Senior Scrum Master“ und Co [Edit: Link ist mittlerweile tot]

Grundsätzlich hat Patrick Koglin mit seinem kleinen Rant recht - so etwas wie einen Senior Scrum Master gibt es in Scrum eigentlich nicht. Die Einführung von Rängen/Hierarchiestufen würde den Grundideen von Scrum widersprechen. Aber: Dort wo Scrum neu eingeführt wird kann es durchaus Sinn machen solche Abstufungen zu haben. Ich habe es schon mehrfach erlebt, dass man irgendwelche armen Menschen nach einem zweitägigen Zertifizierungskurs auf eine Scrum Master-Stelle gesetzt und alleine gelassen hat. Die Ergebnisse waren durchwachsen bis verheerend. Zumindest dort wo es mehrere Teams gibt sollte mindestens einer der Scrum Master schon Erfahrung haben, die er nach und nach an die anderen weitergeben kann. De facto ist das dann der Senior Scum Master, selbst wenn der Begriff unschön ist.

Ken Schwaber: What is Scaling Scrum?

Ein Klassiker. Mittlerweile gibt es ja eine ganze Reihe von Ansätzen wie man Scrum in Großprojekte umsetzen kann. SAFe, LeSS, SPS und vermutlich noch einige mehr. Die entscheidende Frage dabei ist weniger ob das denn funktionieren kann sondern vielmehr ob das dann noch Scrum ist. Laut Ken Schwaber wird skaliertes Scrum spätestens ab 10 Teams ineffektiv (er führt das am Beispiel von SPS aus). Ich würde zustimmen - allerspätestens ab Projektteams über 100 Leuten wiegen die Nachteile die Vorteile wieder auf. Der Versuch das durch Standards und Quality Gates aufzufangen führt dann zu einer schleichenden Einführung von Wasserfall-Vorgehensweisen.

Forbes: Is Agile Just Another Management Fad?

Noch ein Klassiker: Die Aussage, dass Agile, Scrum & Co nur weitere vorübergehende Moden sind, die sich "bald" als wirkungslos erweisen und wieder abgeschafft werden. Steve Denning glaubt das nicht, und belegt das indem er die agilen Methoden der Gegenwart mit vergangenen und gescheiterten Management-Ansätzen vergleicht, die er die "humanistischen Methoden des 20sten Jahrhunderts" nennt. Diese sind ihm zufolge vor allem daran gescheitert, dass von ihnen letztendlich nur die Terminologie übernommen wurde, während sonst alles beim Alten geblieben ist. Obwohl er diese Risiken auch bei Scrum sieht ist er zuversichtlich, dass es diesesmal anders kommen wird. Mal sehen ob er recht behält.

Mittwoch, 24. Juni 2015

Qualität ist mehr als Testen: Reverse Engineering

Bild: Pixabay / Ennelise - Lizenz

Zu den häufigsten Problemen mit denen man als agiler Tester konfrontiert wird gehört das völlige oder weitgehende Fehlen von schriftlichen Anforderungen oder Dokumentationen. Im Normalfall ist das ein starker Indikator dafür, dass das Team Agilität nicht verstanden hat und sie nach dem Dilbert-Modell eingeführt hat. Viele Tester neigen in solchen Situationen dazu, die Entwickler zu fragen was sie programmiert haben, um dann genau das zu testen. Dieses Vorgehen ist deshalb häufig weil es der einfachste und schnellste Weg ist - und ausserdem ist es grundfalsch!

Was bei diesem Ansatz völlig unter den Tisch fällt ist die eigentlich wichtigste Frage, die nämlich ob das was entwickelt wurde tatsächlich das ist was der Kunde/Product Owner/Auftraggeber wirklich wollte. Ohne festgehaltene Anforderungen oder Dokumentationen besteht ein hohes Risiko, dass einer der folgenden Fälle eingetreten ist oder eintreten wird:

  • Der Ersteller der Anforderungen wusste selbst nicht genau was er wollte und hat daher "hinreichend unscharf" formuliert. In diesem Fall sind ausufernde Diskussionen um Anspruch und Wirklichkeit kaum zu vermeiden.
  • Der Ersteller der Anforderungen wusste was er wollte, konnte es aber nicht formulieren. Mit großer Wahrscheinlichkeit entspricht das Ergebnis nicht seinen Vorstellungen.
  • Der Ersteller der Anforderungen wusste was er wollte, hat es aber mittlerweile wieder vergessen. Auch hier werden lange Diskussionen das Ergebnis sein.
  • Die Entwickler haben eine "pragmatische Lösung" gefunden, oder mit anderen Worten: sie haben die Anforderung ganz oder in Teilen ignoriert.

Die dringend notwendige (und hochgradig undankbare) Aufgabe des agilen Testers muss es jetzt sein, so genanntes Reverse Engineering zu betreiben. Das bedeutet zunächst, noch vor dem Testen die ursprüngliche Anforderung zu recherchieren, sie von ihrem Ersteller absegnen zu lassen und erst auf dieser Basis fortzufahren. Und fortfahren bedeutet in diesem Fall zunächst nicht das Testen, sondern vielmehr ein Gespräch mit dem Entwicklern, in dem diese sagen können wie die Anforderung von ihnen verstanden worden ist. Im Regelfall stellt sich bereits an dieser Stelle heraus, dass die (rekonstruierte) Anforderung und die Implementation spürbar auseinenderliegen. Ein Softwaretest in dem Sinn, dass überprüft wird ob Anforderung und Implementation übereinstimmen macht von da an praktisch keinen Sinn mehr.

An die Stelle des Testens sollte jetzt sinnigerweise eine Analyse treten, an deren Ende die Antworten auf die folgenden Fragen stehen sollten:

  • Welche Teile der rekonstruierten Anforderung sind umgesetzt worden?
  • Welche Teile der rekonstruierten Anforderung sind nicht umgesetzt worden?
  • Was ist umgesetzt worden obwohl es in der rekonstruierten Anforderung nicht gefordert war?
  • Was ist umgesetzt worden obwohl es mit der rekonstruierten Anforderung nicht kompatibel ist?

Auf Basis dieser Erkenntnisse können dann neue Anforderungen (diesesmal nach Möglichkeit schriftlich) formuliert werden um den Spalt zwischen Anspruch und Wirklichkeit zu schließen. Erst danach macht das Durchführen von Tests wirklich Sinn.

PS:
Ein Tipp aus der Praxis: Sobald es absehbar ist, dass das Fehlen schriftlicher Anforderungen und Dokumentationen dazu geführt hat, dass das Verständnis von Anforderungsersteller und Entwicklern sich auseinanderentwickelt hat, besteht das Risiko von verstärktem Blaming und Fingerpointing. Es ist an dieser Stelle immer eine gute Idee sich a) nicht daran zu beteiligen und b) anzumerken, dass ein gemeinsames Arbeiten an einer Lösung wesentlich zielführender ist als gegenseitige Schuldzuweisungen.

Montag, 22. Juni 2015

Ein Zähler für technische und organisatorische Schulden

Es soll ja angeblich Projekte geben, in denen in (un)schöner Regelmässigkeit organisatorische oder technische Schulden aufgenommen werden. Gründe dafür gibt es viele und dagegen anzukämpfen ist nicht immer leicht. Ein erster Schritt zur Besserung ist (wie so häufig) die Herstellung von Transparenz, etwa mit einem Zähler, der in Form einer Scrum-typischen Papierwand aufgebaut werden kann. Beispielbilder hätte ich zwar einige, da sich aus der Gesamtaufnahme aber das Unternehmen erkennen liesse ist hier nur eine abstrahierte Darstellung:



Der Vorteil an dieser Variante: beim Updaten kann man in der rechten Spalte der Gesamtschuld beim wachsen zusehen. Um dem gesamten Team diese Entwicklung deutlich zu machen empfiehlt es sich, dieses Update in einem gemeinsamen Meeting vorzunehmen, z.B. der Retrospektive.

Donnerstag, 18. Juni 2015

The World's worst Agile Coach

Ein Klassiker von Atlassian: Fünf kurze Videos von Chet Rong und seinem "Rong way to do Agile".










Montag, 15. Juni 2015

Die narzisstisch gekränkten Entwickler und ihre Abneigung gegen Agile und Scrum

Bild: Pixabay / Geralt - Lizenz

Seit ich angefangen habe in agilen Projekten zu arbeiten ist es fast zu einer Routine geworden: in regelmässigen Abständen schicken mir Freunde, Kollegen und sonstige Leute Links zu Seiten auf denen irgendwer in meist epischer Breite erklärt, warum Agile im Allgemeinen und Scrum im Besonderen etwas Furchtbares ist (bzw. geworden ist) und besser heute als morgen abgeschafft werden sollte. Mitunter sind es sogar einigermassen bekannte Zeitgenossen die Sich da äussern - recht moderat Dave Thomas, ein Unterzeichner des agilen Manifests etwa (Time to kill agile) und Andy Hunt, ein weiterer Unterzeichner (The failure of agile), wesentlich radikaler Erik Meijer, Mitentwickler von Visual Basic und .net (Scrum is a cancer) und zuletzt IT-Blogger Michael O. Church (Why Agile and especially Scrum are terrible). Geballte Kompetenz und/oder Prominenz also.

Nun bin ich sicher nicht einmal in Ansätzen in der Lage so zu programmieren wie die genannten Herren, widersprechen möchte ich aber trotzdem und zudem noch einen Verdacht äussern: Bei diesen Leuten handelt es sich möglicherweise um einen Typ Mensch den ich auf Projekten häufiger erlebe, und den ich als den "narzisstisch gekränkten Entwickler" bezeichne. Eine narzisstisch gekränkte Person ist laut Sigmund Freud jemand der es nicht verwinden kann, dass jemand dem er es eigentlich nicht zutraut etwas genau so gut kann wie er selbst. Dadurch fühlt der narzisstisch Gekränkte sich in seinem Selbstwertgefühl angegriffen, worauf er in der Regel mit Wutanfällen reagiert. Die Auslassungen der oben genannten Entwickler lesen sich vor diesem Hintergrund sofort ganz anders, denn ihnen allen ist eines gemeinsam: Die Klage darüber, dass die Begriffe Agile und Scrum (angeblich) von Nicht-Entwicklern übernommen sind, von Projektmanagern, Abteilungsleitern, Testern oder (ganz schlimm) Unternehmensberatern.

Keine Frage - mit Sicherheit ist es richtig, dass hier vieles im Argen liegt. Von jeder der vier genannten Gruppen habe ich Exemplare erleben dürfen, die die agilen Ideen solange vergewaltigt haben bis sie in ihr Gegenteil verdreht wurden. Und dennoch: aus der mitunter fundamentalen Ablehnung schaut auch etwas ganz anderes heraus, nämlich ein zum Teil kaum verhüllter Standesdünkel. "Wie kann es sein, dass jemand der kaum oder gar nicht programmieren kann sich anmaßt einem Entwickler zu erklären, wie er seinen Code schreiben soll?" Diese Frage zieht sich im Hintergrund durch viele der Kritiken und Angriffe denen Scrum und Agile ausgesetzt sind, genau wie die Aussage "Lasst uns doch einfach programmieren." Auch von vielen Programmierern in den Projekten bekommt man immer wieder Ähnliches zu hören.

Allein - so einfach ist es nicht. "Die 'Experten' einfach programmieren lassen" ist nämlich so ziemlich der sicherste Weg zu exorbitanten Kostensteigerungen. Wenn Programmierer sich erst einmal "im Tunnel befinden", sich in den Flow vertieft haben" oder "dem Perfektionismus hingegeben haben" dann bekommt man zwar durchaus bemerkenswerte Ergebnisse, früher oder später wird man aber auch fast zwangsläufig mit den folgenden Phänomenen konfrontiert: Für viele Komponenten werden unverhältnismäßig hohe Aufwände investiert, da sich durch die Wahl des jeweils komplexeren Lösungsansatzes die Möglichkeit bietet "eine Doktorarbeit in Code zu schreiben", gleichzeitig wird wie bei allem was man "einfach drauf losmacht" nicht weit genug in die Zukunft gedacht - und nach einem opulenten Einstieg in ein Projekt ist plötzlich ein zeitlicher Verzug da, der gegen Ende zu Hast, Hektik und Murks führt.

Das alles soll keineswegs heißen, dass Entwickler keine Projekte planen können, aber genauso wie die meisten Projektmanager nicht wissen wie man entwickelt, genauso wenig wissen die meisten Entwickler wie man auf der Management-Ebene IT-Projekte durchführt. Dafür können tatsächlich Nicht-Entwickler besser geeignet sein. Und genau diese Tatsache ist es, die vielen Programmierern die Narzisstische Kränkung zufügt, die sie so wüten lässt.

Aber jetzt kommt die große Frage: wenn Manager in der Regel nicht nicht entwickeln können und Entwickler in der Regel nicht managen - sind dann nicht alle IT-Projekte von vornherein zum Scheitern verurteilt? Nicht unbedingt. Denn tatsächlich gibt es eine Methode, die (richtig umgesetzt) beide Seiten zusammenbringen kann. In ihr beschränken sich die (Produkt)Manager darauf, Anforderungen zu erfassen und zu priorisieren und fertige Features abzunehmen, sagen den Entwicklern aber nicht wie sie zu entwickeln haben. Die Entwickler dagegen sind frei in der Programmierung, überlassen dem (Produkt)Manager aber die Priorisierung der Anforderungen und die Abnahme der fertigen Features. Sogar einen Namen hat diese sagenhafte Methode: man nennt sie Scrum. Und jeder der sich von seinem Entwickler-Standesdünkel (oder dem Gegenstück, der Management-Arroganz) befreien kann wird einsehen, dass man wunderbar damit arbeiten kann.

Donnerstag, 11. Juni 2015

8 Regeln für den totalen Stillstand in Unternehmen

Ein Klassiker:

Freitag, 5. Juni 2015

Dunning-Kruger-Effekt

Grafik: Wikimedia Commons/Nevit Dilmen - CC BY-SA 3.0

Ein Nachtrag zum Impostor-Syndrom, also der übertriebenen Geringschätzung der eigenen Leistung: Auch das Gegenteil existiert, die Überschätzung der eigenen Fähigkeiten, welche bemerkenswerterweise oft dann besonders stark ausgeprägt ist, wenn in Wirklichkeit ein eher geringes Qualifikationsniveau vorliegt. Sogar ein (populär)wissenschaftlicher Name dafür existiert, man spricht vom Dunning-Krüger-Effekt, dessen Auswirkungen auf den Betroffenen der namensgebende Sozialpsychologe David Dunning folgendermassen auf den Punkt brachte:
Their incompetence robs them of the ability to realize it
Mit anderen Worten: Um zu erkennen, dass man inkompetent ist müsste man kompetent sein. Wenn man das aber nicht ist, dann ist einem die eigene Unzulänglichkeit nicht bewusst und man überschätzt sich.

Und an dieser Stelle kommt auch der Praxisbezug, diesesmal in Form von Scrum Mastern und Product Ownern deren bisherige Erfahrung mit Scrum bestenfalls der Zertifizierungslehrgang gewesen ist. Ohne tieferes Verständnis, dafür aber ausgestattet mit unerschütterlichem Selbstbewusstsein hört man von ihnen häufig die im Brustton der Überzeugung vorgetragene Aussage "in Scrum macht man das so", vor allem dann wenn es um fehlende Planung, fehlende Dokumentation oder fehlende Struktur geht (legendär ist der Dilbert-Comic zu diesem Thema). Riskant ist das vor allem dann, wenn es derartige Mitarbeiter sind, die agile Methoden in einem Team oder Unternehmen einführen sollen. Eine derartig vermurkste Implementation ist in vielen Fällen kaum noch zurückzudrehen, und zwar alleine deshalb nicht weil das Eingeständnis gemurkst zu haben die Reputation und/oder Karriere der Betroffenen nachhaltig beschädigen würde.

Das Tragische an der Sache: oft ist am Ende nicht unbedingt der Ruf der inkompetenten Personen beschädigt, sondern der der agilen Methoden, von denen es dann heißt "Wir haben es versucht, aber es funktioniert nicht!". Die Welt ist ungerecht.


Nachtrag:
Siehe auch Dunning-Kruger-Effekt (II)