Scrum ist nichts für Anfänger

Es gibt viele Dinge zu beachten, wenn sich ein Unternehmen oder einzelne Teams dazu entscheiden, in die agile Welt vorzurücken. Die meisten Probleme treten jedoch erst in den Vordergrund, wenn die Umstellung bereits erfolgt ist. Das ist auch gleichzeitig einer der größten Vorteile von Scrum: Die Schaffung von Transparenz und die Sichtbarkeit von Problemen und Flaschenhälsen.

Viel zu selten werden jedoch die betroffenen Personen betrachtet. Längst nicht jeder ist dazu geeignet, eine agile Vorgehensweise einzusetzen. Viel zu komfortabel waren bisher die Inseln, die man sich selbst geschaffen hat. Wieso soll man daher eine Umstellung wagen? Es lief bisher doch auch alles super!

Scrum selbst ist aufgrund der wenigen Regeln super für den Einstieg in die Agilität geeignet. Die wenigen Regeln, Rollen, Aktivitäten und Artefakte lassen sich schnell und einfach verinnerlichen. Die eigentliche Schwierigkeit besteht aber in der Anwendung agiler Methoden, die nirgends festgeschrieben sind. Neben hohen Anforderungen, die an den Product Owner und den Scrum Master gestellt werden, sind vor allem die Entwickler gefragt, die nur mit höchster Professionalität in agilen Umgebungen überleben können.

Die Anforderungen an die Entwickler sind unter anderem:

Anforderung 1: Sehr hohe technische Kompetenz

Das technische Know-How muss bis zu einem gewissen Grad bereits vorhanden sein oder die Zusammensetzung des Teams muss ergeben, dass sich alle technischen Problemen in gemeinsamer Arbeit bewältigen lassen. Technische Kompetenz wird aber nicht nur durch Wissen erlangt, sondern auch durch bestimmte Vorgehensweisen.
Agile Methoden erfordern, dass für Anforderungen und Probleme flexible und schnelle Lösungen gefunden werden, damit dem Kunden möglichst zeitnah ein funktionierendes Stück Software präsentiert werden kann. Nur so ist es möglich, schnell auf Änderungswünsche einzugehen.
Diese schnelle Lösungsfindung erfordert entweder ein hohes Talent oder viel Erfahrung in der Technik und deren Anwendung.

Anforderung 2: Sehr hohes Verständnis von Software-Design

In einer agilen Umgebung hat der klassische Architekt oder Designer ausgedient. Diese Aufgabe übernimmt nun der Entwickler und muss sich Gedanken dazu machen, wie die neue Funktionalität am besten in das Programm passt. Dazu kommt, dass sich in den Auftraggeber hineinversetzt werden muss um festzustellen, was der Kunde überhaupt will und welche Ziele verfolgt werden. Als dritte Schwierigkeit steht dann noch die Frage im Raum, wie die neue Funktion mit anderen Bereichen in der Software oder sogar mit anderen Produktbereichen zusammenarbeiten soll.
Eine gute Hilfestellung kann da der Produkt Owner geben, der die Vision des Kunden gut übermitteln kann. Doch die Gedanken, wie etwas umgesetzt werden muss, muss sich der Entwickler selbst machen.

Anforderung 3: Kommunikation auf verschiedenen Ebenen

Der Entwickler muss mit unterschiedlichen Menschen klar kommen, um die Anforderungen an eine Aufgabe vollends zu verstehen. Dazu ist technische Kommunikation mit einem direkten Kollegen notwendig, z.B. zum Erlernen neuer Entwicklungstechniken oder der Einsatz eines neuen Entwicklungstools zur Verbesserung der eigenen Arbeitsleistung. Diese Gespräche finden meist mit Gleichgesinnten mit ähnlichem Hintergrund statt.
Oft müssen aber auch fachliche Gespräche geführt werden, z.B. wie eine bestimmte Programmlogik implementiert werden soll. Abhängig von der Software kann das nicht mit reinen Programmierkenntnissen abgefangen werden, sondern es ist fachliches Anwender-Know-How notwendig. Dazu sind dann Gespräche mit anderen Personenkreisen erforderlich, die oft auch direkt geführt werden können, ohne eine zusätzliche Schnittstelle einzubinden (Scrum Master oder Product Owner).
Die Kommunikation auf unterschiedlichen Ebenen erfordert vom Entwickler ein hohes Verständnis der eigenen Arbeit und Hinterfragen der Programmlogik.

Anforderung 4: Charakterstark

Agile Methoden erfordern nicht nur hohe technische Kompetenz, sondern stellen auch hohe Ansprüche an die Persönlichkeit des Entwicklers. Nicht alle Fähigkeiten lassen sich erlernen, sodass sicher nicht jede Person agil arbeiten kann und entsprechend anders im Unternehmen eingesetzt werden muss. Doch das sind nur extreme Ausnahmen, in der Regel werden weniger stark ausgeprägte Fähigkeiten durch die Gruppendynamik abgefangen.

Primär sollte der Entwickler keine Angst vor Veränderungen haben. Allein die Einführung von Scrum im Unternehmen bringt schon sehr viele Veränderungen mit sich. Doch auch Anforderungen werden in agilen Umgebungen oft neu definiert, was eine aktualisierte Zielsetzung erforderlich macht. Oft wird dadurch bereits getane Arbeit hinfällig und muss neu angegangen werden, weil es das veränderte Ziel so vorgibt.

