Mittwoch, 31. August 2016

Kommentierte Links (XVI)

Grafik: Pixabay / Geralt - Lizenz

Ethan Bernstein, John Bunch, Niko Canner, Michael Lee: Beyond the Holocracy Hype

Mal wieder ein Longread. Man lernt hier viel über Holocracy, eine Management-Methode die dort ansetzt wo Scrum aufhört: in den höheren Ebenen mittlerer und größerer Unternehmen. Statt fester Manager-Positionen gibt es hier flexible Rollen, die je nach Bedarf von unterschiedlichen Personen wahrgenommen werden können, wodurch eine Entkoppelung von Entscheidungs- und Umsetzungsebene verhindert wird. Über die bloße Erklärung der Rollen und Prozesse werden aber auch Grenzen aufgezeigt, bis zu dem Punkt an dem Mitarbeiter kündigen weil sie sich in den neuen Strukturen nicht mehr wiederfinden.

Lars Jensen: Ein Blatt wendet sich

Die Washington Post dürfte zur Zeit wohl eines der weltweit spannendsten Medien-Experimente sein. Seit der Übernahme durch den Amazon-Gründer Jeff Bezos wird dort in einer Art gearbeitet die sich in vieler Hinsicht an die agilen Frameworks anlehnt: datengetrieben, mit A/B-Tests, kurzen Feedback-Zyklen und IT-gestützten Prozessen. Von der Realität in den deutschen Redaktionen ist das noch Lichtjahre entfernt, bietet aber einen Blick auf eine Zukunft wie sie auch hier irgendwann eintreten könnte.

Jason Little: Why Agile Breaks Your Organization (Edit: Link ist mittlerweile tot)

Die zentrale These von Jason Little beruht darauf, dass es in großen Unternehmen zwei Organisationsstrukturen gibt: eine offizielle, die in der Theorie besser funktioniert als in der Praxis, und eine inoffizielle, die den Laden am Laufen hält (die brauchbare Illegalität, zu der ich bereits etwas geschrieben habe). Im Rahmen von agilen Transitionen werden meistens aus den bisher informellen Prozessen offizielle, da in ihnen Entscheidungen immer dorthin verlagert werden wo sie in der Praxis Sinn machen. Für das Gesamtunternehmen ist das aus wirtschaftlicher Sicht gut, aus organisatorischer Sicht aber kritisch, da die Dysfunktionalität der offiziellen Prozesse jetzt offensichtlich wird.

Patrik Höglund: Hackable Projects (Code Health)

Unter "Hackable" versteht man bei Google nicht etwa, dass ein Projekt Sicherheitslücken hat, sondern dass es jederzeit leicht modifizierbar und umplanbar ist. Konkreter definiert gilt es aus technischer Sicht als hackable sobald die folgenden Kriterien erfüllt sind:
  • Developing is easy
  • Fast build
  • Good, fast tests
  • Clean code
  • Easy running + debugging
  • One-click rollbacks
Aus diesen Kriterien werden die drei Pfeiler Code Health, Debuggability und Infrastructure abgeleitet, deren Google-Definition in einer Serie von Einträgen erläutert wird. Dieser hier ist der erste und dreht sich folgerichtig um Code Health.

Red Herring: How Zalando Tech Became Berlin’s Hottest Workplace

"Radical Agility" klingt erstmal vielversprechend. Was sich anscheinend bei Zalando dahinter verbirgt ist eine Abschaffung der klassischen Abteilungs-, Bereichs- und Teamleiter mitsamt vieler dahinterstehender Kompetenzen: Teamzusammenstellung und Auswahl der Themen an denen gearbeitet wiird erfolgen jetzt beispielsweise selbstorganisiert auf der untersten Ebene. Ich habe ähnliche Konstellationen bereits erlebt, mitsamt der damit verbundenen Herausforderungen. Sich so aufzustellen ist in vieler Hinsicht schwer, aber auch in vieler Hinsicht lohnenswert.

Montag, 29. August 2016

Scaled Agile: Scrum of Scrums und Communities of Practice

Bild: Wikimedia Commons/Caroline Léna Becker - CC BY 3.0
Zu den häufigsten Problemen auf größeren Scrum-Projekten gehört die übergreifende Koordination zwischen den Entwicklungsteams. Es muss sichergestellt werden, dass Abhängigkeiten berücksichtigt werden, dass redundante Arbeit vermieden wird und dass Erkenntnisse und Erfahrungen ausgetauscht werden. Da die Koordination durch einen oder mehrere Manager zu Hierarchie, Zeitverlust und Ineffizienz führen würde (siehe hier) tauschen die Teams sich direkt aus, in Meetings die meistens unter den Namen "Scrum of Scrums" (SoS) oder "Communitiy of Practice" (CoP) stattfinden.

