Was macht Scrum zu Scrum?

5 Kommentare

Von Zeit zu Zeit stellen sich Projektteams die Frage: „Ist das Scrum was wir machen oder nicht?“ Diese Teams verwenden meist schon Begriffe aus Scrum (und anderen agilen Methoden). Es gibt ein „Daily Standup Meeting“, das Projekt ist in vierwöchige Zeitabschnitte („Sprints“) eingeteilt, am Anfang des Zeitabschnittes trifft man sich zum „Sprint Planning“, die Anforderungen stehen in einem „Product Backlog“. Eine Person aus dem Fachbereich wird als „Product Owner“ bezeichnet und der Projektleiter nennt sich „Scrum Master“. Aber ist das Ganze auch Scrum?

Die Antwort darauf ist eindeutig nein. Nur weil das Scrum Jargon verwendet wird, handelt es sich noch lange nicht um Scrum. Der Scrum Prozess muss von den Beteiligten gelebt werden! Die Einhaltung der Scrum Regeln hilft zwar ungemein, aber es reicht bei weitem nicht aus und ist noch nicht einmal Voraussetzung für Scrum, siehe „Individuals and interactions over processes and tools“ und „Responding to change over following a plan“ aus dem Agilen Manifest.

Es  geht eben um mehr, als nur um das Befolgen des Prozesses mit seinen Regeln. Es geht darum, dass das Team den Zustand des „Flows“ erreicht, seine emergenten Eigenschaften ausbildet und wirken lässt und dadurch seine Leistungsfähigkeit auf ein Niveau steigert, dass man zu Beginn nicht erwarten würde. Als ich so etwas hörte, klang das für mich auch etwas „spirituell“. Meine Einstellung dazu hat sich aber geändert, als ich es zum ersten Mal in einen Projekt miterleben durfte. Eine Erklärung was und warum das passiert, findet sich im Buch „Management 3.0” von Jurgen Appelo, welches ich wärmsten empfehlen kann.

Das hat natürlich Auswirkung auf die Art und Weise, wie man Scrum in eine Organisation einführen sollte. Es reicht nicht aus, Artefakte, Rollen und Meetings einzuführen. Ebenfalls notwendig sind die passenden Rahmenbedingungen, sowohl im zukünftigen Scrum Team, als auch im direkten Projektumfeld.

Aus diesem Grund ist es für eine erfolgreiche Einführung wichtig, dass alle unerfahrenen Beteiligten Scrum frühzeitig erleben. Noch bedeutender ist es demzufolge, gerade bei der Einführung optimale Rahmenbedingungen zu haben. Die Auswahl der Projektaufgaben, der Teams und des Managementumfelds müssen stimmig sein. Hat man den Einführungsrahmen gewählt, sollte dort Scrum auch vollständig eingeführt werden.

Den Prozess mit seinen Regeln sehe ich nur als ein (zugegeben wichtiges und sinnvolles) Hilfsmittel an, um Scrum anzuwenden. Meiner Meinung nach ist jedoch der Kern von Scrum, die Interaktion der beteiligten Personen im Sinne der Werte und Ideen von Scrum. Dessen sollte man sich in der täglichen Arbeit, besonders als Scrum Coach während der Einführung,  immer wieder bewusst werden.

Wie seht Ihr das? Woran würdet Ihr festmachen ob ein Projekt Scrum einsetzt? Auf Eure Kommentare freue ich mich.

 

Marc Clemens

