Mittwoch, 29. April 2015

Scrum Master oder Team Coach?

Bild: State Library of New South Wales - CC BY 4.0
Unter Scrum Mastern und Scrum Practicioners dürfte es eines der absoluten Dauerbrenner-Themen sein: Wie bestimmend darf ein Scrum Master seinem Team gegenüber auftreten? Ich erinnere mich an mehrere Diskussionen zu dem Thema auf Meetups in Köln, Hannover und dem Ruhrgebiet, bei denen die Antwort immer die gleiche war - wenig bis gar nicht. Praktisch jeder der anwesenden Scrum Master gibt bei derartigen Gelegenheiten fast schon reflexartig eine Anekdote zum Besten, wie ein Team dem er besonders viel Freiheit gelassen hat sich aussergewöhnlich gut enwickelte, hervorragend performte und sich zu höchsten Graden der Selbstorganisation aufgeschwungen hat. Häufig sind diese Erzählungen verbunden mit der Aussage, gar nicht als Scrum Master aufgetreten zu sein sondern nur als Team Coach, um selbst das im Namen Scrum Master implizit mitschwingende Hierarchiegefühl (wie in Master and Servant) gar nicht erst aufkommen zu lassen. Das mag auch alles so gewesen sein, trotzdem ist es meiner Meinung nach nur die halbe Wahrheit. Die andere Hälfte ist die, dass man auch die entsprechenden Teammitglieder und das entsprechende Teamumfeld für eine solche Erfolgsgeschichte braucht. Wenn man diese Faktoren nicht hat kann die Situation schnell anders aussehen.

Auch diese Geschichte können viele Scrum Master nämlich erzählen: Teams die sich von Beginn an gegen jede Form von agilen Frameworks gesträubt haben, sie nicht einmal ausprobieren oder diskutieren wollten. Gründe dafür gibt es viele - die Angst vor der Verantwortung (bzw. der damit verbundenen Mehrarbeit), die Sorge, für ausbleibende Erfolge verantwortlich gemacht zu werden, der im Hintergrund sein Unheil treibende Abteilungsleiter, dogmatischer Methodismus, schlechte Erfahrungen mit (angeblich) agilen Projekten, eine generelle Frustration und Desillusionierung durch jahrzehntelanges Leiden in kafkaesken Konzernstrukturen, etc., etc., etc. Die Liste ließe sich endlos erweitern. Das alles bedeutet zwar keineswegs, dass Agilität mit solchen Kollegen unmöglich ist - wenn ihnen langsam bewusst wird, dass die Ergebnisse besser werden, die Belastung abnimmt und dass ihnen keiner bei Fehlern den Kopf abreißt, dann kommt die Bereitschaft meistens auch bei ihnen auf1. Häufig muss aber zuerst eine initiale Verweigerungshaltung überwunden werden. Hier kann ein eher bestimmender Scrum Master sinnvoll sein. [Edit: mehr zu den Risiken die mit einem bestimmenden Scrum Master verbunden sind gibt es hier]

Man sollte nur wissen - wann ist welcher der beiden Typen (Scrum Master oder Team Coach) der Richtige für das Team? Ich glaube, dass sich diese Frage mit dem bekannten Scrum Master Reifegrad-Modell (Scrum Master Maturity Model) beantworten lässt, das folgendermassen aussieht:
Inspiriert von Angel Medinilla: Developing Scrum Masters
Zugegeben, auf den ersten Blick hält sich der Erkenntnisgewinn in Grenzen. Der Team Coach wird gleichgesetzt mit dem Scrum Master der höchsten Stufe, für die niedrigste Stufe wird der Begriff des "Scrum Master-Imitators" hinzugefügt2, in der Mitte bleibt die Bezeichnung gleich. Es wird zwar genauer ausgeführt was er tut, aber nicht wann welches Verhalten sinnvoll ist. Was an dieser Stelle die entscheidende und noch fehlende Zusatzinformation ist, ist die, dass jeder Reifegradstufe eines Scrum Masters/Team Coach auch eine korrespondierende Stufe des Scrum Teams gegenübersteht. Wie oben gesagt - für eine agile Erfolgsgeschichte braucht es ein Team das Scrum vorantreiben will und auch weiß wie es geht. Umgekehrt werden unwissende und unwillige Teams es ihrem Scrum Master schwer machen zu höheren Stufen emporzusteigen. Ein aus dem Scrum Master Reifegrad-Modell abgeleitetes Scrum Team Reifegrad-Modell sähe demnach etwa so aus:
Inspiriert von Angel Medinilla: Developing Scrum Masters
An dieser Stelle wird auch die Zuordnung von Scrum Master/Team Coach zu den Reifegrad-Stufen klar. Je selbstständiger und in Agilität erfahrener das Team, desto besser kann der Scrum Master werden, bis hin zur hoch über den Dingen des Alltags schwebenden Coach-Rolle. Und umgekehrt - je unerfahrener das Team, desto anleitender muss der Scrum Master bei Bedarf agieren, wenn nicht gewollt wird, dass die missverstandene Methodik aus scheinbarem Selbstschutz ausgehöhlt und unbrauchbar wird. Das führt zwar dazu dass er seine Rolle zunächst schlecht (weil zu bestimmend) ausübt, im Gegensatz zu klassischen Command & Control-Ansätzen aber mit der klaren Absicht sich zurückzuziehen sobald sich Mechanismen der Selbstorganisation etabliert haben. 

