Mittwoch, 30. September 2015

Kommentierte Links (V)

Grafik: Pixabay / Elisa Riva - Lizenz

Ron Jeffries: The Goal in Scrum

Ein etwas in die Irre führender Titel. Tatsächlich geht es in diesem Text darum, dass die Rollen des Product Owners und der Teammitglieder verschwimmen (können). Der Product Owner, der in dieser Konstellation zu einer neuen Rolle namens Product Champion wird, gibt nur noch die grobe Richtung vor (ich als Kunde möchte meine Daten verwalten können). Alles weitere erarbeitet und entscheidet das Team selbst, wodurch es sich das Produkt "selbst aneignet" - daher auch kein Product Owner mehr. Das klingt für mich zwar durchaus so wie Scrum im Idealfall sein sollte, zumindest in Großunternehmen oder Großprojekten bin ich aber nicht sicher ob das so einfach machbar sein wird. Zum einen besteht hier die Gefahr, dass das Team zu sehr in politische Strukturen hineingezogen wird, zum anderen würde dem Management die "Telefonnummer" fehlen, bei der es schnelle Informationen bekommen kann.

Ritika Puri: Bottom up vs. top down - How to scale agile

Ritika Puri macht sich hier sehr gute Gedanken darüber, wie agile Großvorhaben organisiert werden können. Entweder durch das Aufsetzen einer übergeordneten Hierarchie oberhalb der Entwicklungsteams - das passt besser in bestehende (Konzern)Strukturen und erleichtert es dem Management (scheinbar) die Übersicht zu behalten, ist aber schwerfällig und verlangsamt alles. Oder man versucht auch das agil zu machen, wobei aber einige Voraussetzungen nötig sind: Professionelle Tools, Clean Code, horizontale Kommunikation zwischen den Teams und schnelles Feedback, das von den Kunden direkt zu den Teams durchgeht. Dass der zweite Ansatz der bessere ist klingt erstmal nachvollziehbar, wohl aber in erster Linie für Menschen wie mich. Einige der Manager die ich kenne, sehen das durchaus anders. Sie zu überzeugen ist dann ein wesentlicher Teil meines Jobs.

Elmar Jürgens: Wie können wir verhindern, dass geänderter Code ungetestet ins Release gelangt?

Ausgangspunkt dieses Beitrags ist ein grundlegendes Problem vieler IT-Projekte: Änderungen am Code werden "nebenbei" durchgeführt. Nicht auf Grundlage einer Story und auch nicht auf Grundlage eines Bug- oder Defect-Tickets sondern weil ein oder mehrere Entwickler einen Teil ihrer Zeit nutzen um bestehende Features zu "optimieren". Um diesen Aufwand nicht vorher vom PO oder dem Projektleiter genehmigen oder nachher vor ihm rechtfertigen zu müssen werden diese gar nicht erst benachrichtigt. Da es das beabsichtigte Ergebnis ist, dass sich die Anwendung nachher genau so verhält wie vorher und lediglich schneller oder besser wartbar ist, kommt man mit diesem Verhalten häufig unbemerkt durch. Eine Analysemethode wie die hier von Elmar Jürgens vorgestellte würde helfen derartige heimliche Änderungen aufzudecken und dadurch wichtige Informationen in gleich zwei Dimensionen liefern: man entdeckt geänderten aber ungetesteten Code und man entdeckt welchen Entwickler man zukünftig um mehr Transparenz seiner Ergebnisse bitten muss.

Manas Fuloria: Richtlinien für die Enterprise-Agilität moderner Unternehmen

Ein Text von Manas Fuloria mit schönen Beispielen und Begründungen dafür, warum Unternehmen als ganze (und nicht bloß ihre IT) heute agil sein sollten. Bereits das erste Fallbeispiel, die unterschiedliche Entwicklung der Mode-Ketten GAP und Zara macht das deutlich: während GAP versuchte durch langfristige Planungen die Trends der nächsten Saison vorauszusagen und die Produktion frühzeitig darauf einzustellen, perfektionierte Zara eine möglichst schnelle Reaktion auf neue Trends, die so in kürzester Zeit in das eigene Sortiment integriert werden konnten. So konnte das ursprünglich kleinere Unternehmen den größeren Konkurrenten GAP überholen.

Volker Zastrow: Deutschland schafft sich ab [Edit: Link ist mittlerweile tot]

Der erste Reflex: Wenn die FAZ schon in der Überschrift schreibt, dass Deutschland sich abschafft, dann ist der Artikel vermutlich voller weinerlichem Kulturpessimmismus. Weit gefehlt - was Volker Zastrow hier beschreibt ist eher die kreative Zerstörung auf gesellschaftlicher Ebene. Und er lehnt sie nicht etwa ab, sondern er empfiehlt sich ihr durch ein agiles Vorgehen anzupassen - durch Inspect and Adapt, oder wie er es nennt "Versuch und Irrtum, Versuch und Erfolg". Das man derartiges mal in dieser Zeitung lesen würde ...

