Donnerstag, 23. November 2017

Rollen und Tätigkeiten

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

FS
Bild: Pixabay / Skeeze - CC0 1.0
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

FS
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

FS
Bild: Pixabay / Karen_Nadine - 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 besehen 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

FS
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

FS
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

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

Montag, 30. Oktober 2017

Kommentierte Links (XXX)

FS
  • Joshua Kerievsky: Size teams for few to no handoffs

    Ein schönes Beispiel dafür wie sich Lean und Agile überschneiden. Übergaben zwischen Teams führen zu Wartezeiten, Wartezeiten führen zu langsamen Produktionsvorgängen und langsame Produktionsvorgänge sind nicht mehr agil. Joshua Kerievsky definiert die Freiheit von Übergaben (→ Crossfunktionalität und Autonomie) als so wichtig, dass dafür im Zweifel sogar relativ große Teams (größer als zehn Mitglieder) in Kauf genommen werden sollten. Ein interessanter Gedanke, selbst wenn ich glaube, dass in der täglichen Arbeit mit hoher Wahrscheinlichkeit ein Zerfall in Subteams stattfinden würde.

  • Michael Küsters: How splitting work kills companies

  • Der gleiche Gedankengang aus einer anderen Perspektive. Dass selbst kleine und gut gemeinte Aufgabenteilungen zwischen mehreren Teams zu Bürokratie und Verlangsamung führen können ist auf einer abstrakten Ebene klar, das ganze Ausmaß erschließt sich aber erst an konkreten Beispielen. Das in diesem Fall genannte ist besonders anschaulich, da es sich nicht um Softwareproduktion handelt sondern um einen outgesourcten Kundenservice. Und auch ein weiterer Aha-Effekt ist enthalten: wenn Bürokratie selbst in einem so begrenzten Fall bereits entstehen kann - was passiert dann erst in komplexen Umgebungen?

  • Claire Lew: The Culture Cliché

    An der Universität habe ich gelernt, dass Kultur die Summe der impliziten und expliziten Konventionen, Normen, Werte und gemeinsamen Erinnerungen ist, aus der eine soziale Gruppe ihre Identität konstruiert. Claire Lew formuliert es einfacher: “Culture is the way we do things around here.” Was beiden Definitionen gemeinsam ist - man kann Kultur nicht verordnen oder einführen. Sie ist einfach da und überlagert früher oder später alles andere. Wenn im Rahmen einer Unternehmenstransition nicht auch die Kultur geändert wird ändert sich im Zweifel gar nichts, zumindest nicht so wie gewünscht.

  • Leon Tranter: Technical debt — or technical bankruptcy?

    Vermutlich muss man eine ausser Kontrolle geratene technische Schuld selbst erlebt haben um ihre Tragweite erfassen zu können. Wenn selbst kleinste Änderungen zu umfangreichen Arbeiten in allen Anwendungsteilen, systemweiten Ausfällen und langwierigem Bugfixing führen ist dieses Endstadium erreicht, das Leon Tranter sehr anschaulich als "technischen Bankrott" beschreibt. Sowohl die Ursachen als auch mögliche Lösungen sind gut zusammengefasst, jetzt müsste sie nur noch jemand lesen, der den Entwicklern seines technisch bankrotten Projekts/Unternehmens erlauben kann sie umzusetzen.

  • Zeit: Feindbild Algorithmus

    Kurz nachdem die Digitalbranche zum größten Arbeitgeber in Deutschland geworden ist zeigt der Staat, dass er diesen Wandel leider noch immer nicht versteht. Wenn Bundesjustizministerium, wissenschaftlicher Dienst des Bundestages und weitere Politiker jetzt fordern, dass den Nutzern von Google, Facebook & Co offengelegt wird welche Algorithmen einem Suchergebnis oder Newsfeed zugrundeliegen, dann wird deren Volatilität verkannt. Alleine im letzten Jahr wurden in der Web-Suche von Google 9800 Modifikationen im Livebetrieb getestet, von denen dann 1600 dauerhaft eingeführt wurden (Bericht hier). Soll dann jeder Benutzer 27 Benachrichtigungen pro Tag erhalten? Vielleicht würden dem Bundestag und der Regierung eine Einführung in die Grundlagen agiler Softwareentwicklung gut tun.

Donnerstag, 26. Oktober 2017

Das Ende der Selbstorganisation

FS
Bild: Wikimedia Commons / Famartin - CC BY-SA 4.0
Einer der zahlreichen heiligen Grale der Agilität ist die Selbstorganisation der Teams. Autonom, crossfunktional und empowered sollten sie sein, von niemandem gemicromanaged, lediglich von Servant Leadern umgeben und unterstützt. Nur wenn all das gegeben ist können sie zu schlagkräftigen und reaktionsschnellen High Performance-Units werden, ungebremst von Flaschenhälsen oder Handovers. Das stimmt in der Theorie und das stimmt auch in der Praxis, und doch - Selbstorganisation muss häufig Grenzen haben.

Man kann es am einfachsten an den Extremfällen sehen. Ein Team in einer Firma für Bürosoftware kann noch so selbstorganisiert sein, wenn es sich entscheiden würde statt eines Antivirus-Patch der Bürosoftware lieber Computerspiele zu programmieren würde das Management das zu Recht verhindern. Und ein Entwicklungsteam einer Bank kann noch so selbstorganisiert entscheiden, dass es seine Prozesse nicht mehr dokumentiert, die Bafin würde ungerührt untersagen, dass die so entstandene Software in Produktion geht.

Auch Grenzfälle sind bei genauerer Betrachtung offensichtlich: ein Team das die eigene Anwendung sowohl weiterentwickelt als auch wartet kann zwar selbstorganisiert entscheiden wann seine Mitglieder ihren Urlaub nehmen, es muss aber dafür sorgen, dass immer jemand da ist der die Live-Version am Laufen hält. Und ein Team das eine neue Software baut kann zwar wählen welche Programmiersprache es benutzt, das Unternehmen kann aber verlangen, dass es eine ist die auch ausserhalb des Teams verstanden wird.

Schwierig wird es schließlich wenn die Selbstorganisation mit Unternehmensgrundsätzen kollidiert. Darf ein Team für seine MVPs Quick & Dirty-Lösungen implementieren wenn das Unternehmen Clean Code will? Dürfen sich Entwickler selbstorganisiert zu Teams von über 20 Personen zusammenschliessen wenn das Unternehmen auf kleine Squads oder Scrum Teams setzt um agil zu bleiben? Spätestens hier heißt es oft: "Wenn Ihr das vorschreibt schafft Ihr die Selbstorganisation ab!" Aber ist das wirklich ein Argument?

In den meisten Fällen zeigt sich an solchen Situationen, dass nie daran gedacht wurde festzulegen bis wohin Selbstorganisation geht (dass es solche Grenzen gibt sieht man an den ersten Beispielen). Bei vielen agilen Transitionen heisst es einfach "Ab jetzt sind die Teams selbstorganisiert". Und wenn die im Rahmen ihrer Selbstorganisation auf eine Stelle stossen an der diese doch nicht gewünscht ist knallt es gelegentlich. Das muss nicht sein.

Es ist empfehlenswert, dass Management und Team gemeinsam (!) Grenzen festlegen bis zu denen die Autonomie reicht. Welche das sind kann von Fall zu Fall unterschiedlich sein, sie sollten aber begründet und nachvollziehbar sein. Und es sollte auch jedem klar sein, dass diese Grenzen nicht unverrückbar sind sondern sich verschieben können. So kann etwa zu Beginn noch ein Architekt vorhanden sein, der sich irgendwann später selbst abschafft und in das Team geht.

Zuletzt kann jedes einzelne Teammitglied anhand dieser Grenzen entscheiden ob es sich hier noch richtig aufgehoben fühlt. Und wenn das nicht der Fall ist kann es mit den Füssen abstimmen und gehen, in ein anderes Team oder ein anderes Unternehmen.

Montag, 23. Oktober 2017

Kollektives Gedächtnis

FS
Bild: Pixabay / Skeeze - CC0 1.0
Zu den häufigsten Beschwerden bei der Einführung agiler Methoden gehört die, dass man sich "das alles" unmöglich merken könnte. Das Grundgerüst von Scrum oder Kanban würde ja noch gehen, aber die zahllosen good und best Practices aus Extreme Programming, Lean Startup, Lean Management, TPS, Design Thinking, Clean Code, DevOps und sonstigen Ursprüngen wären einfach zu viel.