Letzteres wird übrigens nicht überall so gesehen, ich kenne auch (anerkannt gute) Scrum Practitioner die der Meinung sind, auch unreife und explizit unwillige Teammitglieder durch sanftes Coachen verbessern zu können. Aus meiner Erfahrung heraus habe ich daran allerdings starke Zweifel, lasse mich aber gerne durch Beispiele vom Gegenteil überzeugen. Der Vollständigkeit halber sei auch noch erwähnt, dass die Unterscheidung zwischen zurückhaltendem Team Coach und dominantem Scrum Master (noch) kein allgemeiner Sprachgebrauch ist, man findet durchaus auch abweichende Definitionen. Vom Gefühl her3 würde ich allerdings sagen, dass sich die hier vorgestellte Definition langsam verbreitet.


Nachtrag 27.04.2020:
Siehe auch: Scrum Master oder Team Coach? (revisited)


1Voraussetzung dafür ist natürlich, dass es sich nicht um totale Menschenfeinde handelt und dass sie in einem Unternehmen arbeiten das Agilität zulässt.
2Bisher noch nicht erwähnt, da es sich um keinen erstrebenswerten Status handelt.
3Ich weiß, keine Statistische Relevanz. Aber trotzdem.

Donnerstag, 23. April 2015

Transparenz ist etwas anderes als Kontrolle (und der Spiegel ist ein Käseblatt)

Bild: Pixabay / Bykst - Lizenz
Vor etwa 10 Jahren habe ich aufgehört den Spiegel zu lesen. Gründe dafür gab es einige: Den überheblichen Besserwisser-Ton, die länglichen Artikel, deren Umfang in keinem Vehältnis zum Inhalt steht, die fast schon zwanghafte Angewohnheit auch die geringste Kleinigkeit zum Skandal hochzustilisieren. Vor allem aber die immer deutlicher zu Tage tretende Modernisierungs- und Technikfeindlichkeit. Von den Computerspielen bis zu den Suchmaschinen, von Social Media bis hin zur Augmented Reality - alles doof, alles gefährlich, alles macht dumm, alles führt in eine kapitalistisch dominierte Überwachungs- und Ausbeutungsgesellschaft. Aber okay, es muss mir ja auch nicht gefallen. Wenn sich das Sturmgeschütz der Demokratie unbedingt zur Klagemauer der Maschinenstürmer entwickeln will - bitte. Wenn es dafür einen Markt gibt soll es mir recht sein. Ich nehme dieses Heft seitdem nur noch zur Kenntnis wenn es durch irgendetwas in meine Timeline gespült wird. So wie gestern.

Im Artikel Die neue soziale Frage geht mal wieder die Welt unter. Der Sozialstaat wird durch "die Digitalisierung" unterlaufen, Menschen werden ausgebeutet, Arbeitnehmer entrechtet. Mittendrin: eine Firma die es geschafft hat, dass ihre Mitarbeiter sich selber in eine Art selbstgezimmerten orwellschen Überwachungsapparat begeben. Jeder muss dokumentieren was er tut, sobald er es nicht schafft steht er am Pranger. Die Kollegen werden "online beobachtet", es herrscht "volle Kontrolle". Um Gottes Willen!! Was hier beschrieben wird ist aber keineswegs irgendeine Wahrheit gewordene Dystopie, was hier beschrieben wird ist agiles Arbeiten, ist Scrum. Und das wird hier böswillig verzerrend dargestellt. An dieser Stelle zwei Klarstellungen: Ich konzentriere mich im Folgenden auf diesen einen Abschnitt (S.60), in dem die Agilität dämonisiert wird. Den Rest kann aufdröseln wer will. Und ich kenne die betroffene Firma nicht. Was ich kenne ist Scrum, ist Agile. Dazu ein paar Sätze.

Zunächst: Scrum bedeutet, dass die Teams sich selbst organisieren. Es gibt in dieser Methode eben nicht mehr den von oben herunterregierenden Abteilungsleiter oder Geschäftsführer; das Team stellt sich täglich zusammen, berichtet sich gegenseitig vom aktuellen Arbeitsfortschritt und geht selbstbestimmt die nächsten Aufgabenpakete an. Natürlich ist das nur dann möglich, wenn jeder weiß was bereits erledigt ist und was noch zu tun ist. Durch Transparenz eben. Wie sonst soll man verhindern, das manche Arbeiten doppelt und manche gar nicht erledigt werden?