Samstag, 26. September 2015

In agile steckt auch ...

... etwas Anderes. Nachdem die Buchstaben aufgestellt wurden dauerte es keine Woche bis jemand auf die Idee kam sie anders anzuordnen.



Mittwoch, 23. September 2015

Der Experte im Projekt-Kickoff

Eine wunderbare (und fast gar nicht überzeichnete) Fallstudie des Dunning-Kruger-Effekts. Ich fühlte mich wirklich sehr stark an verschiedene Projektmanager, Business Analysten und Anwendungsdesignerinnen erinnert, mit denen ich bereits zusammenarbeiten durfte.

Donnerstag, 17. September 2015

Scaled Agile: Scrum.org veröffentlicht Nexus Guide

Grafik: Wikimedia Commons / Scrum.org - CC BY-SA 4.0

Seit Jahren dürfte es der heilige Gral der Scrum-Welt sein - die Frage wie man diese Methode so skaliert, dass sie auch auf große Unternehmen anwendbar ist. Ich habe bereits in mehreren Projekten (zwischen vier und zwanzig Scrum-Teams) miterleben dürfen wie man sich daran versucht hat, und das Ergebnis war nicht selten unagil und unerfreulich: nach und nach wurde die Selbstverwaltung der Teams aufgehoben und stattdessen ein klassisches Mittelmanagement eingeführt. Um den Schein zu wahren wurden einem Teil dieser Leute Scrum-ähnliche Titel gegeben, etwa Scrum-Projektmanager, Chief Scrum Master, Epic Owner oder Lead Product Owner, in der Realität erwiesen sie sich aber fast immer als die klassische Zwischenschicht, die alles verlangsamte indem sie Informationen durch Flaschenhälse leitete und starre Prozesse und Hierarchien einführte. Da die Lösung allerdings nicht sein kann, dass man auf skaliertes Scrum grundsätzlich verzichtet, schaue ich mir ab und zu neue Ideen dazu an, und die Letzte erscheint mir sogar recht vielversprechend: Nexus (Link zum Nexus Guide), entwickelt vom Scrum-Erfinder Ken Schwaber und Scrum.org.

So wie ich es verstehe baut es auf die schon in Scrum vorhandene Idee auf, dass mehrere Teams an einem gemeinsamen Backlog arbeiten (und damit auch einen gemeinsamen Product Owner haben). Zu deren Koordination hat Nexus die Praktiken weiterentwickelt, die ich bisher als Scrum of Scrums, Retro of Retros, o.Ä. kannte. Diese bestehen daraus, dass die verschiedenen Scrum-Meetings jeweils zweimal durchgeführt werden: einmal ganz normal innerhalb der Scrum Teams, ein zweites mal auf einer Koordinationsebene. Zu dieser nächsthöheren Ebene schickt jedes Team einen Stellvertreter, der von den Teammitgliedern selbst bestimmt wird. Planning, Refinements und Dailies finden dabei zuerst auf der Koordinationsebene und dann auf der Teamebene statt, bei den Retrospektiven ist es umgekehrt. Backlog Refinements und Sprint Reviews fallen aus diesem Muster heraus und finden als gemeinsame Veranstaltung statt.

Wirklich neu ist in Nexus nur eines: ein Integration Team. [Edit: dieser Abschnitt wurde nach dem Update des Nexus Guide 2018 angepasst] Zum einen sind hier die Spezialisten versammelt, die die Teams zwar ab und zu aber nicht in jedem Sprint brauchen, zum anderen können hier die erfahreneren unter den Teammitgliedern daran arbeiten, dass ihre Erfahrungen auch auf andere Teams übertragen werden. Wichtig ist, dass vor allem das Coachen und Beraten (nicht das Anleiten oder Koordinieren) der eigentlichen Teams zu den Aufgaben des Integration Teams gehört. Es soll kein Selbstzweck werden und kann seine Zusammensetzung immer wieder ändern, je nachdem in welchen Bereichen gerade Coaching- und Beratungsbedarf besteht. Mitglieder der eigentlichen Teams die im Integration Team mitarbeiten müssen dafür soweit wie nötig freigestellt werden.