Bis zu einem gewissen Grad ist dieser Einwand sicher richtig, kein Mensch ist in der Lage sich alles zu merken. Dass in Summe trotzdem viel mehr an Wissen hängenbleibt als man denken sollte liegt an einem Phänomen das man als "kollektives Gedächtnis" bezeichnet, welches erstmals 1939 vom Soziologen Maurice Halbwachs beschrieben wurde. Vereinfacht gesagt bedeutet es, dass sich Gruppen von Menschen mehr Dinge merken können als einzelne Personen. Wie so oft: ein Ganzes ist mehr als die Summe seiner Teile.

Zunächst klingt das banal. Person A lernt Wissensgebiet A, Person B lernt Wissensgebiet B und zusammen wissen beide mehr als jeder für sich genommen. In der Realität ist es aber komplexer als das. Da die verschiedenen Personen sich kontinuierlich miteinander austauschen wird das Wissen nicht nur untereinander und mit Dritten geteilt, es wird auch immer wieder zurück in Erinnerung gerufen, so dass es nicht in Vergessenheit geraten kann. Ohne diese Kommunikation würde das Wissen irgendwann wieder verfallen.

An dieser Stelle überschneidet sich die Idee des kollektiven Gedächtnis mit verschiedenen good Practices im agilen Vorgehen. Die überschaubare Größe von Organisationseinheiten und die verschiedenen Querschnittsgruppen sorgen dafür, dass die gemeinsamen Erinnerungen durch eine permanente Kommunikation immer wieder erneuert werden, während der Soft Power-Aspekt der Methode dafür sorgt, dass das auch gerne und von sich aus stattfindet. Die verschiedenen themenspezifischen Meetingformate bieten den geeigneten Rahmen.

Ein für große Organisationen unerfreulicher Aspekt ist übrigens, dass auch schlechte Erinnerungen im kollektiven Gedächtnis hängenbleiben. Besonders das Fehlverhalten herausgehobener Personen (→ Manager) kann jahrelang im gemeinsamen Bewusstsein erhalten bleiben und selbst in jüngere Generationen hereingetragen werden die es gar nicht selbst erlebt haben. Ein Grund mehr das eigene Tun regelmässig zu überdenken.

Donnerstag, 19. Oktober 2017

Scaled Agile: Gilden

FS
Bild: Wikimedia Commons / Gerbrand van den Eeckhout - Public Domain
Wenn es um die Skalierung von agiler Softwareentwicklung geht sind die Gilden in den letzten Jahren zu einem Buzzword geworden an dem kaum jemand vorbeikommt. Fast jedes größere Unternehmen oder Projekt das mehr als fünf Entwicklungsteams umfasst hat mittlerweile mehrere von ihnen, in denen gleichartige Spezialisten zusammengefasst sind. Frontend-Gilden, QA-Gilden, Architektur-Gilden, etc.

Wann genau die Verwendung dieses Begriffs in diesem Kontext angefangen hat ist nicht mehr genau nachzuvollziehen, es dürfte aber innerhalb der letzten zehn Jahre gewesen sein. Zwar gab es auch vorher schon Gruppierungen die sich in Anlehnung an die mittelalterlichen Handwerksvereinigungen Gilden nannten, allerdings waren das noch Zusammenschlüsse von Softwareentwicklern im Allgemeinen, die Spezialisierung auf bestimmte Teilbereiche erfolgte irgendwann in der Zeit danach.

Popularisiert wurde das Konzept schließlich durch die Management 3.0-Bewegung, von der auch die heute am weitesten verbreitete Definition stammt. Ihr zufolge ist eine Software-Gilde eine freiwillige Vereinigung von Entwicklern, die sich (wie in einer klassischen Community of Practice) über ihr jeweiliges Spezialthema austauschen, gleichzeitig aber auch Standards und Werkzeuge weiterentwickeln. Das Ziel ist dabei, sowohl die Mitarbeiter als auch die Methoden selbst immer weiter in Richtung Exzellenz zu bewegen und so bessere Produkte zu schaffen.

Der zentrale Unterschied zu Scrum of Scrums und Chaptern ist in der Regel, dass die Gilden nicht das Ziel haben die Arbeitsfortschritte der einzelnen Teams zu koordinieren. Es geht eher um die Weiterentwicklung der "Handwerkskunst" im Allgmeinen, unabhängig vom jeweiligen Produkt- oder Projektkontext. Die Ergebnisse können in die tägliche Arbeit einfliessen, müssen es aber nicht. Und häufig werden sie der Welt als Open Source zur Verfügung gestellt.

Bedingt durch die schnelle Verbreitung und dadurch dass er nicht geschützt oder geregelt ist kann der Begriff der Gilden natürlich auch anders verwendet werden. Gerade in einem eher hierarchischen Umfeld ist er mittlerweile oft als Bezeichnung für klassische Koordinationsgremien anzutreffen, etwa als Testmanagement-Gilde. Derartige Verwendungen sind starke Indikatoren für Cargo Cult und sollten daher am besten intensiv hinterfragt werden.

Montag, 16. Oktober 2017

Story Points

FS
Bild: Publicdomainpictures - CC0 1.0
Es gibt eine Grundsatzdebatte die bei fast jeder Scrum-Einführung aufkommt, und zwar die um die Story Points. Muss das sein? Warum braucht man die? Warum schätzen wir nicht in Personentagen, wie jeder andere auch? Alle diese Fragen sind berechtigt und müssen beantwortet werden wenn diese Methode vom Team akzeptiert und angewandt werden soll. Story Points sind nämlich keineswegs Teil von Scrum, sie sind good Practice und können von jedem Team auch weggelassen werden.

Um zu verstehen warum man es zwar kann aber nicht sollte bietet sich ein Gedankenspiel an. Ein Team schätzt eine Anforderung während eines Backlog Refinements und benutzt dabei Personentage als Metrik. Die Schätzung ist auch einigermassen realistisch. In einem der folgenden Sprints beginnt ihre Umsetzung, und jetzt stellt sich aber heraus, dass die geschätzte Zeit nicht ausreichend ist (tatsächlich passiert das sogar recht häufig). Fast jedes Team wird an dieser Stelle bestätigen, dass ihnen das permanent passiert. Woran kann das liegen?

Ein häufiger Grund ist, dass einzelne Teammitglieder fehlen, etwa durch Urlaub, Krankheit oder Weiterbildungen. Das beeinflusst die Schätzung auf den ersten Blick nicht, die Anzahl der Personentage muss dann eben auf weniger Personen verteilt werden, bleibt aber gleich. Tatsächlich ist aber Expertise in fast allen Teams ungleich verteilt, und ohne den größten Experten z.B. zum Thema Fronntend braucht eine Anforderung auf einmal nicht mehr vier Personentage sondern sechs. Auch andere Faktoren können in ähnlicher Form den nötigen Aufwand vergrößern, etwa das Training on the Job eines neuen Kollegen.

Um die Schätzungen realistisch zu halten dürften sie aufgrund dieser Faktoren nur zu Beginn eines Sprints stattfinden, wenn klar ist wer während seiner Laufzeit anwesend und verfügbar sein wird. Das wäre zwar realistischer, allerdings würde es dadurch unmöglich weiter in die Zukunft zu planen. Story Points bieten einen Ausweg aus dieser Situation. Sie sind eine neutrale Größe mit der man langfristig planen kann, die aber in jedem Sprint neu interpretiert werden kann. Z.B: Mit dem ganzen Team würden wir ca. 20 Story Points schaffen, mit einem Mitglied weniger ein Fünftel weniger, wenn der Abwesende unser Frondend-Experte ist ein Viertel weniger.

Es gibt darüber hinaus noch weitere Argumente für Story Points, etwa die Veranlagung des menschlichen Gehirns zum relationalen Schätzen oder die dadurch möglichen Moderationstechniken. Wenn all das einem Team erklärt wird einscheidet es sich in den meisten Fällen dafür dauerhaft mit dieser Metrik zu arbeiten.

Donnerstag, 12. Oktober 2017