Marc Clemens ist Senior Agile Consultant und Coach in der Agilen Software Factory (ASF) und seit 1998 Mitarbeiter der MBG bzw. – nach Fusion der beiden Unternehmen – der codecentric AG. In kleineren und größerern Projekten, auch mit Teams, die sich über entfernte Standorte verteilen, agiert er in der Rolle des Product Owners. Weiterhin gibt er seine gewonnen Erfahrungen und Wissen beim Agilen Coaching an Kunden weiter.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • Niklas

    Hi Marc! Finde Deinen Beitrag echt gut. Für mich ist es so: am Anfang sollte man einen agilen Prozess wie Scrum als Mensch mal zu 100% erlebt haben und in ganzer Ausprägung praktizieren. Der Grund ist, dass man erstmal gemäß „Lehrbuch“ ein paar Monate Erfahrung sammeln muss. Wenn man ein hohes Maß an Erfahrung hat, und man kann deswegen die Problemsituation einschätzen, dann finde ich man sollte sich „dem Fluss“ unterordnen. Damit meine ich: ich mache dann genau das was zur Lösung des Problems notwendig ist und nicht was im Scrum Lehrbuch steht (auch eine Untermenge der Scrum-Elemente). Ich mache das aber nur, wenn ich die Expertise in der konkreten Situation habe, auf Dinge auch verzichten zu können. Dazu ein Zitat von Ron Jeffries: „My advice is to do it by the book, get good at the practices, then do as you will. Many people want to skip to step three. How do they know?“

    In der Praxis ist es im Moment so bei mir: wenn ich die Situation gut einschätzen kann, setze ich ein Team auch nur mit einer Untermenge der Elemente auf. Das setzt aber die entsprechende Projekt-Erfahrung und ein bischen Mut voraus (ich glaube ich habe beides, aber wer weiss :-)). Das hat auch noch den Vorteil, dass der Mindshift für die Leute nicht so riesig ist. Für Dich ist das was in Scrum gemacht wird völlig klar und logisch, für andere ist es das ganz und garnicht. Dann fange ich lieber mit einer Untermende der Techniken an, um den Leuten keine Angst zu machen. Nochmal aus Ron Jeffries Blog: „[…] big change up front or itty-bitty change up front isn’t the most important thing to me. Choosing the best moves we can manage, every day, that’s what I’m talking about.“ Man verliert die Leute leicht, wenn man mit zu viel Veränderung „um die Ecke kommt“. Deswegen ist bei mir ein bischen, mehr als garnichts. 80:20 Regel auch hier?

    LG Niklas

  • Johannes

    14. April 2011 von Johannes

    Hi,
    bei uns im kleinem Entwickler Team hätte ich keine Bedenken Scrum vollständig einzuführen. Viele Teile haben wir uns jetzt schon entliehen: Daily, Sprint Panning und Reflection. Leider scheitert es schon daran, das der Product Owner nicht „empowered“ ist und generell außerhalb des Teams das Verständnis und der Mut fehlt. Dazu muss man sagen, dass wir Teil eines Großprojektes sind und gerade dort sicherlich sehr viel Mut (und Vertrauen!) erforderlich ist Scrum durchzuziehen. Die Rolle Product Owner wird nicht einfacher, wenn man die Interessen Vieler vertreten muss. Da brauchen die Abstimmungsprozesse schon mal länger.
    Zusätzlich wird Email leider viel zu oft bei uns als Kommunikationsmedium gewählt. Hier wünsche ich mir oft das einfach die Werte des Agile Manifesto höher gehalten werden.
    Aber ich habe trotzdem das Gefühl das unser kleines Team sehr gut fährt und die anderen auch durchaus manchmal neidisch auf unsere Zahlen schielen 🙂

    Es muss halt nicht immer Scrum sein oder wie Niklas auch schön erwähnte der Weg dorthin ist ein langer und man sollte mit kleinen Schritten anfangen.

    Viele Grüße
    Johannes

  • Marc Clemens

    19. April 2011 von Marc Clemens

    Hallo Niklas,
    Hallo Johannes,

    Danke für Eure interessanten Kommentare. Bezüglich „mit kleinen Schritten anfangen“ finde ich den Abschnitt über „Memetics“ aus dem von mir schon erwähnten Buch „Management 3.0“ von Jurgen Appelo interessant.

    Dabei betrachtet er Agile Verfahren wie Scrum als Memeplex (Gruppen von Ideen) bei denen unter anderem zu beobachten ist, dass sich ein Memeplex meist einfacher einführen lässt als eine einzelne Idee. Viele der Einzelideen der Memeplexe XP oder Scrum existieren schon lange vor den Memplexen, haben sich aber erst durch die Zusammenfassung durchgesetzt. Das sollte man beim „scheibchenweise“ Einführen von Scrumpraktiken bedenken und dabei nicht vergessen, das erst durch die Änderung der mentalen Einstellung zum Prozess von allen Beteiligten Scrum erfolgreich eingeführt ist.

    Viele Grüße,

    Marc

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.