Donnerstag, 31. Dezember 2015

Kommentierte Links (VIII)

Grafik: Pixabay / Elisa Riva - Lizenz

Oliver Weyergraf, Thomas Ramge: Vielen ist bewusst, dass sie Teil eines lächerlichen Spiels sind

Ein Interview mit Oliver Weyergraf, einem der Autoren des Buches Mad Business. Von ihm habe ich ein neues Wort gelernt, den "Betafehler". Der liegt vor wenn nicht zielführende Prozesse nicht abgeschafft sondern duch noch mehr nicht zielführende Prozesse verschlimmbessert werden. Etwa wenn eigentlich gut gemeinte Detailvorschriften zur Reise- oder Hotelbuchung zu Bürokratie führen, die dann durch noch mehr Detailvorschriften vereinfacht werden soll. Auch weitere Diagnosen werden jedem bekannt vorkommen, der in großen Organisationen arbeitet: zu viel unrealistische Planung, zu viele Meetings, zu wenig Flexibilität, zu wenig Kompetenz oder auch so genannte "Nebenwährungen", die den eigenen Status anzeigen (Lage des Parkplatzes, Anzahl der Fenster im Büro, etc.). Zuletzt die tragische Diagnose - Unsinn hat oft einen selbstverstärkenden Effekt.

Jay Inslee: 13-year-old sentencing errors discovered at state prisons

Ein weiteres Beispiel für die weitreichenden Auswirkungen von Software-Bugs. Laut dieser Pressemitteilung von Jay Inslee, dem Gouverneur von Washington State, führte fehlerhafte Software seit 2002 (!) dazu, dass über 3000 Straftäter versehentlich aus den Staatsgefängnissen entlassen wurden bevor sie ihre Strafe abgesessen hatten. Den Recherchen einer lokalen Zeitung zufolge konnte es so dazu kommen, dass bis zu zwei Jahre der Strafzeit wegfielen. Besonders bemerkenswert ist auch folgender Aspekt: die Fehlfunktion war schon seit 2012 bekannt, konnte aber bisher nicht vollständig behoben werden. Bis auf weiteres werden die Entlassungsdaten jetzt wieder manuell berechnet.

Corinna Baldauf : Slack-Time & Open Space – Nächstes Mal mit noch mehr Kuchen!

Ein Praxisbericht von Corinna Baldauf von der Firma Sipgate, in dem sie berichtet wie in ihrer Firma so genannte "Open Fridays" eingeführt wurden. In diesem Unternehmen sind das Tage in denen die Mitarbeiter ohne Anleitungen das machen können was sie für ihre Firma für sinnvoll halten. Interessant zum einen, weil sowohl die Häufigkeit (alle zwei Wochen) als auch die positiven Erfahrungen so nur in den wenigsten Unternehmen vorkommen. Interessant aber auch zum anderen, weil die zu Beginn gemachten und später korrigierten Fehler aufzeigen wie man es nicht machen sollte: Wenn man Selbstorganisation will darf man den Mitarbeitern nicht das Gefühl geben gegängelt und in feste Prozesse gepresst zu werden. Tut man es doch wird das Ergebnis von allen Seiten als unbefriedigend empfunden werden.

Dilbert: How to produce great Engineering [Edit: Link ist mittlerweile tot]

Das ganze Elend des Projekt-Staffings komprimiert in einem Comic-Strip. Um Geld zu sparen werden für das nächste Vorhaben vor allem billige Arbeitskräfte unter Vertrag genommen. Da diese nicht ohne Grund billig sind dauert alles länger, ausserdem entstehen ungeplante Zusatzaufwände durch ständiges Reparieren und Refactoring. Um im Plan zu bleiben werden nicht etwa die grundlegenden Fehler behoben, stattdessen werden die Mitarbeiter aufgefordert mehr und länger zu arbeiten und sich stärker mit der Arbeit zu indentifizieren. Dass das nicht funktionieren kann wird ignoriert und wer es anspricht wird abgebügelt. Ich habe solche Projekte erlebt, und jedes einzelne davon ist wirklich, wirklich teuer geworden.

: Die besten Links des Jahres 2015

Sehr Meta: ein Link aus einer kommentierten Linkliste der auf eine kommentierte Linkliste verweist. Eine Sammlung von ausgewählten Artikeln des Jahres 2015, unter anderem zu den Themen (Selbst)Organisation und Agile.

Montag, 28. Dezember 2015

The final Countdown

Bild: Wikimedia Commons/Jhong Dizon - CC BY 2.0

Da das Jahr fast zu Ende ist, einige Überlegungen zum Thema "nahende Deadline". Auch in Scrum oder anderen agilen Vorgehensweisen gibt es fixe Liefertermine, zum Beispiel wenn sich die Software ab dem ersten Januar anders verhalten muss um konform zu neuen Gesetzen oder Vorschriften zu sein. Und auch hier kommt es immer wieder vor, dass einige Sprints vor dem Termin absehbar ist, dass sich nicht alles umsetzen lässt was geplant ist. Wie soll man damit umgehen?

Ein verbreiteter Weg besteht darin, das Ergebnis zu "erzwingen". Die Teams werden angewiesen ihre Velocity zu steigern oder ihre Durchlaufzeit zu verringern und zu diesem Zweck Überstunden zu machen, ausserdem gibt man sich mit Umgehungslösungen und halbfertigen Funktionen zufrieden, solange alles "irgendwie funktioniert". Das kann kurzfristig zum Ziel führen, bringt aber mittel- und langfristig die bekannten Probleme:
  • überarbeitete Mitarbeiter machen mehr Fehler
  • die werden aufgrund der fehlenden Zeit nicht alle korrigiert
  • die Anwendung geht mit Notbehelfen in die Produktion
  • weitere Fehler werden gar nicht entdeckt, da die Zeit nicht für das Schreiben der Tests gereicht hat
  • das nachträgliche Fehlerbeheben und das Ersetzen der Provisorien erweist sich als aufwändiger als gedacht
Am Ende sind Aufräumarbeiten nötig, die sich über Monate ziehen können. Als Nebeneffekt kann ausserdem die Selbstorganisation der Teams schweren Schaden nehmen, wenn diese immer dann "wenn es dringend ist" in den Modus von Befehl und Gehorsam zurückmüssen.

Ein besserer Weg ist der, das Team in die Entscheidungen mit einzubeziehen. Das kann z.B. in Form einer offenen Fragestellung passieren: "Das hier sind die Vorschriften, die zum Stichtag erfüllt sein müssen, das ist die Zeit die wir noch haben - was müssen wir tun um am Tag X das gewünschte Ergebnis zu haben?" Ich selber habe mit diesem Vorgehen sehr gute Erfahrungen gemacht, allerdings bedarf es dazu bestimmter Bedingungen und Voraussetzungen:
  • Das Team muss ein gutes fachliches Verständnis des Produktes haben
    Nur wer das große Bild im Kopf hat kann überhaupt wissen was verzichtbar und was unverzichtbar ist. Wer bisher "an der kurzen Leine gehalten wurde" hat dieses Verständnis in der Regel nicht, und um es kurz vor Ende aufzubauen fehlt die Zeit.
  • Der Product Owner oder Auftraggeber muss bereit sein, auf bereits geplante Features zu verzichten
    Von der Komfortfunktion über den "machen wir immer so"-Workflow bis hin zum Lieblings-Gadget des IT-Chefs - alles was nicht zwingend zum kleinstmöglichen Funktionsumfang gehört muss rausfliegen. Wenn es wirklich so wichtig ist kann es in einem späteren Release nachgeholt werden.
  • Das Team muss (zumindest in dieser Phase) an einem Ort versammelt sein
    Nichts frisst Zeit und Effektivität in vergleichbarem Ausmaß auf wie langsame und schlechte Kommunikation. Unter Termindruck ist schlicht keine Zeit für unverständliche Telefonkonferenzen, langwierigen Email-Verkehr oder wackeliges Screen-Sharing.