Des weiteren: Scrum bedeutet ebenfalls, dass man den Kunden von Beginn an einbindet. Ihm wird nicht mehr ganz zum Schluß ein fertiges Produkt vorgesetzt, das während der Erstellung von ihm abgeschirmt wurde, und das vielleicht gar nicht dem entspricht was er eigentlich wollte. Stattdessen kann er frühzeitig sagen "Ja, so habe ich mir das vorgestellt" oder "Nein, da habt Ihr mich falsch verstanden". Gegebenenfalls kann er sogar Änderungswünsche anbringen, wenn er merkt, dass es in der Realität nicht ganz so gut aussieht wie er es sich vorher gedacht hat. Wie sonst soll ein frühes und konstruktives Feedback möglich sein?

Für den Spiegel ist das trotzdem alles verdächtig. Offenheit, Vertrauen, Transparenz, Zusammenarbeit, konstruktives Feedback und Kritikfähigkeit kommen in dem dort herrschenden Weltbild anscheinend nicht vor, stattdessen wird alles in seine schlimmstmögliche Auslegung verdreht und in ein Untergansszenario ausgehöhlt zusammenbrechender Arbeitnehmerrechte eingebaut. Letztendlich muss man fast froh sein, dass die Begriffe Scrum und Agile hier nicht genannt und damit durch den Schmutz gezogen werden. Differenzierung? Einordnung? Vielleicht sogar ein bisschen Hintergrundinformation? Fehlanzeige.

Das betroffene Unternehmen, Seibert Media, wirft dem Spiegel übrigens vor, dass Aussagen verdreht und sinnentstellend wiedergegeben wurden und dass die journalistische Sorgfalt der bereits im voraus feststehenden Stoßrichtung des Artikels geopfert wurden. Das Traurige daran: Es würde mich weder wundern noch überraschen. Dieses Magazin hat in meinen Augen keine Reputation mehr, die es verlieren könnte.


Zur Stellungname von Seibert Media (incl. einer Dokumentation der entsprechenden Passage des Spiegel-Artikels) geht es hier.

Mittwoch, 22. April 2015

Woher kommt der Name 'Scrum'?

Bild: Wikimedia Commons / Edward Frank Gillette - Public Domain
Die Frage nach der Herkunft dieses Namens ist vermutlich eine der häufigsten die im Rahmen von Scrum-Einführungen gestellt werden, und (erstaunlich genug) kaum einer kann sie beantworten. Selbst langjährige Practitioner zucken oft nur mit den Schultern. Auf der einen Seite ist das nicht weiter schlimm, bei den meisten Begriffen die wir täglich verwenden ist das Verständnis der ursprünglichen Bedeutung irgendwann verlorengegangen. Wem ist z.B. klar, dass das Wort "Projekt" vom leiteinischen proicere, d.h. nach vorne werfen, kommt? Wohl kaum jemandem. Im Falle von Scrum ist es trotzdem etwas merkwürdig, denn seine gegenwärtige Bedeutung als Name eines Produkt-, bzw. Projektmanagement-Vorgehensmodells ist relativ neu. Dass trotzdem kaum jemand die Übersetzung kennt liegt vermutlich daran, dass es sich ursprünglich um einen britisch-englischen Slang-Begriff handelt, der selbst vielen Muttersprachlern unbekannt ist: Scrum bedeutet "Menschenauflauf" oder "Gedränge". So weit, so interessant. Es bleibt die Frage - wie kommt es zu der gegenwärtigen Verwendung?

Um der Antwort näher zu kommen muss man wissen, dass der Begriff Scrum auch einen bestimmten Spielzug im Rugby-Sport bezeichnet, naheliegenderweise einen bei dem die Spieler dicht aneinandergedrängt auf dem Rasen stehen. Wer versuchen will ihn zu verstehen kann die Regeln hier nachlesen, viel einfacher ist es allerdings sich ihn einfach anzusehen. Ich präsentiere: einen Scrum.



Nun ja. So weit, so skurril.Was immer noch unklar ist - wie hat es diese Rauferei um den Ball geschafft namensgebend für ein Management-Framework zu werden? Auch hier hilft eine Geschichte aus einer exotischen Inselnation weiter, diesesmal allerdings nicht aus England sondern aus Japan.

Die Japaner entwickelten in den Jahren nach dem zweiten Weltkrieg das so genannte Lean Management, dessen Ziel die möglichst weitgehende Vermeidung unproduktiver Tätigkeiten ist. Ein nachträglich dazugekommener Aspekt dieser zunächst auf die Industrieproduktion bezogenen Managementlehre sind Maßnahmen die darauf abzielen möglichst schnell auf geänderte Rahmenbedingungen zu reagieren, damit keine Energie mehr in mittlerweile überholte Ziele gesteckt werden muss. Als richtungsweisendes Werk gilt in diesem Zusammenhang ein Artikel mit dem etwas merkwürdigen Namen "The New New Product Development Game", der im Jahr 1986 von zwei Wirtschaftswissenschaftlern namens Hirotaka Takeuchi und Ikujiro Nonaka im Harvard Business Review veröffentlicht wurde (nachzulesen hier). Da die beiden Herren anscheinend Fans des britischen Sports sind nannten sie die hier vorgestellten Vorgehensweisen "Rugby-Approach", was sie folgendermassen begründeten:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method - as in rugby, the ball gets passed within the team as it moves as a unit up the field.

