Samstag, 30. Juli 2016

Kommentierte Links (XV)

Grafik: Pixabay / Geralt - Lizenz
  • Vladimir Oane: Medieval Lessons to Help Your Company Become More Lean & Agile

  • Und ich dachte, ich hätte mit Graf Clausewitz die Messlatte schon hochgelegt. Vladimir Oane überbietet das locker, indem er bei den mongolischen Eroberern Dschingis Khan und Subutai agile Managementmethoden findet. Zumindest was die Aspekte des (bewussten) Kontrollverlustes und der Teamautonomie betrifft scheint er da durchaus recht zu haben, mir fehlt allerdings ein bisschen der datengetriebene Ansatz. Den von den beiden bekennenden Analphabeten zu verlangen wäre allerdings auch etwas vermessen. Insgesamt ein interessanter Blickwinkel.

  • Erik Duindam: How I built an app with 500,000 users in 5 days on a $100 server

  • Über Lean Startup und Minimum viable Products reden können viele, das Ganze in die Tat umsetzen nur wenige. Erik Duindam scheint dazuzugehören, und er reichert den Begriff sogar noch um eine zusätzliche Dimension an: die Skalierbarkeit. Im klassischen Sinn mag die nicht immer Teil der Methode gewesen sein, aber in der extrem volatilen digitalen Ökonomie hat Duindam einen Punkt - ein Produkt das nicht in der Lage ist eine extrem schnell steigende Nachfrage zu befriedigen läuft in die Gefahr am eigenen Erfolg zu ersticken.

  • Petra Wille: Böse Deadline! Wie man zu einer realistischen & flexiblen Planung kommt

    Ich habe Ende letzten Jahres mal etwas über Scrum und feste Deadlines geschrieben, und darüber, wie ein Team damit umgehen kann. Petra Wille geht zu diesem Thema wesentlich tiefer ins Detail und nähert sich ihm von verschiedenen Seiten um die Frage nach Planungsmöglichkeiten im agilen Umfeld zu beantworten. Ich bin mir nicht sicher ob ich ihren Rat gut finde, ab einem gewissen Punkt die Planungen vor Change Requests zu schützen, im Großen und Ganzen sagt sie aber viele richtige und kluge Dinge.

  • Daniel Hüfner: In dieser deutschen IT-Firma hat der Chef nichts mehr zu sagen

  • In mehreren Firmen konnte ich bereits Schnappatmung beim Management auslösen, wenn ich als Antwort auf die Frage nach "agilem HR" Modelle wie das hier von Sipgate vorgestellt habe. Selbstverantwortliche Teams, ja bitte - aber doch nicht in Personalfragen! Und transparent zu Stande kommende Gehälter, wo kämen wir denn da hin? Auf einmal war Agilität im Personalbereich doch nicht mehr so wichtig. Sicher lässt sich das Sipgate-Vorgehen nicht in jede Firma übertragen, allerdings würde es nicht schaden, wenn einige mehr es zumindest versuchen würden.

  • Resalin Rago: 5 Non-Agile TED Talks About Agile

  • Ich könnte ja stundenlang TED-Videos ansehen, wenn ich nur die Zeit dafür hätte. Glücklicherweise hat mir hier jemand das Kuratieren und Kommentieren abgenommen. In Summe trotzdem mehr als eine Stunde Material, also etwas für einen verregneten Abend (wann auch immer so etwas wieder vorkommen wird).

Dienstag, 26. Juli 2016

Wie man Kreativität ins Arbeitsleben (zurück)bringen kann

Irgendwo in den kommentierten Links habe ich schonmal etwas daüber geschrieben, dass in den meisten modernen Firmen Kreativität systematisch unterdrückt wird. In diesem Vortrag von Catherine Courage geht es darum wie man sie zurückbringen kann. Verkürzt gesagt: indem man sich daran erinnert, mit welchen Mitteln man als Kind kreativ sein konnte.

Donnerstag, 21. Juli 2016

20.000 mal automatisch getestet

Bild: Wikimedia Commons/Library of Congress - Public Domain
Die Geschichte die in den letzten Tagen durch die Medien ging war in vieler Hinsicht bemerkenswert: Nachdem die Comdirekt-Bank Anfang der Woche eine neue Version ihrer Banking-Software deployed hatte war es zeitweise möglich sich in die Accounts anderer Kunden einzuloggen, die Kontenstände einzusehen und Änderungen der Einstellungen vorzunehmen. Ein massives Versagen der Qualitätssicherung also, das den Ruf dieses Instituts schwer beschädigt hat. Ein interessantes Detail war in diesem Zusammenhang das Statement einer Unternehmenssprecherin, die gegenüber der FAZ erklärte, dass alle IT-Updates mehr als 20.000 Mal automatisch getestet würden, weshalb solche Fehlfunktionen die absolute Ausnahme wären.

