From time to time project teams ask themselves the question: “Is it Scrum what we do?” These teams usually use terms from Scrum (and other agile methods). There is a “Daily Standup Meeting” and the project uses four-week periods (“Sprint”). At the beginning of a period is a meeting for “Sprint Planning” and requirements are placed in a “Product Backlog”. A person from the department is called “Product Owner” and the project lead is called “Scrum Master”. Still the question remains: Is it Scrum?
Definitely the answer is no. Just because the Scrum jargon is used, it doesn’t need to be Scrum. The participants should live the Scrum process! Compliance with the Scrum rules helps tremendously, but this does not go far enough and it is not even a prerequisite for Scrum, see “Individuals and interactions over processes and tools” and “Responding to change over following a plan” from the Agile Manifesto.
It’s just more than obeying the process with its rules. The point is that the team reaches the state of “flow”, forms its emergent properties and uses them to increase its efficiency to a level that no one has expected before. At first, it sounded a little bit “spiritually” to me, but then I changed my attitude when experienced it in a project. “Management 3.0” by Jurgen Appelo, which I can strongly recommend, gives an explanation of what happened and why.
Naturally these facts have impact on the way to implement Scrum in an organization. It is not enough to introduce artifacts, roles and meetings. The appropriate conditions are also required, both in the future Scrum team and in the close project environment.
It is important for a successful launch that all inexperienced members feel Scrum as soon as possible. Therefore ideal conditions are more important when Scrum is introduced. You should wisely select the project, the team and the management environment you want to start with. And if you decide to introduce Scrum, you should do it completely for the project.
For me the process with its rules is only a (admittedly important and useful) tool to apply Scrum. However, in my opinion the essence of Scrum is the interaction of the participants in the sense of the values and ideas of Scrum. It is important to keep this in mind during the daily work, especially as a scrum coach during the implementation.
What do you think? How would you fix whether or not a project does Scrum? I’m looking forward to your comments.
category: 
English 
Deutsch 
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
Pingback: Ressourcen zu Scrum
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
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
Pingback: Ressourcen zu Scrum | Sebastian Schneider