Kategorie: Agilität

Scrum ist, wie Entwickler arbeiten – nicht die ganze Welt

Daemonic Coder

Ich mag Scrum. Naja, okay, das ist vielleicht nicht so eine riesige Überraschung, wenn man einen Blog schreibt, der sich mit Agilität beschäftigt. Trotzdem glaube ich, dass ich das betonen sollte, bevor ich mich in diesen Artikel stürze.

Scrum ist gefühlt überall. Wenn irgendwo von Agilität die Rede ist, ist es oft das erste und einzige Framework, das genannt und in Betracht gezogen wird – oft in der unsäglichen Schreibweise SCRUM. Aber es ist ein Framework, das aus der Softwareentwicklung kommt und sich für genau diesen Kontext bewährt hat. Doch anstatt es dort sinnvoll einzusetzen, wird es immer häufiger als generelle Methode für alles Mögliche verwendet – ob es passt oder nicht.

Scrum ist für Software gemacht

Scrum wurde entwickelt, um die Arbeit von Softwareteams zu organisieren. Iterative Entwicklung, inkrementelle Verbesserungen und enge Zusammenarbeit im Team – all das sind Prinzipien, die wunderbar in die Art und Weise passen, wie Software entsteht. In einem Umfeld, in dem Anforderungen sich schnell ändern, technische Herausforderungen komplex sind und ein funktionierendes Produkt nicht einfach im Voraus durchgeplant werden kann, entfaltet Scrum seine Stärken. Die Rollen, Artefakte und Events sind genau darauf abgestimmt.

Aber: Scrum ist keine Universallösung. Es ist kein Allheilmittel für jegliche Art von Arbeit. Trotzdem versuchen viele Unternehmen, es auch in Bereichen einzusetzen, in denen es schlicht nicht funktioniert und die Vorausssetzungen nicht gegeben sind. Dazu gehören:

  • Ein iterativer Arbeitsstil mit regelmäßigen, funktionierenden Zwischenergebnissen – einen Satelliten stückchenweise ins All zu schießen wäre unsinnig.
  • Ein autonomes, interdisziplinäres Team, das eigenverantwortlich Entscheidungen treffen kann – bitte wirklich ein kritischer Blick in die Organisation, ob das nicht nur Wunschdenken wäre.
  • Ein Umfeld, in dem sich Anforderungen häufig ändern und schnelle Anpassungen notwendig sind

Doch wie oft werden diese Bedingungen ignoriert? Ich habe Scrum bereits in Bereichen gesehen, in denen es einfach nicht passt: von Marketing-Teams über HR-Abteilungen bis hin zu strategischen Projekten in Unternehmen. Was passiert dann? Die Meetings werden abgehalten, weil sie im Scrum Guide stehen, Sprints werden erzwungen, obwohl es keine sinnvollen Inkremente gibt, und das Team kämpft gegen ein Framework, das nie für seine Arbeit gedacht war.

Agilität bedeutet Anpassungsfähigkeit. Das sollte auch für die Wahl der Arbeitsweise gelten. Nur weil Scrum ein bekanntes und bewährtes Framework ist, heißt das nicht, dass es für jede Art von Arbeit oder jedes Team geeignet ist. Statt Scrum reflexartig als „den agilen Standard“ zu betrachten, sollten Unternehmen sich die Zeit nehmen, die passende Methode für ihre spezifische Situation zu finden. Denn Agilität bedeutet nicht, einfach nur Scrum zu machen – sondern so zu arbeiten, dass es wirklich funktioniert.

Holokratie – Taylorismus 2.0?

Daemonic Coder

Winslow Taylor gilt als der Erfinder des „Scientific Management“ mit der Idee, die Arbeitsabläufe eines Unternehmens vollständig zu beschreiben und so „perfekte“ Abläufe schaffen zu können. Und er gilt heute beinahe schon als Feindbild der agilen Unternehmen, da seine Ideen als hierarchisch und starr wahrgenommen werden. Und zugegebenermaßen waren seine Ideen Grundlage für eine gewisse Dehumanisierung in der Arbeitswelt. Aber: Das ist meist gar nicht die hauptsächliche Kritik am Taylorismus aus Sicht Agiler Transformationscoaches. Diese merken eher an, dass es in der komplexen Arbeitswelt nicht möglich sei, eine exakte, immer gültige Arbeitsaufteilung vorzugeben. Softwareentwicklung beispielsweise funktioniert nicht „wie am Fließband“.

