Mittwoch, 30. September 2015

Kommentierte Links (V)

FS
  • 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.

  • The Next Web: Bottom up vs. top down - How to scale agile

  • Eine Dame namens Ritika Puri macht sich hier sehr gute Gedanken daü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 Manager die ich kenne sehen das durchaus anders.

  • Jaxenter: 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.

  • Manage IT: 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.

  • FAZ: Deutschland schafft sich ab

  • 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 ...

FS
... 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

FS
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: Ein Blick in den Scrum-Nexus

FS
Bild: Pixabay/Geralt - CC0 1.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, Lean-Agile Leader, Epic Owner oder Lead Scrum Master, in der Realität erwiesen sie sich aber fast immer als die klassische Lehmschicht, bzw. Lähmschicht, die in vielen Großunternehmen so verheerend wirkt indem sie Informationen durch Flaschenhälse leitet und starre Prozesse und Hierarchien einführt.1 Da die Lösung allerdings nicht sein kann, dass man auf skaliertes Scrum ganz 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 von Ken Schwaber und Scrum.org.

So wie ich es verstehe ist es eine Weiterentwickelung der Praktiken, 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 und Grooming finden dabei zuerst auf der Koordinationsebene und dann auf der Teamebene statt, bei Dailies, Reviews und Retrospektiven ist es umgekehrt. Dieses Grundmuster findet sich auch in Nexus wieder, wobei folgende Neuerungen eingeführt worden sind:

  • Gemeinsames Backlog
  • Zwar behält jedes Team ein eigenes Sprint-Board, es gibt aber nur ein gemeinsames Product Backlog, dessen Stories im übergreifenden Planning von den Teams aufgeteilt werden.
  • Gemeinsames Review
  • Gar nicht mal so neu, das habe ich bereits in anderen Zusammenhängen erlebt. Dass die Teams sich gegenseitig zeigen was sie fertiggestellt haben macht ja auch Sinn.
  • Übergreifendes Integrationsteam
  • Das ist wirklich neu. Zum einen sind hier die Spezialisten versammelt, die die Teams zwar ab und zu aber nicht in jedem Sprint brauchen, zum anderen gibt es jeweils einen Product Owner und Scrum Master. Die genannten Spezialaufgaben können wenn nötig nach normalem Scrum-Vorgehen in User Stories und Sprints abgearbeitet werden, daneben gehören das Coachen und Beraten (nicht das Kommandieren) der anderen Teams zu den Aufgaben.

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. Die schleichende Aushöhlung der Selbstverwaltung 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


1Um einen Insider-Witz zu bringen: Safe sein und agil sein schließen sich meistens aus

Montag, 14. September 2015

Ein Bild sagt mehr als 1000 Worte (VI)

FS

Freitag, 11. September 2015

Agile Governance

FS
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 das mittlere Management eben diese Erfordernisse regelmässig als Hebel einzusetzen versucht um agile Methoden in Richtung Wasserfall um-, bzw. rückzugestalten.

Der aus meiner Sicht zentrale Satz des Artikels ist folgender: "Es reicht [...] in bestehenden Strukturen neu zu denken." Anders als von dem erwähnten mittleren Management oft behauptet ist es nämlich meistens nicht so, dass die Vorschriften nur eine einzige Vorgehensweise zulassen, und zwar die "schon immer" benutzte, die sich in der Regel durch Hierarchie, Bürokratie, Dokumentations-Overhead und Tendenz zum Blaming/Fingerpointing auszeichnet. Dass das trotzdem behauptet wird ist in der Regel Bestandteil einer Derailing-Strategie, die das Ziel hat 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 allem bei großen Mittelständlern und Großkonzernen nahezu aussichtsloses 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 Scrum-Prozess 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 dem nun zum dritten mal erwähnten mittleren Management erfunden worden sind.

Diese Aussage wirkt zunächst schwer nachvollziehbar - in vielen Fällen soll diese Management-Ebene durch das Erfinden immer weiterer unnötiger Governance- (oder Compliance- oder sonstiger) Vorschriften ihren Mitarbeitern 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: in der Regel um die eigene Existenz zu rechtfertigen. Gerade in größeren Unternehmen ist das mittlere Management bei näherer Betrachtung nämlich oft erschütternd überflüssig. Um das nicht offensichtlich werden zu lassen (die Folge wäre nämlich der Abbau dieser Stellen) werden die genannten Pseudo-Vorschriften erfunden. 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 wird das Mittelmanagement auch mit großer Wahrscheinlichkeit gegen jede Form agiler Governance Sturm laufen. Sich diesem entgegenzustemmen ist dann die anstrengende aber verdienstvolle Arbeit des Scrum Masters (und ggf. des PO).

Montag, 7. September 2015

Der iterative Wasserfall (ist nicht agil)

FS
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.
Powered by Blogger.