Scrum of Scrums

Das Scrum of Scrums dient der Identifitierung und Auflösung von Problemen und Abhängigkeiten zwischen den Teams, bzw. zwischen mehreren Teams und Kunden, Stakeholdern oder dem umgebenden Unternehmen. Beispiele wären unklar definierte Schnittstellen oder Architektur-Standards. Ein SoS sollte regelmässig, z.B. einmal pro Woche als 15-minütiges Standup-Meeting stattfinden, teilnehmen sollte ein Vertreter jedes Teams (im Idealfall weder der PO noch der Scrum Master, es kann aber ein Scrum Master als Moderator anwesend sein).1 Um die Arbeit strukturiert und transparent zu halten kann ein Scrum of Scrum ein eigenes Backlog haben, in dem die Aufgaben gesammelt, priorisiert und sequentiell abgearbeitet werden. In diesem Rahmen kann auch mit Sprints und "Aufgaben-Ownern" gearbeitet werden, wenn das für die Beteiligten sinnvoll erscheint.

Community of Practice

Eine Community of Practice hat den gegenseitigen Austausch von Erfahrungen und Best Practices zum Ziel. Da diese sich im Einzelfall sehr stark unterscheiden können sind Format, Dauer und Teilnehmerkreis nicht vorgegeben. Für eine CoP die sich mit Erfahrungswerten zu Meeting-Moderation befasst bietet sich beispielsweise ein Lean Coffee an, für eine die sich mit Programmier-Techniken befasst ein Coding-Dojo, für wieder andere ein Expertenvortrag. Teilnehmen kann jeder der Interesse hat, die hier gelernten Techniken können in die anderen Teams übernommen werden, müssen aber nicht. In vielen Unternehmen werden Communities of Practice auch als Gilden bezeichnet.

Der Expertentipp: SoS und CoP getrennt halten

Ein häufiges Antipattern ist es, diese beiden Koordinations-Meetings zu einem zusammenzulegen um dadurch Zeit zu sparen. Wer das tut hat meistens nicht verstanden, dass Scrum of Scrums und Community of Practice grundlegend verschiedene Konzepte sind, die unterschiedliche Teilnehmer und unterschiedliche Meetingformate erfordern und unterschiedliche Ergebnisse hervorbringen. Derartige Hybrid-Meetings haben ein sehr hohes Dysfunktionalitäts-Risiko, weshalb sie nach Möglichkeit vermieden werden sollten.


1Im den Skalierungsframeworks Scrum@Scale und SAFe ist die Teilnahme am Scrum of Scrums den Scrum Mastern vorbehalten, was ein häufiger Kritikpunkt an ihnen ist

Donnerstag, 25. August 2016

Jede User Story sollte beschreiben welchen Mehrwert sie erzeugt


Über die letzten Jahre habe ich mit einer mittleren zweistelligen Zahl von Product Ownern zusammengearbeitet, mit manchen nur einige Tage, mit anderen länger als ein Jahr. Es waren gute dabei, sehr gute, schlechte und durchschnittliche, aber einen Fehler haben sie früher oder später alle gemacht: das Verfassen einer User Story oder Anforderung aus der nicht hervorging welchen Mehrwert sie erzeugen sollte.

Klassische User Stories sind nach einem einheitlichen Muster aufgebaut: "Als <Person mit Rolle X> möchte ich <Aktion Y durchführen können> um <einen Mehrwert Z zu erhalten>". Bei diesem Vorgehen ist der Mehrwert offensichtlich, er ergibt sich aus dem Zwecksatz am Ende des Story-Titels. Einige meiner Product Owner wollten sich nicht auf dieses Muster einlassen, waren aber bereit die entsprechenden Informationen in die Detail-Felder zu schreiben, was etwa so aussah: Rolle: A, Funktionalität: B, Mehrwert: C. Eine weitere Möglichkeit wendet ein Kollege an mit dem ich gerade zusammenarbeite, indem er seinen Anforderungen einen "Motivations-Satz" hinzufügt: "Um den Microservice X aus dem Monolithen herauslösen zu können muss Voraussetzung Y geschaffen werden". Diese Variante macht vor allem bei Backend-lastigen Aufgaben Sinn. Zuletzt ist in einigen Fällen der Mehrwert so offensichtlich, so dass er nicht gesondert genannt werden muss, etwa im Fall "Optimierung der Seite für den Browser Q". Und hier lauert ein Risiko.