Dem stimme ich übrigens uneingeschränkt zu.

Um so mehr wundert mich der Zuspruch, den Holokratie oft erfährt. Ich möchte hier nicht Holokratie beschreiben, das ist sicher an anderer Stelle ausführlich genug geschehen, nur meine Kritik oder Verwunderung daran formulieren: Die Idee von Holokratie ist es, dass es ein „Betriebssystem“ ist, das eine Beschreibung „perfekter“ Abläufe hervorbringen kann. Sicher, im Unterschied zum Taylorismus wird diese Beschreibung kollaborativ und nicht vom „allwissenden Management“ erzeugt, aber nichts desto trotz ist das Ziel eine möglichst vollständige (wenn auch veränderliche) Beschreibung der Prozesse.

Für mich klingt daher Holokratie wie ein Taylorismus 2.0.

 

Entschieden entscheiden – egal wer da ist

Daemonic Coder

In „klassischen“ Organisationsstrukturen ist die Frage, wer entscheiden darf, oft recht eindeutig geregelt: Der Chef bestimmt. Und wenn es keine hierarchische Chef-Rolle gibt, dann oft eine fachliche Führung, die entscheidet und die Verantwortung für die Entscheidungen trägt oder zumindest tragen sollte.

Beim Wechsel hin zu einer agileren Organisation beobachte ich oft, dass Teams für sich einen Weg suchen, wie Entscheidungen im Team gemeinschaftlich getroffen werden können. Mehrere Methoden stehen dabei oft zur Diskussion:

  • Mehrheitsentscheid
  • Konsenzverfahren
  • Widerstandsmessung
  • Konsentverfahren

Sicher gibt es nicht die eine Methode, die immer und für alle am besten funktioniert. Aber ich möchte an dieser Stelle aus einem bestimmten Grund die Lanze für das Konsentverfahren brechen:

Gut abgestimmte Teams müssen beim Konsentverfahren keine Beschlussfähigkeit feststellen und sie sind jederzeit flexibel, Entscheidungen zu treffen.

Der erste Reflex vieler Teams für eine Entscheidungsfindung ist oft ein Mehrheitsentscheid. In der Diskussion wird dann aber schnell deutlich, dass zu besprechen ist, wie viele aus dem Team anwesend sein müssen, um eine Entscheidung überhaupt treffen zu können oder ob anstehende Entscheidungen gar im Vorfeld (Agenda) angekündigt werden müssen, um eine Beschlussfähigkeit zu haben. Meiner Meinung nach ist das bei einem Konsentverfahren gar nicht nötig.

Ein Konstentverfahren beschreibe ich so: Steht eine Entscheidung an, so können alle Teammitglieder entweder ihre Zustimmung ausdrücken (Daumen hoch), eine Entscheidung des Teams mittragen (Daumen seitlich) oder gegen die Entscheidung stimmen (Daumen runter). Letzteres ist aber nur mit einem „qualifizierten Einwand“ möglich, also einem Vorschlag, wie der Widerspruch aufgelöst werden kann. Ein solcher Einwand kann auch sein „das können wir nur unter Einbeziehung einer weiteren Person entscheiden“.

Ein Beispiel: Ein Team möchte über eine Änderung der Softwarearchitektur entscheiden, beispielsweise, ob bestimmte Funktionalitäten aus einem Monolithen herausgezogen und in Microservices migriert werden sollen. Bei der Entscheidung darüber kommt es zu einem Widerspruch mit der Begründung „Heute ist Sarah nicht da, die am meisten Erfahrung mit Microservices hat, wir sollten sie auf jeden Fall in die Entscheidung einbeziehen, wenn sie morgen wieder da ist.“

Der Vorteil dessen ist, dass man eine Entscheidung nicht von einem bestimmten Quorum abhängig macht, sondern von der Entscheidungskompetenz der Teammitglieder. Es würde in diesem Beispiel nichts bringen, wenn aus dem Team alle Frontend-Entwickler anwesend wären, die kaum Aussagen zu Microservices machen können.