Bad technology choices can influence your culture

FS
Die agile Coaches dieser Welt werden nicht müde es zu betonen: praktisch alles in der agilen Softwareentwicklung basiert auf der (Unternehmens)Kultur, bzw. auf ihren einzelnen Ausprägungen. Auf Werten, Verhaltensweisen, Überzeugungen und Mindsets. Das ist zwar richtig, verkennt aber einen zentralen Aspekt - die eingesetzten Technologien können auch die Kultur beeinflussen. Tim Gross erklärt in diesem Video Zusammenhänge und Auswirkungen.



Man kann es natürlich auch umgekehrt sehen: wenn die richtige Kultur vorhanden ist wird das automatisch zur Folge haben, dass bestimmte technologische Entscheidungen nicht getroffen oder verworfen werden. Grundsätzlich stimmt das zwar, stellt aber alle Unternehmen vor große Herausforderungen in denen der Kulturwandel gerade stattfindet und ggf. gerade erst begonnen hat. Wenn in einer solchen Situation die falschen technologischen Entscheidungen getroffen (oder nicht korrigiert) werden, dann kann das den Wandel stoppen oder sogar zum Scheitern bringen.

Montag, 9. Oktober 2017

Ein Bild sagt mehr als 1000 Worte (XX)

FS
Diese Grafik liefert die Antwort auf eine immer wieder gestellte Frage: warum soll ein Scrum Team nicht mehr als neun Mitglieder haben? Die Antwort ist die: für schnellen Wissensaustausch und schnelle Entscheidungen muss in selbstorganisierten Teams jeder mit jedem kommunizieren. Ab einer bestimmten Größe würde das zu einer unbeherrschbaren Menge an Kommunikationskanälen führen. Zu sehen hier im Bild.

Donnerstag, 5. Oktober 2017

Es gibt keine Kanban-Rollen - oder doch?

FS
Bild: Pixabay - Schuetz Mediendesign - CC0 1.0
Zu den Fragen die im Rahmen von Kanban-Trainings immer wieder gestellt werden gehört die nach den Rollen die dieses Framework mit sich bringt. Vor allem die nach einem Äquivalent des Scrum Masters taucht immer wieder auf. Die Antwort kann allerdings immer nur sein, dass derartige Rollen in Kanban nicht vorgesehen sind. Das ergibt sich sogar zwangläufig aus seiner Natur, die eine andere ist als die von Scrum.

Scrum ist designt als ein Framework mit dem Zweck der Produktherstellung. Es definiert daher verschiedene Rollen, einen bestimmten Ergebnistyp und klar definierte zeitliche Abläufe, während derer bestimmte Tätigkeiten auszuüben sind um die gewünschten Ergebnisse zu erzielen. Kanban ist im Gegensatz dazu ein Framework mit dem Zweck der Prozessverbesserung, dass auf jeden beliebigen bestehenden Prozess aufgesetzt werden kann um ihn nach und nach zu optimieren. Da zu diesen bestehenden Prozessen auch bestehende Rollen gehören können ist es nicht möglich neue Rollen verbindlich zu definieren. Der bestehende Prozess würde dadurch nicht mehr nach und nach optimiert sondern aprubt verändert, was so nicht vorgesehen ist.

Ungeachtet dieser grundsätzlichen Funktionsweisen besteht aber trotzdem eine Konstellation in der die Schaffung von Rollen nötig sein kann. Dann nämlich wenn eine neue Organisationseinheit von Beginn an mit den Kanban-Werzeugen arbeiten soll (Boards, Wertströme, WIP-Limits), und zwar bewusst ohne sich initial an die bisher bestehenden (suboptimalen) Prozesse anzulehnen. Zwar könnte man auch komplett ohne Vorgaben starten und warten bis sich aus dem Chaos Strukturen bilden, der damit verbundene Effektivitäts- oder Effizienzverlust führt aber dazu, dass dieses Vorgehen praktisch nie angewandt wird.

Der zur Zeit populärste Ansatz wurde 2016/2017 unabhängig voneinander von David Anderson und Jeff Sutherland entwickelt und lehnt sich stark an Scrum an. Als Äquivalent zum Scrum Master gibt es auch hier einen Prozessverantwortlichen (Flow Master, Flow Manager oder Delivery Manager), als Äquivalent zum Product Owner ist auch ein Produktverantwortlicher vorgesehen (Service Manager, Product Owner oder Product Manager). Anders als bei Scrum handelt es sich hier um Rollen im eigentlichen Sinn, das heisst sie können ggf. auch von Personen übernommen werden deren eigentliche Jobs ganz andere sind. Auch ein Umsetzungsteam existiert, das aber stärker arbeitsteilig sein kann als in Scrum.

Von elementarer Bedeutung ist, dass auch diese Rollen sich im Rahmen der kontinuierlichen Optimierung verändern, verschwinden oder vermehren  können. Wäre das nicht mehr der Fall gäbe es Teile der Organisation die per Definition nicht optimiert werden dürften. Das aber wäre mit Kanban nicht mehr vereinbar.

Montag, 2. Oktober 2017

Die Zertifizierungs-Tretmühle

FS
Bild: Freegreatpicture / Maxpixel - CC0 1.0
Angekündigt hatte es sich schon im letzten Jahr, seit einigen Tagen steht es auf der Website der Scrum Alliance: die angebotenen Zertifizierungen ändern sich, es werden weitere dazukommen. Die drei Basis-Zertifizierungen für Scrum Master, Product Owner und Developer werden ergänzt um ein Advanced-Level, der bisher rollenübergreifende Scrum Professional wird ebenfalls auf die drei Rollen aufgespalten. Aus bisher vier Zertifizierungen werden so neun1. Und obwohl ich verstehe warum das so kommt glaube ich nicht, dass das eine gute Entwicklung ist.

Von der geplanten Erweiterung des Zertifizierungsspektrums habe ich zum ersten mal letztes Jahr auf dem Global Scrum Gathering Munich gehört. In den dort stattgefundenen Diskussionen war der Konsens der, dass die bisherigen Zertifizierungen über die Jahre weitgehend entwertet worden sind. In manchen Unternehmen wurde das gesamte mittlere Management geschlossen in die Zertifizierungslehrgänge geschickt, zahllose Freelancer kleben sich das Siegel auf den Lebenslauf um ihre Kunden zu beeindrucken und Schulungsanbieter haben in den dazugehörigen Kursen eine Goldgrube entdeckt.

Bedingt durch diese Inflation beweisen die Zertifikate heute eigentlich nur noch zwei Dinge: a) ihr Inhaber hatte genug Geld für die Prüfungsgebür und b) er ist in der Lage eine überschaubare Menge an Lernstoff auswendig zu lernen. Das zu ändern und die Zertifikate durch mehr Stoff und mehr Praxiserfahrung aufzuwerten ist zunächst ein nachvollziehbares Anliegen, aber selbst wenn es von der Zielgruppe angenommen werden sollte ist für mich fraglich ob das gesteckte Ziel damit erreicht werden wird.

In den Gesellschaftswissenschaften gibt es den Begriff der Euphemismus-Tretmühle, der besagt, dass jedes neutrale oder positive Wort mit dem man die Benutzung eines negativ geprägten Begriffs umgehen will irgendwann die negative Konnotation seines Vorgängerausdrucks annehmen wird, solange sich die tatsächlichen Verhältnisse nicht verändern. Analog dazu glaube ich, dass wir uns gerade im Prozess einer "Zertifizierungs-Tretmühle" befinden.

Demnach findet im Moment Folgendes statt: eine Zertifizierung hat durch massenhafte Verteilung ihre Aussagekraft verloren und wird darum um eine "höhere Stufe" ergänzt. Auch die erleidet absehbar das selbe Schicksal, weshalb zur "Aufwertung" noch eine Stufe dazukommt, etc. Bereits nach kurzer Zeit wird die verästelte Hierarchie der entstehenden Zertifikate so groß, dass die meisten Menschen den Überblick verlieren2. Abgesehen von wenigen Experten weiss keiner mehr was sich im Einzelfall dahinter verbirgt.