Und wenn so etwas einmal geklappt hat kann das auch einen grundsätzlichen Aha-Effekt bedeuten. Die genannten Punkte machen nämlich auch im Normalbetrieb Sinn, selbst wenn es gerade mal keinen Zeitdruck gibt.

Mittwoch, 23. Dezember 2015

Jahresgespräche

Bild: Flickr/Tech.Co - CC BY-SA 2.0
Würde man unter den Angestellten vor allem grosser Unternehmen eine Umfrage machen um herauszufinden welche Methode ihrer Führung sie als eher dysfunktional empfinden - die Chancen stünden gross, dass die Jahresgespräche weit oben unter den Ergebnissen landen würden, jene Termine also in denen man gemeinsam mit dem Vorgesetzten auf das vergangene Jahr zurückblickt. In der Theorie sind diese zwar dazu da, Kommunikation zu verbessern, Vertrauen zu schaffen und die Mitarbeiter für die Unternehmensziele gewinnen, in der Realität sieht das aber oft anders aus, aus einer Reihe von Gründen:

1. Viele Vorgesetzte sind fachlich nur eingeschränkt in der Lage, die Leistung ihrer Mitarbeiter zu bewerten


Ein schwieriges Thema, aber eines an dem man nicht vorbeikommt. Leitende Angestellte kommen erstaunlich oft aus einem fremden Fachbereich (z.B. BWL) und kennen sich mit den eigentlichen Umsetzungs-Themen (z.B. IT oder Kundenservice) nur oberflächlich aus. Diejenigen die ihre Karriere dort begonnen haben sind nach Jahren oder Jahrzehnten im Management mit der eigentlichen Arbeit kaum noch vertraut, bzw. sie wissen nur noch wie es früher einmal war. Komplexe Themen erscheinen ihnen häufig zu einfach und einfache Themen zu komplex, die Geschwindigkeit des technologischen Wandels kann nicht mehr eingeschätzt werden und der direkte Kontakt zu Kunden und Anwendern ist unterbrochen. Notgedrungen lenken solche Führungskräfte die Gespräche in Gebiete in denen sie besser mitreden können, was zu einem weiteren Problem führt:

2. Leistung wird auf Messwerte (KPIs) reduziert


Derartige Führungskräfte haben die Tendenz sich in den Jahresgesprächen auf Themen zu konzentrieren die sich messen und zählen lassen, da das Betrachten der so erzeugten Zahlen sich auch mit wenig Detailwissen machen lässt. Statt konstruktiv darüber zu sprechen was gut lief und was man besser machen könnte wird versucht alles auf zählbare Werte herunterzubrechen. Im besten Fall geht es dabei um Fertigstellungsdaten oder generierte Umsätze, im schlimmsten Fall wird versucht Produktivität zu messen indem man die Einhaltung von (oft willkürlich gesetzten) Meilensteinen überprüft oder geschriebene Lines of Code, die Dauer von Beratungsgesprächen oder die Menge bearbeiteter Tickets zählt. Und wenn man damit einmal angefangen hat ist der nächste Fehler nicht weit:

3. Belohnung und Bestrafung finden auf Basis dieser Messwerte statt


 In dem Moment in dem sich die KPIs als zentrales Bewertungskriterium etabliert haben ist es (scheinbar) einfach: Wer seine messbaren Ziele erreicht bekommt ein Lob, wer sie übertrifft bekommt einen Bonus, wer sie nicht erreicht einen Malus. Die Folgen eines solchen Vorgehens wirken sich fast immer negativ auf die Produktqualität aus: Um Meinenstein-Termine zu halten wird an Architektur, Dokumentation und Testen gespart, das möglichst schnelle Beenden von Beratungsgesprächen beeinträchtigt die Beratungsqualität und um geforderte Ticket-Mengen zu liefern wird deren Menge durch unnötige Kleinteiligkeit aufgebläht. Anwendungen werden dadurch fehleranfällig, Kunden unzufrieden und Geschäftsvorgänge unübersichtlich und bürokratisch. Und noch ein Nebeneffekt tritt auf:

4. In den Gesprächen geht es oft nur noch um die Festlegung von zählbaren Zielen und um die Diskussion ob diese erreicht wurden


Zur Erinnerung: Kommunikation zu verbessern, Vertrauen zu schaffen und Mitarbeiter für Ziele zu gewinnen sollte das eigentliche Ziel sein. Stattdessen ist es in Jahresgesprächen die sich nur noch um Zahlen drehen häufig so, dass sich die Mitarbeiter zunächst für die Zahlen des letzten Jahres rechtfertigen müssen. Wenn Erfolge nicht klar zuzuordnen sind müssen sie beweisen, dass sie dazu beigetragen haben und im Misserfolgsfall findet eine Beweislastumkehr statt - jetzt müssen sie beweisen, dass sie nicht schuld daran sind. Die Zahlen für das nächste Jahr sind häufig "anspruchsvoll" und nicht selten von noch weiter oben vorgegeben (d.h. nicht verhandelbar). Selbst wenn ausserdem noch ein vertrauensbildender Teil oder ein Personalentwicklungsgespräch vorgesehen ist, kann das jetzt nur noch scheitern. Und apropos Vertrauen und Personalentwicklung:

5. Für Vertrauensbildung und Personalentwicklung sind Abstände von einem Jahr zu lang


In zwölf Monaten kann sich viel ändern. Durch neue Produkte von Konkurrenten ändert sich der Markt, die Technik entwickelt sich weiter, neue gesetzliche Regulierungen haben unerwartete Auswirkungen, Kollegen kommen und gehen und beeinflussen damit die Leistung der Abteilungen, etc., etc. Das alles sind Faktoren die in die Bewertung der Leistungen des letzten Jahres einfließen müssten, genau wie Grippewellen, Infrastrukturausfälle oder insolvente Lieferanten. Das alles in einem jährlichen Termin zu berücksichtigen ist nahezu unmöglich, allein die Auflistung aller relevanten Faktoren würde ewig dauern, ganz zu schweigen von der Diskussion über ihre Auswirkungen. Da das nicht geht entsteht Unmut auf beiden Seiten: der Mitarbeiter fühlt sich ungerecht behandelt, der Vorgesetzte hat das Gefühl nur mit nicht überprüfbaren Ausflüchten konfrontiert zu werden.

Aber wenn nicht so, wie dann?


