Montag, 30. November 2015

Kommentierte Links (VII)

Grafik: Pixabay / Elisa Riva - Lizenz

Henrik Kniberg: How we do Large Scale Retrospectives

Ein interessantes und wichtiges Thema. Teamübergreifende Reviews sind mittlerweile in vielen Projekten üblich, teamübergreifende Retrospektiven nicht. Was ich bisher kannte sind Retros of Retros, in denen analog zum Scrum of Scrums Delegierte aus den einzelnen Teams zusammenkommen. Andy Park und Henrik Kniberg gehen einen anderen Weg: Übergreifende Retrospektiven finden nicht als einzelne, zentrale Veranstaltungen statt. Stattdessen gibt es zuerst parallele "Themen-Retrospektiven", z.B. zu Architektur, Programm-Management, etc. Erst danach kommt eine zentrale Veranstaltung, in der versucht wird aus den einzelnen Ergebnissen übergreifende Trends abzuleiten. Zuletzt werden die Erkenntnisse in größeren oder kleineren Runden in die Entwicklungsteams kommuniziert. Müsste man mal ausprobieren.

Roland Quandt: Uralt-PCs mit Windows 3.1 ausgefallen, Pariser Flughafen lahmgelegt

Die Geschichte in Kürze: am Pariser Flughafen ist eine Software namens DECOR im Einsatz, die nur auf dem Windows 3.1-Betriebssystem von 1992 (!) läuft. Probleme dieser Anwendung sind immer schwerer zu beheben, da sowohl kompatible Hardware als auch Entwickler mit derartig "historischen" Kenntnissen kaum noch zu bekommen sind. Was sich dahinter verbirgt ist ein grundlegendes Problem - viel zu häufig werden (Groß)Programme unnötig tief mit dem Betriebssystem verzahnt, so dass sie mit neueren Versionen nicht mehr funktionieren. Weil auch nachtragliche Anpassungen nicht vorgenommen werden (sagen wir es wie es ist - meistens aus Geiz) ist man plötzlich gezwungen sich vom technischen Fortschritt abzukoppeln, und damit auch von den aktuellen Standards in Sicherheit, Usability, etc. Dieses Beispiel aus Paris ist zwar extrem, es ist aber kein Einzelfall. Und wie so häufig gilt: durch Sparen an der falschen Stelle macht man alles nur teurer.

Ron Jeffries: Is Code Coverage irrelevant?

Code Coverage ist erstaunlich häufig ein kontroverses Thema. Von "das bringt alles nichts" über "das geht nur mit bestimmten Leuten" bis zu "das führt nur dazu, dass alle Entwickler Getter-Setter-Tests schreiben" habe ich schon alles an Einwänden gehört. Ron Jeffries anscheinend auch, aber überzeugt hat ihn das alles nicht. Er bricht seine Argumente auf ein Gedankenspiel herunter: Wenn es zwei Projekte gibt, die in fast allem identisch sind, von denen aber eines eine Codeabdeckung von 95% hat und das andere eine von 45% - in welchem werden Fehler in der Software wohl besser gefunden? Man kann eigentlich nur eine einzige ehrliche Antwort auf diese Frage finden, es sei denn man führt das Thema durch die Aufzählung unwahrscheinlicher Ausnahme-Szenarien ad Absurdum. Genau das scheint ihm passiert zu sein. Da ich derartige Diskussionen auch schon einmal miterleben musste hat er mein volles Mitleid.

Rainer Gibbert: Innovation Antipattern

Ein witziger Grundansatz. Statt zum x-ten Mal darüber zu berichten, wie Design Thinking, Lean Startup oder andere Vorgehensweisen zu innovativen Produkten führen (können) geht Rainer Gibbert den anderen Weg und zeigt auf was man tun muss um Innovationen zu verhindern. Der Hintergedanke: wer sich selbst in diesen Mustern wiedererkennt weiss, dass er etwas falsch macht. Und jedes dieser Antipattern ließe sich auch auf die Einführung von Agile/Scrum in Unternehmen anwenden:
  1. Warten auf den großen Visionär
  2. Gallische Dörfer (Auslagerung von Innovation in isolierte Abteilungen)
  3. Mangelnde Offenheit und Fehlerkultur
  4. Das falsche Mindset im Team
  5. Fehlende Methoden und Prozesse
  6. Innovation unter Druck
  7. Innovation im Hamsterrad (kein Innehalten, kein Inspect and Adapt)
  8. Innovation am Nutzer vorbei