Der Effekt ist, dass die Menschen sich am Ende nur noch genervt abwenden wenn das Gespräch auf dieses Thema kommt. Noch einmal eine Parallele zur Euphemismus-Tretmühle: ausserhalb winziger Milieus gilt heute jeder der von "LSBTTIQ-Menschen", "Professorx" oder "Person mit Migrationshintergrund ohne eigene Migrationserfahrung" spricht als weltfremder Wunderling mit dem Unterhaltung eher anstrengend werden. Wer zukünftig den Scrum Master in CSM, A-CSM und CSP-SM unterteilen will dürfte schnell in der selben Schublade landen, und das nicht einmal völlig zu Unrecht.

Nun ja. Wie man hier im Rheinland sagt: Et es wie et es. Mal sehen wie die Sache ausgeht.

1Dazu kommen die vor kurzem eingeführten Trainer-, Coach- und Leader-Zertifikate, die nochmal ein Thema für sich sind.
2Ich glaube, dass das gerade stattfindet.

Freitag, 29. September 2017

Kommentierte Links (XXIX)

FS
  • John Cutler: One Day Sprints

    Ich habe bereits Teams begleiten dürfen deren Anforderungen so klein geschnitten waren (und so klein geschnitten werden konnten), dass sie innerhalb eines Tages zu erledigen waren. Für die hätte man einen solchen Versuch starten können. Der Grund warum ich den meisten aber davon abraten würde ist, dass es bei komplexen Anwendungen und Anwendungslandschaften sehr schwer fallen wird in nur einem Tag ein Increment zu erzeugen, also eine Funktionalität die einen benutzbaren und bestenfalls vermarktbaren Mehrwert erzeugt. Trotzdem - probieren kann man es, etwa indem man es als Experiment für die Dauer eines "normalen" Sprints laufen lässt. Selbst wenn es nicht beibehalten wird - die Überlegungen zum Kleinerschneiden von Requirements sind in jedem Fall eine wertvolle Übung.

  • Roman Pichler: Choosing the Right Planning Horizon for Your Product

    Wenn ich als Berater oder Coach in ein Unternehmen komme in dem Scrum/Agile nicht optimal laufen ist die fehlende mittel- und langfristige Planung ein Problem dass fast immer vorliegt. Das was Roman Pichler hier vorstellt ist ein guter Weg damit umzugehen, vor allem weil er nicht nur verschiedene Horizonte/Zeiträume nennt sondern auch Ratschläge gibt in welchen Zeiträumen sie aktualisiert werden sollten. Mein Modell, das ich bei manchen Kunden eingebracht habe, ist in einigen Punkten noch weniger ausformuliert, gegebenenfalls werde ich das eine oder andere von Pichler übernehmen.

  • Stephan Grabmeier: Heterogene Teams bilden und führen – Diversity Faultline Ansatz

  • Mit Sollbruchstellen in Teams habe ich auch schon Erfahrungen machen dürfen, besonders mit einer die Stephan Grabmeier gar nicht beschreibt: der zwischen internen und externen Mitarbeitern. Selbst wenn es nach Klischee klingt - alleine durch die häufigen Wechsel von Unternehmenskulturen, angewandten Technologien und Produkten sind externe Entwickler häufig flexibler, offener umd umfassender qualifiziert als interne, die seit Jahren oder Jahrzehnten in der gleichen Abteilung an der gleichen Anwendung arbeiten. Hier einen Ausgleich zu finden und Team Spirit zu fördern kann eine Herausforderung sein.

  • Robert Galen: Agile Leadership – Eating our own Dogfood

    Was diesem Artikel zugrundeliegt ist ein grundsätzliches Problem: (Change)Manager haben häufig bessere Arbeitsbedingungen als "normale" Mitarbeiter. Bessere Hardware, bessere Software, weniger Vorschriften, weniger Deadlines, etc. Die Implementierung neuer Arbeitsweisen wird daher von ihnen häufig als einfacher empfunden als von den Entwicklungsteams. Um die "Schmerzen des Übergangs" nachvollziehbar zu machen empfiehlt es sich daher, die neuen Regeln auch auf die Change-Manager selbst anzuwenden. Die besten Change-Teams die ich erleben durfte (die auch die höchste Akzeptanz durch die Entwicklungsteams hatten) waren die, die selbst nach Scrum oder Kanban gearbeitet haben.

  • Adam Henshall: How to Build an MVP App Without Writing Code

    Es ist einer der zentralen Painpoints bei Teams oder Unternehmen die sich an Design Thinking oder Lean Startup versuchen. Entweder hat bei Prototypen und MVPs ein "Dumbing down" bis zu einem fast schon albernen Level stattgefunden (z.B. wird der Testgruppe ein mit Buntstiften auf Papier gemalter Website-Entwurf vorgelegt um Feedback zur Usability zu erhalten) oder es ist bereits soviel Arbeit und Geld in ihn geflossen, dass das Verwerfen zu einem schmerzhaften Schritt wird ("das darf nicht alles umsonst gewesen sein!"). Adam Henshall bietet einige gute Werkzeuge um dieser Situation auszuweichen und mit sehr geringem Aufwand vorzeigbare und benutzbare Ergebnisse zu erstellen, die man im Zweifel auch ohne Bauchschmerzen wieder verwerfen kann.

Dienstag, 26. September 2017

How to convince your boss to be agile

FS


Ein Vortrag der nicht nur inhaltlich gut ist sondern auch hohen Unterhaltungswert hat. Kann man sich ansehen.

Donnerstag, 21. September 2017

Scaled Agile: Release Trains

FS
Bild: Wikimedia Commons / David Gubler - CC BY-SA 3.0
Die Idealwelt ist die von der man hört wenn von Netflix, Zalando und Spotify die Rede ist. Statt einer großen, monolithischen Anwendung gibt es viele kleine Module (Microservices), die unabhängig voneinander deploybar sind und ihren Teams dadurch hohe Autonomie sichern. Die Realität ist häufig eine andere - Microservices existieren nicht (oder sind ungünstig geschnitten), so dass es doch dazu kommt, dass verschiedene Teams ihre Features gemeinsam auf Produktion bringen müssen. Wie passt das zu agiler Softwareentwicklung?

Der typische Management-Reflex ist "Koordination", womit in den meisten Fällen gemeint ist, dass ein koordinierender Manager eingesetzt wird, der den Teams vorgibt wann sie was fertigzustellen haben. In der Theorie sorgt das dafür, dass zusammengehörende Features gleichzeitig fertigwerden, in der Realität ist das leider seltener der Fall. Eher kommt es hier zu den aus dem Wasserfall bekannten Effekten: es passieren ungeplante Entwicklungen, die Geschwindigkeiten der Teams laufen auseinander, es kommt zu Leerlauf, Merge-Konflikten, etc.

Es könnte auch anders laufen, und um zu wissen wie braucht man nur auf einen ähnlichen Fall zu schauen - auf zu erreichende Deadlines. Auch damit können agile Teams zurechtkommen indem sie auf Komfortfunktionen verzichten, einfache Lösungen bevorzugen oder auf andere Art den Scope reduzieren. Ein langsameres Team kann auf diese Weise seinen zeitlichen Rückstand wieder aufholen. Umgekenrt kann gegebenenfalls das schnellere Team einen Gang zurückschalten und mehr Zeit in Refactoring, Bugfixing oder Wissenstransfer stecken, auch dadurch erreichen alle gleichzeitig den gemeinsamen Release-Zeitpunkt.

Als Analogie bietet sich der Bahnverkehr an: wenn in Hamm die Züge aus Duisburg und Köln zusammengekoppelt werden sollen, dann kann der langsamere (in diesem Fall aus Duisburg) schlimmstenfalls einen der vielen Stops im Ruhrgebiet ausfallen lassen, etwa den in Bochum. Umgekehrt könnte der schnellere (in diesem Fall der aus Köln) auch einen Zusatzhalt in Dortmund einlegen. In beiden Fällen würden beide gleichzeitig ankommen und gemeinsam ihre Fahrt nach Berlin fortsetzen.

Bleibt nur die Frage: könnte das nicht auch von einem koordinierenden Manager orchestriert werden? Nur bedingt. Da es erfahrungsgemäß nicht nur zu einer ungeplanten Entwicklung kommt sondern zu mehreren müssen im Zweifel alle beteiligten Teams permanent (in Scrum jeden Sprint, d.h. alle 1 bis 4 Wochen) Korrekturen vornehmen, das mit den Stakeholdern und anderen Teams abstimmen und die Planungen entsprechend aktualisieren. Schon bei zwei Teams wäre das für einen Koordinator eine Herausforderung, bei noch mehr Teams kaum zu schaffen.

Direkt miteinander kommunizierende autonome Teams können sich dagegen ohne Entscheidungs-Engpässe oder Stille Post-Effekte abstimmen und jedes für sich Kurs und Geschwindigkeit so anpassen, dass Vorsprünge und Verspätungen sich ausgleichen. Das Zusammenkoppeln kann dann reibungsloser stattfinden und der gemeinsame "Release-Zug" Fahrt aufnehmen.

Montag, 18. September 2017

Wenn der Agile Coach überall Cargo Cult sieht

FS
Bild: Wikimedia Commons / Thorsten Bachner - CC BY 3.0
Das Leben als Agile Coach kann großartig sein. Dann nämlich wenn man sieht wie die eigenen Ratschläge zu höherer Produktivität, höherer Kundenzufriedenheit oder höherer Mitarbeiterzufriedenheit führen. Andererseits kann es manchmal auch frustrierend sein, dann nämlich wenn man damit konfrontiert ist, dass unwillige Teams oder Manager eigentlich alles beim Alten lassen wollen und überall nur "Agile" als Buzzword-Label draufkleben.

Das Risiko das sich daraus ergibt ist, dass irgendwann reflexhaft jede (scheinbar) falsche Verwendung der Begriffe Agile und Agilität als Cargo Cult abqualifiziert wird. Ich sehe das manchmal an mir selbst, vor allem dann wenn ich gerade nicht bei einem Kunden unterwegs bin und mich daher (unbewusst) nicht an die selbst auferlegte Sorgfaltspflicht gebunden fühle. In solchen Situationen rutscht mir mitunter ein schnelles Urteil durch, eines für das ich mich im Nachhinein ein bisschen schäme.

Um dem entgegenzuwirken versuche ich regelmässig meine eigenen Ansichten zu reflektieren, mich selber zu hinterfragen und mich auf andere Standpunkte einzulassen. Gerade bei Menschen die nicht so tief und dauerhaft in der Thematik stecken wie ich kann eine falsche Benennung von Begriffen ja leicht vorkommen. Auf der anderen Seite ist aber auch deren missbräuchliche Verwendung eine immer wiederkehrende Realität. Und manchmal verschwimmen auch die Grenzen. Einen Schritt zurückzutreten und alles nochmal in Ruhe zu betrachten macht fast immer Sinn.

Was sich immer wieder als hilfreich herausgestellt hat sind "Selbsthilfegruppen" mit anderen Agile Coaches, sei es im Rahmen einer (Un)Konferenz, eines Coaching Retreat oder einer Kollegialen Fallberatung. Und sei es nur um festzustellen, dass andere genau die gleichen Probleme haben wie ich.

Donnerstag, 14. September 2017

Relationale Schätzungen

FS
Bild: Wikimedia Commons / mossi889 - CC BY 3.0
Ob das relationale Schätzen wirklich eine agile Methode im eigentlichen Sinn ist wird immer wieder diskutiert. Tatsache ist, dass die meisten agilen Teams (und fast alle Scrum Teams) derartige Ansätze nutzen um die Größemschätzung ihrer Arbeitspakete durchzuführen. Aber was ist das eigentlich, dieses relationale Schätzen?

Die grundlegende Einsicht dahinter ist, dass das menschliche Gehirn bei Schätzungen bestimmte Schwächen und bestimmte Stärken aufweist. Zu den Schwächen gehört dabei leider eine Schätzung in Zeitaufwänden. Ob eine Arbeit drei oder vier Stunden in Anspruch nehmen wird oder vier oder fünf Tage ist kaum zu sagen, schon gar nicht bei so komplexen und unberechenbaren Aufgaben wie der Neuentwicklung von Software. Zu den Stärken gehört dagegen die Einschätzung von Relationen. Jeder Mensch wird ohne Nachzudenken sagen können, dass eine Walnuss schwerer ist als eine Haselnuss, oder dass das Bauen einer Bank länger dauert als das Bauen eines Stuhls.

Um sich diese Stärke zu mutze zu machen kommt das relationale Schätzen zum Einsatz: neue Aufgaben werden in Bezug gesetzt zu älteren, bereits erledigten. "Wenn das Verarbeiten von Emails mit Word-Anhängen Größe X hatte, ist dann das Verarbeiten von Emails mit Excel-Anhängen ähnlich, größer oder kleiner?" Beruhend darauf ist eine Einschätzung nicht nur einfacher sondern auch wesentlich verlässlicher.

Erfahrungsgemäß hilft es den Beteiligten noch mehr, wenn auch bei diesen Relationsvergleichen keine Zeiteinheiten verwendet werden. Die Frage "Wenn das Erstellen einer Word-Verarbeitung 5 Tage gedauert hat, wie lange dauert dann die Excel-Verarbeitung?" ist zwar einfacher zu beantworten als "Wie lange dauert das Erstellen einer Excel-Verarbeitung?", trotzdem werden sich viele Menschen schwer tun. Leichter fällt es den meisten bei neutralen Einheiten, die nicht sofort mit Zeiteinheiten zu verbinden sind.

Die üblichste dieser neutralen Einheiten sind so genannte Story Points (meistens eine abgewandelte Fibonacci-Reihe), aber es gibt auch T-Shirt-Größen, Tierarten (wie im Symbolbild oben) oder andere selbstentwickelte Einheiten. Das kann jedes Team für sich optimieren.

Montag, 11. September 2017

Erfolgs-User Stories

FS
Bild: Wikimedia Commons / Abdulrahman Raofi - CC BY 4.0
Wieder etwas dazugelernt: in einem zur Zeit von mir gecoachten Team wird eine Art von Anforderungsbeschreibung verwendet die ich noch nicht kannte - die Erfolgsgeschichte, bzw. Erfolgs-User Story. Sie beschreibt einen (noch nicht eingetretenen) Fortschritt der Produktentwicklung aus der Sicht desjenigen, der ihr Ergebnis bereits benutzen kann. Ein Beispiel:

"Zum Glück sind ist die Performance unseres Systems besser geworden, gerade noch rechtzeitig vor der Einspeisung der Partnerdaten. Jetzt können wir sie nutzen ohne durch lange Ladezeiten aufgehalten zu werden."

Wie im Fall normaler User Stories gibt es auch hier präzisierende Akzeptanzkriterien, allerdings in einer neuen Form: "Das war nur möglich weil der Datenbankindex angepasst wurde." "Das war nur möglich weil Duplikate bereinigt wurden.", etc.

Bei genauerer Betrachtung steckt etwas Ähnliches dahinter wie im Fall einer normalen User Story, nämlich der grundlegende Use Case mit angehängtem Business Value, bei Bedarf ergänzt um eine Rolle. Auch die Akkzeptanzkriterien sind trotz der neuen Formulierung inhaltlich mit den alten vergleichbar. Der Mehrwert dieses neuen Ansatzes ergibt sich aus seinem Einsatz in der Zusammenarbeit mit Kunden, Anwendern und Auftraggebern.

Im Rahmen von Anforderungs-Workshops kann man jetzt Fragen stellen wie "Welche Erfolgsmeldung würden sie als nächstes hören wollen?" oder "Welche Erfolgsmeldung möchten Sie als nächstes verkünden können?". Anders bei der klassischen Frage "Was brauchen Sie alles?" ist in einer Antwort darauf bereits eine Priorisierung eingeflossen. Darüber hinaus wird auch die (implizite) Erwartungshaltung aufgelöst, eine Anforderung umfassend beschreiben zu müssen.

Auch hier bedarf es natürlich einer gewissen Übung, damit ein Stakeholder nicht auf die Idee kommt ein "Zum Glück ist alles fertig"zu verfassen. Sobald das geschafft ist kann eine Erfolgs-User Story aber eine gute Ergänzung zu der klassischen Form sein.

Donnerstag, 7. September 2017

Why agile: Gesetzesänderungen

FS
Bild: Pixabay / Jörg Elman - CC0 1.0
"Warum sollen wir jetzt agil werden? Uns betrifft das doch nicht. unser Tagesgeschäft läuft stabil, keine großen Neuerungen, kein intensiver Wettbewerb." Äusserungen wie diese gibt es immer wieder aus Firmen, Behörden und sonstigen großen Organisationen. Tatsächlich ist es auch in vielen wirklich so, dass die Rahmenbedingungen sehr stabil und unveränderbar scheinen. Dass es aber auch in einem scheinbar ruhigen Umfeld zu unerwarteten Änderungen kommen kann zeigt ein aktuelles Beispiel.

Vor gerade erst zwei Monaten hat der Bundestag die Ehe für alle beschlossen, so dass bald auch gleichgeschlechtliche Paare heiraten dürfen. Ab dem ersten Oktober können sie zum Standesamt gehen und sich dort trauen lassen, werden danach aber auf ein technisches Problem stossen: in der dort verwendeten Software befinden sich weiterhin Felder für Ehemann und Ehefrau. Für eine Eintragung von zwei Ehefrauen oder zwei Ehemänndern muss diese Software angepasst werden, und das dauert voraussichtlich (festhalten) bis Herbst 2018. Vierzehn bis sechzehn Monate nach der Gesetzesänderung.

Dieses Beispiel erscheint extrem, es ist aber gewöhnlicher als man denken sollte. Gerade bei älterer Software können die Planungs-, Umsetzungs oder Rolloutprozesse so langwierig sein, dass es selbst bei kleineren Änderungen länger als ein Jahr dauern kann bis neue Versionen in Betrieb genommen sind. Gründe dafür sind umständliche Genehmigungsvorschriften, schlechte Dokumentation der bestehenden Anwendungen, schlechte Absicherung durch Tests und vieles mehr.

Da in diesem Fall der Staat selbst von seiner Gesetzgebung betroffen ist werden sich die Konsequenzen im überschaubaren Rahmen halten, es braucht aber nicht viel Phantasie um sich Konstellationen vorzustellen in denen er strikt auf der zügigen Umsetzung bestehen würde. Mögliche Beispiele finden sich vor allem in stark regulierten Branchen wie im Finanzwesen und der Stromerzeugung, und spätestens beim Thema Verbraucher- oder Umweltschutz ist so ziemlich die ganze Wirtschaft betroffen.

Würde in solchen Fällen mehr als ein Jahr vergehen bis gesetzliche Vorgaben umgesetzt werden, es könnte für die jeweiligen Unternehmen unangenehm werden. Von daher ist die Fähigkeit zur schnellen Anpassung der eigenen Systeme (→ Agilität) etwas das man auch in einem scheinbar stabilen Umfeld haben sollte.

Montag, 4. September 2017

Ein Bild sagt mehr als 1000 Worte (XIX)

FS
Auf dieses Bild gibt es zwei Reaktionen. Menschen die nicht in der Softwareentwicklung arbeiten: Wow, so viel? Menschen die in der Softwareentwicklung arbeiten: Wow, so wenig?

Donnerstag, 31. August 2017

Kommentierte Links (XXVIII)

FS
  • Tendayi Viki: Lessons From Kodak’s Bankruptcy - How Can Large Companies Sustain Innovation?

    Direkt zu Beginn dieses Textes wird die Tragik des Untergangs von Kodak auf den Punkt gebracht: die Firma ging nicht nur unter weil ihre Erzeugnisse durch den technischen Wandel obsolet wurden, sie hatte diesen Wandel selbst begonnen, wollte dann aber doch nicht auf ihre traditionellen Erfolgsprodukte verzichten. Tendayi Viki geht davon aus, dass ein solches Management-Verhalten seinen Ursprung in einer falschen Ausbildung der Manager an den Universitäten und in den Firmen hat, wo vermittelt wird, dass eine Fokussierung auf ein einziges Geschäftsfeld sinnvoll ist. Sein Gegenvorschlag besteht darin bis zu 30 % der Ressourcen auf neue und disruptive Geschäftsmodelle mit noch unklaren Erfolgschancen zu verwenden und diese möglichst früh validierbar zu machen. Klingt gut, es bleibt aber die Frage wie das mit kurzfristigen Shareholder-Interessen in Einklang zu bringen sein wird.

  • Ron Jeffries: Business Agile - Built Upon Sand

    Ob Business Agility und agiles Projektmanagement wirklich neue Trends sind und ob sie grundsätzlich das Risiko in sich tragen die eigentliche Agilität mit zu viel Prozessen einzuengen würde ich hinterfragen. Ron Jeffries hat aber Recht damit, dass es eine spürbare Tendenz gibt agile Transformationen als rein organisatorische Vorhaben zu sehen und die technischen Implikationen auszublenden. Bei vielen Managern gibt es den Irrglauben, dass eine zweitägige Zertifizierung oder eine zweiwöchige Begleitung durch einen Coach ausreichen um ein Team "agil zu machen". In meiner Erfahrung sind eher mehrere Monate nötig, aber das muss erstmal jemand bezahlen wollen. Wobei klar ist - wer eine billige Transition will zahlt meistens drauf.

  • Jurgen Appelo: Frameworks are like Radio Stations

  • Da Jurgen Appelo zur Zeit an einem Framework-unabhängigen Methodenbaukasten arbeitet sind seine in letzter Zeit zunehmenden Äusserungen über die Starrheit und Unflexibilität dieser Frameworks mit Vorsicht zu betrachten. Einen zutreffenden Kern haben sie aber, hier werden Freiheiten und Optionen bewusst durch Leitplanken eingegrenzt. Ich bin auch bereit zu hinterfragen ob agile Teams diese Leitplanken wirklich brauchen, erfahrungsgemäß ist das oft nicht der Fall. Wenn aber auf der anderen Seite unerfahrene Teams versuchen die Methoden anzupassen endet das sehr oft in Verschlimmbesserungen. Harikiri, wie ich es nenne. Frameworks haben ihren Sinn, man muss ihn sich nur bewusst machen statt ihnen kritiklos zu folgen.

  • Urs Enzler: Problem-Centric User Stories

    Einer der klassischen Fehler die man bei User Stories machen kann ist, dass bereits Lösungen beschrieben werden statt der Bedürfnisse des Benutzers oder des Kunden. Übertroffen wird das gelegentlich noch durch die Beschreibung von Bearbeitungsschritten ("Als Sachbearbeiter möchte ich auf einen Knopf drücken ..."). Der Lösungsansatz von Urs Enzler ist der Richtige, da er das Erarbeiten der Lösung beim Team lässt. Die Voraussetzung dafür ist allerdings, dass in dem auch wirkliche Software-Entwickler sitzen und nicht nur Coding Monkeys. (siehe auch: "As a User" needs to stop).

  • Mind the Product: Scaling Autonomous Teams

    Mit ihrer Aussage "It's all about Business Agility" gibt Debbie Wren scheinbar eine Gegenthese zu Ron Jeffries (weiter oben) ab. Wo sie wieder mit ihm zusammenkommt: um das zu erreichen ist (unter anderem) "technische Agilität" notwendig. Erst das, in Kombination mit Autonomie und Empowerment, macht Business Agility möglich.

Montag, 28. August 2017

Die verlorene agile Disziplin - Domain Driven Design (DDD)

FS
Vor einiger Zeit gehörte Christoph Baudson zu einem Entwicklungsteam das ich coachen durfte. Deshalb freut es mich um so mehr, dass ich heute auf ihn, bzw. seinen Vortrag auf der Froscon 2017 verlinken kann.



Auch jenseits persönlicher Sympathie ist das Video sehenswert, da DDD in der Tat relativ selten diskutiert wird. Und wie Christoph richtig sagt: man muss es nicht als Konkurrenz zu Frameworks wie Scrum sehen sondern als mögliche Ergänzung.

Donnerstag, 24. August 2017

Warum Konzerne nicht versuchen sollten agil zu werden

FS
Bild: Max Pixel / Freegreatpicture - CC0 1.0
Im Vergleich zu kleineren Unternehmen tun sich Konzerne häufig besonders schwer wenn es darum geht agile Vorgehensmodelle einzuführen. Dabei fehlt es meistens nicht am Willen, zumindest nicht an dem des Managements. Gemeinsam um einen langen Konferenztisch sitzend schaut man sich tief in die Augen und versichert sich gegenseitig "Wir werden Agil", tritt vor die Belegschaft und spricht auf Kickoff-Veranstaltungen um die Botschaft hinauszutragen in das eigene Unternehmen. Die Mitarbeiter verstehen, sie haben den Auftrag Agil zu werden. Die Umsetzung beginnt. Und dann passiert das genaue Gegenteil.

Das Problem in vielen Organisationen ist, dass sie ein falsches Verständnis von Agilität haben. Agilität wird gleichgesetzt mit den Rollen und Meetings von Scrum, SAFe und Spotify. Gibt es in den IT-Teams statt Teamleitern Scrum Master? Check. In den Fachabteilungen statt Business Analysten Product Owner? Check. Der Statusbericht heisst jetzt Daily Standup? Check. Die Architektur- und QA-Teams heissen jetzt Gilden? Check. Das Problem: hinter den neuen Rollen, Personen und Strukturen bestehen die alte Kultur und die alten Mindsets weiter. Das bloße Einführen neuer Organisationsstrukturen ändert gar nichts.

Was hier passiert ist nichts anderes als eine Umkehrung von Mittel und Zweck. Eigentlich sind agile Methoden nur ein Mittel um den Kulturwandel zu stützen und zu befördern der Voraussetzung ist um den eigentlichen Zweck zu erreichen: kurze Time to Market, hohe Reaktionsgeschwindigkeit, Vermeidung sinnloser Arbeit. Nur dafür wurden die Frameworks, Rollen und Events erfunden und nur wenn sie darauf ausgerichtet sind machen sie Sinn. Wenn sie stattdessen als Selbstzweck eingeführt werden ist dieser nicht mehr gegeben. Einen Product Owner zu benennen nur damit er da ist bringt niemandem etwas.

Dass es trotzdem immer wieder vorkommt liegt daran, dass die meisten großen Unternehmen sich mit "weichen" Begriffen wie Kulturwandel oder Mindset-Weiterentwicklung extrem schwer tun. Nach Jahrzehnten der "Optimierung" durch zahllose Unternehmensberatungen greift fast überall der Reflex, dass sofort alles gemessen, gezählt und anhand dieser Zahlen kontrolliert werden muss. Und im Fall einer Agile- oder Scrum-Einführung ist das erste im Wortsinn Zählbare das man findet die Anzahl der Teams die schon die neuen Rollen und Meetings haben. Die alte Kultur formt die agilen Vorgehensmodelle auf diese Weise wieder in Command & Control um.

Um diese Zustände zurück auf die Füße zu bringen kann es sinnvoll sein die Begrifflichkeiten der Agilität fallenzulassen (und damit aus dem Focus der "Zähl- und Mess-Fetischisten" zu nehmen) und den eigentlichen Zweck wieder in den Mittelpunkt zu stellen. Wenn kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit erreicht werden sollen, dann kann man das auch so benennen. Und die dahinführenden Maßnahmen werden automatisch die sein müssen die man aus Scrum & Co kennt: Nähe zum Kunden, flache Hierarchien, schlanke Prozesse und Automatisierung sich wiederholender Tätigkeiten. An dieser Stelle angekommen kann die Zähl- und Mess-Fixierung sogar wieder zum Vorteil werden - die Erkennung und Messung von Lead Times, Cycle Times und Reaktionszeiten ist genau das was man für die (von Natur aus datengetriebenen) agilen Vorgehensmodelle braucht.

Am Ende ist es fast ein Paradoxon. Sich das Ziel zu setzen Agil zu werden führt viele Konzerne in eine Sackgasse. Auf diese Bezeichnung zu verzichten kann Agilität dagegen fördern.

Montag, 21. August 2017

Team-Urlaub für einen Sprint

FS
Bild: Pixabay / Walkerssk - CC0 1.0
Als Agile Coach besuche ich bei einem meiner Kunden in unregelmässigen Abständen die Scrum Teams bei ihren Sprintwechseln. Auch letzte Woche war es wieder soweit, allerdings nur in kleinster Runde - neben dem Product Owner waren nur ein Entwickler und ein Business Analyst anwesend, das restliche Team (den Scrum Master eingeschlossen) befand sich in den Sommerferien. Naheliegenderweise war das auch das Thema der Retrospektive: wie kann unter solchen Bedingungen noch ein geregelter Arbeitsbetrieb aufrechterhalten werden?

Diese Frage dürfte bei so gut wie jedem Scrum Team regelmässig auftreten, und das nicht nur im August sondern in allen üblichen Ferienzeiten, z.B. Ende Dezember. Jedesmal wenn sich ein Teil der Teammitglieder für einige Tage oder Wochen verabschiedet fehlen Erfahrungswerte, unerwartete Mehraufwände fallen schwerer ins Gewicht und Arbeitstechniken wie Pair Programming oder Code Reviews können ggf. gar nicht mehr angewandt werden, weil wie im gerade genannten Beispiel nur ein Entwickler übrig ist.

Ein Lösungsansatz den ich bei einem anderen Kunden gesehen habe war, dass ein Team sich entschieden hat geschlossen in den Urlaub zu gehen, und zwar für genau einen Sprint. Nach der Retrospektive des Sprints davor gingen alle in ihre Ferien. Nach der Rückkehr gab es ein kurzes Backlog Refinement um sicherzustellen, dass sich in der Zwischenzeit nichts Neues ergeben hatte, danach ging der normale Rhythmus mit einem Planning wieder los.

Der Vorteil dieses Vorgehens war, dass die oben genannten negativen Effekte auf diese Art vermieden werden konnten. Statt mehrere Sprints mit ausgedünnter Personaldecke zu haben war das Team mit Ausnahme dieser zwei Wochen durchgehend voll besetzt, der "Urlaubssprint" wurde in der Sprintplanung ignoriert und auch in der Berechnung der Velocity nicht berücksichtigt. Dass das Review ausfallen würde wurde den Stakeholdern rechtzeitig vorher mitgeteilt.

Was dieses Vorgehen in diesem Fall begünstigt hat war eine besondere Rahmenbedingung: das Team war Teil eines Tribes, so dass andere Teams einspringen konnten wenn Bugfixing- oder Support-Aufgaben zu erledigen waren. In Konstellationen in denen das nicht der Fall ist müsste man über Ausgleichsmaßnahmen nachdenken. Eine die ich an anderer Stelle miterlebt habe war z.B. die, dass ein Team-Mitglied sich bereiterklärt hat seinen Urlaub später zu nehmen. Während des Urlaubssprints arbeitete er aber in einem anderen Team mit, wodurch die Auswirkungen der Ferienzeit auch dort abgeschwächt wurden.

Donnerstag, 17. August 2017

Scaled Agile: Chapter (Querschnittsorganisationen)

FS
Bild: Flickr / iMorpheus - CC BY 2.0
Die Verwendung des englischen Begriffs "Chapter" für eine Untergruppe einer größeren Organisation ist in Deutschland noch immer ungewöhnlich, sie kommt vor allem im Zusammenhang mit Rocker-Clubs wie den Hells Angels oder den Bandidos vor. Im englischen Sprachraum ist er dagegen viel normaler und wird für Gruppen jeglicher Art verwandt. Auch im Kontext agiler Skalierung ist er in Mode gekommen und bezeichnet hier in der Regel eine Querschnittsorganisation zur Koordination verschiedener Entwicklungsteams.

Genau wie der Begriff des Tribes ist der des Chapters durch den Skalierungsansatz der Firma Spotify bekanntgeworden, wo diese beiden Konzepte auch in Verbindung miteinander stehen. Ein Tribe ist dort eine Gruppe von Teams die an einem gemeinsamen (Teil)Produkt arbeiten, weshalb sie durch gegenseitige technische und fachliche Abhängigkeiten verbunden sind. Um sich nicht gegenseitig zu behindern ist eine Koordination zwischen diesen Teams nötig. Da der klassische Lösungsweg (die Einsetzung eines koordinierenden Managers) zu Hierarchien und Flaschenhälsen führen würde, wurde ein anderer Ansatz entwickelt, die Chapter.

In einem Chapter sind aus allen beteiligten Teams die Verantwortlichen für jeweils ein Spezialgebiet zusammengefasst. Häufig sind das Frontend, Backend und QA, es sind aber auch andere Konstellationen möglich, z.B. UX oder SEO. Zusammen haben sie die Aufgabe an übergreifenden Architekturen und gemeinsamen Standards und Tools zu arbeiten. Im Grunde eine ausdifferenzierte Version eines Scrum of Scrums, gewissermassen mit jeweils einem davon für jedes Spezialgebiet. Über Frequenz und Intensität der gegenseitigen Abstimmung entscheidet jedes Chapter dabei selbst.

Was ein Chapter ausserdem noch von einem Scrum of Scrums unterscheidet ist die Rolle des "Chapter Lead". Sie wird von einem der beteiligten Entwickler in Teilzeit ausgeübt und übernimmt das was von den klassischen Management-Tätigkeiten übrigbleibt: Personalentwicklung/Coaching, Gehaltsverhandlungen, Koordination des Recruitings, etc. Explizit nicht zu ihren Aufgaben gehört dagegen das Entscheiden fachlicher und technischer Konflikte oder das Vorgeben von Architekturen und Standards.

Wenn andere Organisationen versuchen Spotify zu kopieren ist die Rolle des Chapter Lead eine häufige Bruchstelle an der Probleme auftreten. Oft wird sie mit Personen besetzt die vorher Manager, Teamleiter, Architekt oder Lead Developer waren und sich aus ihrer alten, weisungsbefugten Rolle nur schwer lösen können. In solchen Fällen kann die helfende oder hemmende Begleitung durch einen Scrum Master oder Agile Coach Sinn machen.

Montag, 14. August 2017

Organizations that are fit for the Future

FS
Das Internet hält offensichtlich einen nie versiegenden Nachschub mitreißender Redner bereit. Die neueste Entdeckung ist Gary Hamel, der sich das Thema der zukunftsfähigen Organisationen zu eigen gemacht hat:

Gary_Hamel from Speaking.com on Vimeo.


Wie viele professionelle Konferenzredner ist er nicht nur rhetorisch brilliant sondern verfügt auch über das Wissen wie man gute, den Vortrag unterstützende und trotzdem nicht ablenkende Powerpoint-Präsentationen erstellt. Und sein ab Minute 07.40 vorgestelltes Beispiel von "Reverse Accountability" in einer indischen Firma ist wirklich inspirierend.

Donnerstag, 10. August 2017

Why agile: Feature-Wettrennen

FS
Bild: Pixabay / Macayran - CC0 1.0
Zu agiler Softwareentwicklung in der Lage zu sein kann vor allem für Firmen in umkämpften Märkten Vorteile bringen. Kurze Time to Market, schlanke Prozesse und schnelle Feedbackzyklen sind zwar eigentlich immer erstebenswert, besonders aber in einer Situation: wenn mehrere Unternehmen vergleichbare Produkte entwickeln und sich dabei einen Wettlauf um neue Features liefern. Jede der beteiligten Firmen versucht Kunden zu gewinnen und an sich zu binden indem sie zum Einen alle Funktionen der Konkurrenz kopiert und zum Anderen das eigene Produkt immer schneller weiterentwickelt, um so dauerhaft einen Vorsprung zu haben. Um konkurrenzfähig zu bleiben müssen die anderen mitziehen, und so geht es weiter und weiter, bin einer nicht mehr mithalten kann und aufgeben muss.

Die beiden Firmen die diese Vorgehensweise am weitesten perfektioniert haben dürften vermutlich Facebook und Google sein, die sich bereits mehrere solche Wettläufe geliefert haben. Facebook hat einen solchen im Jahr 2009 sowohl gegen Twitter als auch gegen StudiVZ gewonnen und führt im Augenblick einen gegen Snapchat. Google hat alle anderen Suchmaschinen (Altavista, Yahoo, Lycos, Ask, Bing, etc.) weit hinter sich gelassen und 2009 seinen Landkartendienst gegen Apple um die Wette entwickelt. Der aktuelle Wettstreit findet gegen ein Unternehmen namens Pinterest statt, das im Nischenmarkt der Bildersuche und -kuratierung ein Konkurrent ist. Beide Firmen arbeiten zeitgleich an Bilderkennung und Schnittstellen, wodurch z.B. Kuchenbilder sowohl mit ähnlichen Aufnahmen als auch mit Rezepten verknüpft werden können.

Pinterest vs. Google

Auf lange Sicht bedenklich ist, dass die beiden Großunternehmen durch ihre Fähigkeit Feature-Wettrennen zu gewinnen praktisch jede neue Konkurrenz marginalisieren können. Selbst disruptive Technologien und Ideen bringen wenig wenn ein bereits etablierter Wettbewerber sie in kürzester Zeit kopieren und in sein Produkt einbauen kann. Auf der anderen Seite kann man gespannt sein ob der ständige Nachbau von Konkurrenzprodukten nicht irgendwann zu überladenen Funktionsumfängen und Codebases führen wird. Die wiederum wären für Agilität hinderlich.

Montag, 7. August 2017

Diversität

FS
Bild: pxhere - CC0 1.0
Der Sturm der in den letzten Tagen durch das Wasserglas der Tech-Industrie gegangen ist drehte sich um die Firma Google, genauer gesagt um deren Maßnahmen zur Diversitätsförderung. In einem kontroversen und viralen Diskussionsbeitrag wurden diese von einem Mitarbeiter in Frage gestellt, da sie aus seiner Sicht zwar gut gemeint aber schlecht umgesetzt sind [Edit: Da ich es anscheinend nicht deutlich genug formuliert habe - nein, ich teile diese Meinung dieses Herrn nicht]. Selbst in diesem Beitrag wird Diversität aber als etwas grundsätzlich Notwendiges betrachtet, eine Sicht der Dinge die immer populärer wird. Es stellt sich die Frage - warum ist das so? Warum ist Diversität unter den Mitarbeitern etwas Erstrebenswertes? Und bringt sie einem Unternehmen wirklich einen Mehrwert? Ja, das tut sie, und zwar aus mehreren Gründen.

Zunächst deshalb, weil diverse Teams in der Regel eine größere Vielfalt an möglichen Innovations- oder Lösungsoptionen erarbeiten können. Entgegen einer häufigen Annahme allerdings nicht weil Diversität das befördert sondern weil Gleichartigkeit das behindert. Je homogener eine Gruppe ist, desto einmütiger denkt sie und verhält sie sich. Dieses Phänomen, das so genannte Group Think, wird durch diverse Teams aufgebrochen.

Als Zweites kommt ein wirtschaftlicher Aspekt dazu. In Zeiten des Fachkräftemangels ist es nahezu fahrlässig wenn weite Teile der Bevölkerung einem Segment des Arbeitsmarktes nicht zur Verfügung stehen. Man muss dazu nicht nach Kalifornien blicken, es reicht ein Blick in eine Maschinenbau-, IT- oder Buchhaltungsabteilung eines beliebigen deutschen Unternehmens. Frauen und Gastarbeiter-Kinder sind hier sehr, sehr, selten. Angesichts zahlloser unbesetzter Stellen ist das ein Zustand den zu ändern sich lohnen würde.

Zuletzt kann Diversität zu einer besseren (weil ausgeglicheneren) Firmenkultur führen. Es ist ein tiefer Griff in die Klischee-Kiste, aber rein männliche Teams neigen häufig zu einer gewissen Ruppigkeit im Umgang, Teams aus älteren Mitarbeitern hinterfragen Routinen seltener und rein deutsche Teams sind tendenziell weniger sensibel gegenüber kulturellen und religiösen Befindlichkeiten ausländischer Mitarbeiter (und Kunden). In diversen Teams ist all das meistens besser.

Natürlich ist Diversität nicht die Wunderlösung für alles, die gibt es nicht. Gerade in agil arbeitenden Unternehmen, solchen also in denen Offenheit und Anpassungsfähigkeit eminent wichtig sind, ist sie ein wichtiger Baustein für Erfolg und Wettbewerbsfähigkeit. Dass man damit auch Kontroversen auslösen kann zeigt das oben genannte Beispiel Google [Edit: Siehe dazu auch diesen Beitrag in der Zeit, diesen aus der FAZ oder diesen aus der New York Times]. Allerdings ist davon auszugehen, dass sich auch hier mittels Inspect & Adapt eine Lösung finden lassen wird.
Powered by Blogger.