Flexibler, in kürzeren Intervallen, ohne festes Schema, ohne falsche Anreize.
  • Zunächst einmal müssten solche Gespräche in kürzeren Abständen stattfinden, beispielsweise monatlich. Und dazu müsste auch genug Zeit zur Verfügung stehen. Nur so können alle relevanten Faktoren berücksichtigt und Ziele ggf. angepasst werden.
  • Die Bewertung dürfte nicht mehr auf einer quantitativen sondern auf einer qualitativen Ebene stattfinden. Dazu wäre es notwendig, dass der Vorgesetzte auch fachlich mitreden kann, selbst wenn das für ihn einen Einarbeitungsaufwand erfordert (für den er auch Zeit haben muss).
  • Es müsste auf jeden Mitarbeiter und seine Situation individuell eingegangen werden, also ohne zu starke Orientierung an einheitlichen Gesprächsleitfäden und Checklisten.
  • Und zuletzt müssten sämtliche Anreizsetzungen kritisch hinterfragt werden. Wenn ein individuelles Ziel negative Auswirkungen auf Kundenzufriedenheit oder Produktqualität haben kann, dann sollte man es nicht vorgeben. Auch hier gilt aber: um das erkennen zu können braucht es tiefere Beschäftigung mit dem Thema.
Es ist übrigens nicht so als ob es das nicht bereits gäbe, viele Unternehmen haben ihre Prozesse bereits entsprechend angepasst oder sind gerade dabei das zu tun. Genausoviele verharren aber noch in den alten Mustern und führen weiterhin Jahresgespräche durch die eher Schaden anrichten als Nutzen stiften. Und wenn es immer wieder nach diesen Gesprächen zu inneren oder tatsächlichen Kündigungen kommt, ist die Verwunderung groß.

Montag, 21. Dezember 2015

Ein Bild sagt mehr als 1000 Worte (IX)

Eine schöne Visualisierung vom Bent Flyvbjerg, über dessen unsichtbare Hände des Projektmanagements ich ja schonmal etwas geschrieben hatte.

Donnerstag, 17. Dezember 2015

Zertifizierungen schaden nicht - oder doch?

Über den Nutzen und Wert der Agile- und Scrum-Zertifizierungen von Scrum Alliance, Scrum.org, ISTQB, ISQI, PMI, Prince2, TÜV1 und wer weiß wem sonst noch gibt es deutlich auseinandergehende Meinungen. Von nützlichem Grundlagenwissen bis sinnlosem Geldverbrennen ist alles dabei, die Wahrheit dürfte wie so oft in der Mitte liegen. Konsens herrscht allerdings darüber, dass sie zumindest nicht schaden - dachte ich zumindest bis vor kurzem. Bei Menschen die in großen Consulting-Unternehmen sozialisiert wurden kann es nämlich durchaus einen Minuspunkt bedeuten wenn man Inhaber mehrerer verschiedener Zertifikate ist.

Um zu verstehen wie es dazu kommen kann muss man die interne Struktur einiger dieser Unternehmen kennen. Viele von ihnen rekrutieren die Berater die sie zu ihren Kunden schicken in einem internen Projektmarkt. Ähnlich wie Freelancer auf dem normalen Markt muss man sich auf die hier ausgeschriebenen Stellen bewerben und ein Auswahlverfahren durchlaufen bevor man angenommen wird. Wer dabei aussortiert wird fällt allerdings nicht in die Untätigkeit zurück sondern wird angehalten sich weiterzuqualifizieren, etwa durch Trainings, Fortbildungen oder eben Zertifizierungen.

Was eigentlich dazu gedacht ist die Chancen beim nächsten Projekt zu verbessern kann sich im schlimmsten Fall zum Stigma auswachsen: Wer in größerem Ausmaß Zertifizierungen gesammelt hat gerät in den Verdacht, dass er von vielen Projekten  abgelehnt wurde, woraus negative Rückschlüsse auf Qualifikation, Teamfähigkeit, Selbstdarstellung oder Ähnliches abgeleitet werden. Zunächst ist das ein rein internes Phänomen großer Beratungshäuser, das aber auch Auswirkungen auf andere Unternehen haben kann - wenn ein Unternehmensberater in das Management einer anderen Firma wechselt nimmt er seine Vorurteile im Regelfall mit.

Im Großen und Ganzen dürfte es zwar der Ausnahmefall sein, ganz ausschließen kann man es aber nicht: Möglicherweise bringt die Zertifizierung bei der nächsten Bewerbung keinen Bonus sondern einen Malus. Man kann es eben nicht jedem Recht machen.


1No kidding: Der TÜV bietet Scrum-Zertifizierungen.

Dienstag, 15. Dezember 2015

Scaled Agile: Hybrid-Strukturen vs. Meta Teams

Bild: Flickr / St Munchin's College - CC BY 2.0
Ein Thema das mich seit meinem ersten agilen Projekt begleitet ist die Frage nach der Skalierung. Dass Scrum in kleinen Teams funktioniert sieht noch fast jeder ein, sobald es in Größenordnungen von fünf Teams aufwärts geht kommen aber Zweifel auf. Einer der häufigsten Einwände: da sich die Teams selbst untereinander koordinieren müssen steigt mit jedem weiteren dazukommenden der Kommunikationsaufwand. Früher oder später ist der nicht mehr zu bewältigen und die Koordination bricht zusammen. Die Teams zerschießen sich dann gegenseitig den Code, arbeiten redundant oder bauen inkompatible Komponenten. Als Lösung wird von klassischen Managern häufig ein Hybrid-Modell installiert: die Entwicklungsteams arbeiten weiter agil, oberhalb von ihnen wird ein Wasserfall aufgesetzt, der die Anforderungen erfasst und auf die Teams verteilt (ein Framework dem man das häufig vorwirft ist das Scaled Agile Framework, bzw. SAFe). Ein solches Modell sieht etwa so aus:


Auf den ersten Blick mag das zwar ganz sinnvoll erscheinen, in der Realität kollabiert die Kommunikation in diesem Modell aber erst recht. Wenn z.B. Team 1 bemerken sollte, dass versehentlich eine nicht umsetzbare Anforderung in eine Story geflossen ist, muss es das an die nächsthöhere Ebene zurückmelden. Diese muss dann gegebenenfalls auch Team 2 zurückrufen, da auch dieses von der Falschannahme betroffen ist. Da aber der Weg von Team 1 nach oben und von dort wieder nach unten Zeit in Anspruch nimmt hat Team 2 bereits mit der Arbeit begonnen. Die war damit umsonst und kann jetzt weggeworfen werden. Noch verheerender wird es wenn von dem Fehler in der Anforderung auch eines der Teams drei bis sechs betroffen ist: der Feedbackweg geht dann noch weiter nach oben und von dort wieder nach unten, die Benachrichtigung der anderen Teams erfolgt noch später, noch mehr Zeit und Geld werden verschwendet. Das ist also kein sinnvoller Weg.

Es bleibt die Frage: Wenn nicht so, wie dann? Dass sich jedes Team mit jedem anderen direkt abstimmt führt ja auch zu Problemen (siehe oben). Ein möglicher Ausweg geht so:


Man sieht: ein deutlich flacheres Modell. Der hier gewählte Lösungsansatz ist der, dass thematisch oder technisch verwandte Teams enger kooperieren als andere. Die Teams eins und zwei arbeiten beispielsweise gemeinsam am CMS, drei und vier am Shop, fünf und sechs an verschiedenen Mobile-Apps. In den zusammengehörigen Teams finden engere Abstimmungen statt, etwa zwischen den POs (die sogar ein Meta-PO-Team bilden können) und zwischen den Entwicklungteams (durch gemeinsame Groomings, Reviews, etc.). Die verschiedenen Gruppierungen stimmen sich dann direkt (ohne koordinierende Management-Ebene) mit den jeweils anderen ab, etwa in Form eines Scrum of Scrums. Reibungsverluste gibt es zwar auch hier (ganz vermeiden kann man die im skalierten Vorgehen nie), sie sind aber deutlich geringer als im oben gezeigten Modell. Zum Einen weil es kaum Kommunikationswege über mehrere Hierarchieebenen gibt, zum anderen weil die Entwickler ohne technikfremde Zwischenpersonen direkt miteinander kommunizieren können. Im Großen und Ganzen erfolgt die Koordination so wesentlich effektiver.

Was dabei allerdings klar sein muss: auch dieses Modell ist nicht universell anwendbar. Es ist eine Lösungsmöglichkeit, die zwar besser als das Hybrid-Modell funktioniert, je nach Kontext aber weiter angepasst werden muss. Für diese Anpassungen gibt es dann wieder weitere Möglichkeiten wie z.B. Communities of Practice, Gilden, teamübergreifende Plannings und Backlogs oder Unterstützungs-, bzw. Spezialistenteams. Das sind dann aber wieder Themen für sich.

Donnerstag, 10. Dezember 2015

Scrum-Kochen

Diese Woche haben wir beim Bonner Scrumtisch etwas gemacht was ich schon lange ausprobieren wollte: Scrum-Kochen, also die Zubereitung eines (Abend)Essens nach Scrum-Regeln. Die jeweils 40 Minuten lange Vor- und Zubereitung eines Gangs entspricht einem Sprint, die einzelnen Teile (z.B. Fleisch, Beilage, Tisch decken) entsprechen einer Story, einzelne Tätigkeiten (Schneiden, Stampfen, Servietten falten) entsprechen den Tasks. Und genau wie in der Software-Entwicklung gibt es auch hier ein Kanban-Board und die Rollen und Regeln von Scrum. Für das Aufteilen einer Story in Tasks gibt es beispielsweise ein Planning.


Um das Ergebnis vorwegzunehmen: es entstand ein sehr gutes und leckeres Essen. Genauso wichtig waren aber auch die Erkenntnisse, die ich für einen möglichen Einsatz dieser Idee bei einem Kunden mitgenommen habe1:
  • Regeln sollten vorab und sehr klar definiert und kommuniziert werden: Dass vor dem Sprintbeginn ein Backlog Refinement liegen sollte (um zu klären was mit den vorhandenen Zutaten überhaupt gekocht werden kann) und dass es während des Sprints kurze Scrum Meetings am Board geben sollte war nicht für alle gleich offensichtlich.
  • Es sollte vorher eine kurze Einführung in die Küche stattfinden: Ceranfelder die sich bei Bedienfehlern selbst ausschalten oder dezent getarnte Mülleimer können ein hartnäckiges Impediment sein.
  • Die Koch-Erfahrung der Teilnehmer sollte berücksichtigt werden: Wer die "Komplexität" der Zubereitung oder die "Velocity" der Teammitglieder falsch einschätzt wird möglicherweise einen unrealistischen Forecast abgeben.
  • Es sollten mehrere Sprints (Gänge) mit vergleichbarem Aufwand eingeplant werden, damit sich über die "Iterationen" Lerneffekte feststellen lassen. Auch dass man für Inspect & Adapt Retrospektiven benötigt sollte in der Zeitplanung berücksichtigt werden.
  • Es sollte immer genug Amaretto vorhanden sein.
Es war also nicht nur lecker und unterhaltsam, es war auch lehrreich. Was kann man mehr wollen? Und vielen Dank an Chefkoch.de für das Bereitstellen der Küche. 


1Hintergrund des Scrum-Kochens ist, dass damit die Methode spielerisch vermittelt wird und auch von Personen ohne IT-Kenntnisse verstanden werden kann

Dienstag, 8. Dezember 2015

Thomas Tuchel Rulebreaker

Fussball ist ja extrem beliebt, wenn es darum geht, Vorbilder für jegliche Art von Teamarbeit zu finden. Oft erschöpft sich das in relativ flachem Sprücheklopfen ("Du bist immer nur so gut wie Deine Mannschaft", "In der Nachspielzeit geben wir noch mal Gas", etc.), manchmal ist aber auch erstaunlich inspirierend. Hier etwa im Rahmen eines Vortrags des Mainzer und Dortmunder Trainers Thomas Tuchel, der mit erstaunlicher Leichtigkeit vieles von dem anspricht, was sich auch im modernen Management wiederfindet: Trial & Error, Inspect & Adapt, Leitplanken statt Vorschriften, Anreize statt Bestrafungen, Servant Leadership, Selbstkritik und Motivation.

Freitag, 4. Dezember 2015

The Zombie Cage

Bild: Flickr / Gage Skidmmore - CC BY-SA 2.0
Zu den Problemen in einem meiner vergangenen Jobs gehörte der klassische Konflikt zwischen Projekt und Linie. Auf dem Papier waren einige Kollegen zu 50% von ihrer Linientätigkeit freigestellt, Ausnahmen davon gab es nur wenn äusserst dringende Aufgaben anlagen. Das Problem: es war praktisch immer irgendetwas äusserst dringend. Infolgedessen konnte es durchaus vorkommen, dass der eine oder andere dem Projekt tage- oder sogar wochenlang nicht zur Verfügung stand.

Das gegenüber dem Kunden zu thematisieren gestaltete sich unerwartet schwierig - obwohl ständig einzelne Aufgaben auf unserem Kanban-Board "feststeckten" sorgte die Arbeit der anderen Kollegen dafür, dass insgesamt ein beständiger Flow stattfand, in dem die Blockade der einzelnen Tasks, bzw. Personen nur noch schwer sichtbar war. Das für die Überplanung der eigenen Mitarbeiter verantwortliche mittlere Management konnte so immer behaupten, dass es gar kein Problem gäbe, schließlich ginge es doch beständig voran und alles würde abgearbeitet. Um die Blockaden so sichtbar zu machen, dass sie sich nicht mehr kleinreden liessen suchten wir nach einer guten Visualisierung und erfanden den Zombie Cage.


Der Zombie Cage war eine einzelne Box unterhalb des eigentlichen Boards, in die alle Tasks verschoben wurden, die während der letzten vier Meetings nicht bewegt worden waren. Durch ihre Platzierung auf dem Board waren diese Tasks bis dahin "lebendig" (d.h. in Arbeit befindlich) erschienen, obwohl sie in Wirklichkeit schon längst "tot" (aus dem Bearbeitungsstatus herausgefallen) waren, daher der Name. Sie nach unten zu verschieben erfülte zwei Zwecke: zum einen führten sie jetzt weiter oben nicht mehr zu "Work in Progress-Stauungen", zum anderen konnte das mittlere Management die personell bedingten Blockaden nicht mehr wegreden. Als besonders hilfreich erwiesen sich dabei die ungewöhnliche Benennung und die auffällige Gestaltung des Cage, die das sporadisch vorbeikommende obere Management immer wieder dazu bewegten diesen Bereich genauer anzusehen.

