Historische Hintergründe

Die Anfänge von Scrum lassen sich auf Ikujiro Nonaka zurückführen. Mit seinem Buch „The Knowledge-Creating Company“, legte der mittlerweile eremitierte Professor der japanischen Hitotsubashi-Universität 1991 zusammen mit Hirotaka Takeuchi die Grundlage für ein neues Wissensmanagement. Er unterscheidet zwei Arten von Wissen: explizites Wissen, das in Betriebsanleitungen und Prozeduren enthalten ist und implizites Wissen, das nur durch persönliche Erfahrungen erlernt werden kann. Dieses implizite Wissen ist subjektiv und intuitiv, es enthält unser Bild der Realität und unsere Vision für die Zukunft. Während explizites Wissen sich leicht darstellen und verarbeiten lässt, ist dies bei implizitem Wissen deutlich schwerer. Unternehmen wie Toyota oder Canon profitieren vom impliziten Wissen ihrer Mitarbeiter, indem sie hohen Wert auf die Interaktion zwischen ihren Mitarbeitern legen. Dieses implizite Wissen in explizites Wissen umzuwandeln, macht nach Nonakas Meinung den Erfolg japanischer Firmen aus und wird von ihm als das erstrebenswerte Modell dargestellt. Er bezeichnet Wissen als die Schlüsselkompetenz unseres Zeitalters und den Erwerb und die Anwendung von Wissen als einen wesentlichen Wettbewerbsfaktor. Dieses „Wissen sammeln durch gemeinsame Erfahrungen“ findet sich auch in Scrum wieder.

Agile Softwareentwicklung

Jeff Sutherland und Ken Schwaber entwickelten gemeinsam für die OOPSLA 1995 den ersten formalen Scrum Software-Entwicklungsprozess. Sie schufen eine neue Rolle für die damaligen Projektleiter. Diese wurden zu Teammitgliedern und ihre Rolle war eher die eines Moderators als eines Managers.

In ihrem Konferenzbeitrag über Scrum auf der OOPSLA 1995 hieß es:

„Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“

Parallelen zu Scrum finden sich in der so genannten Schlanken Produktion (engl. lean production), die ihren Ursprung in japanischen Unternehmen hat und eine bessere Wertschöpfung unter anderem durch stärkeres Teamworking anstrebt. Nonaka und Takeuchi führen den Erfolg solcher Unternehmen letztlich auf das gelungene Wissensmanagement zurück.

Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstehen, in der Mitarbeiter möglichst genaue Arbeitsanweisungen zu erhalten haben. Stattdessen baut Scrum auf hoch qualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen. Scrum gilt damit als eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen, wie dem Wasserfallmodell.

Scrum verkörpert die Werte der agilen Software-Entwicklung. Popularität erreichte diese erstmals 1999, als Kent Beck und andere das erste Buch zu Extreme Programming veröffentlichten. Das Interesse an Extreme Programming ebnete den Weg auch für andere agile Prozesse und Methoden. Die Bezeichnung agil für diese Art der Softwareentwicklung wurde im Februar 2001 bei einem Treffen führender Entwickler in Utah ausgewählt, als Ersatz für das bis dahin gebräuchliche leichtgewichtig (engl. lightweight). Bei diesem Treffen wurde auch das Agile Manifest mit den folgenden 4 Punkten formuliert:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

2001 veröffentlichten Ken Schwaber und Mike Beedle mit „Agile Software Development with Scrum“ das erste Buch über Scrum. 2003 wurden die ersten zertifizierten ScrumMaster von Schwaber ausgebildet.

Was ist jetzt eigentlich Scrum

Scrum heißt übersetzt „Gedränge“ (wird auch im Rugby benutzt) und ist ein agiles Vorgehensmodell in der Softwareentwicklung. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Ansicht, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um durchgängig planbar zu sein. Deshalb ist es ein fester Bestandteil von Scrum sich regelmäßig zusammenzusetzen (->Gedränge), über den aktuellen Projektstand auszutauschen und bei einer Änderung der Anforderungen das Vorgehen entsprechend anzupassen.