Durch Scrum wird im Team und auch von Außerhalb eine hohe Transparenz erzeugt. Alle können sehen, woran die einzelne Person gerade arbeitet, was bereits geschafft wurde und welche Probleme existieren. Viele setzen die Transparenz, die mit vielen Vorteilen für Abläufe und Arbeitsplanung einhergeht, mit einer erhöhten Kontrolle durch den Arbeitgeber gleich. Arbeitsleistungen werden messbarer und vergleichbarer. Doch das dient hauptsächlich dazu, verlässlichere Ergebnisse und bessere Abschätzungen zu erhalten. Dass das Unternehmen die Mitarbeiter kontrollieren will ist eher ein Widerspruch dazu, dass dem einzelnen Entwickler mehr Verantwortung in die Arbeitsweise und Durchführung der Arbeit gegeben wurde. Wenn Misstrauen geherrscht hätte, würden agile Methoden nicht angewandt werden. Die Einführung von Scrum ist ein Vertrauensbeweis an den Entwickler und seine Arbeit. Warum sollte dann mehr kontrolliert werden? Mit dieser Transparenz und dieser Denkweise sollte der Entwickler auf jeden Fall umgehen können.

Klar, jeder macht Fehler. Doch Fehler bringen immer Potential zur Verbesserung mit sich. Der Gedanke, dass Fehler schlecht seien, darf beim Entwickler nicht existieren. Fehler dürfen nicht mit Scheitern verbunden werden. Zudem ist die Toleranz, ab wann etwas als Fehler gilt, von Entwickler zu Entwickler sehr unterschiedlich.
Grundsätzlich sollte die Mentalität herrschen, dass keine Fehler existieren, sondern nur Chancen zur Verbesserung der Software oder der Arbeitsweise. Wichtige Erkenntnisse und die daraus resultierenden Lösungen müssen beim Entwickler die entscheidende Motivation für seine Arbeitsleistung auslösen.

Damit wären wir auch beim nächsten Punkt, der Fähigkeit zur Eigenmotivation. Diese Eigenschaft ist sehr wichtig, da nur motivierte Entwickler gute Arbeit abliefern und aktiv im Team zusammenarbeiten. Motivation entsteht oft aus der Erreichung persönlicher Ziele. Diese Ziele sollten dann natürlich realistisch und erreichbar sein und sich nach dem SMART-Prinzip richten:

S = Specific (Spezifisch)
M = Measurable (Messbar)
A = Achievable (Erreichbar)
R = Realistic (Realistisch)
T = Timeboxed (Zeitrahmen)

Falsch gesetzte Ziele führen nur zu ungewollter Demotivation, die es verhindern gilt. Das muss der Entwickler schon bei der Zielsetzung erkennen können.

Anforderung 5: Kenntnis über agile Techniken

Nicht nur die agile Methode (z.B. Scrum oder Kanban) und deren Regeln sollten bekannt sein, sondern auch agile Techniken und wie sie effektiv eingesetzt werden. Dazu gehören z.B. Test Driven Development, (Test-)Automatisierung oder Refactoring.
Die Vorkenntnisse sind in diesem Bereich sehr unterschiedlich. Manchmal werden agile Techniken bereits in der klassischen Entwicklung eingesetzt, die nach dem Wasserfallmodell vorgeht. Häufig sind diese Vorgehensweisen aber nicht einmal fortgeschrittenen agilen Entwicklern bekannt (wobei man dann auch nicht von 'agil' sprechen kann), oder diese Methoden sind bekannt, werden aber nicht eingesetzt und es fehlt die praktische Erfahrung.

Anforderung 6: Fähigkeit zur Selbstorganisation und Abstimmung mit dem Team

Der letzte Punkt in dieser Liste beschreibt die Fähigkeit zur Selbstorganisation als einzelne Person und im Team. Durch die Anwendung agiler Methoden wird dem Entwickler viel Vertrauen entgegengebracht und ihm ermöglich, seine Arbeit selbst zu organisieren, ohne dass bis auf klare Regeln große Vorgaben gemacht werden. Innerhalb eines abgesteckten Rahmens dürfen sich die Entwickler freier bewegen als zuvor.
Für die Frage, die im Team gestellt wird gilt: "Wer Macht Wann Was?"
Für einen selbst heißt das: "Wie Mache ich Wann Was?"
Selbstorganisation ist kein Selbstläufer und erfordert ein hohes Maß an Disziplin und Ordnung. Es erfordert regelmäßige Absprachen im Team (z.B. Daily Standup), um alle weiteren Vorgehen zu planen. Damit das auch in einem angemessenen Zeitrahmen bleibt, müssen gewisse Selbsterkenntnisse gewonnen werden (was ist wirklich wichtig für das Team?).

Fazit

Das klassische Vorgehen nach Wasserfall hat nur wenige der genannten Punkt erforderlich gemacht, die Entwickler mussten sich weniger Gedanken um das 'wie' machen. Die Organisation wurde von anderen Personen übernommen und Insellösungen haben nur wenig Kommunikation erfordert.
Der agile Entwickler hat viele Anforderungen zu erfüllen, um den agilen Prinzipien gerecht zu werden. Wer jedoch erfolgreich Scrum anwendet, bereits viele agile Vorgehensweisen etabliert hat und in einem harmonischen Team arbeitet, darf sich ohne falsche Bescheidenheit als Profi bezeichnen. Scrum ist nichts für Anfänger.