Plötzlich waren die Blockaden ein regelmässiges Thema in den Projektleitungsrunden und das Problem der Überplanung wurde offensichtlich. Letztendlich führte die Situation dazu, dass die überplanten Kollegen auf Druck von ganz oben ganz aus dem Projekt herausgenommen wurden, da es zu offensichtlich war, dass sie gar keine Zeit für eine zielführende Mitarbeit hatten. Die Nichtverfügbarkeit der ursprünglich zugesagten Ressourcen war damit offiziell beschlossen und führte auch zu einer Anpassung der Projektplanungen, die damit wieder ein Stück realistischer wurden. Gegen Ende war der Zombie Cage dann nur noch selten in Benutzung, alleine seine Anwesenheit sorgte aber dafür, dass Überplanungsversuche kaum noch stattfanden.

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.

Samstag, 31. Oktober 2015

Kommentierte Links (VI)

Grafik: Pixabay / Elisa Riva - Lizenz

C. Dierig, N. Doll, S. Fründt, O. Gersemann, G. Hegmann: Deutschlands Problem ist der deutsche Ingenieur

Was ein ganzes Autorenkollektiv da für die Welt aufgeschrieben hat, zeigt die Negativseiten jener Ressource auf, auf der praktisch die ganze deutsche Wirtschaft aufbaut: der deutschen Ingenieursmentalität. Der ihr zugrundeliegende Perfektionismus hat dazu geführt, dass unsere Autos, Maschinen und Geräte zu den besten und sichersten der Welt gehören, verringert aber mittlerweile die Erfolgschancen vieler Unternehmen - statt Wert auf möglichst frühe Marktreife zu legen werden Produkte durch kleinteiligste und nicht hinterfragbare Anforderungen "kaputtentwickelt" oder kommen erst nach der Konkurrenz auf den Markt. Erschwerend kommt dazu, dass in diesem Perfektionismus ein nicht ganz abstreitbarer Größenwahnsinn steckt, der es sehr schwierig macht dagegen anzuargumentieren. Wohin das führen kann zeigt ein zweiter Artikel aus der Süddeutschen Zeitung, der beschreibt, dass bei VW kritische Mitarbeiter einfach niedergeschrien wurden. Der vorgeschlagene Ausweg aus dieser Situation wären Entbürokratisierung und Enthierarchisierung bis zum Wegfall ganzer Managementebenen, womit auch gleich klar ist wer dagegen ankämpfen wird.

Sascha Lobo: Die lustige, bittere Wahrheit über die Vorratsdatenspeicherung

Ausgehend von einem ganz anderen Punkt (der Voratsdatenspeicherung) wird in diesem Artikel beschrieben wie der Planungsperfektionismus, an dem die (Groß)Wirtschaft leidet, überhaupt entstehen konnte. Lobo schlägt zur Erklärung den ganz großen Bogen zurück zur Epoche der Aufklärung von über 200 Jahren, in der man aufhörte an Götter und Zauber zu glauben und stattdessen die Ursachen fast aller Phänomene in Physik und Chemie entdeckte. Plötzlich ließ sich fast alles erklären, nachvollziehen und messen. Und in dieser Messbarkeit sieht Lobo die Wurzel für eine verhängnisvolle Fehlannahme: "Wenn man alles messen kann, kann man die Realität komplett erfassen und deshalb alles vorhersagen." Derartige Ansichten habe ich bei verschiedenen Managern tatsächlich bereits erleben dürfen, meistens verbunden mit einem noch verhängnisvolleren Umkehrschluss: "Wenn es sich nicht planen lässt, dann haben wir einfach noch nicht genug Daten erhoben." Diese Einstellung ist die Ursache für den Betonklotz aus Reportingpflichten, der gerade in scheiternden Projekten häufig an die Füße der Mitarbeiter gehängt wird und so auch die letzten Erfolgsaussichten vernichtet.

Sabine Bernecker-Bendixen: LaaS – Leadership as a Service

Aufzählen was alles schlecht läuft ist einfach, aber wie ginge Management heute besser? Sabine Bernecker-Bendixen macht sich die Mühe und trägt einige Gedanken zusammen. Grundlegende Ideen sind Vertrauen statt Kontrolle, Abkehr von der oben beschriebenen Zahlengläubigkeit, die Verlagerung von Verantwortung nach unten zu den Mitarbeitern, Förderung von deren Kompetenzen, die Entwicklung einer Teamkultur, Coaching statt Befehle geben, Bereitschaft zur Selbstkritik, Bereitschaft sich kritisieren zu lassen, Bereitschaft eigene Schwächen und Fehler einzugestehen und sie zu korrigieren sowie Abschaffung von Flaschenhälsen und Herrschaftswissen. Im Großen und Ganzen soll am Ende genau das entstehen was die Überschrift besagt: Leadership as a Service. Wer die klassische Unternehmenswelt kennt weiß - die Frau spricht von einer Revolution.

Steve Denning: Can The 21st Century Corporation Operate Without Agile?

Apropos Revolution. Steve Denning von Forbes hat einen sehr, sehr langen Fortune-Artikel von Geoff Colvin gelesen und darauf aufbauend einen sehr langen eigenen geschrieben. Wer beide liest bekommt erklärt, wie die (Business)Agilität zum Erfolg der "21st-century corporations" beiträgt, die im Augenblick die Märkte revolutionieren: Skype, Apple, Tesla, Uber, AirBnB, etc. Zu ihren Erfolgsfaktoren zählt er neben einer neuen Art der Personalführung (siehe oben) auch die Bereitschaft, die Beziehungen zum Kunden neu zu definieren - statt ihn durch Werbung, Preise, etc. so zu manipulieren, dass er die angebotenen Produkte kauft, wird ergründet was er will und ihm dann das angeboten. Da Kunden aber häufig ihre Meinung über das was sie brauchen ändern, erfordert das hohe Reaktionsgeschwindigkeiten, also Agilität.

Der Fruehlix: Ich habe den Scrum-Master besiegt!

Mit erwartbarem Ergebnis.

Dienstag, 27. Oktober 2015

Management was killed by Complexity

Es scheint ja gerade die Zeit der agilen Konferenzen am Rhein zu sein. Neben der Agile Cologne und der kommenden Scrum Deutschland muss wohl auch vor Kurzem die agile Inhouse-Konferenz der Telekom stattgefunden haben, von der auch diese launige Keynote stammt:



Bei allem Amüsement muss ich aber auch ein bisschen Kritik üben: Zum einen ist das Halten eines frontalen Vortrages eher unagil, zum anderen wird hier thematisch lediglich eine "Grundlagen-Einführung" gehalten - das alles sollte eigentlich jedem der sich ein bisschen mit dem Thema beschäftigt schon klar sein. Vielleicht wollte aber auch einfach jemand ein bisschen Geld dafür ausgeben, dass sein Unternehmen als "dummer Mist" bezeichnet wird. Das wäre dann gelungen.

Montag, 26. Oktober 2015

Agile wird in Vergessenheit geraten

Bild: Flickr/Wandering Soul - CC BY 2.0
Zugegeben, ein etwas reisserischer Titel, aber die Essenz meiner Ideen die ich am Wochenende auf der Agile Cologne in eine Session mit dem Dauerbrennerthema Die Zukunft agiler Methoden eingebracht habe. Und falls das angesichts meiner bisherigen Aussagen verwirren sollte kann ich das sogar noch verstärken: Agile wird in Vergessenheit geraten - und das ist eine gute und wünschenswerte Entwicklung.