In diesem Artikel taucht auch der Begriff Scrum wieder auf, und zwar in dem Absatz in dem die sechs Bedingungen genannt sind, die laut Takeuchi und Nonaka für den Rugby Approach erfüllt sein müssen: Built-in instability, Self-organizing project teams, Overlapping development phases, Multilearning, Subtle control und Organizational transfer of learning. Sie erscheinen als Aufzählung unter der Überschrift "Moving the Scrum Downfield". Als der Rugby-Approach dann ca. 10 Jahre später von Peter DeGrace und Leslie Hulet Stahl in die IT übertragen und von Jeff Sutherland und Ken Schwaber zu dem heute bekannten Framework weiterentwickelt wurde, benannten sie ihn unter direktem Verweis auf diesen Artikel in Scrum um. Mit ihren eigenen Worten (nachzulesen hier):

We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986), after the SCRUM in rugby -- a tight formation of forwards who bind together in specific positions when a scrumdown is called.

Abgeleitet aus dieser übergreifenden Bedeutung entstand später dann auch das "Daily Scrum", das dadurch doppeldeutig ist: Zum einen ist es das Regelmeeting des gleich heißenden Produkt-, bzw. Projektmanagement-Frameworks, zum anderen ist es ganz im Sinn der ursprünglichen Wortbedeutung das tägliche "Gedränge" des Teams vor dem Sprint Board.

Und damit ist die Frage beantwortet, woher dieser Begriff kommt und was er bedeutet.

Donnerstag, 16. April 2015

Denkanstoss: Wendigkeit (warum Agilität?)

Wieder einmal war gestern Scrumtisch in Köln und wie jedes mal war es sehr angenehm und sehr inspirierend. Was ich diesesmal am interessantesten fand war eine Session von Richard Maasen, in der er einen Ansatz vorstellte, der Business-Seite des Kunden/Unternehmen den Sinn von Agilen Methoden zu vermitteln. Auf der Basis meiner spärlichen Notizen und durch Hinzufügen einiger eigener Gedanken habe ich das folgendermassen visualisiert:
Der zentrale Unterschied zu Richard dürfte die Verwendung des Begriffs "Agilität" sein, der in seinem beruflichen Umfeld so vieldeutig ist, dass er lieber von "Wendigkeit" spricht. In der Mitte steht bei ihm auch nicht die Problemstellung sondern die Wendigkeit selbst als zu erreichendes, bzw. zu optimierendes Ziel. Als Ergänzung habe ich unten Links ausserdem den "klassischen" Projektmanagement-Ansatz dazugeschrieben um die Unterschiede hervorzuheben. Künstlerische Freiheit.

Was aus meiner Sicht der interessante Punkt ist, ist die Definition von Agilität/Wendigkeit als die Durchlaufzeit von der Idee zur Wirkung. Diese Definition hat zwei Vorteile, die sie für die Vermittlung an Business-Leute gut einsetzbar machen: Geringes Abstraktionslevel und einfache Meßbarkeit - genau das ist dort häufig gewollt.

Dienstag, 14. April 2015

10 Gründe, warum es nervt Scrum Master zu sein

Bild: Flickr/Fabio Venni - CC BY-SA 2.0

Kurze Vorbemerkung: Scrum Master zu sein ist großartig! Trotzdem gibt es einzelne, verstreute Momente des Schmerzes. Hier ist eine Auswahl:

1. Du gibst mehr Geld für Büroartikel aus als Du verdienst 

Boardmarker, Filzstifte, Moderationskarten, Heftzwecken, Magnete, Notizblöcke und natürlich Post-Its in allen möglichen Farben - als Scrum Master verbrauchst Du diese Dinge schneller als das PMO sie nachkaufen kann. Also überbrückst Du Engpässe indem Du Dich beim Händler Deiner Wahl selber eindeckst.

Du verbringst gefühlte Stunden mit der Verschönerung der Kanban-Boards und Burndown-Charts, Du willst jede neue Farbe und Form von Post-Its direkt verfügbar haben und verfügst irgendwann über einen Fundus der jeden professionellen Moderationskoffer in den Schatten stellt.

Du rechtfertigst das damit, dass es nur den Zweck hat Dich und Dein Team effektiver zu machen, was oft auch stimmt. Oft aber auch nicht.

2. Wenn Du gute Arbeit machst halten die Leute Dich für überflüssig