Mir sind auch sofort einige Manager und Unternehmen eingefallen, die in genau in solchen Fehlverhalten unterwegs sind. Das Tragische daran: viele davon bemerken es nicht, selbst dann nicht wenn man es ihnen sagt.

Bertelsmann-Stiftung: Proklamation Zukunft der Arbeit

Die Ergebnisse des Barcamp Arbeiten 4.0, zusammengefasst auf 40 Seiten. Gar nicht so uninteressant, aber mal ehrlich - ein besserer Titel liess sich nicht finden?

Mittwoch, 25. November 2015

Viable, testable, unsable & loveable Products

Bild: Wikimedia Commons/Visitor7 - CC BY-SA 2.0

Zu den interessanteren Beiträgen der letzten Tage gehörte für mich ein Bericht über den Auftritt von Henrik Kniberg, über den ich ja schonmal geschrieben hatte, auf der Agile Tour Bangkok. Im Wesentlichen ging es dabei um skaliertes Agile, und er scheint da viele richtige und wichtige Sachen gesagt zu haben. Was mir aber besonders aufgefallen ist, ist ein Seitenaspekt den ich ähnlich sehe: die Kritik am Konzept des Mimimum viable Product (MVP, kleinstes lebensfähiges Produkt).

Die Grundidee des MVP ist zunächst einmal völlig richtig: statt alles auf einmal zu wollen und daran zu scheitern oder statt das Produkt "schichtweise" aufzubauen (DB → Backend → Frontend), wodurch es erst ganz zum Schluss benutzbar wird, geht man einen anderen Weg - man erstellt eine kleine, aber nutzbare Komponente (z.B. eine Webseite mit einer Service-Telefonnummer), dann eine zweite (z.B. ein Kontaktformular), dann eine dritte, eine vierte, etc. Jede Erweiterung ist idealerweise die kleinstmögliche durch die eine neue Funktion entsteht. Die Folge sind kleinere Merges, kleinere Test Runs, kleinere Seiteneffekte, weniger Bugs und größere Stabilität. Das Problem daran: dem Kunden/Auftraggeber sind die vielen kleinen Schritte nicht immer einfach zu verkaufen, und oft muss man sich in Reviews anhören, dass es kaum, gar nicht oder nur schleichend vorangehen würde, im schlimmsten Fall, dass man unfertige oder unbrauchbare Produkte präsentieren würde.

Kniberg versucht dem zu begegnen indem er das Minimum viable Produkt differenziert betrachtet und in verschiedene Untertypen aufteilt:

  • Der erste Typ ist das Earliest testable Product
    Beispielsweise könnte das die allererste Form eines CMS sein, die zunächst nur mit unformatiertem Text befüllbare Seiten anlegt. Testbar, aber noch weit davon entfernt den Ansprüchen der Benutzer gerecht zu werden.
  • Der zweite Typ ist das Earliest usable Product
    Um beim Beispiel zu bleiben: Der Text der erstellten Seiten ist formatierbar, es lassen sich Bilder und Videos einbetten, die Redakteure können damit bereits arbeiten, selbst wenn noch einiges fehlt.
  • Typ drei ist das Earliest loveable Product
    Freigabe-Workflows, Verschlagwortung, Social Media-Einbindung und Autorenprofile - jetzt ist eigentlich alles da um an den Markt zu gehen. Es geht zwar noch mehr, aber vermarkten lässt sich das Ganze bereits.


Der Vorteil an diesem Vorgehen: man kann mit den verschiedenen Untertypen die verschiedenen Teil-Zielgruppen da abholen wo es Sinn macht - etwa die IT-Abteilung des Kunden mit dem Earliest testable Product, die Redakteure mit dem Earliest usable Product und das Marketing mit dem Earliest loveable Product. Jeder bekommt in etwa das was er will, keiner bekommt etwas vorgesetzt was ihn völlig über- oder unterfordert, Konfliktpotential entsteht gar nicht erst. Und in der Praxis ist so etwas bereits jetzt in gewisser Weise üblich, was sich zum Beispiel darin ausdrückt, dass die Geschäftsführung nur zu den Reviews im Vorfeld größerer Releases kommt. Während sich das aber eher selbst reguliert bieten Knibergs Untertypen die Gelegenheit Erwartungsmanagement zu betreiben und die verschiedenen Stakeholder dorthin zu bekommen wo es Sinn macht und wo sie auch selber sein möchten.

 