Ganz abgesehen davon, dass diese Aussage für die Betroffenen nicht besonders tröstlich sein dürfte - sie steht symptomatisch für ein Problem an dem viele Firmen leiden: den Glauben, dass Risiken sich minimieren lassen indem einfach mehr Tests durchgeführt werden. Das ist zwar nicht völlig falsch, viele, in kurzen Abständen durchgeführte Tests können einen hohen Mehrwert bringen. Zu glauben, dass hier eine Kausalität bestehen würde ist allerdings hochgradig riskant. Die Anzahl der Tests ist bestenfalls ein Indikator, mehr nicht.

Ich habe es über die Jahre immer wieder erlebt, dass ein Management "ambitionierte Ziele" formuliert hat, die erfüllt werden mussten. Pro Woche wurde eine bestimmte Anzahl von Tests vorgegeben die zu schreiben waren, und zwar sowohl bei den manuellen Tests als auch bei Unit Tests, automatisierten GUI-Tests und in anderen Bereichen. Um nicht an die Wand gestellt zu werden taten die Entwickler und Tester alles dafür diese Vorgaben zu erfüllen. Am Ende wurde die Planzahl erfüllt, allerdings durch sinnloses Aufblähen: Unit Tests für Getter und Setter, eigene End to End Tests für praktisch identische Testdaten-Sets und Ähnliches mehr kam so zu stande.

Wesentlich wichtiger als die Anzahl der Tests ist aber ihre Qualität: decken sie auch negative Validierungen ab? Überprüfen sie Grenzwerte? Basieren sie auf Überlegungen wo eine Fehlfunktion besonders großen Schaden anrichten würde? Solche Sachen. Das Problem dabei - lässt man sich darauf ein kann man als Manager nicht mehr so einfach an irgendwelchen Stellschrauben drehen um die (Illusion von) Sicherheit zu erhöhen. Auf der anderen Seite produzieren solche Tests dann tatsächlich einen Mehrwert und nicht bloß eine imposant klingende Zahl. Wenn es darauf ankommt ist die nämlich weder tröstlich noch nützlich. Siehe oben.

Montag, 18. Juli 2016

Kritischer Rationalismus


Vielleicht habe ich doch mehr aus meinem Studium in meinen Beruf übertragen als ich dachte - aus einer Diskussion mit einem alten Studienfreund habe ich mitgenommen, dass das was ich im Rahmen von Organisationsentwicklung mache, viel mit dem Kritischen Rationalismus zu tun hat, über den ich damals Klausuren schreiben durfte. Das Zitat oben auf dem Bild sagt im Grunde alles aus:
Alle Aussagen müssen an der Erfahrung überprüfbar sein, müssen sich in der Konfrontation mit der Realität bewähren. Mit anderen Worten: Alle Aussagen einer empirischen Wissenschaft müssen - sofern sie unzutreffend sind - prinzipiell an der Erfahrung scheitern können.
Karl Popper, Logik der Forschung
Vor allem eine Variation des letzten Satzes trage ich schon seit Jahren jedem meiner Kunden vor: "Alle Maßnahmen müssen an der Realität scheitern können." Hinter dieser Aussage steckt ein Ansatz der allgemein als datengetrieben (data driven) bezeichnet wird und nichts anderes tut als das gute alte Inspect & Adapt auf eine empirische Basis zu stellen: jede Maßnahme sollte mit einem messbaren Ziel verbunden sein, damit sich feststellen lässt ob sie wirksam ist oder nicht. Die in diesem Zusammenhang notwendige empirische Validierung beginnt idealerweise bereits mit der initialen Formulierung. Statt sie um eine vermeintliche Kenntnis kausaler Zusammenhänge herum aufzubauen (Um mehr Kunden zu bekommen bauen wir mehr blinkende Banner ein) sollte sie als widerlegbare Hypothese formuliert sein (Wenn auf jeder Webseite mindestens ein blinkendes Banner zu sehen ist gewinnen wir mindestens 100 neue Kunden).

