Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Data is Loading...
Your address will show here +12 34 56 78
Scrum

Schon seit ein paar Jahren ist Scrum quasi Standard in der Softwareentwicklung. In den letzten Jahren springen jetzt auch vermehrt andere Bereiche auf den Scrum-Zug, wie z.B. Hardwareentwicklung, HR oder Organisationsprojekte. Wenn ich mir allerdings viele dieser Scrum-Implementierung anschaue, stelle ich häufig fest, dass zwar Scrum eingeführt wurde, sich aber trotzdem nicht allzu viel geändert hat. Aber woran liegt das? Ganz einfach: Scrum löst keine Probleme und wird es auch nie machen. Wenn Du auf ein Kliff zuhältst, wird Scrum Dir dabei helfen es noch schneller zu erreichen.

Aber für was ist Scrum dann gut? Ganz einfach: Es macht Deine Probleme transparent und schafft eine Umgebung, in der man gefahrlos experimentieren kann. Also eine Umgebung, in der man auch mal etwas Neues ausprobieren kann. Durch die eingebaute Feedbackschleife, erfährt man relativ schnell, ob die neue Idee was taugt oder nicht und man kann sie problemlos rückgängig machen. Und genau hier liegt der Hund begraben: Die neuen Ideen und der Mut diese umzusetzen muss von Dir kommen.

Scrum ist wie eine böse Schwiegermutter. Es zeigt auf, was nicht funktioniert, lösen musst Du es aber selbst. Niemand anderes als Du und Dein Team müssen Scrum Leben einhauchen. Scrum selbst ist nur ein Framework. Solange Du oder deine Organisation, die nicht zu übersehenden Probleme ignorieren oder nur fadenscheinige Maßnahmen ergreifen, so lange wird Scrum kaum Mehrwert bringen.

Hier ein paar Beispiele: Scrum definiert ein Product Backlog, in welchem die Anforderungen nach Business Value geordnet sind. Kopiert man allerdings nur Ihr bestehendes Anforderungsdokument 1 zu 1 ins Backlog und man kann keine Aussage darüber treffen, was sinnvollerweise als Nächstes implementiert werden muss („alles ist wichtig“), dann hilft das auch nichts. Wenn bei Deinen Sprint Reviews nur das Team anwesend ist und keinerlei Stakeholder oder Kunden, wirst Du ein Produkt entwickeln, welches der Markt nicht braucht. Wenn Ihr Euch in Euren Retrospektiven lediglich auf die Symptome und nicht auf die Ursachen fokussieren, wirst Du keine tiefgreifenden Veränderungen umsetzen können. Wenn Du nicht in der Lage bist, am Ende eines Sprints etwas Fertiges zu liefern, machst Du nichts weiter, als Deine bisherige Arbeit im 2 Wochen Rhythmus abzuarbeiten. In Scrum musst Du täglich testen und integrieren. Wenn Du in Deinem Daily Scrum immer noch die „3 Fragen“ beantwortest, wirst Du Schwierigkeiten haben, den Reporting-Modus zu verlassen und ein selbstorganisiertes Team zu werden. Ich könnte diese Liste noch unendlich lange fortsetzen.

Und die Quintessenz dieses Artikels? Es geht wie immer nur um Dich. Probleme verschwinden nicht von alleine und erst Recht nicht, wenn Du Scrum nutzt (das gleiche gilt übrigens auch für Kanban). Am Ende musst Du es selbst in die Hand nehmen. Scrum kann Dich dabei unterstützen, aber umsetzen musst Du es selbst.

0