Wenn ich höre und lese, warum einzelne Unternehmen auf Scrum oder Agile Methoden im allgemeinen setzen, wird mir ganz schwindelig. Wir wollen besser werden – was auch immer das heißen mag, wir wollen schneller werden, wir wollen weniger Fehler machen. Wer sich nicht wirklich vollends darüber im Klaren ist, was Scrum ihm bringt, wird nicht glücklich werden und irgendwann auf den nächsten Hype-Train aufspringen.

Machen wir uns nichts vor: Scrum und Agile sind noch immer der heiße Scheiß, bei dem man einfach mitmachen muss, wenn man von sich selbst sagen will, dass man ein modernes Unternehmen sei. Bitte versteht mich nicht falsch: viele Unternehmen haben genau die richtige Motivation, auf Scrum zu setzen. Ihr würdet aber stauen, wie viele eben genau die falsche Motivation haben, oder eigentlich gar nicht wissen, was sie wollen.

Und was – lieber Herr Klugscheißer – ist genau die richtige Motivation?

Ich werde Euch noch ein wenig quälen und erst in aller Ruhe darauf eingehen, warum Scrum nicht alle Probleme löst und nicht immer die richtige Wahl ist, bevor ich darauf komme, was in meinen Augen der einzige Grund für den Einsatz Agiler Methoden sein kann.

Mir begegnet leider immer wieder das Phänomen, dass Unternehmen nicht genau wissen, was sie mit diesem Agilen Zeug eigentlich anfangen sollen. Es ist nicht unbedingt so, dass irgendwann irgendjemand auf die Idee kommt, dass man auch unbedingt Agil machen müsste, weil das alle machen. Das wird zwar gelegentlich behauptet, aber das ist Quatsch. Kein Mensch ist sooo dumm, auch wenn wir nicht immer die höchste Meinung von einzelnen Personen im Management haben. Vielmehr ist es meist so, dass jemand einen Blick auf die Entwicklung wirft und sieht, dass etwas nicht richtig funktioniert. Ob das objektiv betrachtet auch so ist, bleibt eine ganz andere Frage, aber in der Wahrnehmung des Betrachters gibt es Raum für Verbesserung.

Vielleicht ist man der Meinung, dass man schneller sein müsste, vielleicht sieht man eine gewisse Orientierungslosigkeit, vielleicht wird man mit einem sehr hohen Bug-Count konfrontiert, vielleicht sind die Kollegen überfordert und unzufrieden. An dieser Stelle wird oft der erste und schwerste Fehler gemacht: man sucht nicht ausreichend intensiv nach dem Grund des (gefühlten) Problems, sondern steigt gleich in die Lösungsfindung ein.

Man hört sich also um, liest viel, und stößt dann z.B. auf die Aussage, dass Scrum die Entwicklung beschleunigen würde. Mit Verlaub: das ist ausgemachter Blödsinn. Scrum ist keine Wunderdroge, die dafür sorgt, dass ein Entwickler plötzlich ein paar hundert Zeilen Code mehr am Tag schreibt. Da ist sogar ein Espresso wirksamer. Scrum hilft uns nicht dabei schneller zu werden, es unterstützt uns dabei, die richtigen Dinge auszuwählen, die wir tun. Es bewahrt uns also davor, zu viel Müll zu produzieren, den kein Mensch braucht. Aber seid trotzdem gewarnt: ein Prinzip von Scrum ist, dass wir bewusst immer wieder Dinge entwickeln, die wir wieder verwerfen müssen. Der Wunsch ist, das wir kleine Dinge bauen, die wir wieder wegwerfen, um immer wieder unseren Kurs zu korrigieren, anstatt irgendwann der Arbeit von Monaten ein ergreifendes Mülltonnenbegräbnis zu spendieren.

Wenn Entwicklungsgeschwindigkeit unser Problem ist, dann sollten wir uns auf jeden Fall zunächst die Frage stellen, was unsere Wunschvorstellung ist, und inwiefern die realistisch ist. Vielleicht werden wir bei genauerer Betrachtung feststellen, dass unsere Kollegen einfach die fachliche Tiefe nicht haben, die sie für das Projekt brauchen. Die Lösung heißt dann nicht Scrum sondern Weiterbildung.

Ein anderes gern genanntes Argument ist, dass man mit Scrum weniger Fehler produzieren würde. Wie soll das gehen, bitte? Wie durch ein Wunder werden dann plötzlich keine Bugs mehr produziert? Oder man findet plötzlich alles, bevor es die Anwender finden? Mal ernsthaft: eine winzige Prise gesunder Menschenverstand reicht aus, um hier ein großes Fragezeichen erscheinen zu lassen. Wenn wir zu viele Bugs produzieren, sollten wir uns vielleicht zuerst Gedanken über unsere QS machen. Scrum ersetzt diese nicht, es integriert sie nur.

Wenn unsere Software absolut unbedienbar ist, sollten wir uns wahrscheinlich zunächst mit jemandem unterhalten, der etwas von User Experience und Usability versteht. Softwareentwickler werden nicht allein durch den Einsatz von Scrum zu Experten in diesen Themen.

Scrum sagt zum Thema Qualitätskontrolle lediglich, dass der Product Owner die umgesetzten Anforderungen im Rahmen des Reviews (oder auch schon davor – was ich in jedem Fall bevorzugen würde) abnimmt. Wie wir eine QS umsetzen und in Scrum integrieren, ist unsere Sache. Für eine funktionierende QS brauche ich Scrum nicht. Im Gegenteil: Scrum bringt mir nichts, wenn ich mir nicht auch über die QS Gedanken mache.