Aufbauend auf diese Fomulierung sollte dieses Widerlegen dann versucht werden, und zwar durch einen transparenten Vergleich von Hypothese und Ergebnis. Dabei ist es von wesentlicher Bedeutung, dass nicht versehentlich doch eine Belegung oder Verifizierung der Hypothese im Mittelpunkt steht, sondern die zentrale Komponente des kritischen Rationalismus, die Falsifizierung oder eben Widerlegung. Hintergrund ist, dass man bei Verifizierungen immer wieder auf Vermutungen angewiesen ist (wir haben 100 neue Kunden, das muss an den blinkenden Bannern liegen), während die Falsifizierungen klarere Aussagen zulassen (im Vergleich zu Produkten mit blinkenden Bannern haben die Produkte ohne blinkende Banner genauso viele Neukunden, die Maßnahme ist also wirkungslos).

Einige der erfolgreichsten agilen Unternehmen wie z.B. Netflix oder Spotify setzen bei der Produktentwicklung durchgehend darauf, Hypothesen in Experimenten zu überprüfen und rollen Neuheiten erst dann komplett aus, wenn sie nicht falsifizierbar sind. Der Erfolg ihrer Produkte gibt ihnen recht. Im Umkehrschluss ist das auch ein Grund dafür, dass viele Großkonzerne mit ihren "innovativen" Produkten nur mittel bis wenig erfolgreich sind - da hier oft eine Kultur des keine Fehler machen dürfens vorherrscht kann sich niemand die Falsifikation seiner Hypothesen erlauben, da ihr Eintreten als Versagen gesehen würde und Karrieren beschädigen könnte. Um sicher zu sein versucht man es meistens gar nicht erst.

Letztendlich folgt aus dem Gesagten eine Schlusspointe - der auf den ersten Blick negative, destruktive und auf Falsifikation fixierte Ansatz des Kritischen Rationalismus entpuppt sich bei näherer Betrachtung als durchaus menschenfreundlich: Fehler werden in ihm nicht nur toleriert sondern sogar zum Zweck des Erkenntnisgewinns bewusst in Kauf genommen. Die Folge ist eine angstfreie Arbeitsumgebung, etwas das weit weniger selbstverständlich ist als man glauben sollte.

Donnerstag, 14. Juli 2016

Das agile Pandämonium

Mein favorisiertes Video der letzten Tage. Nicht nur wegen des österreichischen Dialekts (ich habe ein paar Jahre an der Grenze gewohnt) sondern auch wegen des Wahrheitsgehalts. Jedem dieser "Dämonen" habe ich in der Realität bereits begegnen dürfen.

Das Agile Pandämonium from JAX TV on Vimeo.

Montag, 11. Juli 2016

Update des Scrum Guide 2016

Bild: Pixabay/Geralt - Lizenz
Zum ersten mal seit drei Jahren hat der Scrum Guide, das offizielle Regelwerk von Scrum, wieder ein Update bekomen. Neu hinzugefügt wurde ein Abschnitt über die Werte von Scrum. Im Einzelnen sind das Commitment (Engagement/Hingabe), Courage (Mut), Focus (Konzentration/Zielgerichtetheit), Openness (Offenheit) und Respect (Respekt). Diese Werte sind keineswegs neu, sie gehören schon seit Jahren zu den Best Practices von Scrum, nur eben ohne offizieller Bestandteil zu sein. Das sind sie erst jetzt.

Ich kann diese Erweiterung nur begrüßen, schließlich habe ich mehr als einmal erleben dürfen was mit Unternehmen oder Teams passiert, die versuchen Scrum zu adaptieren ohne die dahinterstehenden Werte zu ihren eigenen zu machen (kurz gesagt: sie scheitern). Bisher ließ sich diese Art von Cargo Cult immer damit rechtfertigen, dass diese Werte ja nicht zwingend notwendig wären, denn sonst würden sie ja im Scrum Guide stehen. Jetzt stehen sie drin, es gibt also eine Ausrede weniger.

Da wir gerade beim Thema Update des Scrum Guide sind - ich finde, eine weitere Ergänzung wäre sinnvoll gewesen, nämlich die Verkürzung der maximal möglichen Sprint-Dauer von vier auf drei oder vielleicht sogar zwei Wochen. Überall dort wo ich Drei- oder Vierwochensprints erlebt habe war das Inspect & Adapt etwas schwerfällig, Stories wurden tendenziell zu groß geschnitten und Arbeit staute sich vor dem Sprintende. Aber vielleicht kommt das ja beim nächsten Update.

Donnerstag, 7. Juli 2016

Remote-Retrospectiven mit Google Docs

