Scrum im Überblick

Agile Methoden und Verfahren gibt es schon lange seit den Zeiten von Extreme Programming. Doch sind sie noch immer nicht überall bekannt bzw. werden nicht durchgängig gelebt. Deshalb möchten wir mit dieser Artikelserie zu Scrum dazu beitragen, dass Scrum als agile Methode insbesondere in Deutschland weitere Verbreitung findet.

Ich beginne den Einstieg in Scrum mit den Grundideen und Prinzipien, bevor wir uns den weiteren Details wie Rollen, Artefakte, Veranstaltungen etc. zuwenden. Viele Scrum-Begriffe verwende ich in meinen Artikeln und Büchern im Original und deutsche sie nicht ein. Denn es würde sich ziemlich sperrig anhören, wenn jemand von Gedränge (Scrum), Gedränge-Meister (Scrum Master), Produktbesitzer (Product Owner), Spurtplanungsveranstaltung (Sprint Planning Event) usw. sprechen würde. Dies gilt für alle Artikel dieser Artikelserie über Scrum.

Scrum ist einfach

Eigentlich ist Scrum überaus einfach. Es ist ein gut überschaubares Rahmenwerk und versucht nicht wie schwergewichtige Softwareentwicklungsprozesse viele verschiedene spezialisierte Rollen, Dutzende von Artefakten und Aktivitäten und sonstiges vorzudefinieren.

Stattdessen beschränkt Scrum sich darauf, wenige grundlegende Rollen und Artefakte zu definieren sowie ein paar Arten von Meetings zur Zusammenarbeit zwischen den Teammitgliedern.

Alles andere ergibt sich dann aus der Interaktion der Beteiligten.

Dabei wird vorausgesetzt, dass die an einem Projekt Beteiligten ausreichende Kenntnisse und Fähigkeiten mitbringen, um auch ohne feinziselierte Prozessbeschreibungen ihrer Arbeit Lösungen zu finden und die richtigen Ergebnisse zu erzielen.

Scrum unterstützt sie „lediglich“ dabei, sich auf das zu fokussieren, was den höchsten Kundennutzen bringt und womit frühestmöglich die wichtigsten Risiken ausgeschaltet werden können.

Scrum ist agil

Scrum basiert auf einigen grundlegenden Überzeugungen, die darauf hinauslaufen, nicht detailliert viele einzelne Aufgaben und Ergebnistypen bei der Softwareentwicklung vorzugeben und stattdessen auf die Kreativität und Zielorientierung der Beteiligten zu vertrauen. Darum wird ihnen mehr Spielraum gegeben als in anderen Softwareentwicklungsprozessen.

Die Grundannahmen sind:

• Viele Entwicklungsprojekte sind zu komplex für eine vollständige Planung vorab
• Ständiges Feedback sichert den Erfolg
• Wir akzeptieren, dass der Entwicklungsprozess nicht vollständig vorherzusehen ist
• Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.

Das agile Manifest

Um eine hohe Flexibilität in komplexen Umgebungen zu erreichen, wurde das „Agile Manifest“ erstellt.

Die Grundaussagen des agilen Manifestes lauten:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden ist wichtiger als  Vertragsverhandlung
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Die Werte auf der rechten Seite sind zwar wichtig, diejenigen auf der linken Seite sind jedoch wichtiger.

Scrum als Gegenentwurf zur Befehls-und-Kontroll-Organisation

Klassisch sind viele große Unternehmen auch heute noch geprägt von einer „command-and-control“-Organisation.

D.h. von oben werden Anweisungen gegeben und Vorgaben gemacht, die dann nach unten durchgereicht und dort nur noch ausgeführt werden sollen.

Das geht noch ganz gut, wenn stark standardisierte Massenprodukte produziert oder Dienstleistungen von der Stange erbracht werden. Dann kann man sich recht viel vorab ausdenken und die ausführenden Mitarbeiter müssen sich nur noch an den großen allumfassenden Plan, die Prozessleitlinien etc. halten und tun, was ihnen vorgegeben wird. Die Entscheidungsspielräume auf den unteren Ebenen solcherart aufgebauter Organisationen sind gering. Das erhöht die Sicherheit, Produkte und Dienstleistungen in relativ konstanter Qualität zu produzieren. Verringert jedoch gleichzeitig die Möglichkeit für flexibles kunden- oder situationsorientiertes Handeln. Wer jemals ein individuelles selten auftretendes Problem mit einem großen Telekommunikationsanbieter lösen musste, weiß, was das bedeutet.

Wiewohl auch in diesen Umgebungen mehr Flexibilität Vorteile brächte, kann es sein, dass die Kostenersparnis durch geringer qualifizierte Mitarbeiter mit weniger Schulungsbedarf unter dem Strich betriebswirtschaftlich sinnvoll sein kann.

In der Softwareentwicklung gilt das jedoch ganz überwiegend nicht. Das in der Vergangenheit in größeren Unternehmen verfolgte Leitbild einer Software-Fabrik, die mit gering qualifizierten, angelernten oder umgeschulten Codierern versucht, Wunderwerke der Technik zu erstellen, ist grandios gescheitert. Die Liste von Großprojekten, die auf dieser Grundlage durchgeführt wurden und dann gescheitert sind, ist legendär.

Ebenso legendär ist die Liste von Projekten in agilen Unternehmen oder im Opensource-Bereich, wo durch Selbstorganisation von fähigen Teams mit geringem Headcount hervorragende Ergebnisse erzielt wurden und werden.

Softwareentwicklung ist ein kreativer Prozess. Sowohl was das Finden von Anforderungen betrifft als auch deren Umsetzung in lauffähige Software.

Scrum als agile Methode passt dazu sehr viel besser als schwergewichtige Prozesse, die zu viele Details von Anfang an feingranular vorgeben wollen.

Man setzt mit Scrum auf:

• hoch qualifizierte, interdisziplinär besetzte Entwicklungsteams
• klare Zielvorgaben
• Teams, die für die Umsetzung allein zuständig sind
• ausreichenden Freiraum für die Entfaltung des Wissens- und Kreativitätspotenzials der Teams

Die Abkehr von einer Befehls-und-Kontroll-Organisation hin zu mehr Selbstorganisation von Teams auf der Arbeitsebene bereitet manch einem zu Beginn Unbehagen. Insbesondere weil sich viele Manager dann fragen, was denn ihre Aufgabe dann noch sei. Mit diesem Transformationsprozess beschäftigen wir uns in einem späteren Artikel.

Komplexität beherrschen durch 4 Prinzipien

Die Komplexität großer Projekte ist teilweise gigantisch.

Um diese Komplexität zu beherrschen, bedient sich Scrum folgender Prinzipien:

1. Zerlegung
   • Große Aufgaben zerlegen in einzelne kleine, gut überprüfbare Schritte
2. Transparenz
   • Fortschritt und Hindernisse täglich und für alle sichtbar festhalten
3. Überprüfung
   • Regelmäßig liefern und bewerten
4. Anpassung
   • Anforderungen nach jeder Lieferung überarbeiten

Mit der konsequenten Anwendung dieser Prinzipien kommt man schon sehr weit.

Zerlegung

Dieses Prinzip ist jetzt keine besondere Neuerung durch Scrum. Das „Teile und herrsche“-Prinzip gibt es schon lange. Denn auch die klassische Planung mit WBS (work breakdown structure) in Microsoft Project und vielen anderen Tools basiert darauf, Aufgaben immer weiter zu verfeinern. Zum einen, um gedankliche Klarheit zu gewinnen. Zum anderen fällt es erheblich leichter, eine Aufwandsschätzung für kleine Aufgaben im Stunden- oder Tagesbereich zu machen und diese dann aufzusummieren als den Aufwand für eine Task zu schätzen, die sich über mehrere Monate erstreckt.

Transparenz

Wer schon mal in Großprojekten gearbeitet hat, wo Teilprojekte aus den unterschiedlichsten Gründen heraus versuchen, ihren tatsächlichen Status zu beschönigen anstatt Probleme offen zu kommunizieren, ahnt, wie hilfreich es wäre, wenn gnadenlose Transparenz herrschen würde. Dafür sind jedoch einige Vorbereitungen notwendig. Von denen die wichtigste ist, dass nicht nach Schuldigen, sondern nach Lösungen gesucht wird.

Überprüfung

Projekte erfolgreich abzuwickeln ist wie Autofahren auf einer langen Reise.

Es gibt einen Startpunkt (Projektbeginn) und ein Ziel (lauffähiges Software-Produkt). Es gibt ferner die Reisegruppe (das Scrum-Team sowie Stakeholder wie Management, Kunden, Anwender etc.) und einen groben Plan für die Route zum Ziel.

Dann geht die Reise los und wie bei jeder längeren Reise geht immer mal wieder etwas schief, mit dem man nicht gerechnet hatte. Ein Reifen kann dabei auf unterschiedliche Weise platzen:

• Ein Mitarbeiter wird krank oder kündigt
• der Markt verändert sich
• ein großer Mitbewerber bringt tolle neue Features heraus
• ein Techniklieferant macht Pleite und man muss auf eine andere Entwicklungsplattform migrieren
• eine wichtige Messe steht bevor, auf der man ein bestimmtes Feature zeigen will
• usw. usf.

Es gibt unendlich viele Dinge, auf die man reagieren können sollte anstatt nur starr einem vorgegebenen Plan zu folgen.

Auch hier ist es wie beim Autofahren: eine Straße ist nicht schnurgerade, sondern unregelmäßig, es gibt Kurven, Kreuzungen etc. Daher achtet ein Fahrer kontinuierlich auf die Streckenführung und passt die Fahrtrichtung und die Geschwindigkeit permanent an die Gegebenheiten an anstatt das Lenkrad starr zu umklammern und mit konstanter vorher im Tempomaten eingestellter Geschwindigkeit auf das Ziel zuzufahren.

In einem Software-Projekt nach Scrum erreicht man diese Art der Mikrosteuerung in Bezug auf die Anforderungen, indem in möglichst kurzen zeitlichen Abständen Releases erstellt werden, die lauffähig sind und anhand derer die Kunden und Anwender beurteilen können, ob das Produkt sich in die richtige Richtung entwickelt.

Etwas zynisch sagen Entwickler häufig „Die meisten Anwender können besser sehen als denken“. Das ist aber auch nicht weiter verwunderlich. Denn Software ist höchst komplex und sich anhand von BPMN- oder UML-Modellen und Quellcode vorzustellen, was die Software wie tun wird, können nun mal nur Entwickler. Insofern ist es zwingend notwendig, den Anwendern etwas an die Hand zu geben, anhand dessen sie ihre Anforderungen schärfen können.

Mithin sieht Scrum vor, kontinuierlich am Ende jeden Sprints ein Produkt zu haben, welches lauffähig ist und von den Stakeholdern überprüft werden kann. Das erleichtert den Stakeholdern, wichtiges Feedback zu geben für die weitere Produktentwicklung. Das hilft dem Product Owner und dem Entwicklungsteam bei der Klärung der Priorisierung von Features und der Form ihrer Implementierung.

Anpassung

Scrum sieht vor, dass ein Projekt sich kurzfristig an neue Erkenntnisse und Herausforderungen anpassen kann.

Daher ist die Entwicklung auf der Zeitschiene unterteilt in kurze Abschnitte, an deren Ende jeweils neu entschieden werden kann, was als Nächstes getan werden soll. D.h. welche Storys umgesetzt und welche Hindernisse beseitigt werden sollen, welche Teammitglieder hinzugenommen oder ausgetauscht werden sollen etc.

Ausblick

Dies soll als Überblick über die Grundideen und –prinzipien von Scrum zunächst ausreichen.

In weiteren Artikeln dieser Artikelserie zu Scrum steigen wir tiefer in die Details ein.