Um das zu erklären möchte ich Agilität mit zwei anderen, älteren Ansätzen vergleichen, die die Wirtschaft in ähnlicher Art und Weise revolutioniert haben wie die Agilität es gerade tut: mit Standardisierung und Fordismus. Die Standardisierung war eine um 1800 einsetzende Bewegung deren Ziel es war, Maße und Einheiten, aber auch Produkte, so zu vereinheitlichen, dass sie universal anwendbar wurden. Erst durch die Standardisierung wurde es beispielsweise möglich, dass sich Schrauben und Muttern oder Knöpfe und Knopflöcher1 unabhängig voneinander herstellen lassen und trotzdem zueinander passen. Der Fordismus baute etwa 100 Jahre später darauf auf und optimierte (und verbilligte damit) die Fertigung der standardisierten Gegenstände in arbeitsteiligen Fertigungsstrassen, in denen beispielsweise Marmeladengläser erst auf ein Fließband gestellt, dann gefüllt, dann verschlossen und dann verpackt werden. Es ist ersichtlich: ohne die beiden Konzepte der Standardisierung und des Fordismus wären weder Industrielle Revolution noch Konsumgesellschaft möglich gewesen. Unser gesamtes modernes Wirtschaftssystem beruht darauf. Trotzdem kennt kaum noch jemand diese Begriffe.2

Dass diese Ansätze heute nahezu unbekannt sind liegt allerdings nicht daran, dass sie nicht mehr genutzt werden, ganz im Gegenteil. Sie sind nach wie vor allgegenwärtig. Zumindest die (Hardware)produzierende Industrie wäre ohne sie überhaupt nicht vorstellbar. Sie sind sogar derartig selbstverständlich geworden, dass es gar nicht mehr notwendig ist sie zu erwähnen - jeder Mensch erkennt (zumindest implizit) ihre universelle Bedeutung und Berechtigung, ohne dass das noch ausgesprochen werden müsste. Und an der Stelle kommen wir zurück zu Agile: Im Moment ist es noch so, dass agile Methoden von vielen als etwas Neues, Disruptives und Erklärungsbedürftiges angesehen werden. Gleichzeitig werden sie aber im Umfeld komplexer Faktoren immer üblicher, in der IT sind sie mittlerweile sogar der de facto-Standard. Und wie im Fall der Industrieprodukte, bei denen heute ganz selbstverständlich davon ausgegangen wird, dass sie standardisiert sind, wird es mittelfristig so sein, dass man ganz selbstverständlich davon ausgeht, dass Projektmanagement praktisch immer agil ist.

Der Begriff agiles Produktmanagement wird vermutlich bereits der nächsten Generation genauso redundant vorkommen wie standardisiertes Industrieprodukt. Man wird das vorangestellte Adjektiv agil einfach weglassen und es wird in Vergessenheit geraten. Und wie oben gesagt: das ist auch gut so.


1Bzw. Kleidung mit Knopflöchern
2Was man kennt ist die Normung, die aber kein Synonym der Standardisierung ist sondern durch sie erst ermöglicht wurde

Freitag, 23. Oktober 2015

Scrum, Gamification und Seriösität

Bild: Flickr / I am R. - CC BY 2.0

Da morgen die Agile Cologne beginnt geht mir zur Zeit wieder die Session durch den Kopf, die ich bei der letzten Ausgabe gehalten habe: Scrum und Seriösität. Dahinter steht ein Problem das mir auf verschiedenen Projekten begegnet ist, das aber erstaunlich selten thematisiert wird - Scrum wird von Management und Mitarbeitern vieler Unternehmen wegen seines äusseren Erscheinungsbildes als unseriös empfunden und deswegen abgelehnt.

Hintergrund dieses Phänomens ist weniger Scrum selbst (obwohl das in diesem Kontext immer wieder behauptet wird) sondern eher ein Konzept mit dem es häufig eingeführt und umgesetzt wird: die Gamification. Die Idee dahinter ist, dass neue Techniken durch einen eher spielerischen oder wettbewerbsartigen Ansatz besser vermittelt werden können, da Motivation, Engagement und Lernleistung der Beteiligten dann erfahrungsgemäss höher sind. Vor allem einige Praktiken erfreuen sich in agilen Projekten großer Verbreitung:

  • Bei der Lego-Simulation werden Scrum, TDD und weitere Praktiken mit Hilfe von Lego-Steinen erklärt, aus denen das Team in einem simulierten Sprint ein "Produkt" erstellt oder es testet.
  • Beim Estimation Poker wird die Komplexität von User Stories geschätzt indem die Teammitglieder Pokerkarten mit aufgedruckten Nummernwerten hochhalten.
  • Beim Scrum Promptness Game wird das letzte Teammitglied das zu einem Meeting erscheint mit Spielzeugpistolen beschossen, mit Bällen beworfen, o.ä.
  • Beim Standup-Ball wird Durcheinanderreden vermieden indem die Teammitglieder sich gegenseitig einen Ball zuwerfen, der mit der "Sprecherrolle" verbunden ist.
  • In manchen Projekten rotieren bestimmte Rollen wie z.B. der Releasemanager durch das Team, wobei derjenige der sie gerade innehat durch einen auffälligen Hut, ein Plüschtier auf dem Schreibtisch oder Ähnliches sichtbar gemacht wird.

Grundsätzlich erkenne ich zwar den Sinn dieser Vorgehensweisen, in der Realität führen sie aber häufig zu mitunter heftigen Abwehrreaktionen. Viele Mitarbeiter haben das Gefühl, dass ihre Arbeit zu einem "Kinderspiel" reduziert wird und fühlen sich nicht mehr ernstgenommen oder wertgeschätzt, andere sehen den Mehrwert nicht und haben das Gefühl, dass sie ihre Zeit verschwenden. Das Management wiederum bekommt schnell den Eindruck, dass die Teammitglieder für "Ball- und Kartenspielen" bezahlt werden wollen und ist dazu nicht bereit. Auch interne Kontrollabteilungen reagieren schnell allergisch wenn Ausgaben für Pokerspiele, Plüschtiere oder Ähnliches genehmigt werden sollen.

Zum Teil ist diese Ablehnung von Gamification-Elementen ein kulturelles Problem, das seine Ursache darin hat, dass sich amerikanische Konzepte nicht immer Eins zu Eins auf Deutschland übertragen lassen, zum Teil ist es sicher auch so, dass die deutsche Unternehmenskultur tendenziell "Spassfeindlich", bzw. ernsthaft ist. Auch wenn ich bestimmte Spielelemente (wie z.B. das Planning Poker) für sehr sinnvoll halte würde ich aufgrund meiner Erfahrungen mittlerweile empfehlen, sie nur sehr vorsichtig und sehr dosiert einzusetzen, und auch nur dann wenn das Entwicklungsteam sie nicht grundsätzlich ablehnt. Der Schaden ist sonst schnell größer als der Nutzen.

Montag, 19. Oktober 2015

Ein Bild sagt mehr als 1000 Worte (VII)

Ich sage nur: Technischer Fortschritt.
5 MB harddrive being shipped by IBM - 1956.

Freitag, 16. Oktober 2015