Bild: Pexels / Monstera - Lizenz
Zum ersten mal seit längerem habe ich diese Woche wieder eine Remote-Retrospektive moderiert. Ich persönlich finde es zwar immer besser alle Teilnehmer in einem Raum zu haben, wenn es aber nicht anders geht ist remote besser als nichts. Die Frage ist nur: wie gestalte ich den Termin so, dass man sich auch aus der Ferne aktiv beteiligen kann? Zu diesem Zweck habe ich in dieser Woche etwas Neues ausprobiert, nämlich die  Einbindung von Google Docs in den Veranstaltungsablauf. Das hat gleich so gut funktioniert, dass ich es hier teilen möchte.

Google Docs hat gleich mehrere Vorteile: es ist kostenlos, es kann online benutzt werden und die hier erstellten Dokumente können von mehreren Personen gleichzeitig bearbeitet werden. Vor allem der letzte Aspekt ist wichtig - die Bearbeitungen sind sofort und ohne Neuladen der Seite für alle Teilnehmer sichtbar. Durch diese Bearbeitung in Echtzeit kann ein solches Dokument viele der Funktionen übernehmen, die sonst eine Wand oder ein Board hätte. Gleichzeitig kann es direkt im Anschluss als Dokumentation des Meetings benutzt werden, entweder online gespeichert bei Google oder heruntergeladen als PDF, JPG, PPT oder Doc-Datei.

Das folgende Template entspricht etwa dem das ich benutzt habe, ergänzt um einige Verbesserungsmöglichkeiten die mir während der Durchführung aufgefallen sind. Als Tonspur haben wir Hangout benutzt, aber auch jede andere Konferenz- oder Chatsoftware wäre möglich. Die Bilder sind von Pixabay, einem Anbieter für kostenlose lizenzfreie Inhalte, die auch komerziell genutzt werden können.

Dienstag, 5. Juli 2016

Wer nimmt am Estimation-Poker teil?


Zugegeben, im Normalfall ist das keine schwere Antwort. Der Product Owner stellt die Story vor, das Entwicklungsteam hält die Karten hoch, der Scrum Master steht daneben und macht ein interessiertes Gesicht. So einfach ist das. Es kann allerdings auch anders kommen, nämlich dann wenn im Team sehr unterschiedliche Berufe vertreten sind. Der Scrum Guide gibt es klar vor: "Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment". Je nach Produkt können also auch Designer, Business Analysten, manuelle Tester oder sonstige IT-ferne Gruppen zum Team gehören. Sollten die an den Schätzungen teilnehmen?

Von verschiedenen Scrum Mastern oder Agile Coaches habe ich gehört, dass auch solche Personen mit der Zeit ein Gespür für die Komplexität von Anforderungen bekommen könnten. Das mag in diesen Fällen auch so gewesen sein, allerdings bezweifele ich, dass man daraus eine Regel ableiten kann. Ich durfte bereits mehrmals beobachten wie sich derartig gemischte Teams über einen längeren Zeitraum entwickeln, und selbst nach ein oder zwei Jahren war von einem "Gespür" nichts zu sehen. Es war so als würde man nur die Kühlerhaube kennen und würde versuchen auf dieser Grundlage über den Motor zu reden. Für die beteiligten Entwickler war es bestenfalls amüsant, für die anderen im schlimmsten Fall demütigend. Hilfreich war es für niemanden.

Die verborgene Tragik in derartigen Anekdoten: nirgendwo in den Scrum-Regeln steht geschrieben, dass alle Teammitglieder an jeder Schätzung teilnehmen müssen. Es reicht völlig aus wenn Estimations nur von denjenigen vorgenommen werden die dazu wirklich in der Lage sind, im Fall von Software-Entwicklung also von den beteiligten Entwicklern. Dabei ist es natürlich so, dass die anderen Mitglieder in den dazugehörenden Diskussionen darauf hinweisen können, dass der Dokumentations- oder Testaufwand mit berücksichtigt werden sollten. Das kann wertvoll sein. Aber: wenn es z.B. darum geht den Kundendaten-Bereich aus einer monolithischen Anwendung in einen Microservice zu überführen - welcher Nicht-Entwickler soll das beurteilen können? Keiner.

Natürlich mag es immer Ausnahmen geben, grundsätzlich kann man aber sagen: so schade es aus methodischer Sicht auch ist, es wird immer wieder Fälle geben in denen nicht alle Teammitglieder an den Aufwandsschätzungen teilnehmen können (und manchmal kann das sogar umgekehrt sein, etwa wenn die Entwickler nicht beurteilen können wie aufwändig eine Marktstudie ist). Genau dafür gibt es im Estimation Poker auch die Karte mit dem Fragezeichen.