Was mir sofort an diesem Modell gefällt ist die Idee, dass die Koordinationsebene (die Abgesandten in den Koordinationsmeetings und das Integrationsteam) den Scrum Teams nicht disziplinarisch vorgesetzt ist. Eine schleichende Aushöhlung der Selbstorganisation auf Team-Ebene ist damit zwar nicht völlig unmöglich aber zumindest unwahrscheinlicher geworden. Auch die Ideen von gemeinsamem Backlog und Review erscheinen sinnvoll, da sie dem Entstehen von Kirchturm- und Scheuklappendenken vorbeugen. Leichte Zweifel habe ich bei dem zweistufigen Planning - wenn im Planning eines oder mehrerer Einzelteams festgestellt wird, dass die im übergreifenden Planning vereinbarte Themenaufteilung doch nicht funktioniert, muss ggf. alles von vorne beginnen. Vermutlich ist das aber der Preis für eine gemeinsame Produktvision und das dazugehörende gemeinsame Product Backlog. Ich bin gespannt ob ich den Nexus einmal in Aktion erleben werde, interessieren würde es mich auf jeden Fall.


Nachtrag März 2020:
Mittlerweile habe ich in mehreren Nexus-Teams mitgearbeitet und bin sehr angetan.

Montag, 14. September 2015

Ein Bild sagt mehr als 1000 Worte (VI)

Freitag, 11. September 2015

Agile Governance

Bild: Wikimedia Commons/CTBTO - CC BY 2.0

Gerade ist mir beim Blättern in IT-Zeitschriften dieser Artikel hier in die Hände gefallen: Agile Governance auch in regulierten Märkten und für Konzerne. Verkürzt gesagt geht es hier darum, wie agile Projekte und Abteilungen den Governance-Erfordernissen großer Konzerne gerecht werden können. Ein wichtiges Thema, schließlich habe ich die Erfahrung gemacht, dass Unklarheiten in diesem Bereich regelmässig dazu führen, dass agile Methoden (absichtlich oder versehentlich) in Richtung Wasserfall um-, bzw. zurückzugestaltet werden.

Der aus meiner Sicht zentrale Satz des Artikels ist folgender: "Es reicht [...] in bestehenden Strukturen neu zu denken." Anders oft fälschlicherweise angenommen ist es nämlich meistens nicht so, dass die Vorschriften nur eine einzige Vorgehensweise zulassen, und zwar die "schon immer" benutzte, die sich oft durch Hierarchie, Bürokratie, latenten Dokumentations-Overhead und schlimmstenfalls Tendenz zum Blaming/Fingerpointing auszeichnet. Dort wo das trotzdem behauptet wird sind es häufig Konzern-Trolle, die das Ziel haben den Diskussionsschwerpunkt zu verlagern: lässt man sich darauf ein geht es plötzlich nicht mehr darum den Governance-Anforderungen mit möglichst geringem Aufwand gerecht zu werden, sondern darum diese zu ändern - ein vor allen in frühen Phasen einer Transition hochgradig anspruchsvolles Unterfangen. Die erste und wichtigste Maßnahme sollte also sein, diesem Derailing auszuweichen und im direkten Kontakt mit der Revisionsstelle/-abteilung das "minimum viable Requirement" festzustellen mit dem diese sich zufrieden gibt.

Erstaunlich oft wird man dabei feststellen, dass diese Damen und Herren sehr verständnisvoll und entgegenkommend sind. Bemerkenswert gute Ergebnisse können zum Beispiel alleine dadurch entstehen, dass man mit ihnen gemeinsam den jeweiligen Prozess (z.B. Scrum) durchgeht und nachfragt welche ihrer Anforderungen durch ihn bereits abgedeckt sind. Es kann passieren, dass die angeblich völlig unverzichtbare Feinspezifikation plötzlich unnötig wird, da ja bereits in den User Stories klar dokumentiert ist was die Fach- von der Entwicklungsabteilung will. Auch ist es keineswegs so, dass das häufig vorgegebene Vier Augen-Prinzip gesonderte Test-Abteilungen oder -phasen erfordert - wenn eine Story zuerst im Team getestet und danach vom PO abgenommen wird kann das völlig ausreichen. Derartige Beispiele ließen sich viele finden, denn fast überall ist es so, dass viele der angeblich von oben vorgegebenen Vorschriften in Wirklichkeit von den oben genannten Konzern-Trollen erfunden oder übermässig dramatisiert worden sind.

An dieser Stelle ein kurzer Exkurs zu diesen Trollen - in vielen Fällen sollen Angestellte eines Unternehmens ihren Kollegen durch das Erfinden immer weiterer Governance- (oder Compliance- oder sonstiger) Vorschriften Klötze an die Beine hängen und damit Effizienz, Agilität und Kreativität hemmen oder verhindern? Man fragt sich an dieser Stelle - warum sollten die so etwas machen? Wer Konzernerfahrung hat wird es erraten können: oft um die eigene Existenz zu rechtfertigen. Selbst in größeren Unternehmen gibt es für viele derartige Stellen bei näherer Betrachtung erschütternd wenig anderes zu tun. Um das nicht offensichtlich werden zu lassen (die Folge wäre nämlich meistens der Abbau dieser Stellen) werden Vorschriften zu rigide ausgelegt und schlimmstenfalls sogar erweitert. Für diese kann dann nämlich eine umfangreiche Planungs-, Steuerungs- und Überwachungsbürokratie aufgebaut werden, aus der sich ausreichend Tätigkeiten (und damit Legitimation) ableiten lassen.