Nachtrag 26.01.2016:

Kniberg hat seine Gedanken nochmal ausführlich selbst aufgeschrieben.

Montag, 23. November 2015

Ein Bild sagt mehr als 1000 Worte (VIII)

Genau gesagt sind es diesesmal mehrere Bilder. Und jeder der schon einmal das Verkabelungs-Chaos in IT-Projekten miterlebt hat wird begeistert sein.

Was auch immer da verlegt wurde, das ist #CablePorn vom feinsten! Strenges NSFW für alle Kabelfetischisten und Sysadmins! (via VKontakte "connect_service_pro")
Posted by t3n Magazin on Freitag, 20. November 2015

Ach ja, und einen neuen Begriff gelernt: Cable Porn.

Donnerstag, 19. November 2015

Agile Familienprogrammierung

Ich finde es ja immer interessant wenn jemand versucht agile Methoden ausserhalb der IT anzuwenden. Die Idee von Bruce Feiler ist sicher eine der exotischeren aber auch eine der interessanteren: die agile "Programmierung" der eigenen Familie.

Dienstag, 17. November 2015

Agiles Branchen und Mergen

Grafik: Flickr/Jawspeak - CC BY 2.0

Die Dominanz des als Projektmanagement-Framework angelegten Scrum überdeckt manchmal die Tatsache, dass es auch agile Praktiken in der eigentlichen Software-Entwicklung gibt. Eine die gerade in meinem aktuellen Projekt diskutiert wird und ihren Ursprung im Extreme Programming hat ist der Umgang mit dem Branchen und Mergen, konkret mit Feature- und Task-Branches.

Zur Einführung: als Branchen bezeichnet man das Kopieren (Abzweigen) eines aktuellen Code-Standes von der zentralen Anwendung (dem Master). Dieser Branch wird von einem Entwickler um eine neue Funktion erweitert und danach (sobald die Erweiterung stabil läuft) auf den Master zurückkopiert, wobei die Erweiterung den bisherigen Codestand überschreibt. Diesen Vorgang bezeichnet man als Mergen.

Um diesen Prozess möglichst agil zu halten empfiehlt es sich, das Branchen und Mergen möglichst kleiner Erweiterungen in möglichst kurzen Abständen durchzuführen. Je kleiner die in den Master gemergte Erweiterung ist, desto geringer ist die Wahrscheinlichkeit, dass unbeabsichtigte Seitenauswirkungen enthalten sind. Aus diesem Grund sollte versucht werden so genannte Release Branches (ein Merge pro Release, z.B. nach jedem Sprint) zu vermeiden, da sie tendenziell zu groß sind. Besser sind Feature Branches die etwa einer Story entsprechen (mehrere Merges pro Sprint) und am besten Task-Branches, die einmal pro Tag oder sogar noch öfter gemerged werden können.

Als hilfreich und notwendig haben sich in diesem Zusammenhang zwei Dinge erwiesen: zum einen eine möglichst hohe Abdeckung mit automatisierten Tests, durch die verhindert wird, dass schadhafter Code in den Master gemerged wird, zum anderen die Kennzeichnung von neu eingebrachtem Code durch eine Markierung (Flag), durch die ein neues Feature "an- und abgeschaltet" werden kann. Durch ein derartiges Vorgehen ist es z.B. möglich, dem Kunden im Livebetrieb einen Vorher-Nachher-Vergleich zu geben oder Features kontinuierlich zu entwickeln, sie den (änderungsaversen) Benutzern aber blockweise zur Verfügung zu stellen.

Donnerstag, 12. November 2015

Master of Future Administration

Ich gebe es zu, der Titel der Veranstaltung klang für mich zunächst etwas windig. Master of Future Administration. Aber hey, ein Wochenendtrip in Berlin mit ein paar Kollegen, dazu ein bisschen Weiterbildung am Montag - warum nicht? Also sind wir hin.