Gerade wenn ein Product Owner mit seinem Team schon seit längerem an einem Thema arbeitet sind das Verständnis untereinander und das Verständnis der Fachlichkeit häufig so gross, dass die Beteiligten glauben, der Mehrweit sei für sie eigentlich immer offensichtlich. Der Zwecksatz, bzw. die Motivation erscheint dann als ein "Schnörkel", den man "auch mal weglassen kann". Am Anfang mag das sogar stimmen, aber sobald sich diese Angewohnheit einmal einschleift sind meistens unangenehme Effekte die Folge. Einer davon kann sein, dass der Scope ausufert und "schon mal Vorarbeiten für eine spätere Story mitgemacht werden", was besonders dann ärgerlich ist wenn diese spätere Story wegpriorisiert oder nochmal umgeschrieben wird. In diesem Fall war die Arbeit umsonst. Auch das Gegenteil kann der Fall sein, etwa wenn "nur ein Minimum Viable Product umgesetzt wird", was zwar die Ressourcen schont, aber ggf. nicht ausrollbar ist weil das neue Feature nicht dem Nutzerführungs-Konzept entspricht. Und zwischen diesen beiden Grenzfällen gibt es noch zahllose Zwischen- und Misch-Typen.

Wenn der Mehrwert in einer der oben genannten Formen spezifiziert ist kann man dagegen ganz anders an die Umsetzung herangehen. Zum einen kann man sich fragen ob der Funktionsumfang für den angestrebten Mehrwert überhaupt ausreichend ist. Beispielsweise ist die Anforderung "ich möchte eine reduzierte mobile Version der Website haben" gegebenenfalls zu unspezifisch, während "ich möchte eine reduzierte mobile Version der Website haben, damit sie auch bei einer Edge-Verbindung in unter fünf Sekunden geladen wird" wesentlich klarer ist. Zum anderen gibt die Nennung des Mehrwertes dem Team ein Gefühl dafür, was im Zweifel weggelassen und nach hinten priorisiert werden kann. Auch hier ein Beispiel: die Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen" lässt nicht erkennen was auf diesen Kacheln abgebildet sein soll; die Versuchung ist groß dort mehr abzubilden als eigentlich nötig. Im Fall der Story "Als Kunde möchte ich Vorschau-Kacheln mit möglichen Ersatzartikeln sehen, damit ich die Preise vergleichen kann" ist die Lage wesentlich klarer. Produktname, Vorschaubild, Preis - mehr braucht es nicht um den angestrebten Mehrwert zu erreichen.

Zuletzt kann auch ein ganz spezieller Fall auftreten: ich habe es auch schon erlebt, dass Product Owner mir gar nicht sagen konnten welchen Mehrwert eine Story mit sich bringt. Die sind mir ehrlich gesagt sogar die liebsten - man kann sie einfach weglassen und kommt dadurch schneller voran als gedacht.

Montag, 22. August 2016

Trost für den 'gescheiterten' Scrum Master

Bild: Flickr/Gage Skidmore - CC BY-SA 2.0
Nicht alle agilen Transitionen sind erfolgreich. Immer wieder kommt es zu Rollbacks Richtung Wasserfall, aus den verschiedensten Gründen: kontrollwütiges Management, Angst vor zu viel Transparenz, Dokumentationsverliebtheit, Bürokratie-Fetischismus, you name it. Am schwierigsten ist ein solcher Fehlschlag fast immer für den Scrum Master (wenn er denn nicht selbst Ursache dafür ist), denn als Change Agent ist es eigentlich seine Aufgabe die Transition voranzutreiben. Wenn ihm das nicht gelingt fühlt es sich häufig wie ein Scheitern an. Ich habe schon mehrfach dazu beigetragen derartig "gescheiterte" Kollegen wieder aufzubauen, indem ich ihnen klar gemacht habe, dass keineswegs "alles umsonst" gewesen ist. Denn selbst wenn ganze Projekte oder Abteilungen zurück ins Command & Control kippen bleibt doch etwas zurück, nämlich in den Köpfen der Mitarbeiter.