Grundprinzipien von Scrum

Ziel dieser Vorgehensweise ist es, den Softwareentwicklungsprozess durch Abbau der Bürokratisierung und durch die stärkere Berücksichtigung der menschlichen Aspekte effektiver zu gestalten. Dadurch soll eine schnelle, kostengünstige und qualitativ hochwertige Fertigstellung des Produktes gewährleistet werden. Folgende drei Punkte bilden die Grundlage der Softwareentwicklung mit Scrum:

Pro

• Flexible Anpassungsmöglichkeiten: Agile Verfahren eignen sich gut bei weichen und wenig ausformulierten Anforderungen, bzw. einem hohen Maß an externen Störfaktoren/Marktveränderungen.
• Wettbewerbsfähigkeit: das Wettbewerbsumfeld verändert sich immer schneller. Nur Unternehmen die flexibel und agil sind, können schnell auf Marktveränderungen reagieren und einen Wettbewerbsvorteil für sich nutzen.
• Entwickeln, was benötigt wird: Scrum ermöglicht die inkrementelle Entwicklung von Funktionen. Der Kunde erhält die ersten Versionen der Software sehr früh, kann die Fortschritte sehen und wenn nötig neue Ideen einbringen.
• Vertrauen durch Transparenz: Transparenz spielt eine wichtige Rolle auf verschiedenen Ebenen in Scrum und ist einer der wichtigsten Treiber, die Scrum so effizient machen. Aufgrund der Transparenz werden alle Beteiligten darüber informiert, wo das Projekt zu einem bestimmten Zeitpunkt steht. Dies hilft bei der Entdeckung Schwächen aufzudecken und macht effektive Teamarbeit möglich.
• Testen als integraler Bestandteil: Nur wenn die Software getestet und dokumentiert ist, ist sie fertig. Methoden wie Continuous Integration sind sehr geeignet um von Anfang an eine höhere Qualität zu erzielen.
• Systematisches Risikomanagement: Durch regelmäßige Releases werden Probleme rechtzeitig erkannt und können behandelt werden.
• Änderungen sind willkommen: Änderungen können jederzeit an den Product Owner herangetragen und in den folgenden Sprints realisiert werden. Auf diese Weise erhält der Kunde das Produkt, das er sich wünscht.
• Effiziente Zusammenarbeit und Kundenzufriedenheit: Scrum beinhaltet regelmäßige Kommunikation zwischen allen Teilnehmern des Projekts. Respekt und Verständnis dafür, was der Kunde benötigt und was das Team entwickelt, ist die Grundlage für die Durchführung erfolgreicher Projekte.
• Last but not least – Scrum macht Spaß: Die Zusammenarbeit und Entscheidungsfindung im Team ist ein wichtiger Teil von Scrum. Software-Entwicklung ist eine kreative und vielschichtige Tätigkeit, die nur dann richtig funktionieren kann, wenn jeder Verantwortung übernimmt.

Contra