How to write a User Story

Eine Zusammenfassung die ich in einem meiner Projekte benutzt habe um Product Owner zu coachen. Natürlich geht sie auf die dortigen Besonderheiten ein, weshalb manche Aspekte besonders betont werden. Bemerkenswert ist aber nicht nur was darin steht, sondern auch was nicht - beispielsweise wird kaum darauf eingegangen wie Stories geschnitten werden. Auch das sagt etwas über dieses Projekt aus.

What is a story about?

  • A Story is a requirement for a small feature that can be implemented within one two-week-sprint.
  • A Story describes a complete, working, testable feature (no separation in frontend/backend).
  • A Story does not describe the current state of the application in detail.
  • A Story does not describe what is planned for future sprints.
  • A Story tells the development team what to implement, not how.

The Structure:

  • A Card of roughly Din A 6-size is what classic User Stories are written on (meanwhile digital tools like Redmine or Jira are common as well).
  • A Title is written on the front side (or in the top field of the digital form).
  • Acceptance Criteria were originally written on the back of the card (in this project we add them in a mandatory field in our digital tool).
  • Additional Information can be written in the description field of the digital tool – the shorter and catchier the better. 
  • And keep in mind – the description is a supplement to the Acceptance Criteria, not the other way round.

The Title:

  • The classic Title format is: As <Role> I want to <Perform Action> so that <I can have a Business Value>. For example: As a User of my company’s intranet I want to upload a profile picture so that the offshore colleagues can see my face.
  • All three parts are important: The Role tells the developers which permissions are required, the Action is the new feature, the Business Value justifies cost and effort of the story. 
  • Of course you can choose another format (for example the FDD-Syntax: <action> the <result>  to <object>. Example: Trigger a signal to confirm readiness) but in that case you should name the role and the business value in the description. 

The Acceptance Criteria:

  • The Criteria define which actions must be executable before the story is considered done
  • The Criteria must be testable: not "Performance must be better", but "Pages must load in less than three seconds". 
  • It is recommended to put them in If-Then-form if possible: If I upload my profile picture and save it, then users who are logged in can see it on my profile page
  • It is best practice to create them together with someone from the QA, because they can give you input about the testability.

The Additional Information:

  • As said above: the shorter and catchier the better. And the description is a supplement to the Acceptance Criteria, not the other way round. 
  • Valuable Information could be: 
    • Preconditions (which Story must be finished before we can start this one?) 
    • Dependencies (which features/teams might be affected when we work on this component?) 
    • Constraints (the new page must be designed according to the company’s CI) 
  • Important: Please name Preconditions, Dependencies or Constraints as such. Otherwise the developers might think they are requirements and try to implement them. 

Feasibility and Size of a story:

  • Only the development team can say if a story is feasible and estimate it’s size. Thinking about feasibility and size without developers included is nothing more than a waste of time, money and brains. 
  • There is a meeting for that, it’s the Backlog Grooming
  • Stories are estimated in complexity, not in days/hours.

And one last thing: the earlier and the more people are involved in the creation of a story, the better the result.

Dienstag, 13. Oktober 2015

No Grooming in England

Bild: Pixabay/Superedd - Lizenz

Dass es Begriffe gibt, die in anderen Sprachen eine andere, mitunter negative Bedeutung haben, ist keine neue Erkenntnis. Auch im Fall von Agile und Scrum ist das nicht völlig auszuschließen, denn wer kann schon wissen, ob nicht z.B. auch im Indonesischen, Arabischen oder Russischen Wörter wie Kanban oder Backlog existieren, die dort aber eine völlig andere Bedeutung haben? Was wirklich überraschend ist, ist aber die Tatsache, dass derartige Missverständnisse ausgerechnet in einer Sprache auftauchen, von der man es am wenigsten erwarten würde - im Englischen.

Scrum ist zwar im englischen Sprachraum entstanden, allerdings nur in einem besonderen Teil davon, in Nordamerika. Die Unterschiede zwischen dem hier gesprochenen Englisch und dem im Rest der Welt gesprochenen sind häufig größer als man denkt und mitunter Ursache peinlicher Missverständnisse. Auch im Bereich des agilen Projektmanagements kann es dazu kommen, wie ich bereits zweimal selbst erleben durfte:

Zum einen geht es um das Wort Scrum selbst. In den USA ist es ein Lehnwort aus einer dort völlig unbekannten Sportart, dessen ursprüngliche Bedeutung in der Alttagssprache eher unbekannt ist. Im britischen Englisch dagegen kennt man nicht nur den Sport (Rugby) sondern auch die ursprüngliche, weitaus ältere Bedeutung des Wortes: Scrum wird zwar im Regelfall mit "Gedränge" übersetzt, der tatsächlichen Bedeutung kämen aber "Tumult" oder "chaotischer Menschenhaufen" näher. Über "Media Scrums" (Gruppen von Reportern, die einen Politiker bedrängen) heisst es zum Beispiel: "The disorganization and pressure of the scrum makes it notorious". Dass viele britische Manager derartige Zustände ungern in ihrem Unternehmen sehen möchten ist nachvollziehbar. Gegebenenfalls hilft es, hier einfach von Agile Software Development zu sprechen.

Ein wesentlich peinlicheres Beispiel ist das Grooming, hinter dem sich zunächst einmal nichts anderes verbirgt als ein Meeting in dem die User Stories der nächsten Sprints durchgesehen und optimiert werden. Dass britische Teammitglieder auf diesen Begriff trotzdem häufig sehr ungehalten reagieren liegt in einer umgangssprachlichen Bedeutung, die so in kaum einem Wörterbuch zu finden ist: Unter Grooming versteht man dort auch das Verführen kleiner Kinder durch pädophile Sexualstraftäter. Da ich die Erfahrung gemacht habe, dass selbst das Ansprechen dieses Themas dem einen oder anderen sehr unangenehm sein kann, würde ich grundsätzlich empfehlen in Teams mit englischen oder schottischen Mitgliedern nicht vom Grooming zu sprechen sondern den unverfänglicheren Begriff des Backlog Refinement zu benutzen.

Mittwoch, 7. Oktober 2015

Brauchbare Illegalität und Agilität

Bild: Pixabay/Foto-Rabe - Lizenz

Zu den in meinem Bekanntenkreis am meisten diskutierten Artikeln der letzten Tage gehört Nützliche Kriminalität aus der letzten Frankfurter Allgemeinen Sonntagszeitung. Die beiden Autoren, Rainer Hank und Georg Meck, versuchen den VW-Abgasskandal von einer neuen Seite zu betrachten und führen ihn auf ein Systemversagen innerhalb des Konzerns zurück. Demnach könnte es so gewesen sein, dass Mitarbeiter gegen die Abgasvorschriften verstießen weil sie glaubten, dem Unternehmen nützlich sein zu können indem sie Abläufe verkürzten und so Geld sparten. Hank und Meck berufen sich dabei ausdrücklich auf Niklas Luhmann, der diese Gedanken vorformuliert haben soll.

Nun fürchte ich, dass die beiden Luhmann entweder missverstanden haben oder dass ihr Artikel von der Redaktion zusammengekürzt wurde, denn in seinem Werk Funktionen und Folgen formaler Organisation ist dieses Phänomen der brauchbaren Illegalität1 etwas weitreichender dargestellt. Es tritt demnach vor allem dort auf, wo die Anweisungen des Managements an die Mitarbeiter in sich so widersprüchlich sind, dass sie gar nicht erfüllt werden können. Da die Nichterfüllung aber mit Strafe verbunden ist, greifen die Mitarbeiter praktisch in Notwehr zu unerlaubten Methoden um die Ziele doch zu erreichen. Da das zumindest auf der Ausführungsebene allgemein bekannt ist, entsteht etwas, was Luhmann die informelle Organisation nennt, praktisch ein Geheimbund, der ein nicht (mehr) funktionsfähiges System durch Regelverstöße und darauf aufbauende (Schein)Erfolge am Leben hält. Genau das könnte bei VW passiert sein.2

Zurück zu meinem Bekanntenkreis. Was dort auf allgemeinen Unglauben gestoßen ist, ist die Möglichkeit, dass das Management tatsächlich in sich widersprüchliche Befehle geben könnte. Warum sollte es das tun, oder bei anderer Auslegung - wie könnte es sein, dass es diese Widersprüchlichkeit selbst nicht bemerkt? Die Antwort darauf liegt wieder bei Luhmann selbst. Er sieht diese Widersprüchlichkeit als Folge des Anpassungsdrucks, den eine sich ständig ändernde Umgebung (z.B. durch neue Umweltvorschriften) auf ein zu Beginn noch funktionierendes System ausübt. Ursprünglich sinnvolle Vorgehensweisen funktionieren plötzlich nicht mehr, was das Management aber nicht nachvollziehen kann (warum soll heute falsch sein was gestern richtig war?). Es erwartet weiterhin, dass die "bewährten" Methoden die gleichen Ergebnisse bringen wie früher und zwingt die Mitarbeiter so in die oben genannten informellen, bzw. illegalen Verhaltensweisen.

Was das alles mit Agilität zu tun hat? Nun, mit ihr kann man die Wahrscheinlichkeit, dass diese Situation überhaupt entsteht, deutlich herabsetzen. Die agilen Methoden gehen in ihren Grundannahmen davon aus, dass sich Umgebungsfaktoren regelmässig ändern und dass man beweglich (agil) darauf reagieren muss wenn man erfolgreich sein will. Ein regelmässiges Inspect and Adapt sorgt deshalb frühzeitig dafür, dass sich Organisationen und Erwartungshaltungen den geänderten Rahmenbedingungen anpassen. Infolgedessen versucht das Management nicht mehr die aktuellen Probleme mit überholten Methoden zu lösen, seine Anweisungen sind nicht mehr (oder zumindest weniger) widersprüchlich und die Mitarbeiter werden nicht mehr in informelle Strukturen und brauchbare Illegalität getrieben.

So hätte es sein können. Aber im Fall VW ist es für derartige Überlegungen wohl zu spät.


1Dass in dem Artikel von Nützlicher Kriminalität und Nützlicher Illegalität die Rede ist, dürfte Folge einer fehlerhaften Rückübersetzung aus dem Englischen sein.
2Gemeint ist damit an dieser Stelle nicht der Gesamtkonzern sondern die für die Abgaswerte zuständige Entwicklungsabteilung.

Montag, 5. Oktober 2015

Der Scroduct Ownster

Bild: Wikimedia Commons / Wilhelm von Kaulbach - Public Domain
Zu den einschneidendsten Änderungen die Scrum in das Projektmanagement gebracht hat gehört die Teilung des bisherigen Projektleiters oder Teamleiters in zwei Positionen, den Scrum Master und den Product Owner. Der Grund für diese Aufteilung war die Erkenntnis, dass die Konzentration aller Verantwortlichkeit auf eine Person sich zu häufig als dysfunktional erwiesen hat, da diese dann zwei sich widersprechende Rollen erfüllen sollte: Zum einen sollte der Projektleiter dafür sorgen, dass die Teammitglieder sich an die Projektmethodik hielten, also an Prince2, PMP, ITIL oder andere. Zum anderen wurde von ihm aber auch erwartet, dass er neue Produkte oder Features möglichst schnell an den Markt brachte, damit mit ihnen Geld verdient werden konnte.

Wenn nun gegen Ende des Projekts oder eines Projektabschnitts ein (scheinbar) fertiges Produkt vorlag, die Methodik aber noch Quality Gates oder Dokumentationen vorsah, entstand ein Intra-Rollen-Konflikt - sollte die Vermarktung des Produktes jetzt warten bis die Prozesse sauber abgeschlossen waren, oder waren die Prozesse verzichtbar wenn der Markt mit schnellem Geld lockte? In der Theorie wurde zwar verlangt eine Lösung zu finden die beide Aspekte berücksichtigte, in der Realität war es aber anders - fast immer entschieden sich die Projektmanager für eine der beiden Seiten, vernachlässigten die andere und fügten dem Projekt und Produkt so Schaden zu. Mal wurden von den Teams möglichst viele neue Produkte und Funktionen in möglichst kurzer Zeit verlangt (Featuritis, bzw. Feature Creep), mal wurde das einmal beschlossene Vorgehen in Beton gegossen und jede Anpassung abgelehnt (Methodismus). Der eine Fall führt zu Bugs in der Produktion, der andere zu verspäteter Auslieferung.

Die Teilung in Scrum Master und Product Owner beseitigt diesen Intra-Rollen-Konflikt: Der Product Owner ist nur dafür verantwortlich die Anforderungen so in das Team zu steuern, dass möglichst viele Features möglichst schnell entstehen können, der Scrum Master sorgt nur für die Einhaltung der vorgegebenen Regeln und damit für Prozessqualität (und höchstens indirekt für Produktqualität). Sollte beides im Widerspruch stehen kann nicht die eine Seite die andere unterdrücken (alleine deshalb nicht weil keiner der beiden dem Team Befehle geben darf), sondern sie müssen sich auf einen gangbaren Mittelweg einigen.1 Leider wird dieser Hintergrund von vielen Managern nicht verstanden, weshalb eine häufige "Effizienzsteigerungsmassnahme" die ist, die Positionen des Scrum Masters und des Product Owners wieder zusammenzulegen. Der damit einhergehende, bzw. zurückkehrende Intra-Rollen-Konflikt ist in einem der großartigen "The wrong way to do agile"-Videos von Atlassian sowohl visuell als auch semantisch passend dargestellt worden: das Ergebnis ist der "Scroduct Ownster", ein kaum noch arbeitsfähiges Mischwesen.


Abschreckend genug ist dieses Bild aber wohl nicht, denn noch immer liest man wieder und wieder Stellenausschreibungen wie diese hier aus der letzten Woche, in der sich der folgende Satz findet:
Es handelt sich bei dieser Position um eine interne Produktmanager-Position (mit einer Zusammenlegung der Rollen Scrum Product Owner und Scrum Master).
Ich wage die Voraussage, dass dieses Projekt relativ schnell im Murks enden wird. Aber das müssen die dort zuständigen Leute dann vor sich selbst verantworten.


1Natürlich könnte man an dieser Stelle aufschreien und klar machen, dass die Scrum-Regeln nie geändert werden dürfen. Das wäre dann aber auch nur wieder Methodismus. Klar ist aber, dass es einen Kernbereich gibt, der vor "Anpassungen" geschützt sein sollte.