Wer jemals in einem auch nur halbwegs vernünftig umgesetzten Scrum-Umfeld gearbeitet hat, der hat Vieles kennengelernt was traditionell geführte Firmen viel zu selten bieten: selbstbestimmtes und angstfreies Arbeiten, Focus auf Produktentwicklung statt auf Einhaltung von Vorschriften, Respekt vor Kunden und Kollegen, Offenheit, Transparenz sowie die Bereitschaft Fehler einzugestehen und zu korrigieren. Wer einmal Teil einer solchen Welt war wird immer danach streben sie erneut wahr werden zu lassen, wird sinnlose Vorschriften und Prozesse in Frage stellen, Mut und Ehrlichkeit einfordern und zur Not mit den Füssen abstimmen und sich nach einem besseren Job umsehen - in Zeiten des Fachkräftemangels ein starkes Druckmittel. Allein dieses Mindset geweckt und gefördert zu haben ist ein Erfolg, denn in je mehr Köpfen es sich befindet, desto stärker wird die Transition vorangetrieben, und zwar in ganzen Branchen, nicht nur in einzelnen Projekten.

An aufbauende Worte dieser Art habe ich am Wochenende denken müssen. Zum Hintergrund: in den USA ist letzte Woche eine der vermutlich gesellschaftlich wichtigsten Fernsehsendungen wegen schlechten Quoten abgesetzt worden: die Nightly Show with Larry Wilmore - eine Sendung die die Diskussion über Ungleichheit und Diskriminierung in den Mittelpunkt des öffentlichen Diskurses brachte. In ihrer letzten Ausgabe trat der Satiriker und Aktivist Jon Stewart auf, der genau den oben genannten Aspekt betonte: wer es geschafft hat ein relevantes Thema auf die öffentliche Agenda zu setzen der ist erfolgreich gewesen, selbst dann wenn er sich aufgrund eines Rückschlages ein neues Forum suchen muss. Denn auch ohne ihn wird die öffentliche Debatte weitergehen und weitere Veränderungen und Verbesserungen anstossen. Da ich Stewarts Worte mehr als passend finde möchte ich sie hier wiedergeben:
"Did you resonate with an audience? I would say not only that, but in an important way, in a way that you don't realize yet and won't reveal itself for years to come, and it's this: You started a conversation that was not on television when you began. And you worked with a group of people who you invited to that conversation to collaborate with you, to sharpen that conversation, and what you don't realize is, you walk out of this room, and that conversation doesn't end. And all the people that you worked with are gonna take what they learned here and what they learned from you and the beautiful experience that they had, and you're going to start seeing them doing things in the business as well… you're going to watch that flourish, and that's gonna have you on it."
Man muss nur das "on television" durch "in the industry" ersetzen und hat die passende Trostrede für jeden Scrum Master der gerade das Gefühl hat gescheitert zu sein. Er ist es nicht, denn er hat zur Entstehung von etwas beigetragen das größer ist als er es selbst ahnt und länger anhalten wird als er zu hoffen wagt.
[/Pathos off]

Donnerstag, 18. August 2016

Warum eine hundertprozentige Auslastung schlecht ist


Eigentlich sollte man denken, dass es (zumindest aus Arbeitgebersicht) etwas Gutes ist wenn Mitarbeiter zu hundert Prozent ausgelastet sind. Keine unproduktiv verbrachte Arbeitszeit, kein untätiges Herumsitzen, kein gelangweiltes Surfen im Internet. Für viele Manager ist es eines ihrer Hauptziele, dass sie ihren Leuten soviel Arbeit zuweisen, dass die durchgehend etwas zu tun haben. Das Problem: damit begehen sie einen schweren Fehler. Und der lässt sich an einem anschaulichen Beispiel erklären.

Das oben zu sehende Display hängt im Bürgeramt der Stadt Bonn, das unter Anderem für Ausweisangelegenheiten oder die An- und Abmeldung von Autos zuständig ist. Um einen Termin zu bekommen kann man sich online anmelden und bekommt eine Vorgangsnummer und eine Uhrzeit zugemailt zu der man erwartet wird. Durch die Einblendungen auf dem Display wird man zu dieser Zeit sofort zu einem Schalter geleitet, an dem man seinen Behördengang erledigen kann. Ein zunächst unscheinbares Detail dieses Vorgangs ist, dass die Vorgangsnummer chronologisch hochgezählt wird. Die hier zu sehenden Nummern die mit Zwei-, Drei- oder Viertausend beginnen wurden mehrere Tage im voraus vergeben, die mit einer Sieben am Beginn aber erst vor wenigen Minuten, maximal vor wenigen Stunden. Es stellt sich die Frage: warum hat man diese Zeiträume so lange freigelassen? Wäre es nicht effizienter gewesen sie von Beginn an zu verplanen, so dass die Mitarbeiter auch ganz sicher ausgelastet sind?