• Der Einsatz agiler Verfahren wird problematisch, wenn ein Projekt klar (vorher) definierte Anforderungen erfüllen muss und engen Zeit- oder Budgetvorgaben unterliegt. Hier bieten die klassischen, ingenieursmäßigen Vorgehensmodelle mit klar definierten Phasen große Vorteile.
• Gewonnene Erkenntnisse müssen auch verwertet werden: Bei der Verwendung von Scrum muss man sich darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden. Scrum zeigt vom ersten Tag an Abweichungen vom Soll-Zustand an. Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, hängt davon ab, was das Scrum-Team mit den gewonnenen Erkenntnissen macht. Nach Ken Schwaber (Ken Schwaber, The Enterprise and Scrum, 2007) kann auch ein Team von Idioten nach Scrum arbeiten. Das Team liefert am Ende jedes Sprints zuverlässig Produktinkremente, hält alle Meetings ab, und verteilt die Rollen nach Scrum. Wenn aber das Scrum-Team die Ergebnisse nicht nutzt, um anders zu arbeiten und Anpassungen vorzunehmen, wird auch das Produkt nicht besser oder früher fertig sein.
• Hinderliche Einflüsse bei der Teamzusammensetzung: Die Selbstorganisation im Entwicklungsteam beinhaltet den Grundsatz, dass es im Team keine permanente Hierarchie geben darf. Mitglieder, die nicht bereit sind, ihre bisherige Position innerhalb des Entwicklungsteams aufzugeben, können daher zu Konflikten führen. Zudem sollte ein Entwicklungsteam ausreichend interdisziplinär ausgebildet sein, um möglichst viele Aufgaben ohne externe Hilfe zu bearbeiten. Auch bei umfangreichen und vielschichtigen Projekten wird von Scrum gefordert, dass prinzipiell alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können. Somit passt jemand, der sich exklusiv als Tester, Programmierer oder Architekt sieht, nicht optimal in ein Entwicklungsteam nach Scrum: Ein gutes Team kann das berücksichtigen und die Nachteile kompensieren; für ein weniger erfahrenes Team können solche Mitarbeiter aus Scrum-Sicht schwierig sein.
• Hoher Aufwand für Tests: Häufige Änderungen erfordern Refactoring, was wiederum eine ausreichende Testabdeckung durch Unittests nötig macht. Häufige Lieferungen erfordern eine ausreichende fachliche Testabdeckung durch Regressionstests. Gerade in Altsystemen ist eine ausreichende Testabdeckung durch Testautomatisierung mit vertretbarem Aufwand oft nicht zu erreichen. Manuelle Tests generieren nach jedem Sprint erneut Testaufwand und verhindern somit das effektive Arbeiten nach Scrum.
• Juristische Erwägungen: Im Verlauf des Entwicklungsprozesses und insbesondere bei der Beauftragung existieren keine verbindlichen Vorgaben bezüglich der Fachlichkeit der zu erstellenden Software, da sich diese erst während des Projektes formieren. Es besteht aus juristischer Sicht eine deutlich stärkere Unschärfe über die zu erbringende Leistung und deren Abnahmekriterien als bei traditionellen Vorgehensweisen. Bei Streitigkeiten im Rahmen von Werkverträgen kann dies dazu führen, dass keine eindeutige Aussage zur Vertragserfüllung getroffen werden kann und auch Verantwortlichkeiten unklar bleiben.
• Scrum kann zu Konflikten führen: Scrum ist ein sehr einfaches Modell, aber die Kombination aus Transparenz und kurzen Sprints bringt häufig langjährige Konflikte oder Ineffizienzen zwischen Entwicklerteams, Firmeninhabern und Management zum Vorschein.  Die Regeln von Scrum besagen, daß jede Ursache eines Problems in der Software- oder Produktentwicklung der Firma aufgedeckt wird. Das kann unangenehm werden und zu Aussagen wie „Scrum ist chaotisch“ oder „Scrum funktioniert für uns nicht“ führen. Das Spektrum möglicher Konflikte ist breit. Es beginnt bei Managern die gerne Transparenz in der Entwicklung sehen, aber ihre eigenen Visionen nicht teilen wollen. Oder Mitarbeitern die sich gern hinter den Fehlern anderer mit Ausreden wie „Ich mußte hierauf warten“ oder “ Ich hatte soviele andere Dinge zu tun“ verstecken, was mit der klaren Aufgabenverteilung in den Sprints sofort auffliegt. Der traditionelle Projektleiter muss zunächst verstehen wie sich seine Rolle mit Scrum verändert und vollste Kooperation mit Kunden und Entwicklern garantieren.  Es ist unbestritten, daß Scrum eine große Veränderung für die Struktur und das Miteinander im Unternehmen bedeutet.

Links

• Jeff Sutherlands Scrum Handbook: jeffsutherland.com/scrumhandbook.pdf
• Ken Schwabers Blog: http://kenschwaber.wordpress.com/
• Scrum – Challenges, Risks & Anti-Patterns: http://www.agile42.com/en/blog/2009/06/16/Scrum-risks/
• http://de.wikipedia.org/wiki/Scrum