Voraussetzung, damit dies funktioniert, ist allerdings eine gewisse Teamreife. Nur, wenn man die Fähigkeiten der anderen im Team einschätzen kann, ist ein solcher Widerspruch überhaupt nötig. Aber dann ist das Verfahren meiner Meinung nach besser geeignet, als ein Quorum, das eventuell am Ziel vorbei geht oder eine Verpflichtung zur Vorveröffentlichung, was die Flexibilität sehr einschränken kann.

Kurz gesagt: Nutzt das Konsentverfahren ohne Quorum. Erst, wenn das nicht greift, sollten meiner Meinung nach andere Entscheidungsverfahren genutzt werden.

Riesige Risiken und Erwartungen des Managements

Daemonic Coder

Risikomanagement — einer der zentralen Prozesse (nicht nur) im Projektmanagement, eigentlich in jedem (nicht nur) wirtschaftlichen Handeln. Eigentlich sollt man daher meinen, dass Risikomanagement sehr verstanden sein sollte. Leider beobachte ich oft, dass das nur eingeschränkt der Fall ist, spätestens, wenn vom Management die Aufforderung kommt, man solle „Risiken aktiv managen“, so stolpere ich mental oft und frage mich, ob hier alle Beteiligten das gleiche Verständnis haben.

Ich möchte hier nicht zu sehr auf das „normale“ Risikomanagement mit Sammeln, bewerten und Überwachen der Risiken eingehen, denn das kann ganz leicht in geduldigen Excel-Listen oder Tools gemacht werden (und an anderer Stelle nachgelesen werden), ohne dass man sich wirklich über die Implikationen und Erwartungen einig wird. Meine These: Wenn „Manager“ sagen, man solle Risiken aktiv Managen, so scheinen sie oft zu meinen „Sorgt dafür, dass die Risiken gar nicht eintreten.“ Der Unterton: Wir sind uns der Risiken bewusst und akzeptieren diese, liebe Mitarbeiter, aber sorgt dafür, dass nichts schief geht.

Mal einen Schritt zurück, wie kann man mit Risiken umgehen? Spontan fallen mir folgende Möglichkeiten ein:

  1. Risiko akzeptieren
  2. Risiko mitigieren (also abtreten, bspw. durch eine Versicherung)
  3. Eintrittswahrscheinlichkeit senken
  4. Erwarteten Schaden senken

„Risiken aktiv managen“ im Management-Sprech ist also oft Möglichkeit 3, dabei sogar oft ein Extremfall davon, nämlich das Reduzieren der Eintrittswahrscheinlichkeit auf 0. Oft hieße das aber, ein Projekt oder ein Vorhaben gar nicht erst durchzuführen. Andererseits möchte das Management ja, dass die gewinnbringenden Projekte durchgeführt werden, am besten, ohne Zusatzkosten. Das wäre mit Option 1 möglich. Daher der widersprüchliche Wunsch, das Risiko zu akzeptieren und gleichzeitig aktiv managen. In der Realität werden Risiken akzeptiert, wenn der Schaden eintritt will es aber niemand gewesen sein.

Übrigens ist in einem agilen Vorgehen wie Scrum meiner Meinung nach bereits eine ganze Menge Risikomanagement fest eingebaut – vielleicht ist dies sogar der zentrale Vorteil, den Scrum gegenüber einem klassischen Projektvorgehen hat.

Warum schätzen wir das Schätzen so?

Daemonic Coder

Ich hatte kürzlich die Gelegenheit, mich mit einem Kollegen auszutauschen, der neuerdings erstmalig in einem größeren agilen Projekt arbeitet. Er berichtete mir von einigen Schwierigkeiten im Projekt, ein interessanter „Kristallationspunkt“ dieser Probleme zeigte sich im Thema „Schätzungen“ und wie diese im Team angegangen werden.

Zunächst ein paar Infos zum Hintergrund: Mein Kollege hat viel Erfahrung mit „klassischen“ Projekten, in denen er beteiligt und als (Teil-)Projektleiter eingesetzt war, von den Projekten waren auch viele erfolgreich. Er ist jetzt als technischer Berater in einem groß skalierten Scrum-Projekt, das für seinen Auftraggeber auch eine der ersten Berührungen mit agilem Vorgehen ist. Dementsprechend gibt es in dem Projekt und im Umfeld des Projektes eine bunte Mischung aus dem Wunsch, alles „richtig“ und „by the book“ zu machen und Erwartungen und Gewohnheiten, die sich noch sehr an dem bisherigen Vorgehen aurichten.

Eines der Rituale, das dort eingeführt wurde, ist auch das Planning Poker, mit dem den Sprint-Aufgaben Story Points gegeben werden. Daran störte sich nun mein Kollege sehr – von der Frage, warum man denn nun auf einmal Komplexität statt Aufwand schätzen sollte bis hin zu dem zähen Vorgehen, da man in Unkenntnis des Aufgabeninhaltes Zahlen „raten“ müsse.

Interessant war für uns im Gespräch darüber, dass sich einige Dysfunktionalitäten des Vorgehens genau an diesem Punkt heraus kristalisierten.

Der offensichtlichste Punkt ist der, dass es in dem Team aktuell kaum Teamarbeit gibt – im Endeffekt hat jedes Gruppenmitglied seine oder ihre Aufgaben und arbeitet diese innerhalb des Sprints ab, man kann kaum anderen helfen, da jeder ein Spezialgebiet bearbeitet. Das macht die Schätzrunden schwierig, da jeweils immer nur ein Teammitglied eine Aussage zur Komplexität machen kann, während die anderen versuchen zu „erraten“, was diese Person wohl schätzen wird.

Die eigentlichen Probleme im Team zeigen sich aber, wenn man beginnt zu hinterfragen, warum überhaupt Schätzungen gemacht werden. Wenn ja ohnehin jeder seine Aufgaben hat, wird die Schätzung dann benötigt um zu wissen, ob die Aufgaben in den Sprint passen? Soll mit dem Schätzen sichergestellt werden, dass alle im Team das gleiche Verständnis der Aufgabe haben?

Leider war die Antwort, dass das Schätzen benötigt werde, da das Projektcontrolling damit die Leistungsfähigkeit des Teams messen und überprüfen wolle. Darin sehe ich ein grundsätzliches Problem, das ich hier schonmal angesprochen habe, nämlich, dass ein Indikator zu einem (zumindest indirekten) Ziel erklärt wird. Schließlich soll sich – so die Erwartung des Controllings – der Output des Teams ja verbessern. Wenn das erwartet wird, so sorgt dies bestenfalls zu einem Drift der Schätzungen nach oben. Doch selbst, wenn das nicht der Fall wäre: Die Schätzung der Komplexität (meinetwegen auch des Aufwandes) der Aufgaben ist für diese Fragestellung eine absolut unbrauchbare Schätzgröße! Damit wird bestenfalls der konstante (oder steigende) Mittelabfluss sichergestellt, das sagt absolut nichts darüber aus, wie gut der Output des Teams ist! Dann sollte besser der Product Owner den Business Value der Features schätzen. (Und ja, auch da würde sich sicherlich die Schätzung verändern, wenn ich anfange, das zum Ziel zu erklären.)

Es gibt meiner Meinung nach einige Gründe, warum ein Schätzen durch ein Team sinnvoll sein kann. Beispielsweise, damit das Team weiß, wie viel Komplexität es im Sprint umsetzen kann. Hier kamen wir übrigens auf die Diskussion, warum dann nicht gleich Aufwand geschätzt werden sollte. Meiner Meinung nach deswegen, weil die Komplexität eine Einigung erlaubt, auch wenn die Skills im Team unterschiedlich verteilt sind. Es mag sein, dass ich für die Implementierung eines Features 5 Tage brauche, wenn ich mich in der Technologie nicht auskenne, eine erfahrenere Entwicklerin benötigt eventuell nur 2 Tage. So könnten wir uns nie auf einen Aufwand einigen, wohl aber darauf, dass eine CRUD-Applikation nicht allzu komplex wäre. Zudem kann ich mit der Schätzung von Komplexität auch belegen, dass zumindest ein ähnliches Verständnis für das Feature existiert. Nicht zuletzt habe ich damit einen Indikator, dass ein Team eine bestimmte Velocity hat und diese auch besser werden kann.

Das „Standardziel“ ist es, dass der PO mit den Schätzergebnissen eine Vorstellung davon hat, welche Features in einem längeren Zeitraum schaffen kann, diese Schätzungen helfen bei einer langfristigen Planung. Damit diese Schätzungen allerdings eine Aussagekraft haben, müssen eine ganze Reihe von Voraussetzungen erfüllt sein: Das Team muss relativ stabil sein, um seine Velocity kennen und halten zu können; die Schätzgrundlage muss stabil bleiben können, es darf also nicht durch falsche Zielvorgaben eine Veränderung der Schätzbasis belohnt werden; das Entwicklungsziel muss bekannt genug sein, um zukünftige Features sinnvoll und stabil beschreiben (und in der Komplexität kennen) zu können.

Kurz gesagt, Schätzen ist kein Selbstzweck. Bevor man eine Schätzmethode auswählt oder anwendet, sollte das Ziel der Schätzung klar sein, was in der Realität leider erstaunlich selten der Fall ist.

Digitalisierung – Was ist das?

Daemonic Coder

Bei „Captain Power and the Soldiers of the Future“ war das mit der Digitalisierung noch ganz einfach: Ab und an kam der Antagonist, ein fliegender Roboter namens Soaron und digitalisierte Menschen, die dann zu Robotern werden sollten. (Okay, ich gebe es zu: Ich bin ein alternder Nerd.) Heute ist das etwas schwieriger – jetzt wollen alle digitalisieren und eigentlich wissen die meisten gar nicht, was sie damit überhaupt meinen.

Digitalisierung ist „Agilität“, „Schnelligkeit“, „Kundenzentrierung“… Ich weiß gar nicht, was ich alles schon an Erklärungen gehört habe, was Digitalisierung sei. Es scheint also in erster Linie zu sein: Ein Buzzword ohne Bedeutung.

Trotzdem wird jedoch versucht, mit dem Begriff ein Phänomen zu beschreiben, das uns und die Wirtschaft sehr betrifft.

Die ursprüngliche Bedeutung des Wortes ist übrigens ziemlich nahe an dem „Captain Power“-Beispiel: Dokumente werden beispielsweise mit einem Scanner digitalisiert, also in ein Dateiformat für den Computer verwandelt. Die „Digitalisierung“, die in der Wirtschaft oft gemeint ist, ist davon meiner Meinung nach gar nicht so weit entfernt, hier geht es um die Abbildung von Geschäftsprozessen und Vertriebswegen in der IT. Sicherlich begann nach dieser Definition die Digitalisierung bereits, als Mainframe-Computer mit COBOL-Programmen die Folianten in manchen Unternehmen ablösten – aber wenn man nur dies unter Digitalisierung verstehen würde, so wären sogar deutsche Amtsstuben schon vorbildlich digitalisiert.

Digitalisierung geht meiner Meinung nach insofern noch weiter, als dass die IT nicht nur unterstützende Funktion in einzelnen Prozessschritten hat, sondern indem der (Geschäfts-)Prozess an sich durch die IT verändert wird. Das mag nach einer etwas haarspalterischen Unterscheidung klingen, ist jedoch ein fundamentaler Unterschied, ob ich einen Computer verwende, um in einer Autowerkstatt die Fehlerbeschreibung eines Kunden zu erfassen, oder ob der Motor selbst per IoT-Technologie einen Wartungstermin ausmacht, zu dem die benötigten Ersatzteile bereits geliefert wurden.

Die Herausforderung besteht daher in der „Digitalisierung“ darin, dass Entwickler nicht mehr nur in der Umsetzung der Geschäftsprozesse zuarbeiten. Früher war es durchaus möglich, dass sich der „Fachbereich“, der die Geschäftsprozesse definierte, der IT nur als Unterstützung bedienen konnte. Durch die Digitalisierung ist dies nicht mehr ausreichend! Der Fachbereich braucht selbst tiefes IT-Wissen, da das Design des Geschäftsprozesses von der IT stark beeinflusst werden muss.

Gerade für große Unternehmen und Konzerne bedeutet dies meiner Meinung nach, dass einige bisherige Trennung von operativen Bereichen und der IT aufgehoben oder zumindest aufgeweicht werden muss; die Rollen von CEO und CIO müssen verschmelzen.