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. Meist sind das nur Umschreibungen für »wir wollen uns besser fühlen, weil wir jetzt auch diesen Quatsch 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 der heiße Scheiß, bei dem man einfach mitmachen muss, wenn man von sich selbst sagen will, dass man ein modernes Unternehmen ist. Bitte verstehen Sie mich nicht falsch, viele Unternehmen haben genau die richtige Motivation, auf Scrum zu setzen. Sie würden aber staunen, 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 Sie 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 die einzigen Gründe für den Einsatz Agiler Methoden sein können.

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 in der Softwareentwicklung.

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 seien Sie 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 mein Problem ist, dann sollte ich mir auf jeden Fall zunächst die Frage stellen, was meine Wunschvorstellung ist, und inwiefern die realistisch ist. Vielleicht werde ich bei genauerer Betrachtung feststellen, dass meine 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 ich zu viele Bugs produziere, sollte ich mir vielleicht zuerst Gedanken über meine QS machen. Scrum ersetzt diese nicht, es integriert sie nur. Wenn meine Software absolut unbedienbar ist, sollte ich mich 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 ich Scrum aber für ein klassisches Desktop-Produkt einsetze, für das ein jährliches Update vorgesehen ist, dann habe ich trotzdem einen Termin, den ich halten muss.

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 ich allerdings bei meinen Kunden und Anwendern falsche Erwartungen wecke, dann ist das ganz allein mein Problem. 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 beiden 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.

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 erstellt die Anforderungen nicht ohne Grund, er denkt sich was dabei. 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 »Act« des ersten Kreises bildet unseren nächsten Kreis und so weiter und so weiter. Das ist Agiles Vorgehen und genau das sorgt dafür, dass unsere Software mit jeder Iteration besser wird, wenn wir dabei konsequent bleiben. Es bringt mir nichts, wenn ich zwar in kurzen Iterationen vorgehe, dabei aber nicht mit dem Anwender spreche und sein Feedback berücksichtige (übrigens einer der am weitesten verbreiteten Fehler mit Scrum).

Wenn es genau das ist, was ich will, wenn ich verstehe, dass es genau das ist, was meine Anwendung besser macht, dann habe ich die richtige Motivation für den Einsatz von Scrum. Wenn ich auf die Abteilung blicke und feststelle, dass es irgendwie besser laufen müsste, dann sollte ich mich zunächst fragen, was ich eigentlich genau erwarte, um dann der Frage auf den Grund zu gehen, warum diese Erwartung nicht erfüllt wird.

Der zweite große Punkt – wie eben geschrieben – ist die Stärkung des Teams. Das kann 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 ich motiviertere Kollegen habe, dass alle einen besseren Überblick über die Zusammenhänge haben und einige Dinge mehr. All das kann ich aber auch ohne Scrum erreichen. Wenn es nur mein Ziel ist, das Team zu stärken, brauche ich dafür nicht unbedingt Scrum. Das kann ich auf vielen Wegen und in vielen Abstufungen erreichen. Scrum bringt allerdings automatisch eine Stärkung des Teams und die damit verbundenen Vorteile mit sich. 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 Sie erreichen wollen, dann ist Scrum wahrscheinlich der richtige Weg für Sie. Bei allen anderen möglichen Motivationen stellen Sie sich 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 Sie abhalten. Das ist nicht der Fall. Ich möchte Sie lediglich bitten, diese Entscheidung sehr bewusst zu treffen, weil Sie das davor bewahren wird, sie später zu bereuen.

Facebooktwittergoogle_plusredditpinterestlinkedintumblr