Die Kunst den richtigen Prozess zu finden

Bei der Softwareentwicklung sind Team-Prozesse sind so gut wie unvermeidbar. Der Wunsch nach einfachen Prozessen ist dabei groß. Doch scheinen sie so gut wie nie zu passen. Prozesse können durchaus passen. Und dies ist kein Zufall. Es ist das Ergebnis eines Vorgehens, das hier vorgestellt wird.

Wer ein Team hat, hat einen Prozess

Sobald Menschen in einem Team zusammenkommen entstehen unvermeidlich Übergabepunkte. (Andernfalls arbeitet jeder für sich – und das ist keine Teamarbeit.) An diesen Übergabepunkten werden Ergebnisse ausgetauscht und die weitere Arbeit basiert auf darauf.

Der Wunsch einen Prozess definieren zu wollen, ist oft gering. Denn viele haben Prozesse bereits als Hürde und Beschränkung der persönlichen Freiheit und Effizienz erlebt und haben daher eine bisweilen ausgewachsene Aversion gegen Prozesse. Da ist es schwer einen Prozess zu etablieren. So manche Führungskraft, die zunächst als Fachkraft gearbeitet hat und selbst solche Prozesse kennengelernt hat, neigt anfangs noch stärker dazu, Prozesse nicht zu definieren, um einen natürlichen (von sich aus gewachsenen) Prozess zuzulassen.
Das so ein Vorgehen in den meisten Fällen nicht aufgeht ist dabei absehbar.

Scrum als Default

Gerade in der Softwareentwicklung genießt Scrum eine hohe Anerkennung. Dieser Prozess ist agil, schnell und leicht erklärt. Es scheint eine sichere Wahl zu sein. Selbstgebraute Prozesse könnten auf Widerstand und Skepsis stoßen. Der Gefahr will sich so manche Führungskraft nicht aussetzen. - Gegen Scrum wird ja wohl niemand was sagen.

Leider wird Scrum vielerorts immer noch falsch eingesetzt. Gerade als Scrum in Mode kam, war es an der Tagesordnung, dass Teams in größeren Unternehmen mit starren hierarchischen Strukturen Scrum einsetzen wollten. Da hat so mancher Vorgesetzte kurzerhand alte Gewohnheiten einfach nur auf Scrum-Begriffe um-etikettiert und meinte jetzt mit einem Pseudo-Scrum agil zu sein.
Schlimmer noch: Die Rolle des Scrum-Masters und Product Owners nahm zu oft der bisherige Vorgesetzte ein und vermischte so Scrum-Rollen mit unterschiedlichen Zielen. Dies kommt auch heutzutage noch öfters vor. Es führ dazu, dass die Rolle des Scrum Masters untergeht und der Vorgesetzte als Product Owner zu einem Antreiber wird, der die Prinzipien des Scrum früh verrät. Abgabetermine und Aufgaben werden weiterhin diktiert und das Team wird so nicht vor unrealistischen Erwartungen des Managements geschützt.

Andere wiederum mache es sich einfacher: Sie bedienen sich beim Scrum und anderen agilen Prozessen wie an einer Süßigkeiten-Theke und stellen sich so ihren eigenen agilen Prozess zusammen. Dem ist prinzipiell nichts einzuwenden, wenn der Prozess am Ende stimmig ist. Auch hier gibt es so manchen „Frankenstein“-Prozess der eher wie ein Monster daherkommt, als dem Team ein guter Freund zu sein.

Mit Kaizen und Retrospektiven zum besseren Prozess?

Die erfahrene Führungskraft aus den Bereichen Scrum oder Lean-Development wird Kaizen („Veränderung zum Besseren“) bzw. die Scrum-Retrospektive kennen. Diese sind prinzipiell gesehen sehr gute Mittel, um bestehende Prozesse zu verbessern und so stetig kleinere auftretende Hindernisse aus dem Weg zu räumen und den Prozess anzupassen.

Leider werden diese Ansätze zur adaptiven Veränderung als Ersatz für eine Modellierung von Prozessen gesehen. Zu oft wird auf Reibungspunkte und Defizite fokussiert und die eigentlichen Ziele des Teams aus den Augen verloren.

Wie alle agilen Methoden optimieren diese nur in kleinen Schritten vom aktuellen Stand der Dinge heraus. Dies sind Optimierungsmethoden, die das lokale Optimum suchen – und nicht das globale Optimum. Größere Umbrüche und Veränderungen geschehen nicht, wenn es keine größeren Probleme gibt. Zudem haben sie oft strukturelle Schwächen. Wie auch Software, die agil entwickelt wird, einen Hang zur Architekturschwäche hat, so hat ein iterativ verbesserter Prozess den Hang zur Strukturschwäche.

Wer keinen Plan davon hat, was er erschafft, und nur vor sich verbessert erhält einen gewachsenen Prozess, mit dem man leben kann, – aber sicher keinen schönen Prozess, mit dem man leben möchte. Aber Vorsicht! Iterative Verbesserungen sind wichtig. Wer sie nicht macht, riskiert Ineffizienz, Frust und im schlimmsten Fall den inneren Boykott des Prozesses durch die Teammitglieder.

Wie in der Software, braucht auch der Prozess eine Architektur – ein Grundgerüst, der dem Prozess eine Form gibt, die dann iterativ angepasst und optimiert werden kann.

Das Fundament im Prozess

Das wichtigste bei einem Prozess ist wie bei allem das Ziel bzw. das Endprodukt, dass erstellt werden soll. Im der Softwareentwicklung ist es in der Regel die Software. – Doch das ist nicht das Ende, sondern gerade erst einmal der Anfang.

Die wichtigste Aufgabe im Prozess ist es alle Pflicht-Artefakte zu erfassen. Oft werden (neben der Software als wichtigstes Artefakt) Nebenprodukte wie z.B. Handbücher oder ähnliches übersehen, die zwingend gesetzlich oder organisatorisch vorgeschrieben sind. Diese stellen das Fundament des Prozesses dar. Denn sie sind das Produkt – und können nicht eingespart oder wegoptimiert werden.
Wenn sie eingespart werden können, sind sie keine Pflicht-Artefakte.

So wird ein Prozess daraus

Artefakte erstellen sich nicht von selbst, das ist klar. Das Team hat die Aufgabe sie herzustellen. Im Rahmen von Tätigkeiten werden sie als Ergebnisse (Deliverables) erzeugt. (Zum Beispiel wird die Software von Entwicklern programmiert und das Handbuch von Redakteuren verfasst.) Die Tätigkeiten sollten dabei so ausgelegt und eng umfasst sein, dass sie zielgerichtet auf das Ergebnis ausgerichtet sind.

Fast jede Tätigkeit hat Voraussetzungen oder benötigt selbst Ergebnisse anderer, um darauf aufzubauen. So benötigt ein Entwickler z.B. für die Erstellung von Software (Code) eine Spezifikation oder ein detailliertes Konzept. Der Redakteur wiederum kann auf Basis der Konzepte das Handbuch vorbereiten. Die Konzepte ihrerseits müssen ebenfalls erzeugt werden. Sie entstehen in Rahmen eines Konzeptions- und Designprozesses auf Basis von Anforderungen und Szenarien. Und auch diese werden durch Tätigkeiten/Teilprozesse erstellt.

Arbeitet man sich systematisch von den Pflicht-Artefakten über Tätigkeiten zu benötigten Quell-Artefakten durch, sind auch hier schnell vorgelagerte Tätigkeiten identifizierbar. Dies endet dort, wo entweder keine Artefakte benötigt werden oder diese bereits fertig vorliegen.

Hilfsmittel, Systeme und Nachschlagewerke

Die meisten Tätigkeiten im Rahmen agiler Prozesse sind auf Wiederholungen ausgelegt. So wird z.B. eine User Story nach der anderen umgesetzt, eine Anforderung nach der anderen ins Konzept konsolidiert und ein Szenario nach dem nächsten in Testpläne überführt.
Dabei sind die einzelnen Arbeitspakete nicht unabhängig voneinander. Während das erste Feature einer Software noch unberührtes Terrain betritt, findet das zweite Feature bereits das erste vor. Mit der Zeit wird die Software komplexer, die Handbücher umfangreicher, die Konzepte voller und die Testpläne länger. Alles wird komplexer und vernetzter.

Eine Abhilfe schaffen da Repositories, Ticketsysteme, Requirements Management Systeme, Kanban-Boards, Dokumentenmanagement Systeme, Wikis, etc. Sie stehen dem Team bei den jeweiligen Tätigkeiten zur Hilfe und unterstützen sie dabei, die aktuellen Quell-Artefakte und das bisher bestehende komplexe System in Ergebnisse/Deliverables zu wandeln die stimmig sind. Auf diese Art können komplexe Systeme entstehen, die in sich schlüssig und konsistent sind.

Einfluss der Teamzusammensetzung auf den Prozess

Teams unterscheiden sich in vielerlei Hinsicht. Nicht jedes Team erzeugt dieselben Pflicht-Artefakte. Doch der größere Unterscheid ist in der Regel die Zusammensetzung des Teams. Die Unterschiede sind vielseitig:
Wie viele Personen sind im Team vorhanden? In welche Rollen sehen sich die Teammitglieder? Wo liegen ihre Stärken und wo ihre Schwächen? Wer ergänzt wen und welche Fähigkeiten sind im Team eher rar? Wer ist stark spezialisiert und wer kann seine Rolle flexibler wechseln? Wer ist „Forscher“ und wer „Polizist“?

