Kategorien
Warum Scrum funktioniert (Teil 1): Unvorhersehbarkeit
… oder besser warum Scrum funktionieren kann. Ich glaube noch nie hat es ein Entwicklungsprozess (bzw. Rahmenwerk) geschafft von sich zu behaupten damit würde es immer funktionieren, ohne kläglich zu scheitern. Deswegen bin ich mal ganz vorsichtig in meiner Aussage und stelle hier schon mal ein „für mich klappt es so“ dahinter. Ich würde in dieser „Reihe“ gerne ein paar Punkte aufführen, bei denen ich denke, dass sie ganz gut in die Softwareentwicklung passen und von Scrum angemessen abgedeckt werden.
Vielleicht sollte ich erst mal in die Runde fragen, wer alles weiß, was Scrum ist, aber da dies ja ein Blog ist, ist es nicht so einfach. Wenn der Artikel also den meisten von euch nichts sagt, dann lasst es mich in den Kommentaren wissen, ich entschuldige mich und hole noch mal ein Stück weiter aus.
Einer der wichtigsten Punkte in der Softwareentwicklung im Internet (und wahrscheinlich in allen Softwareprojekten), die man verstehen muss, ist, dass man am Anfang keine Ahnung hat, was man eigentlich für ein Produkt am Ende will. Ok klar, der Kunde weiß am Anfang natürlich was er will, aber wenn das Ende der Entwicklungszeit gekommen ist, dann hat das mit dem Anfang gewünschten nicht mehr zu viel zu tun. Im klassischen Projektmanagement, wie Wasserfall, stößt man da auf das große Problem, dass das Produkt am Anfang auskonzipiert und in Feinkonzepte gepackt wurde. Jede Änderung daran bedeutet einen Change-Request und in vielen Fällen auch noch mal eine Neukalkulation der Kosten. Doof das.
Bei Scrum hingegen spezifiziere ich anfänglich alles nur mal so grob, wer weiß denn schon, wie das Feature aussieht, wenn es denn wirklich an der Reihe ist umgesetzt zu werden. Das detaillierte Beschreiben passiert erst kurz vor der Umsetzung. Je näher wir an der ersten Zeile Code also sind, desto genauer ist unser Konzept. Finde ich toll und irgendwie auch sinnvoll, denn die Welt da draußen verändert sich so schnell.
Jetzt kommt natürlich die Standardfrage: „Wie kann ich denn die Kosten berechnen, wenn ich am Anfang gar nicht genau weiß, was ich da baue“. Naja sagen wir es mal so, normale Schätzungen in einer Wasserfall-Welt können bis zu 400 Prozent abweichen. Ich glaube, das bekommen wir auch hin, wenn wir nur die „Vision“ und die grobe Vorstellung haben. Weiterer großer Vorteil ist, dass wir öfters unsere Schätzung korrigieren. Nach jedem Sprint wissen wir ein wenig genauer wann wir denn ankommen.
So das war das erste Ding, was Scrum richtig macht. Ich glaube ich werde die Tage Scrum mal ein wenig genauer beleuchten mit all seinen Artefakten und Meetings, dann verliere ich auch niemanden beim Lesen und ich hab gerade Lust zu bekommen Außer ihr sagt natürlich, dass das total langweilig ist.
PS: Viele der Dinge, die ich da erzähle sind kein Alleinstellungsmerkmal von Scrum. XP und andere agile Ansätzen spielen da das gleiche Spiel, ich kenne mich einfach nur besser mit Scrum aus.
Gerne mehr!
Sehr interessant, ich bin gespannt auf den nächsten Teil.
Gerne mehr davon Nils.
Gerade in meiner Firma ist Scrum wichtig und vor allem wie andere Firmen/Personen den Erfolgsfaktor von Scrum definieren bzw. wo sie ihn sehen.
*Daumen Hoch für die Scrum Reihe* 🙂
Wenn du ein Gastbeitrag als Sinnvoll erachtest, meld dich gerne bei mir. Dann frag ich intern mal rum.
Und wenn der Kunde unbedingt ein Festpreisprojekt will, dann hat man bei Scrum noch die schöne Möglichkeit, sich auf die wirklich wichtigen Features (Business Value) zu konzentrieren und man „sprintet“ eben solange, bis das Budget aufgebraucht ist.
Im besten Fall hat man nach jedem Sprint eine lauffähige, getestete und qualitativ hochwertige Version vorliegen und kann dem Kunden damit den Vorteil bieten, am Ende von Zeit und Budget etwas WIRKLICH lauffähiges zu haben.
Das ist glaube ich ein Punkt, der bei dem Thema Kosten und Schätzungen noch wichtig ist. Denn die von dir genannten, bis zu 400% Abweichungen können in der agilen Welt genauso passieren. Der Kunde steht dann am Ende des Budgets/Projektlaufzeit dann aber nicht mit einem Haufen nicht lauffähigem Softwareschrott da, der erst noch in eine „QA-Phase“ gehen muss.
Ja, gerne mehr davon. Es ist tatsächlich so, dass viele Kunden kurz vor Ende des Projektes noch Änderungswünsche haben, die aus Sicht des Kunden „mal gerade eben“ gemacht sind. Das dies eine komplette Neustrukturierung der Datenbank erfordert oder sämtliche Controller-Actions umgeschrieben werden müssen, ist den wenigsten klar. Ich habe Scrum nie bewusst angewendet, daher, gerne mehr davon!
😀 Ich hab direkt unsere Firma ein wenig wiedererkannt 🙂 Wir haben erst gewusst, wie das Produkt aussehen und funktionieren muss, als wir echte Kunden hatten und entsprechendes Feedback hatten 🙂 Zum Glück waren wir nicht allzu weit entfernt. Vor anderthalb Jahren haben wir den Entwicklungsprozess auf Scrum umgestellt und unsere eigene Dynamik & Interpretation für uns gefunden. „Scrum by Book“ gibt es nicht, so dass gerade Anfangs viele Straucheln und das Ganze erstmal vor die Wand fahren (müssen), um den eigenen Weg zu finden.
Das die Feinplanung immer erst im Sprint erfolgt (bzw. kurz vorher) ist sicher eine der Stärken von scrum, ermöglicht es doch sowohl last minute Änderungen in der Priorisierung als auch eine hohe Aktualität der Feinplanung. Es wird quasi verhindert, dass Planung/Design „für die Tonne“ gemacht wird, was immer eine Ressourcenverschwendung darstellt.
Problematisch wird dies jedoch, wenn vorab Zeit- und Ablaufpläne (und somit Kostenpläne) von der Geschäftsleitung eingefordert werden. Obwohl diese Planungstypen quasi dem klassischen Management entsprechen, bietet gerade Scrum hier wesentliche Chancen für eine höhere Agilität des Managements, zum Preis dass diese akzeptieren, das Planung nur noch grob erfolgt. Und das anerkannt wird, das agile Scrum Teams produktiver als klassische Tams sind (sein können) und somit ohne die klassische Termindruck-Pressures qualitativ hochwertige software effizient entsteht.
Why scrum will never work:
http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/
Schon lustig warum ich heute gleichzeitig über zwei komplett gegensätzliche Scrum Artikel stolpere.
Nicht falsch verstehen: Ich finde es super sich intensiv mit dem Thema auseinanderzusetzen.
Noch ein Spruch den ich über Scrum heute gehört habe:
Scrum ist wie Sozialismus. Immer wenn es nicht funktioniert, heißt es, es war ja nicht der richtige Sozialismus aus dem Lehrbuch.
@Martin: Deswegen habe ich mich ja in der Einleitung auch vorsichtig ausgedrückt. Es kommt immer auch das Team und auch auf die Unternehmenskultur an.
Korrekt, mit Stümpern, Saboteuren oder in einem ansonsten dysfunktionalen Umfeld kann Scrum nicht funktionieren. Da gibt es aber schlicht gar keinen Prozess, der funktioniert.
Vergleichen kann man Vorgehensweisen also nur in funktionierenden Teams/Firmen. Und da schneidet Scrum nunmal ziemlich gut ab.
@Timo: Schöne Antwort. Gefällt mir.
@Timo: Stümper, Saboteure oder ein ansonsten dysfunktionales Umfeld würde ich nicht jedem größeren, an anderer Stelle völlig anders Strukturiertem Unternehmen unterstellen.
Trotzdem ist in solchen Unternehmen zu berücksichtigen, dass nicht nur die IT Kenntnisse von Scrum hat, damit ein Scrum-Projekt nicht ständig in Frage gestellt, oder aus Unwissenheit blockiert wird.
Unter den Verfechtern der „reinen“ Scrum-Lehre gibt es viele, die auf die Scrumbuts schimpfen und immer unterstellen, dass nur das „reine“ Scrum funktionieren kann und alles andere sowieso scheitert. Ich denke, Scrumbut kann gerade die Mischung für die Übergangszeit sein, um alle Beteiligten mitzunehmen auf dem Weg zur „reinen Lehre“.
Aber es gibt auch Dinge – und da möchte ich den Bezug auf die „Unvorhersehbarkeit“ nehmen – welche (wiederum abhängig von Firmenphilosophie und Anforderungen) nicht in einen „geregelten“ Scrum-Prozess passen. Scrum reagiert darauf mit seinem Reglement für „äußere Störungen“. Dies mag für den Einzelfall sicherlich zutreffend sein, stößt für mich allerdings dort an seine Grenzen, wo z.B. Entwicklung und Wartung parallel betrieben werden müssen, bzw. sich z.B. Entwickler sowohl um Wartung, als auch um Entwicklung kümmern müssen. Ich möchte das hier nicht weiter ausführen, vielleicht kommt Nils ja mal darauf zurück. Daneben gibt es natürlich auch noch die „positiven“ Unvorhersehbarkeiten, sprich: Das Team ist früher fertig. Dazu hat mir Scrum bisher keine klare Antwort geliefert. Wir haben dann Scrumbut gemacht und uns etwas Passendes aus dem Productbacklog genommen (natürlich nach Rücksprache mit dem ProductOwner). Scrum funktioniert meiner Meinung nach, auch ohne Beachtung der „reinen Lehre“. In diesem Fall sollte man sich allerdings vorher Gedanken darüber machen, warum man seine Vorgehensweise anpassen will und welche Auswirkungen dies hat. Eine willkürliche Anpassung nach Lust und Laune halte ich für schlichtweg falsch, dann wird es beliebig und man wird das Scheitern dann an Scrum festmachen.
Timo muss ich allerdings in der Hinsicht Recht geben, dass es Störern leicht gemacht wird, aber das gilt immer, sobald man Eigenverantwortliches Handeln erfordert. Gibt es an dieser Stelle keine Möglichkeit zu intervenieren, sollte man lieber eine andere Vorgehensweise wählen.
Ich mag Scrum, ich mag aber auch ScrumBan – es ist halt wie bei so vielen Dingen: Für jede Aufgabe das passende Tool!
@Guido: Meiner Meinung nach kann niemals Scrum nach der `reinen Lehre`, wie du schreibst, funktionieren. Besuch mal einen Scrum Day und du wirst feststellen, dass alle Unternehmen, die Scrum erfolgreich einsetzen, immer irgendwo ihre eigene Interpretation von Scrum haben und etwas gefunden haben, was bei ihrem Unternehmen funktioniert! Das ist doch vor allem der Knackpunkt. Es gibt Lösungen (im doch sehr lose geregelten Scrum), die funktionieren für mein Developer Team, aber nicht für das Developer Team direkt nebenan.
Wer akzeptieren kann, dass Scrum ein Tool und kein Dogma ist, wird es richtig nutzen können.
Richtig, es gibt keine „reine“ Scrum Lehre. Sehr wohl gibt es aber ganz fundamentale Prinzipien, die man erstmal verstanden haben muss, bevor Scrum überhaupt funktionieren kann. Ich nenne immer wieder gerne das Beispiel der Timeboxes, die gerne von Anfang an ignoriert werden. Aber gerade am Anfang sind die ein wichtiges Werkzeug, um auch ein Maß an Selbstorganisation zu erwirken.
Wenn man solche Dinge, die einem an Scrum von Anfang an „komisch“ vorkommen, ohne zu wissen, warum es sie so gibt, direkt abschafft bzw gar nicht erst mit einführt, dann wird Scrum nicht viel Erfolg haben.
Was will ich sagen: es ist wichtig, Scrum an seine eigenen Gegebenheiten anzupassen und damit zu arbeiten und zu experimentieren. Man sollte aber nicht aus Trotz oder weil einem etwas komisch vorkommt einfach auf verschiedene Bausteine verzichten, denn evtl. ist das der fehlende Baustein, der einem irgendwann die Augen geöffnet hätte.
@Dennis: Ich kann Dir nur zustimmen – aber genau das habe ich ja auch geschrieben. Die „reine Lehre“ mag das Ziel sein, dass man anstrebt – in der Regel wird man seine Lösung auf dem Weg dorthin finden, dann hat Scrum als Tool seinen Zweck erfüllt.
Problem an der reinen Scrum-Lehre ist sowieso, dass viele Leute nur 50% davon verstehen, 20% davon anwenden und die Hälfte genau falsch.
Eine GF hatte mir mal erklärt, Scrum würde heißen, dass die Mitarbeiter alles (vor allem: Überstunden) machen würden ein Projekt zu retten und ferner, dass es keine Anforderungserhebung mehr gibt, weil das ja alles dynamisch wäre. Wenn der Entwickler wissen will was er machen muss, würde er sich schon melden.
Mit solchen Leuten hat man es in „Scrum“-Unternehmen eben auch zu tun.
@Tom: Das sind aber sicherlich auch die Leute, die Wasserfall nicht mögen, weil man zu viel Wasser verschwendet.
Nils, das wäre super, wenn Du das Thema mal etwas mehr aufgreifen würdest. Hab schon einiges von Scrum mitbekommen, aber mir fehlt die Zeit mich mit den Prinzipien, Vor- und Nachteilen zu beschäftigen. Deshalb wäre es toll, wenn Du mit einer Artikelserie hier etwas Licht ins Dunkle bringen kannst.