Ich hätte es nicht gedacht, aber im Nachhinein muss ich sagen: es war durchaus lohnend und interessant. Die Veranstaltung war eine große Tour durch verschiedenste Themen - Kulturgeschichte, Philosophie, Hirnforschung, Statistik, Trendforschung, Management, Business-Agilität, Spieltheorie, Wahrscheinlichkeitsrechnung, Systemisches Denken, technische Innovationen und vieles mehr. Alles zu kurz angerissen um vertiefend zu sein aber alles interessant genug präsentiert um zur selbstständigen Vertiefung anzuregen.

Was mein eigentlicher Punkt ist - ich glaube, dass es gut ist wenn man sich ab und zu aus der eigenen Filterblase herausbewegt, externe Denkstimulationen holt und diese reflektiert. Aus diesem Grund habe ich letzten Winter angefangen zu agilen Meetups zu gehen und dieses Blog zu schreiben. Und aus dem Grund werde ich sicher beizeiten zu weiteren zunächst abseitig erscheinenden Veranstaltungen gehen. Vielleicht zögert das das Einrosten des Hirns noch ein bisschen heraus.

Montag, 9. November 2015

Agile Aufmerksamkeitsdefizitstörung

Bild: Wikimedia Commons/Thomas Machnitzki - CC BY 3.0

Zur Bibliothek meines aktuellen Projekts gehört auch das sehr lesenswerte Agile Testing von Lisa Crispin und Janet Gregory. Neben vielen grundlegenden und weiterführenden Informationen zum Thema Softwaretest mag ich vor allem die vielen kleinen Praxisbeispiele und Exkurse, von denen vor allem einer bei mir hängengeblieben ist - die Agile Aufmerksamkeitsdefizitstörung.

Das Phänomen hinter diesem Begriff habe ich bereits mehrfach selbst beobachten dürfen: getrieben von einem falschen Verständnis agiler Vorgehensmodelle (darüber habe hier schonmal geschrieben) konzentrieren sich Teammitglieder oder Projektsponsoren nur noch auf kurzfristige Ziele wie das nächste Daily Scrum oder das nächste Review, verlieren darüber aber die mittel- und langfristigen Ziele völlig aus den Augen. Geplant wird nur noch für den nächsten Sprint, alles was danach kommt "entscheiden wir wenn es soweit ist". Selbst Tätigkeiten mit weitreichenden Auswirkungen werden abgebrochen und liegengelassen sobald der kurzfristige Erfolg gewärleistet ist. Ein derartiges Verhalten weist gewisse Ähnlichkeiten mit der psychischen Erkrankung der Aufmerksamkeitsdefizitstörung auf und wurde daher auch nach ihr benannt.

Die Folge dieser Störung sind Schäden an Produkt und Projekt die zunächst nicht erkennbar sind, langfristig aber um so verheerendere Folgen haben: technische Schulden, ad hoc-Architektur, keine oder veraltete Dokumentation, fehlende Testautomatisierung und Testabdeckung sowie ähnliche Versäumnisse. Wenn die Folgen schließlich auftreten wäre eigentlich die einzige sinnvolle Reaktion ein spätes, dafür aber entschlossenes Beginnen agiler Planung, um die Probleme nicht nur schnell sondern auch nachhaltig in den Griff zu bekommen. Stattdessen folgt häufig ein fließender Übergang in die chaotische und hektische Phase des "Brände Ausschlagens" in der auch die meisten Wasserfallprojekte enden.

In dieser Phase angekommen lässt sich nur noch sehr schwer das Ruder herumreißen, oft wird das agile Vorgehen an dieser Stelle für gescheitert erklärt und zugunsten der "bewährten" Methode wieder abgeschafft. Um ein solches Endergebnis zu vermeiden sollte möglichst schon beim ersten Auftreten einer agilen Aufmerksamkeitsdefizitstörung auf die langfristigen Folgen hingewiesen werden. Wie so oft gilt - je früher man Korrekturmassnahmen einleitet dest leichter sind sie umzusetzen.

Freitag, 6. November 2015

Warum Scrum ohne Testautomatisierung nicht funktioniert (II)

Bild: Pixabay/Charlemagne - Lizenz
Zu den Artikeln die mir bei den kommentierten Links des letzten Monats durchgerutscht sind gehört einer aus der Welt, der den programmatischen Titel Komplizierte Software kostet Deutsche Post viel Geld trägt. In ihm geht es um die gescheiterte Einführung des so genannten New Forwarding Environment (NFE), das Post, IBM und SAP gemeinsam eintwickelt haben um die Prozesse der Postmitarbeiter zu vereinfachen, zu vereinheitlichen und zu beschleunigen. Jetzt, drei Jahre und 350.000.000 € (!) später kommt der Offenbarungseid - das System scheint derartig schlecht zu sein, dass es aus den Märkten die es bereits einsetzen entfernt werden und durch die zurückgeholten Vorgänger-Programme ersetzt werden muss. Beschrieben wird das Problem folgendermassen: "Das System sei extrem anfällig [...]. Trete an einer Stelle ein Fehler auf, führe dies sofort zum Zusammenbruch des gesamten Systems."

Derartig fragile Produkte habe auch ich bereits erleben dürfen - egal ob es um Fehler, Reparaturen oder Erweiterungen ging, jedes mal wenn man sie anfasste gab es einen lauten Knall und alles brach zusammen. Die Aufräumphase im Anschluss dauerte dann Wochen. Einer der Entwickler bezeichnete diese Anwendungen einmal mit dem schönen Begriff "Jenga-Software". Genau wie beim namensgebenden Spiel kam man erstaunlich schnell an den Punkt an, dem man sie nicht mehr berühren konnte ohne dass alles in sich zusammenfiel. Ursachen kann eine derartige Situation einige haben, und keine davon ist schmeichelhaft für das beteiligte Entwicklungsteam (es sei denn, dass ihm vom Management bereits ein kaputter Bestandscode vorgesetzt wurde). Klar ist aber, dass in einer derartigen Situation eine agile (Weiter)Entwicklung nicht mehr machbar ist, denn die lebt ja davon, dass man die Anwendung ständig um- und ausbaut.

Möchte man eine derartige Situation vermeiden hilft eigentlich nur eine umfassende Testautomatisierung in Form von Unit-, Integrations- und Oberflächentests, die jedes einzelne mal durchlaufen müssen wenn neuer oder geänderter Code eingespielt wird. Auf diese Weise wird sofort festgestellt ob durch ihn bestehende Komponenten geschädigt werden, und wenn ja kann man direkt auf die nächstältere Version zurückspringen. Das sagt sich natürlich relativ einfach, ist in der Realität aber eigentlich nur umzusetzen wenn es von Beginn an befolgt wird oder wenn man bereit ist in eine nachholende Testautomatisierung sehr viel Zeit und Geld zu investieren. Wenn man es nicht tut kommt man aber sehr schnell in die Situation in der jetzt anscheinend die Post ist. Und man muss auch schon ein Konzern dieser Größenordnung sein um von derartigen Verlusten nicht in der eigenen Existenz gefährdet zu werden.


Siehe auch: Warum Scrum ohne Testautomatisierung nicht funktioniert (I)

Montag, 2. November 2015

IT Freelancer-Magazin 2.0

Ein kleiner Werbeblock: Michael Wowro, der in diesem Internet früher die Projekt-Suchmaschine Projektfisch verantwortete und heute das Blog IT-Kosmopolit betreibt, hat jetzt auch das IT Freelancer-Magazin übernommen und stellt es gerade von Print auf Online um. Michael, ich und der bisherige Herausgeber Ulrich Bode haben vor ein paar Jahren auf einem Scrum-Großprojekt zusammengearbeitet, was unter anderem dazu geführt hat, dass ich zwei Artikel dort veröffentlicht habe. Die beiden drehen sich um das Thema Trennungskultur in Freelancer-Projekten und sind jetzt auch die ersten die auf der neuen Website veröffentlicht werden:

Jedem Ende wohnt ein Anfang inne

(Ausgabe 6/2013) Artikel Nummer 1 geht von der Perspektive des Freelancers aus: Wie gehe ich mit der unerfreulichen Nachricht um, dass ich nicht mehr gebraucht werde und warum lohnt sich Engagement bis zum Schluss?

Geh - und geh in Frieden

(Ausgabe 1/2014) Artikel Nr. 2 beleuchtet die Situation aus Sicht des Projektbetreibers: Warum man mit Freelancern deren Dienst man nicht mehr benötigt anders umgehen sollte (und kann) als mit Angestellten in vergleichbaren Situationen.

Im Augenblick ist auf www.it-freelancer-magazin.de noch einiges im Stadium Work in Progress, aber ein "Minimum viable Product" steht schon. Mit der Zeit sollen dort weitere alte und neue Artikel erscheinen.