Montag, 27. November 2017

Ein Kanban-Flickenteppich

Agile und Lean im Konzern - geht das überhaupt? Und wenn ja wie? Diese Fragen stellen sich immer wieder. Dieses Video zeigt, dass es grundsätzlich geht und führt Möglichkeiten und Potentiale vor, aber auch Begrenzungen und Kompromisse. Denn selbst wenn das Gesamtbild beeindruckend ist - ab Minute 29 erkennt man noch das klassische Gantt-Chart- und Langfristplanungs-Projektmanagement.



Offenlegung: Daniel und ich kennen und schätzen uns.

Donnerstag, 23. November 2017

Rollen und Tätigkeiten

Bild: Wikimedia Commons / Andriy Makukha - CC BY-SA 3.0
Zu den Gründen aus denen viele Unternehmen Verschlimmbesserungen an Scrum vornehmen (was häufig zum Harikiri führt) gehört die Sorge, dass komplexe Vorhaben ohne leitende und koordinierende Rollen nicht funktionieren. Die Argumentationen sind immer wieder die gleichen: Es gibt viele übergreifende Tests? Dann braucht man einen Testkoordinator. Es gibt eine komplexe Architektur? Dann braucht man einen Architekten. Es müssen verschiedene Features gleichzeitig Live gehen? Dann braucht man einen Releasemanager. Und so weiter. Die Folge: Mit den Rollen kommen Arbeitsteilung und Bürokratie zurück, alles wird langsamer, die Agilität verschwindet.

Dass diese Entwicklung immer wieder auftritt lässt sich auf einen zentralen Denkfehler zurückführen: Es wird davon ausgegangen, dass Tätigkeiten nicht mehr durchgeführt werden wenn sie keiner Person zugeordnet sind. Würde das zutreffen wäre es tatsächlich ein Problem, allerdings trifft es in richtig implementiertem Scrum nicht zu. Hier werden diese Tätigkeiten auch weiterhin erledigt, nur eben von keinem Koordinator oder Mittelmanager mehr sondern vom Entwicklungsteam selbst, und zwar immer dann wenn es notwendig ist.

"Aber das geht nicht, das können die gar nicht!" wird an dieser Stelle häufig eingewandt. Und hier kommen wir wieder zum korrekt implementierten Scrum zurück: Wenn zu den Aufgaben die erledigt werden müssen z.B. Testmanagement gehört, dann müssen dem Entwicklungsteam Personen zugeordnet sein die das können. Der Scrum Guide ist da eindeutig - Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Auch hier gilt die alte Wahrheit, dass dieses Framework nur funktioniert wenn man es einsetzt wie gedacht.

Und das lässt sich sogar noch weitertreiben: um dem Regelwerk formal Genüge zu tun könnte man einfach den Test- oder Releasemanager in das Team versetzen, wo er zwar seinen Titel verlieren würde, seine Rolle aber weiter ausüben könnte. Zu empfehlen wäre das aber nicht, da er zum einen in nur einem Team kaum ausgelastet wäre und zum anderen der Bus-Faktor bedenklich nach unten gehen würde. Zielführender wäre auch hier die Anwendung des Pull-Prinzips: Die Tätigkeit kommt als Task auf das Board und sobald sie erledigt werden muss kann sie vom jeweils nächsten Teammitglied übernommen werden das eine Aufgabe abgeschlossen hat.

Natürlich muss umgedacht werden wenn so gearbeitet wird. Manager müssen Verantwortung dorthin geben wo sie bisher noch nicht war, Mitarbeiter müssen weitergebildet werden und Entwickler müssen Aufgaben übernehmen die sie vorher noch nicht hatten. Die Vorteile wiegen das aber mehr als auf - Wissensverteilung, Abbau von Flaschenhälsen, ganzheitliche Sicht und Übernahme von Verantwortung sind nämlich genau die Faktoren die ein Team schon nach kurzer Zeit effektiver und effizienter machen.

Montag, 20. November 2017

Agilität, dort wo man sie nicht vermutet (II)

Bild: Pixabay / Skeeze - Lizenz
Einer der wirksamsten Impulse gegen festgefahrenes Denken besteht in der Bemerkung, dass einige der besten Umsetzungen agiler Arbeitsweisen aus dem öffentlichen Dienst kommen. In der Regel führt das sofort zu Widerspruch. Das wäre ja gar nicht möglich. Der Staat sei doch für starre Strukturen und ineffizientes Handeln bekannt, für langsame Prozesse, lange Dienstwege und ähnliches. Wor wären denn da Einheiten die flexibel und reaktionsschnell arbeiten würden? Die gäbe es doch gar nicht.

Allerdings - es gibt sie doch, und sie sind sogar so bekannt, dass jeder sofort etwas mit ihnen anfangen kann. Zu ihnen gehören Feuerwehrwachen, Notaufnahmen und Operationsteams in Krankenhäusern, Flugleitzentralen, militärische Einheiten im Fronteinsatz und viele mehr. In jedem dieser Fälle sind die jeweiligen Teams mit sich schnell ändernden und instabilen Umgebungen konfroniert, in denen es überlebenswichtig sein kann innerhalb kürzester Zeit Entscheidungen zu treffen und sie umzusetzen. Und genau deshalb findet das dort statt.

Das Ziel dieses Gedankenspiels (Agilität im öffentlichen Dienst) sind verschiedene Erkenntnisse. Zum einen: jede organisatorische Einheit kann es schaffen sich agil zu organisieren. Wenn sogar Behörden es schaffen können, dann kann jede andere Organisation das auch. Denn soviel Wahrheit steckt doch im Klischee - die deutschen Amtsstuben sind im Normalfall eben doch ein Umfeld das eher Gemächlichkeit und Geruhsamkeit befördert. Aber das kann überwunden werden, wenn man nur will.

Hieraus ergibt sich dann auch die zweite Erkenntnis: es sind oft die Umgebungsfaktoren, die die Fähigkeit eines Teams zur agilen Organisation erst möglich oder unmöglich machen. Wenn die Umgebung einen Sinn in schnellen Reaktionen sieht (z.B. in Notaufnahmen oder Brandwachen), dann wird sie alles dafür tun diese auch herzustellen - sogar beim Staat. Wenn dieser Sinn aber nicht erkannt wird, dann werden die organisatorischen und bürokratischen Hürden im Zweifel nicht beseitigt werden, dann geht alles weiter seinen gemächlichen Gang.

Donnerstag, 16. November 2017

Exkurs in die empirische Sozialforschung

Dieser Talk von Linda Rising erinnert mich sehr stark an die Seminare zur empirischen Sozialforschung die ich vor langer Zeit an der Universität gemacht habe. Und genau wie bei einigen meiner damaligen Dozenten bin ich mir nicht sicher - finde ich ihren Vortragsstil beruhigend, spannend, einschläfernd oder nervtötend? Unabhängig davon hat sie einen Punkt: wenn man im Lean Startup-Modus Experimente durchführen will sollte man darüber nachgedacht haben was das ist.

Montag, 13. November 2017

Über den Tellerrand

Bild: Max Pixel / Reinhard Thrainer - CC0 1.0
Zu den etwas irritierenden Momenten meines Jobs gehört im Augenblick, dass ich (der agile Coach) die Mitarbeiter eines Kunden bei ihren PMI-Weiterbildungen begleiten darf. Ich bin zwar alles andere als ein Fan, habe mich aber bereits vor einiger Zeit durch den dazugehörigen "Body of Knowledge" gearbeitet und kann daher aufzeigen wo er Schnittmengen mit agilen Vorgehensweisen hat (z.B. bei der Rolling Wave-Planung) und wo nicht. Und wenn es dazu beiträgt mehr Realitätsbezug und weniger Bürokratie in Projektplanungen einzubringen, dann hat es sich bereits gelohnt.

Bei einem anderen Kunden wurde ich vor einiger Zeit in Meetings gebeten in denen ein SAFe-Projekt aufgesetzt wurde. Auch davon bin ich kein besonderer Fan, hatte mich aber irgendwann eingearbeitet und konnte dadurch etwas beitragen: als ein Manager darauf bestehen wollte, dass man in dieser Methode möglich viel zentralisierte Planung haben will konnte ich belegen, dass (zumindest in der Theorie) das Gegenteil der Fall ist. Zentralisiert wurde später zwar trotzdem, allerdings zumindest ohne das Wort "Agile" dafür zu missbrauchen.

Im Umkehrschluss kenne ich eine ganze Reihe von Scrum Mastern und agile Coaches die in vergleichbaren Situationen aus Diskussionen aussteigen mussten, weil sie vom jeweiligen Thema keine Ahnung hatten. In einigen dieser Fälle waren Beschlüsse das Ergebnis, die nur mit Mühe oder gar nicht mehr zurückgedreht werden konnten. Hier hätte es geholfen zumindest ein Grundverständnis zu haben.

Genau dieses Grundverständnis ist auch der Punkt um den es geht. Natürlich kann niemand alles wissen, es ist aber auf jeden Fall sinnvoll bis zu einem gewissen Grad mitreden zu können, sei es in den genannten Beispielen zu PMI oder SAFe oder im Fall von ITIL, Prince2, ISTQB oder sonstigen Ansätzen mit kryptischen Abkürzungen. Den meisten überzeugten Agilisten macht das Beschäftigen mit diesen Themen zwar nur wenig Spass, dass es im Job vorteilhaft sein kann dürfte aber offensichtlich sein.

Ein häufiges Argument gegen die Einarbeitung in diese Wissensgebiete ist übrigens, dass das Zeit erfordert, die nicht zur Verfügung steht. Ironischerweise kommt es häufig von Menschen die nicht erklären können was ein Scrum Master/Agile Coach den ganzen Tag macht. Vielleicht besteht da ein Zusammenhang.

Mittwoch, 8. November 2017

Update des Scrum Guide 2017

Bild: Wikimedia Commons / Quintin Smith - CC BY 2.0
Der Scrum Guide scheint selbst agiler zu werden, jedenfalls werden seine Releasezyklen kürzer. Ein Jahr nach dem letzten Update gibt es jetzt ein neues, diesesmal mit einem anderen Schwerpunkt. Während 2016 mit den Scrum Values ein kompletter Abschnitt neu hinzugefügt, bzw. zurückgebracht wurde gab es dieses Jahr verschiedene kleinere Ergänzungen. Aus meiner Sicht werden vor allem zwei davon spürbare Auswirkungen haben: die im Bereich des Daily Scrum und die im Bereich des Sprint Backlog.

  • Daily Scrum

    Die drei Fragen sind jetzt optional. Die neue Formulierung heisst "The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based". Damit wird offiziell was viele Teams ohnehin schon machen und was ich bereits bei einigen Teams eingeführt habe. Letztendlich wird hier ein Auseinanderklaffen von Theorie und Realität repariert. Wenn von den drei Fragen abgewichen wird um Status-Reporting und Kalenderverlesung zu vermeiden wird es von jetzt an weniger Diskussionen geben.

  • Sprint Backlog

    Ein ganz anderer Fall. Die neue Formulierung heisst "The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting". Auch das ist nicht völlig neu, an vielen Boards gibt es bereits Kaizen-Lanes. Allerdings sind derartige Boards bisher eher in der Minderheit. Dass es ab jetzt offizieller Teil von Scrum ist wird für viele Diskussionen sorgen. Und ungeachtet der Tatsache, dass es Sinn macht den ständigen Verbesserungsprozess zu verankern -  wie passt das mit dem (fachlichen) Sprintziel zusammen? Da kann man auf die sich herausbildenden Practices gespannt sein.
Was die anderen Änderungen betrifft halte ich es frei nach dem Schlußsatz des agilen Manifest - sie sind nicht unwichtig, aber die beiden Punkte auf die ich eingegangen bin halte ich für wichtiger. Und zuletzt noch eine Beobachtung: im Livestream von Sutherland und Schwaber waren die Logos von Scrum.org und Scrum Inc prominent eingeblendet, das der Scrum Alliance aber nicht. Ein weiteres Zeichen der Entfremdung?

Montag, 6. November 2017

Hart gecodet

Bild: Wikimedia Commons / Clio20 - CC BY-SA 3.0
Zu den Ausdrücken die bei vielen Projektmanagern Fragezeichen in den Augen verursachen gehört "hart gecodet". Begleitet von einem Augenrollen oder Stöhnen der Entwickler bedeutet es oft, dass an einer Stelle eine "zu einfache" Lösung gewählt wurde, die jetzt durch eine "richtige" ersetzt werden müsste. Da auf der Benutzeroberfläche alles gleich aussieht ist für einen Nicht-Entwickler aber nicht klar warum dieser Aufwand Sinn macht. Ein Übersetzer ist gefragt. Und eine mögliche Übersetzung könnte in Form eines Praxisbeispiels stattfinden, das so tatsächlich existiert hat:

Eine Firma betreibt einen Web-Shop, der wie jede andere Website ein Impressum haben muss. Dieses muss unter anderem eine Adresse und den Namen der vertretungsberechtigten Personen enthalten, in diesem Fall der Geschäftsführung. Etwa so:
ABC AG
XYZ Strasse
Vorstand: Herr Baumann, Herr Bergmann
Wie kommen diese Informationen jetzt auf die Website? Eine Möglichkeit besteht darin, sie direkt in den Code zu schreiben. Genau das ist es was man unter hart gecodet versteht. Das könnte dann so aussehen:
<div id="imprint">
ABC AG<br />
XYZ Strasse<br />
Vorstand: Herr Baumann, Herr Bergmann<br />
<div>
Warum könnte das jetzt ein Problem sein? Nehmen wir an die Firma ist ein schnell wachsendes Startup. Um immer mehr Mitarbeiter unterbringen zu können zieht es in kürzerer Zeit mehrfach um. ausserdem wird im Rahmen der Professionalisierung die Geschäftsführung vergrößert, vielleicht verkauft auch ein Gründer seine Anteile und steigt aus. Jedesmal muss das Impressum aktualisiert werden. Und: auf einmal gibt es mehr als eine Stelle an der ein Impressum vorgeschrieben ist. Es gibt eigene Aktions- oder Produkt-Websites, es gibt automatisierte Mails an die Kunden, es gibt einen Email-Presseverteiler, etc., etc., etc. Schon bald erfordert jede Aktualisierung eine Schnitzeljagd nach allen Stellen an denen das notwendig ist und früher oder später werden einzelne davon vergessen und nicht mehr aktualisiert. Teure Abmahnungen können das Ergebnis sein.

Um dieses Risiko zu umgehen können alle Daten des Impressums an einer zentralen Stelle hinterlegt werden. Wenn die einzelnen Websites und Mailprogramme dann so designt sind, dass sie die Daten immer aus dieser zentralen Stelle abgelesen werden, müssen sie nur noch ein einziges mal aktualisiert werden wenn sich etwas ändert. Das könnte so aussehen:
<div id="imprint">
<p class="getimprint">
<div>
Natürlich verbirgt sich hinter dem <p class="getimprint"> jetzt etwas mehr als nur die bloßen Buchstaben, es ist eine Funktion die die Impressumsdaten aufruft. Die zu schreiben ist aufwändiger als die hart gecodete Eingabe der Informationen, weshalb man auf die Idee kommen könnte durch die einfacher scheinende Lösung Zeit zu sparen. Das man von dieser scheinbaren Ersparnis wieder eingeholt werden würde sieht man an dem oben genannten Beispiel.

<Disclaimer> Es gibt natürlich Fälle in denen harte Codierung unbedenklich ist, oft genug ist sie es aber nicht. Und wenn ein Entwicklungsteam sagt, dass es eine solche Stelle bereinigen möchte ist es eine gute Idee ihm die Zeit dafür zu geben.

Donnerstag, 2. November 2017

Selbst- und Fremdwahrnehmung von IT-Berufen

Wie so oft: klischeehaft, überzeichnet, aber mit einem nicht völlig zu bestreitenden Realitätsbezug. Und die armen Sysadmins haben in der Realität leider wirklich einen durchgehend schlechten Ruf.
Was hier fehlt sind die Scrum Master und agile Coaches. Kommt vielleicht in der nächsten Version (Bild: Imgur).