Du hast Dein Ziel erreicht und das Team arbeitet selbstorganisiert und selbstverantwortlich. Die Prozesse laufen wie sie sollen, die Velocity ist hoch, alle sind zufrieden. Spätestens jetzt fragt das Management sich, warum es Dich überhaupt bezahlt, schließlich scheint es auch ohne Dich zu gehen.

Dass Du gebraucht wirst wird erst wieder klar wenn das Team es ohne Scrum Master versucht und nach und nach ineffektiver wird, weil es die agilen Prinzipien und Werte kurzfristigen Erfolgen opfert. Wenn Du zurückkommst und ihm zurück in die Spur hilfst wird das zwar honoriert, sobald alles wieder rund läuft wirst Du aber erneut hinterfragt.

Manchmal denkst Du Dir, dass die Leute doch sehen sollen wie sie ohne Dich klarkommen, aber sie alleinzulassen bringst Du doch nicht über Dein Herz.

3. Du verzweifelst an Deinen Mitmenschen

Als Scrum Master weisst Du: es gibt keine effektivere, zielführendere und naheliegendere Arbeitsweise als die Agilität. Entwicklelt in 30 Jahren Best-Practice ist sie nicht nur erprobt und erfolgreich - es ist auch offensichtlich und unbestreitbar, dass es sinnvoll ist sich daran zu halten.

Erstaunlich viele Menschen sind da ganz anderer Meinung, auch in Deinem Projekt und in Deinem Team. Die Entwickler wollen im Daily technische Detaildiskussionen führen, die Tester wollen nicht selbst denken sondern gesagt bekommen was sie tun sollen und das Management verlangt ständig Aufwandsschätzungen in Personentagen.

Von Zeit zu Zeit überkommt Dich das Gefühl, dass Du zwar redest und redest, dass Dich aber keiner versteht.

4. Du siehst auch in Deinem Privatleben überall Optimierungsmöglichkeiten

Ob beim Kücheneinkauf oder beim Sommerfest Deiner Fussballmannschaft, bei der Prüfungsvorbereitung Deiner Kinder oder bei der Gartenarbeit - überall siehst Du Prozesse die man visualisieren, optimieren oder automatisieren kann.

Du malst Flussdiagramme in den Badestrand und auf Restaurantservietten, klebst Post-Its an den Kühlschrank und willst eine Retrospektive des letzten Betriebsausflugs durchführen. Du gehst allen Menschen Deiner Umgebung auf die Nerven.

Und das Schlimmste: Du verstehst nicht warum sie sich aufregen, Du meinst es doch nur gut.

5. Du nimmst die Idee des Servant Leader zu ernst

Irgendwann siehst Du es als Deine Aufgabe an, auch die kleinsten Aufgaben für Dein Team zu übernehmen: Du schreibst und bewegst die Zettel auf dem Board, räumst nach den Meetings den Raum auf, organisierst Getränke und sogar Sitzkissen.

Irgendwann sieht Dein Team es als selbstverständlich an und entwickelt daraus eine Anspruchshaltung. Und wenn Du diese Arbeiten nicht machst macht sie keiner.

Das Perfide daran: Du findest das gar nicht schlimm, Du machst diese Arbeit gerne.

6. Du musst Scrum und Agile ständig erklären und rechtfertigen, selbst wenn es funktioniert

Das Team ist glücklich, die Kunden zufrieden, die Zeitpläne werden eingehalten, die Produktqualität stimmt - alles ist so wie es sein sollte. Dass es dazu gekommen ist liegt daran, dass Scrum endlich verstanden wurde und richtig umgesetzt wird.

Und trotzdem: ständig werden Leute behaupten, dass es mit den alten Wasserfall-Modell genau so gekommen wäre, und das das sogar noch viel, viel besser funktioniert hätte. Und wollen wissen warum man nicht dazu zurückkehrt.

Leb damit, das gehört zu dem Job dazu.

7. Du musst die Leute davon abhalten, ständig die Velocity erhöhen zu wollen

Irgendwann hat sich das Team eingespielt und eine einigermassen gleichbleibende Velocity entwickelt. Das kann bedeuten, dass es in einem Sprint eine Summe von 13 Story Points abliefert, im nächsten 15 und im übernächsten dann 14. Für viele Manager und Projektleiter eine Verschlechterung die nicht sein darf - die Zahl soll permanent steigen!

Dass permanente Steigerungen nicht möglich sind, dass auch Faktoren wie Urlaube und Linienaufgaben Einfluß haben und dass all das keineswegs im Widerspruch zum ständigen Verbesserungsprozess steht, das muss geduldig immer wieder erklärt werden.

Und wenn das nächste mal ein Sprint weniger Storypoints enthält als der davor geht alles von vorne los.

8. Du musst immer wieder klarmachen, dass Retrospektiven wichtig sind