Aus diesem Grund werden Teile dieser Organisationseinheiten (die natürlich auch viele gute Leute enthalten, das der Vollständigkeit halber gesagt) auch mit großer Wahrscheinlichkeit gegen jede Form agiler Governance Sturm laufen solange nicht klar ist wie ihre zukünftige Rolle sein wird (und ob es sie noch geben wird). Sich mit dieser Frage zu beschäftigen ist dann die anstrengende aber verdienstvolle Arbeit nicht nur des Managements sondern auch der Agile Coaches, Scrum Master, Product Owner und aller denen schnelle Liefer- und Reaktionsfähigkeit am Herzen liegt.

Montag, 7. September 2015

Der iterative Wasserfall (ist nicht agil)

Bild: Wikimedia Commons/Sergey Ashmarin - CC BY-SA 2.0

Ein paar Gedanken zum iterativen Wasserfall, den Mike Cohn auf seinem Blog als agiles Antipattern vorgestellt hat.

Zum Verständnis zuerst die Erklärung was das ist: Der iterative Wasserfall ist eine Ausformung von ScrumBut, d.h. falsch verstandener Agilität. Das grundsätzliche Missverständnis besteht in dem Glauben, dass man nur alles in Form von User Stories formulieren und die im Sprint-Rhythmus von zwei bis vier Wochen erledigen müsste. Dann wäre man agil. In der Realität führt das dazu, dass eigentlich zusammengehörende Prozesse auseinandergerissen und separat erledigt werden. Zum Beispiel gibt es in Sprint 1 die Story "Als Product Owner möchte ich detaillierte User Stories für die nächsten Sprints schreiben, damit das Entwicklungsteam sie nur noch abarbeiten muss". Im 2. Sprint wird eine der so entstandenen Stories von den Entwicklern umgesetzt, im 3. folgt eine neue Story namens "Als Tester möchte ich die User Story des letzten Sprints testen um sicherzustellen, dass sie funktioniert wie vorgesehen". Gegebenenfalls kommen noch weitere "fachspezifische" Sprints dazu, etwa für Oberflächen-Design, getrennte Frontend/Backend-Entwicklung oder Regressionstest.

Dieses Vorgehen ist, wie Cohn richtig schreibt, weder Scrum noch agil. Stattdessen wird lediglich der bestehende Wasserfall-Prozess genommen und in viele kleine Wasserfälle unterteilt, die dann jeweils drei bis X Sprints dauern können. In der Praxis begegnet man diesem Vorgehen immer wieder, vor allem dort wo Scrum neu eingeführt wird. Zum Teil sind sich die Beteiligten gar nicht bewusst, dass sie die Methode gerade verhunzen, zum Teil machen sie es aber auch mit voller Absicht. Beliebte Begründungen sind in dem Fall, dass man Scrum "verbessert" oder "angepasst" hätte, oder aber "dass es in unseren Unternehmensstrukturen nicht anders geht". Letzteres kann zum Beispiel damit begründet werden, dass POs, Tester oder Entwickler parallele Linienaufgaben haben, die sie in periodischen Abständen ganz aus dem Projekt herausziehen. In diesem Fall stehen sie nur jeden zweiten oder dritten Sprint zur Verfügung, weshalb ihre Aufgaben hierher "verschoben" werden.

Problematisch wird dieses Vorgehen dadurch, dass das Erfüllen einer Definition of Done kaum noch möglich ist. Dass die User Stories vor dem Sprint erstellt werden kann noch sinnvoll sein (so lange sie gegroomt werden und nicht zu Feinspezifikationen ausarten), danach hört es aber auf. Ein Sprint in dem nur eine Benutzeroberfläche ohne Backend erstellt wird oder an dessen Ende eine "fertig entwickelte" aber nicht getestete Komponente steht liefert eben keinen "shippable Code", wie es eigentlich vorgesehen ist. Stattdessen ergibt sich fast zwangsläufig die Notwendigkeit, angeblich "fertige" Features wieder anzufassen und Nacharbeiten durchzuführen. Bedingt dadurch steht immer wieder in den Sprints weniger Zeit für die neuen Stories zur Verfügung als gedacht, wodurch diese nicht fertig und die Sprintziele verfehlt werden. Am Ende steht das gleiche Chaos, das man aus dem "Fast tracking" in Wasserfallprojekten kennt.

Es ist aus diesen Gründen sehr zu empfehlen, dem Entstehen eines iterativen Wasserfalls von Beginn an entgegenzuwirken. Sobald er sich einmal etabliert hat ist er mitunter nur sehr schwer wieder abzuschaffen.