Nun, nicht ganz. Stellen wir uns vor, dass bei vollständiger Verplanung die Bearbeitung eines Vorgangs länger dauert als gedacht, sagen wir 10 Minuten länger. Und nehmen wir an, dass der danach sich genauso in die Länge zieht. Die Folge wäre eine Verspätung von 20 Minuten, um die sich alle folgenden Vorgänge verschieben. Deswegen sind die nächsten Kunden verärgert und sie beschweren sich zunächst ausgiebig. Dadurch dauern auch ihre Fälle länger, die Verzögerung wächst und am Ende des Tages beträgt sie mehr als eine Stunde. Wer die letzten Bearbeitungszeiträume zugewiesen bekommen hat kann dann nicht mehr bedient werden und er muss am nächsten Tag wiederkommen, der dadurch gleich mit ungeplanter Arbeit und dadurch mit verspäteter Abarbeitung der geplanten Aufgaben beginnt. Und so geht es immer weiter.

Derartige Zustände sind natürlich unerwünscht, weshalb vorgegangen wird wie oben beschrieben: ein bestimmter Prozentsatz der Bearbeitungszeiträume bleibt bewusst unverplant. Wenn sich Verspätungen aufstauen können sie als Puffer genutzt werden um den Verzug aufzufangen, und wenn nicht können sie an kurzfristig aufgetauchte Kunden vergeben werden (die man bei vollständiger Verplanung wegschicken müsste). Auch der umgekehrte Fall ist mit diesem Modell möglich: wenn mehrere Bearbeitungen schneller erledigt sind als gedacht lässt sich nachträglich noch ein weiterer Kunde in die Warteschleife aufnehmen und bedienen. Man sieht - dadurch, dass die Sachbearbeiter nicht zu hundert Prozent verplant wurden sind sie in der Lage wesentlich flexibler auf das tagesaktuelle Arbeitspensum zu reagieren, ohne dass dadurch Verspätungen entstehen.

Was hier am Beispiel des bonner Bürgeramts beschrieben wird gilt natürlich auch für jede andere Art der Arbeit. Egal ob in einem Bauvorhaben, auf einem Softwareprojekt oder in einem sonstigen Unternehmen - zu ungeahnten Aufwänden kann es immer kommen. Und wenn man in solchen Momenten keinen Puffer zur Verfügung hat baut sich eine Bugwelle an unerledigter Arbeit auf die man ewig vor sich herschiebt.

Natürlich kann es bei dem Einplanen solcher Puffer dazu kommen, dass es ab und zu zu Phasen des Leerlaufs kommt. Das ist unschön, wird sich aber nie ganz vermeiden lassen. In der Gesamtbetrachtung sollte aber klar sein, dass das um ein vielfaches besser ist als das Auftürmen von immer neuen Verspätungen, die irgendwann nur noch mit Überstunden und Wochenendarbeit zu bewältigen sind. Übermüdete und frustrierte Mitarbeiter führen nämlich zu weiteren nachteiligen Effekten (aber das wäre dann ein Thema für sich).

Montag, 15. August 2016

Ein Bild sagt mehr als 1000 Worte (XII)


Donnerstag, 11. August 2016

Agilität durch Job Hopper

Bild: Wikimedia Commons/Brussels Airport - CC BY-SA 2.0
Ich habe mal wieder einen Artikel für das IT-Freelancer Magazin verfasst: Warum meine Kunden davon profitieren, dass ich nicht nur für sie arbeite. Verkürzt gesagt geht es dort darum, dass jemand der für mehr als ein Unternehmen arbeitet in ganz anderer Weise zur gemeinsamen Wertschöpfung beitragen kann als jemand der Vollzeit vor Ort ist. Neue Methoden, andere Programmiersprachen, alternative Tools und vieles mehr würden für viele interne Mitarbeiter nur schwer zugänglich sein, jemand der bei einem zweiten Kunden unterwegs ist erlebt sie dort ständig live in Aktion. Auch "alternativlose" Entscheidungen lassen sich ganz anders hinterfragen wenn man belegen kann dass die angeblich nicht vorhandenen Alternativen an einem anderen Ort existieren und erfolgreich umgesetzt werden. Das Einbinden von Freelancern, Consultants und sonstigen "Job-Hoppern" kann also für frische Ideen, neue Blickwinkel und neue Lösungsansätze sogen. Und: für mehr Agilität.