Fast alle Teams neigen dazu, Retrospektiven mit der Zeit für immer weniger wichtig zu halten. Manche meinen, dass "alle wichtigen Probleme mittlerweile gelöst sind", andere sagen, dass sich bei hartnäckigen Impediments "eh nichts ändert" - die Teilnahme erfolgt dann wiederwillig und lustlos.

Dass ein einmal erreichtes Level sich nicht von alleine erhält, das neue Probleme auftauchen können und dass ein langer Atem bei hartnäckigen Schwierigkeiten hilft - das muss mit großer Überzeugungskraft vermittelt werden.

Und trotzdem tauchen in der Retrospektive immer wieder Zettel auf, auf denen steht "Die Retro bringt nichts".

9. Jeder in Deiner Umgebung ist ein Kunstkritiker

Wenn Du überdurchschnittliches Talent für Schönschrift und abstrakte Malerei gehabt hättest wärst Du vermutlich in die Kunst oder Gestaltungs-Branche gegangen und nicht in die IT. Jetzt sind Deine Charts und Diagramme vielleicht etwas krakelig, dafür aber stringent und zielführend.

In fast jedem Team werden sich Menschen finden, die darauf herumreiten, selbst wenn es für das aktuelle Thema völlig irrelevant ist. Häufig sind es gerade diejenigen, die sonst nichts sinnvolles beitragen können.

Mit der Zeit entwickelst Du eine Routine darin, dass gekonnt zu ignorieren.

10. Ungelesene Bücher stapeln sich auf Deinem Tisch

Egal was Du bereits gelesen hast - die Zahl noch ungelesener hochinteressanter Bücher zu den Themen Agile, Scrum, Motivation und Prozessverbesserung ist unendlich lang. Und sie wird durch Neuveröffentlichungen ständig länger.

Viel zu schnell kommt der Punkt an dem Du mit dem Lesen der gekauften, geschenkten und geliehenen Werke nicht mehr nachkommst. Dann liegt im wahrsten Sinne des Wortes totes Wissen auf Deinem Tisch.

Aber irgendwann liest Du sie alle. Irgendwann.

Bonusgrund: Die Leute geben Dir alberne Stellenbezeichnungen

Stumm Master (wenn sie sich "mehr Führung" wünschen), Scrum Diktator (wenn Du sie von Dummheiten abhältst), Fragiler Prinzipienreiter (wenn Du auf die Agilen Prinzipien hinweist), Projektmanager (das tut weh), Scrummer, Scrummie, Scrumling, Scrumdog Millionär oder Ähnliches - die meisten Leute halten sich nicht nur für Kunstkritiker sondern auch für witzig.

Meistens sind sie es nicht, aber zumindest das kann Dir als Scrum Master ja egal sein.


PS:

Nach diesen 10 11 Punkten mag man es kaum glauben, aber Scrum Master zu sein ist ein toller Job. Er bietet Spass an der Arbeit, Erfüllung und nicht zuletzt - genug Material für Listen-Artikel wie den hier.


Inspieriert von The Social Tester: 10 Reasons Why Being A Scrum Master Sucks

Freitag, 10. April 2015

Software Design vs. User Experience (Ein Bild sagt mehr als 1000 Worte)

Grundlegende Probleme der IT, auf den Punkt gebracht durch ein einziges Symbolbild. Großartig!

Bild: Flickr / Francis Chuwa - CC BY-SA 2.0

Mittwoch, 8. April 2015

Cynefin Framework

Grafik: Wikimedia Commons / Edwin Stoop - CC BY SA 4.0

Nachdem ich mittlerweile mehrfach gehört habe, dass das so genannte Cynefin Framework (oder Cynefin-Modell) das nächste große Ding im agilen Projektmanagement werden könnte glaube ich, dass sich ein näherer Blick darauf lohnt. Cynefin - was ist das und was soll das?

Zunächst: es ist kein Vorgehensmodell für die Produktentwicklung selbst. Vielmehr bietet es die Möglichkeit, anstehende Aufgaben, Probleme und Herausforderungen einzuordnen und auf dieser Basis zu entscheiden welche Vorgehensweise die beste ist. Die Einordnung erfolgt dabei in zwei Bereiche, die jeweils in zwei weitere Unterbereiche unterteilt sind. Ein fünfter Unterbereich steht zwischen ihnen in der Mitte. Den Unterbereichen sind verschiedene Handlungsempfehlungen zugeordnet:


  • Chaotisch (Chaotic): Gehört zum ungeordneten Bereich. Beziehung zwischen Ursache und Wirkung bestehen, lassen sich aber nicht identifizieren. Die Handlungsempfehlung ist Handeln - Erkennen - Reagieren, das Ziel ist es, dabei Innovative Praktiken (novel practice) zu entdecken.
  • Komplex (Complex): Gehört zum ungeordneten Bereich. Beziehung zwischen Ursache und Wirkung bestehen, können aber nur im Nachhinein wahrgenommen werden. Durch den Ansatz Ausprobieren - Erkennen - Reagieren können sich funktionierende Handlungsweisen herausbilden, die als Emergente Praktiken (emergent practice) bezeichnet werden.
  • Kompliziert (Complicated): Gehört zum geordneten Bereich. Beziehungen zwischen Ursache und Wirkung existieren, allerdings benötigt man Experten- oder Fachwissen um sie zu erkennen. Vorgehen sollte man dabei nach der Reihenfoge Erkennen - Analysieren - Reagieren. Das angestrebte Ergebnis sind naheliegende, bzw. Gute Praktiken (good practice).  
  • Einfach (Simple, bzw. Obvious): Gehört zum geordneten Bereich. Ursache und Wirkung sind offensichtlich. Die Heransgehensweise ist hier Erkennen - Kategorisieren - Reagieren. Bewährte Praktiken (best practice) sind aus aus vergleichbaren Fällen bekannt und können übertragen werden.
  • Unklar (Disorder): Gehört zu keinem Bereich. Hier werden Aufgaben und Probleme eingeordnet über die man zu wenig weiß um sie einem anderen Unterbereich zuzuordnen zu können.
Diese Aufteilung einer Matrix in vier Quadranten erscheint zunächst vertraut, unterscheidet sich aber fundamental von fast allen anderen derartigen Modellen dadurch, dass es hier keine für alle Bereiche maßgeblichen X-Achsen und Y-Achsen gibt. Zudem gibt es eine Besonderheit bei den Übergängen zwischen den Unterbereichen: Während drei der vier Grenzlinien tendenziell durchlässig sind (Aufgaben und Probleme können sich mit der Zeit zwischen ihnen verlagern) bildet die Grenze zwischen Einfach und Chaotisch eine Rutschbahn oder Abbruchkante - die scheinbare Sicherheit und Übersichtlichkeit des einfachen Quadranten verleitet dazu, aufkommende Veränderungen zu übersehen oder zu ignorieren. Ab einem bestimmten Punkt sind diese dann nicht mehr beherrschbar und die Aufgaben und Probleme rutschen in den chaotischen Bereich ab. Sind sie einmal dort angekommen ist der direkte Rückweg schwierig bis unmöglich, der Erkenntnis- und Verbesserungsprozess führt stattdessen auf einem langen Weg durch die anderen Quadranten hindurch.

Soviel zur Erläuterung, zurück zum Anfang: Cynefin ist kein Vorgehensmodell für die Software-Entwicklung. Vielmehr bietet es die Möglichkeit anstehende Aufgaben, Probleme und Herausforderungen in die gerade erläuterte Matrix einzuordnen und auf dieser Basis zu entscheiden welche Vorgehensweise die beste ist. Welche genau am Ende ausgewählt wird ist dabei bis zu einem gewissen Grad offen (und muss es auch sein, da generische Zuweisungen immer ein Fehlerrisiko darstellen). Eine mögliche Zuordnung wäre aber diese:


  • Prototyping liegt bei chaotischen und komplexen Themen nah, vor allem dort wo man noch weitgehend im Nebel stochert. Mit anderen Worten: Trial an Error.
  • Scrum eignet sich für komplexe und komplizierte Themen, da es Komplexität und Kompliziertheit durch das Herunterbrechen auf kleine und überschaubare Einheiten reduzieren kann.
  • Kanban macht bei mäßig komplizierten und einfachen Themen Sinn, dort wo es darum geht Dinge "abzuarbeiten"
  • Wasserfall ist das klassische Vorgehen bei einfachen Themen. Sobald diese Einfachheit nur scheinbar gegeben ist (was wesentlich häufiger der Fall ist als man denken sollte) tritt aber der erwähnte Rutschbahneffekt ins Chaos ein.
---

Soviel in aller Kürze. Eine Frage bleibt allerdings noch offen: Cynefin - was ist das überhaupt für ein Wort? Nun ja. Es ist walisisch, es wird in etwa "Kähniwwin" ausgesprochen und ist praktisch unübersetzbar. Eine naheliegende Beschreibung wäre die "gefühlte Zugehörigkeit". Dave Snowden, der Schöpfer von Cynefin, ist Waliser.

Mittwoch, 1. April 2015

Warum Scrum ohne Testautomatisierung nicht funktioniert (I)

Bild: Flickr/Thisisseba - CC BY-SA 2.0
 "Was bringt das eigentlich?" Diese Frage habe ich mir in den letzten Jahren erstaunlich oft anhören dürfen, wenn es um das Thema Testautomatisierung ging. Selbst im agilen Projektumfeld gibt es immer wieder Projektleiter, Manager und Entwickler denen nicht klar ist warum man diesen Aufwand betreiben soll. Diese Skepsis ist sogar erklärbar, denn wenn man auf die notwendigen Schritte für die Automatisierung eines Tests schaut, dann erscheint die zu leistende Arbeitsmenge auf den ersten Blick unverhältnismäßig hoch zu sein: die Ermittlung von IDs und Xpathes, das Schreiben der Testskripte, die Parametrisierung der Testdaten, das Gruppieren zu Testsuiten, das Starten und Ausführen dieser Suiten, das Auswerten der Ausführungs-Reports, zuletzt das manuelle Nachtesten der fehlgeschlagenen Tests - all das kostet viel Zeit und damit auch viel Geld. Ich kann mich an einen Manager erinnern, der seinen Unwillen in einem symptomatischen Satz zusammenfasste: "In der gleichen Zeit hat der Tester doch die dreifache Zahl von User Stories manuell getestet." Damit hatte er vollkommen Recht. Und zugleich vollbrachte er damit das Kunststück, die drei zentralen Irrtümer des agilen Testens in einem Satz zusammenzufassen. Schauen wir sie uns an:

Erster Irrtum: Tests muss man immer nur einen Sprint lang durchführen
Zugegeben, ein bisschen verleitet Scrum zu dieser Fehlannahme. Die Software wird in diesem Vorgehen bereits in der Anforderungsphase in kleine, für sich selbst funktionsfähige Bausteine, bzw. User Stories zerlegt, die nach und nach erstellt werden und dann sofort lauffähig (und damit auch vollumfänglich getestet) sein müssen. Wenn diese Komponenten aber abschließend getestet und im besten Fall bereits live gegangen sind, entfällt doch der Bedarf weitere Tests durchzuführen - oder? Nun, nicht ganz. Da zukünftige User Stories das bisher erstellte Gesamtsystem laufend erweitern kann nicht ausgeschlossen werden, dass die bereits fertigen Teile beeinträchtigt oder beschädigt werden. Da Scrum aber verlangt, dass die Anwendung nach jedem Sprint Go Live-bereit ist, muss in jedem Sprint ein vollständiger Regressionstest aller Funktionen stattfinden, selbst wenn diese zu einer User Story gehören, die schon längst abgenommen ist.

Zweiter Irrtum: Regressiontest bedeutet, dass man die Akzeptanztests der User Stories wiederholt
Auch da bedarf es eines genaueren Blicks auf die Details. Es ist eben nicht so, dass die Summe aller Akzeptanztests eine gute Testabdeckung der Software ergibt. Akzeptanztests in ihrer ursprünglichen Form machen nur während des Sprints Sinn, in dem die Story umgesetzt wird, zu der sie gehören. Würde man sie danach eins zu eins in die Regression übernehmen, würden Probleme entstehen: Zum Einen wird die in früheren Stories entstandene Funktionalität oft durch spätere Stories verändert. Ältere Akzeptanztests sind dann nicht mehr zutreffend oder sogar obsolet. Zum anderen können verschiedene User Stories Schnittmengen haben, durch die es zu Akzeptanztests kommt, die sich teilweise auch in anderen Stories wiederfinden. Würde man sie trotzdem alle zu Regressiontests machen, entstünden in den Testsuiten Redundanzen und erhöhter Pflegeaufwand. Um diese Effekte zu vermeiden ist es notwendig, die Akzeptanztests abgeschlossener User Stories zu verwerfen und stattdessen eine auf dem aktuellen Entwicklungsstand beruhende, nach jedem Sprint aktualisierte Regressionstestsuite zu erstellen.

Dritter Irrtum: Regressionstests werden nur am Sprintende durchgeführt
Ein weiterer Irrtum, der auf dem alten Wasserfall- bzw. V-Modell beruht, in dem man noch so vorgegangen ist. In Scrum ist dieses Vorgehen hochriskant: Wenn Tests erst am Sprintende durchgeführt werden, können Fehler auch erst ganz zum Schluss entdeckt werden. Zu dem Zeitpunkt fehlt aber die Zeit um sie wieder zu beheben, die Stories können nicht abgenommen werden, der Sprint scheitert. Im schlimmsten Fall stellt sich heraus, dass man Zeit und Geld verschwendet hat, weil man die Arbeit von Beginn an anders hätte machen müssen. Um dem vorzubeugen ist notwendig, dass die Regressionstests regelmässig, am besten sogar nach jedem Checkin von neuem Code durchgeführt werden.

Betrachtet man diese drei Irrtümer (und ihre Widerlegungen), so ist der Sinn der Testautomatisierung sofort klar: Wenn es notwenig ist die Testsuiten praktisch täglich auszuführen, wenn diese Suiten permanent größer werden und wenn sie ausserdem nach jeder User Story-Abnahme aktualisiert und sofort wieder ausgeführt werden müssen, dann ist das schon nach kurzer Zeit manuell nicht mehr zu leisten. Man hat also die Wahl: entweder man verzichtet auf die vollständige Qualitätssicherung der Software (und verstößt damit gegen eine ganze Reihe agiler Prinzipien), oder man automatisiert.