In der Arbeitsmethodik verhält es sich scheinbar ein wenig wie in der Modeindustrie. Zuerst gibt es lange weite Hosen, dann kurze enge, irgendwann wieder lange weite – und zu jedem Zeitpunkt ist kaum denkbar, dass man die andere jemals getragen hat. Im Zyklus der Modeerscheinung der Arbeitsmethodiken befinden wir uns aktuell gefühlt im Nachhall des ganz großen Scrum, Kanban und SAFe bzw. Agilitäts-Hypes. Manche schwören darauf und predigen ihre konsequente Umsetzung weiterhin. Anderswo hat sich die Enttäuschung breit gemacht, dass sich die agile Arbeitsweise nicht wie erhofft als Allheilmittel entpuppt hat. So richtig groß und erfolgreich geworden sind agile Methoden Anfang der 2000er durch das Agile Manifest und ihre unverändert aberwitzig kompakte Retro Homepage (https://agilemanifesto.org/iso/de/manifesto.html) sowie das extrem leichtgewichtige Vorgehen “Scrum” (https://scrumguides.org/). Der komplette aktuelle Scrum Guide besteht aus ca. 10 einfach zu lesenden Seiten. Falls Sie es nicht bereits getan haben, empfehlen wir diesen tatsächlich einmal vollständig zu lesen. In Folge wurde ab 2010 vor allem das Scrum Framework, initial rein für die Software-Entwicklung geschaffen, auch in vielen anderen Kontexten als Basis des agilen Arbeitens eingesetzt. …und nun - wie sollten wir wo, wann und in welchem Kontext zusammenarbeiten? Selbstverständlich muss man das Rad nicht neu erfinden - Warum etwas unnötig kompliziert machen, was schon in geeigneter Form existiert. Und immerhin hat sich Scrum ja vielerorts durchaus bewährt. Aber, und dieses aber muss selbstverständlich kommen: Es sind nun mal nicht alle Bereiche, Organisationen und Stakeholder-Umfelder gleich. Und so ist es nur logisch konsequent, anzunehmen, dass das klassische Scrum eventuell nicht überall der „Perfect Fit“ ist. Brauchen sie jeden Tag ein Daily? Oder besser 2-mal täglich? Wie läuft ein Review genau? Sollten Nicht-Entwickler plötzlich auch in fixierten Sprints von 2 Wochen arbeiten, den sie dann konsequenter Weise bei einem nötigen Change gesamt abbrechen? Die Gründer von Scrum stehen der Anpassung des Frameworks jedenfalls skeptisch entgegen. Und ich denke, dass hat vor allem mit Ihrem riesigen Erfahrungsschatz zu tun. Oft werden Anpassungen gemacht um Missstände zu verdecken. Wenn es nicht gelungen ist, ein lieferbares Ergebnis zu erzeugen, kann das weglassen des Sprint-Reviews das Sprintende hier wesentlich angenehmer gestalten. Schönmalerei ist nicht das Ziel von Scrum und so sehen die beiden Gründer im Vortwort ihres Guides die Idee der Adaption der Kern-Elemente extrem kritisch: “Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.” Ich kann Ihnen die Frage, ob Scrum, oder jegliche andere Methodik, nun die richtige Arbeitsweise für Ihr Team ist, selbstverständlich nicht blind beantwortet. Sie sollten sich auf jeden Fall aber erlauben, diese Fragen selbst zu beantworten. Außerdem dürfen Sie diese Frage regelmäßig stellen, beantworten dabei auch neue Möglichkeiten entdecken!

Sollten Sie jetzt nach Scrum arbeiten?

Ich verspreche Ihnen, dass sich durch das Beachten dieser 3 Schritte die Zusammenarbeit in Ihrem Team verbessern wird. Und noch wichtiger: Die Arbeit macht viel mehr Spaß!

Wenn Sie nun immer noch fragen haben, diskutieren wollen, Fehler korrigieren oder schlicht ihre Gegenmeinung kundtun - Ich freue mich über jegliche Form von Rückmeldung. Kurt Heiny - Senior Consultant (& Organisations-Tüftler) https://www.linkedin.com/in/kurt-heiny/