Unsere Kollegen sind unzufrieden und unglücklich? Überfordert und/oder überlastet? Auch hier möchte ich darum bitten, zunächst nach den Gründen zu forschen. War unsere Terminvorstellung vielleicht von Anfang an vollkommen unrealistisch? Sitzen irgendwo ein paar Arschlöcher, die allen den Tag vermiesen, und deshalb herrscht schlechte Laune?

Ich werde mich jetzt unbeliebt machen und sagen, dass Scrum uns nicht vor Termindruck bewahrt. Agilität verfrachtet uns nicht auf die Insel der Glückseligen und beschützt uns vor der Realität. Irgendwann wird jemand kommen und Ergebnisse fordern, und das auch vollkommen zurecht. Scrum bewahrt uns davor – wenn wir es richtig machen – Versprechungen zu machen, die wir nicht halten können. Wenn wir Scrum aber in einem klassischen Desktop-Produkt einsetzen, für das ein jährliches Update vorgesehen ist, dann haben wir trotzdem einen Termin, den wir halten müssen.

Scrum hilft uns dabei, in kleinen Schritten zu denken. Das ist alles. Auch in Scrum arbeiten wir mit einer Roadmap, aber wir vergessen die detaillierte Planung und den Genau-dieser-Leistungsumfang-ist-genau-an-diesem-Datum-fertig-Scheiß. Wenn wir allerdings bei unseren Kunden und Anwendern falsche Erwartungen wecken, dann ist das ganz allein unsere Schuld. Davor bewahrt mich Scrum nicht.

Werfen wir mal einen Blick darauf, was Scrum eigentlich ist, um entscheiden zu können, was Scrum kann. Scrum ist ein Werkzeug – ein Framework, das wir selbst mit Leben füllen müssen (Beispiel Qualitätssicherung), das unser Vorgehen in kleine Einheiten teilt, und das unser Team stärkt. Das wars. Mehr ist da nicht. Diese Punkte sind allerdings der Grund für eine ganze Reihe von Vorteilen und Stärken. Wir werden diese jedoch nicht nutzen können, wenn wir sie nicht verstehen.

Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen

Die Aufteilung in kleine Einheiten bewirkt, dass wir in einen Regelkreis kommen: Plan-Do-Check-Act. Jeder Sprint ist so ein Kreislauf. Der Product Owner sammelt die Anforderungen. Das Team setzt diese um. Die Ergebnisse werden getestet, man zeigt sie dem Anwender und holt sein Feedback ein, in einem Betatest, einen AB-Test, einer Befragung mit Prototypen oder wie auch immer – völlig egal. Wichtig ist nur, dass wir die Hypothese, die unsere Anforderung beinhaltet, zusammen mit dem Anwender überprüfen. Das ist es, was wir (auch) unter Zusammenarbeit mit dem Anwender verstehen.

Und ganz wichtig: das in diesem Punkt Gelernte bildet die Grundlage für unseren nächsten Kreis. Das ist Agiles Vorgehen, und genau das sorgt dafür, dass unser Produkt mit jeder Iteration besser wird, wenn wir dabei konsequent bleiben. Es bringt uns nichts, wenn wir zwar in kurzen Iterationen vorgehen, dabei aber nicht mit dem Anwender sprechen und sein Feedback berücksichtigen (übrigens einer der am weitesten verbreiteten Fehler mit Scrum).

Wenn es genau das ist, was wir wollen, wenn wir verstehen, dass es genau das ist, was unser Produkt besser macht, dann haben wir die richtige Motivation für den Einsatz von Scrum. Wenn wir auf die Abteilung blicken und feststellen, dass es irgendwie besser laufen müsste, dann sollten wir uns zunächst fragen, was wir eigentlich genau erwarten, um dann der Frage auf den Grund zu gehen, warum diese Erwartung nicht erfüllt wird.

Der nächste Punkt ist die Stärkung des Teams. Das könnte lediglich die Entscheidung des Teams sein, wie viel es in welcher Zeit umsetzen will, ich verstehe darunter aber auch die Einbindung des Teams in viel mehr Planungsprozesse. Wie das im Detail aussehen kann, habe ich schon an anderer Stelle geschildert. Das hat zur Folge, dass wir motiviertere Kollegen haben, dass alle einen besseren Überblick über die Zusammenhänge haben und einige Dinge mehr. All das können wir jedoch auch ohne Scrum erreichen. Wenn es nur unser Ziel ist, das Team zu stärken, brauchen wir dafür nicht unbedingt Scrum. Das können wir auf vielen Wegen und in vielen Abstufungen erreichen. Das allein ist für mich kein Grund für den Einsatz von Scrum. Der bleibt für mich der Regelkreis, und wenn es das ist, was Ihr erreichen wollt, dann ist Scrum wahrscheinlich der richtige Weg für Euch. Bei allen anderen möglichen Motivationen stellt Euch erst die Frage, ob das auch anders erreichbar ist. Der Einsatz von Scrum ist schließlich eine tiefgreifende Veränderung.

Jetzt klingt es so, als wollte ich Euch abhalten. Das ist nicht der Fall. Ich möchte Euch lediglich bitten, diese Entscheidung sehr bewusst zu treffen, weil Euch das davor bewahren wird, sie später zu bereuen.

Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr