Neue Serie. Scrum und Kanban funktionieren im Team, doch wie macht man ein ganzes Unternehmen möglichst schnell agil? Damit beschäftigt sich diese Serie.
Schon mal von LeSS gehört? Oder von SAFe? Kein Wunder, dass diese Organigramme für agile Unternehmen („Rahmenstrukturen“ genannt) kaum bekannt sind. Sie sind unglaublich kompliziert.
Aber auch wichtig für Organisationen, die nicht nur einzelne Teams, sondern den gesamten Betrieb agil machen wollen. Und das möglichst schnell. In dieser Serie werden sie so erklärt, dass auch Laien sie verstehen. Nur Geduld, wir beginnen mit den Basics.
Und mit einem alten japanischen Sprichwort, nämlich Shuhari. Shu heißt, die Regeln zu lernen und zu befolgen. Ha bedeutet, sie mit gutem Grund zu brechen. Und Ri steht dafür, eigene Regeln zu schaffen und einen eigenen Weg zu finden. Es ist ein guter Tipp, sich der eigenen agilen Lösung nach Shuhari zu nähern!
Heute starten wir mit der wohl bekanntesten agilen Methode, mit Scrum. Die meisten haben schon davon gehört. Der Begriff kommt aus dem Rugby und heißt übersetzt Gedränge: Die Teams stehen in Reihen zusammen und steuern selbstständig ein gemeinsames Ziel an. In Unternehmen adoptierten die Methode zuallererst die IT-Entwickler. Scrum im Unternehmen kennt drei wesentliche Funktionen:
- Der Product Owner führt eine priorisierte Anforderungsliste (Product Backlog, das „Was“).
- Die Entwickler arbeiten sie von oben nach unten ab. Das geschieht in Eigenverantwortung (das „Wie“) und in kurzen Zyklen, die Sprints genannt werden. Jeden Morgen treffen sie sich für etwa 15 Minuten, um den aktuellen Stand zu besprechen. Um es kurz zu halten, bleiben sie dabei stehen (Stand-up-Meeting oder Daily Scrum). Sie stellen nur drei Fragen: Was habe ich gestern getan, um das Sprint-Ziel zu erreichen? Was werde ich heute dafür tun? Was könnte mich daran hindern? Dann geht jeder auf seinen Platz und programmiert sein heutiges Inkrement, die Aufgabe, an der er gerade arbeitet. Ist das Inkrement fertig, wird es im Sprint Review, einer Art Feedbackrunde, mit dem Kunden begutachtet und der Product Backlog angepasst. Dann wird beschlossen, was als nächstes getan wird – und immer so weiter. Rückblickend gibt es auch eine Sprint Retrospektive, in der über Team und Prozesse gesprochen wird. Hier darf gemotzt werden, wenn etwas nicht gepasst hat. Fehler passieren immer. Es gehört zum Geist von Scrum, keinem dafür den Kopf abzureißen. Wichtiger ist, daraus zu lernen.
- Die dritte wichtige Rolle spielt der Scrum Master. Achtung, weit verbreiteter Irrtum: Er ist keine Führungskraft und schon gar kein klassischer Projektmanager, sondern unterstützt und schult das Team, damit es seine Aufgaben noch besser macht.
Nächste Woche: Kanban
Die Anregungen zu dieser Serie stammen aus dem Buch von Doug Rose: Das agile Unternehmen.