Im Grunde ist auch das relativ einfach: das in agilen Methoden vorgesehene Inspect & Adapt bedeutet nichts anderes, als dass permanent nach neuen Wegen gesucht wird effizienter, einfacher, billiger oder schneller ans Ziel zu kommen. Neues soll ausprobiert werden, Experimente gewagt, Hypothesen validiert. Das setzt allerdings voraus, dass man überhaupt von diesen neuen Möglichkeiten weiss. Ein simples Beispiel: ein Team aus introvertierten Eigenbrötlern kann möglicherweise in ungeahnter Weise zu besserer Zusammenarbeit gebracht werden indem man es zu Mob Programming oder auch nur zu Mob Code Reviews überredet. Und nicht nur die Zusammenarbeit kann sich so verbessern - in diesem Fall kann auch die berühmte Schwarmintelligenz zum Tragen kommen, wordurch das Produkt schneller und in besserer Qualität fertig wird. In den meisten Firmen in denen ich war ist dieses Konzept allerdings völlig unbekannt gewesen. Ohne externen Input (in diesem Fall durch mich) wäre es das auch geblieben.

Natürlich bedeutet das nicht, dass externe Teilzeitkräfte ein Allheilmittel sind. Einiges kann auch dagegen sprechen, etwa die dadurch verursachte Instabilität der Teams, die Abstimmungsprobleme in den Abwesenheitsphasen oder die Errichtung bürokratischer Hürden durch Konzern-Trolle. Auch kann es je nach Rolle Unterschiede geben, z.B. mag es bei einem agile Coach besser funktionieren als bei einem Tester. Das alles wird sich je nach Einzelfall anders lösen lassen, die Gesamtaussage bleibt aber: wer sich Job Hopper in Haus holt kann dadurch die eigene Agilität befördern.

Montag, 8. August 2016

Konzern-Trolle

Bild: Flick/Jared - CC BY 2.0
Eine kleine Geschichte aus einer großen Firma: Ein Entwicklungteam kommt eines Morgens zur Arbeit und erkennt das eigene Büro nicht wieder: Sprint Board, Product Backlog, Burndown Chart, Velocity Chart und Impediment Backlog sind verschwunden, abgehängt von der Betriebsfeuerwehr wegen Verstoß gegen die Brandschutzvorschriften. Alle Proteste helfen nichts, Papierwände sind nicht erlaubt.

Eine zweite Geschichte aus einer großen Firma: Mitten im Sprint taucht ein Compliance Manager im Teamraum auf und fordert, dass ab sofort keine Daily Standups mehr durchgeführt werden. Zu berichten, was man gestern gemacht hat, würde der Betriebsvereinbarung widersprechen, die eine Erfassung der Arbeitsleistung auf Personenebene verbietet. Als darauf hingewiesen wird, dass Scrum dann nicht mehr funktioniert, sorgt der Manager dafür, dass diese Methode ganz verboten wird.

Eine dritte Geschichte aus einer großen Firma: Nach dem Inkrafttreten einer neuen Sicherheitsrichtlinie darf ein Scrum Team nicht mehr in einem Raum zusammensitzen. Ein Teil der Entwickler ist extern, der andere intern, wodurch sie zu verschiedenen Sicherheitsstufen gehören. Die Externen müssen sogar in ein anderes Gebäude umziehen und sich jedes einzelne Meeting im Hauptgebäude gesondert genehmigen lassen.

Diese drei Geschichten (und noch viele weitere mehr) haben sich genau so zugetragen. Sie gehen jeweils zurück auf einen Menschenschlag, für den sich der schöne Begriff des "Konzern-Trolls" eingebürgert hat. Konzern-Trolle sind Personen ausserhalb der eigentlichen Produkt-Entwicklung, die die Verantwortung für irgendeinen Prozess oder die Einhaltung irgendeiner Vorschrift haben. Über diese wird eifrig und eifersüchtig gewacht, und zwar auch dann, wenn anderen Mitarbeitern die Arbeit dadurch erschwert oder unmöglich gemacht wird. "Da kann man nicht machen" heisst es dann immer, "ich habe die Vorschrift nicht gemacht, ich sorge nur für ihre Einhaltung."

Von den normalen Prozessmanagern unterscheiden sich Konzerntrolle übrigens deutlich, und zwar durch ihre explizit destruktive Grundeinstellung. Fast alle Vorschriften auf die sie sich berufen ließen sich nämlich auch deutlich weniger rigoros auslegen, in einer Weise in der sie nicht mehr ein absolutes Hindernis für agiles und/oder produktives Arbeiten wären. Warum diese Menschen so destruktiv geworden sind wäre nochmal ein Thema für sich, aber selbst wenn man es wissen sollte wäre das nur bedingt hilfreich. Sie sind wie sie sind, was macht man jetzt mit ihnen?

Was ich in diesem Zusammenhang häufig als Lösungsansatz erlebt habe, ist die Holzhammer-Methode: das Problem wird zum Vorgesetzten des Trolls eskaliert, der diesen zu sich ins Büro zitiert, um ihm dort einen ordentlichen Anschiss zu verpassen. Kurzfristig ist das eine sehr effektive Lösung, da der Widerstand des Trolls auf diese Art sofort gebrochen werden kann. Nachhaltig ist es allerdings nicht, da er sich bei der nächsten Gelegenheit sofort wieder querstellen wird.

Zielführender finde ich den Ansatz, die Schmerzen dorthin zu verlagern, wo sie entstehen: sobald ein Konzern-Troll mit seiner Paragraphenreiterei beginnt, kann man ihm selbst einen Arbeitsauftrag geben. Er muss dann einen Weg erarbeiten und vorschlagen, der einerseits die Einhaltung seiner Vorschrift ermöglicht, auf der anderen Seite die Arbeitsprozesse der anderen nicht verlangsamen oder ineffektiv machen darf. Und so lange der nicht von allen Beteiligten akzeptiert ist, muss er wieder und wieder überarbeitet und neu vorgelegt werden. Mein Erfahrungswert: jeder Troll, der das einmal mitgemacht hat, wird sich in Zukunft deutlich zurückhalten.

Freitag, 5. August 2016

Agile Testkonzepte

Bild: Public Domain Images/Amanda Mills - CC0 1.0
Zu den wohl unagilsten Dingen die mir auf verschiedenen Projekten begegnet sind gehörten die Testkonzepte mitsamt der damit verbundenen Testmanager. Die gesamten Dokumente waren durchzogen von Wasserfall, V-Modell, Command & Control, Dokumentationszwängen und ähnlichen Management-Relikten des zwanzigsten Jahrhunderts. Bedingt dadurch, dass nicht nur ich derartige Erfahrungen gemacht habe, ist die Idee des Testkonzepts im agilen Umfeld stark beschädigt und wird häufig kategorisch abgelehnt. Das muss allerdings nicht so sein. Ich habe bereits mehrfach als agiler Testmanager gearbeitet und in diesem Rahmen agile Testkonzepte schreiben dürfen - ohne dass das als Widerspruch zum agilen Vorgehen empfunden wurde. Es kommt eben darauf an wie man es macht.

Aber was gehört in ein agiles Testkonzept?

Im Grunde das Gleiche, das man auch in einem "klassischen" Testkonzept erwarten würde. Es sollte dort geklärt werden wer was wann wie und wo testet. Folgende Punkte sollten sich meiner Meinung nach dort finden:
  • Was bedeutet Testen im agilen Umfeld? (so früh und umfassend wie möglich)
  • Wer trägt QA-Verantwortung? (alle)
  • Was wird getestet? (sowohl die neuen Features als auch regressiv alle alten)
  • Wie wird getestet? (möglichst automatisiert)
  • Auf welchen Ebenen wird getestet? (auf allen, in Form einer Testpyramide)
  • Wann beginnt die Testphase?  (ganz am Anfang, bzw. es gibt sie nicht gesondert)
  • Welche Tools werden eingesetzt? (z.B. Jenkins, Fitnesse)
  • Auf welchen Umgebungen wird getestet? (möglichst produktionsnah)
  • Wie lang sind die Testzyklen (idealerweise maximal ein Tag, siehe Punkt 4)
  • Gibt es spezielle Test-Arten? (z.B. Lasttests, Penetrationstests, A/B-Tests)
  • Wie werden die Ergebnisse dokumentiert? (im Idealfall durch das Test-Tool selbst)
Darüber hinaus kann es je nach Einzelfall Sinn machen weitere Bereiche aufzunehmen, zum Beispiel diese:
  • Wie ist die Rolle des Testers definiert? (Teil des Entwicklungsteams)
  • Wie ist die Rolle des Test-/QA-Managers? (Servant Leader)
  • Gibt es Testvorgaben in den Anforderungen? (Ja, Definition of Done und Akzeptanzkriterien)
  • Wer verfasst diese Vorgaben? (der Product Owner zusammen mit dem Team)
  • Werden interne und externe Regulierungsvorgaben erfüllt? (z.B. durch Mapping-Tabelle)
  • Sonstiges (z.B. Test Driven Development)
Derartig aufgebaute Testkonzepte umfassen meiner Erfahrung nach je nach Prosa-Anteil bis zu 20 Seiten, sind also deutlich schlanker als die noch weit verbreiteten "Telefonbücher". Von mir (mit)verfasste derartige Konzepte waren auch bereits Untersuchungsgegenstand von Revisionsabteilungen und haben somit ihre Praxistauglichkeit unter Beweis gestellt. Voraussetzung dafür ist allerdings die Bereitschaft des Managements sich auf agile Vorgehensmodelle einzulassen und nicht auf dem "haben wir immer schon so gemacht" zu bestehen. Das ist zwar nicht immer gegeben, aber in diesen Fällen gibt es ganz andere Probleme als das Testkonzept.

Dienstag, 2. August 2016

Scrum-Checkliste

Bild: Wikimedia Commons/Ceeseven - CC BY-SA 4.0
Egal ob ein Team neu mit Scrum anfängt oder schon lange damit unterwegs ist, es macht Sinn von Zeit zu Zeit zu überprüfen ob man nicht in ganz andere Richtungen abrutscht. Die folgende Checkliste basiert auf einer die ich bei einem meiner Kunden eingesetzt habe. Sie geht an einigen Stellen über den Scrum Guide hinaus um auch die Best Practices zu umfassen, andere Dinge werden nicht erwähnt, da sie dort selbstverständlich waren (z.B. dass technische Lösungswege oder Architektur von den Teams selbst festgelegt werden). Eine gute Einsatzmöglichkeit für so eine Liste ist, sie ausgedruckt ans Team-Board zu hängen. Sobald ein Punkt aus Sicht eines Teammitglieds nicht mehr erfüllt ist kann er ihn rot markieren, wodurch ein Thema für die nächste Retrospektive entsteht. Alternativ kann sie auch in Workshops, Audits oder zu sonstigen Anlässen genutzt werden. Was ich nicht machen würde wäre ein komplettes Besprechen aller Punkte in einiger einzigen Retrospektive, dafür dürfte die Zeit nicht reichen.
  • Das Team besteht aus 3 - 7 Mitgliedern, einem PO und einem Scrum Master 
  • Das Team ist crossfunktional besetzt (FE, BE, QA, UX, etc) 
  • Der PO und der Scrum Master sitzen beim Team 
  • PO und der Scrum Master sind Vollzeit-Jobs 
  • Der PO hält ständigen Kontakt zu seinen Stakeholdern 
  • Der Scrum Master tauscht sich regelmässig mit dem Management aus 
  • Die Regel-Meetings finden statt (Daily Standup, Planning, Retrospektive, Review) 
  • In jedem Sprint finden Backlog Refinements statt 
  • Es existiert ein physisches Sprint-Board 
  • Es existieren ein Burndown-Chart und ein Velocity Chart 
  • Es existieren eine Definition of Ready und eine Definition of Done 
  • Die Sprints haben jeweils ein fachliches Sprint-Ziel
  • Alle Stories im Sprint sind fachlich geschnitten 
  • Alle Stories im Sprint haben fachliche Akzeptanzkriterien 
  • Alle Stories im Sprint sind geschätzt 
  • Alle Stories im Sprint sind Epics zugeordnet 
  • Alle Stories im Sprint sind in Tasks unterteilt 
  • Die Stories im Sprint werden sequenziell abgearbeitet 
  • Die Tasks sind so geschnitten, dass sie in einem Tag erledigt werden können 
  • Es gibt WIP-Limits für die Team-Mitglieder 
  • Im Sprint finden Pairing und gegenseitige Reviews statt, es gibt shared Codeownership 
  • Die Tests ergeben eine Test-Pyramide 
  • Alle Aufwände (auch SoS, Spikes, Bugs, etc.) sind auf dem Board abgebildet 
  • Nach dem Sprint ist jede fertige Story potentially shippable 
  • Nach dem Sprint erzeugt jede fertige Story eine nutzbare Funktionalität 
  • Im Sprint Review sind Stakeholder anwesend 
  • Impediments werden erkannt und bearbeitet 
  • Es wird an technischen Schulden und Bugs gearbeitet 
  • Der PO weiss woran die Entwickler arbeiten 
  • Das Team kennt die Produktvision und den ungefähren Inhalt der nächsten Sprints 
  • Das Team kennt seine Velocity 
  • Es existiert eine Story Map und/oder Road Map 
  • Es gibt ein Scrum of Scrums zur fachlichen Abstimmung zwischen den Teams 
  • Es gibt eine Community of Practice zum Erfahrungsaustausch mit anderen Personen