Kein Team ist wie das andere. Und das ist der Hauptgrund, wieso kein Teamprozess sein sollte wie jeder andere. Die Positionierung der Teammitglieder innerhalb des Teams und deren Fähigkeiten und Stärken definieren nicht nur wo die Übergabepunkte* sind, sondern auch **welchen Detailgrad die Artefakte haben müssen, um verwertbar zu sein.

Es heißt, die Leute ergänzen sich. Diesen Vorteil will man nutzen. Meist macht man sich die Bedeutung dieser Aussage nicht wirklich vollends bewusst: Es bedeutet, dass die kleinen (oder großen) Schwächen und Unzulänglichkeiten des einen durch die anderen kompensiert werden. Dieser Ausgleich kostet das Team Abstimmung- und Kommunikationsaufwand und wird sich sehr bald im Prozess in Form von klaren Absprachen abzeichnen. Denn es ist die Aufgabe des Prozesses die Koordination und Kommunikation durch Konvention zu reduzieren. So passt sich der Prozess dem Fingerabdruck des Teams an.

Je qualifizierter eine Person für ihre Rolle im Team ist, umso weniger muss durch das Team kompensiert werden und umso einfacher fallen Übergabe-Artefakte aus. Ein guter Prozess berücksichtigt sie Stärken und Schwächen der Einzelnen und hat sinnvoll gewählte Übergabepunkte, die sich an den Fähigkeiten ausrichten.

Kein Team ist statisch. Menschen lernen dazu, entwickeln Verständnis für einander und kommunizieren effizienter und unterliegen wie überall auch einer natürlichen Fluktuation. Auch der Prozess sollte daher von Zeit zu Zeit in Frage gestellt werden und ggf. erneut modelliert werden, auch wenn er kontinuierlich in kleinen Schritten verbessert wird.

Einbettung in Scrum

Scrum ist ein recht schlichter Prozess, der als Rahmen für unterschiedliche Aufgaben dienen kann. Dabei ist er nicht auf Softwareentwicklung beschränkt. Im Grunde kann er für alles genutzt werden, was aus kleinen Teilaufgaben besteht und wenig gut planbar erscheint. So wurde Scrum auch schon bereits in Schulen als Lern-Prozess eingesetzt.

Scrum lässt sich leicht mit einem individuellen Team-Prozess vereinbaren, indem der Scrum-Prozess diesen umschließt und einbettet. Die einzelnen Tätigkeiten lassen sich im Backlog erfassen und priorisieren. Sprints geben dem Team kurzfristige erreichbare Ziele und helfen Kennzahlen (z.B. die Velocity) zu erfassen. Während Scrum den Rahmen und den Takt vorgibt und dem kontinuierlichen Betrieb und der Planung dient, hat der Team-Prozess die Aufgabe die Tätigkeiten, die Koordination und Übergaben im Team zu regeln und zu vereinfachen.

Es besteht kein Widerspruch zwischen einem individuellen Team-Prozess und Scrum, da sie auf unterschiedliche Aspekte des Prozesses abzielen und verbessen.

Akzeptanz des Prozesses

Wie jeder Prozess, ist auch ein maßgeschneiderter Prozess letztendlich nur ein Prozess und unterliegt der allgemeinen Prozess-Aversion. Zudem stehen etwa 30% aller Mitarbeiter Änderungen in ihrem gewohnten Arbeitsablauf mehr als nur skeptisch gegenüber. Kurzum: Prozesse sind der Feind.

Umso wichtiger ist es das Team in die Prozessmodellierung einzubeziehen. Es wird Bedenken geben und diese sollten früh geklärt werden. Auch eine kontinuierliche Prozessverbesserung (z.B. per Retrospektive im Scrum) durch das Team selbst hilft die Akzeptanz des Prozesses zu erhöhen.

Aber egal wie gut gemeint ein Teilprozess oder eine Vorgabe gemeint war, nach einer Weile erinnert sich so mancher nicht mehr daran, wozu es gut war und wird den Sinn in Frage stellen und den Mehraufwand nicht hinnehmen wollen. Es empfiehlt sich daher bei jeder Vorgabe zum Prozess auch ihren ursprünglichen Sinn mit zu dokumentieren. Wer sich Vorgaben durchliest, liest deren Sinn gleich mit. Dies hilft langfristig, den Prozess als Mehrwert zu sehen und weniger als Bürde.