Manche Unternehmen wollen weder Scrum noch Kanban auf Teamebene einführen, weil sie sich nicht durch bestehende Regelsysteme einschränken lassen wollen (obwohl Kanban überhaupt keine festen Regeln mitbringt), aber dennoch eine Agile Transformation vollziehen. Es steht also die Frage im Raum, ob es möglich ist, eine Agile Organisation aufzubauen und dabei einen komplett eigenen Weg zu gehen.
Die kurze Antwort auf diese Frage lautet: ja.
Die längere Antwort lautet: ja, aber…
Wahrscheinlich habt Ihr Euch das schon gedacht. Ich würde Euch auch dringend davon abraten, einen komplett eigenen und neuen Weg gehen zu wollen. Wenn man auf Kanban oder Scrum verzichten möchte (wir sprechen hier im Moment nur von der Teamebene), haben wir zunächst einmal ein Verständnisproblem.
Zum einen bringt Kanban überhaupt keine eigenen Regeln mit. Es ist ein lockeres Konstrukt aus übergeordneten Prinzipien und sehr allgemeinen Praktiken. Wie ich diese umsetze, liegt vollständig bei mir. Zum anderen setzt Scrum das Prinzip Agilität um, indem es einige Leitplanken vorgibt, die wir selbst mit Leben füllen müssen. Es sind jedoch sehr wenige Leitplanken, und wenn ich eine davon entferne, muss ich auch die Frage stellen, welchen Aspekt des Prinzips Agilität ich damit entferne.
Ein Beispiel: Es gibt kurze Sprints, weil Agilität bedeutet, iterativ vorzugehen. Möchte ich also längere Sprints haben, verabschiede ich mich vom Grundsatz des kontinuierlichen iterativen Lernens.
Ein weiteres Beispiel: es gibt eine Retrospektive, weil ich nicht nur das Produkt sondern auch mein eigenes Vorgehen regelmäßig einem Test unterziehen will, um regelmäßig aus dem so gelernten Verbesserungen abzuleiten.
Wenn jemand mit der Aufgabe zu mir kommt, Agilität umzusetzen oder einzuführen, dabei aber auf Scrum oder Kanban zu verzichten, lautet meine Frage, woran sich das Unternehmen (oder die Organisationseinheit) stört, weil es natürlich auch mit einem großen Aufwand verbunden ist, etwas vollkommen Neues und Eigenes zu entwickeln.
Das ist auch der erste Rat, den ich Euch geben kann: versucht zuerst herauszufinden, was der eine Punkt in Scrum oder Kanban ist, an dem sich Eure Organisation stört. Oftmals (mir ist die Situation schon häufiger begegnet) geht es nur um Details. Wir stehen also einer ganz-oder-garnicht-Haltung gegenüber, obwohl das nicht notwendig wäre.
Noch ein Beispiel: es ist nicht möglich (weil man weder die Expertise noch das Budget hat) für jedes Team einen eigenen Product Owner abzustellen. Das Konstrukt sah bisher so aus, dass es einen Projektleiter gegeben hat, der vier Teams befeuert hat. Das wäre nicht einmal wirklich ungewöhnlich.
In einem solchen Fall wäre ich Pragmatiker und würde sagen: lasst uns Scrum nehmen und abwandeln, indem wir die Rolle des Product Owners unseren eigenen Gegebenheiten anpassen.
Bevor Ihr mich jetzt am nächsten Baum aufknüpft: Die Welt ist leider nicht immer so, wie wir sie gern hätten. Manchmal haben wir nicht die Ressourcen, die wir uns wünschen oder brauchen. Manchmal gibt es Regeln und Vereinbarungen, die allem widersprechen, was wir wollen, die wir aber nicht ändern können, weil wir vielleicht Teil eines sehr komplexen Unternehmens sind.
Wir könnten in solchen Fällen einen Kreuzzug starten und zunächst versuchen, all das zu ändern, was nicht passt, was uns wahrscheinlich nicht gelingen wird und in letzter Konsequenz nur dazu führen wird, dass wir niemals den ersten echten Schritt gehen werden.
Diese »radikale« Auffassung bringt uns also möglicherweise nichts.
Klüger ist es, sich den Gegebenheiten anzupassen, Kompromisse einzugehen, und so zumindest auf den Weg zu kommen. Vielleicht gelingt es uns später, einige dieser unpassenden Regeln zu ändern, aber wir sind zumindest schon einmal losgelaufen.
Noch ekliger wird es, wenn es schlichte politische Gründe sind, die uns daran hindern, eines der bekannten Systeme einzuführen. Vielleicht will die Geschäftsführung nichts davon wissen, eine Abteilung möchte aber Agilität einführen, weil sie die Vorteile für sich erkannt hat.
In diesem Fall würde ich sagen, nehmt, was Ihr kennt, wandelt es ab, damit es auf die Gegebenheiten des Umfelds passt (wenn sich das Umfeld nicht ändern lässt) und nennt es anders.
Ist das eine schöne oder elegante Lösung? Nein. Natürlich ist es besser, transparent zu sein und in den Dialog zu gehen, den Weg der Überzeugung zu gehen, aber manchmal gibt es den einfach nicht – wieder eine der dummen Eigenheiten der wahren Welt.
Was aber tun, wenn wir wirklich etwas Neues machen wollen?
Uns zunächst einmal auf viel Arbeit einstellen. Dann nehmen wir uns das Prinzip Agilität vor, sorgen dafür, dass alle wirklich das Gleiche darunter verstehen, und bauen dann für jeden einzelnen Aspekt eine eigene Regel.
Ich warne dringend davor, hierbei nachlässig zu werden. Ein großer Vorteil von Scrum ist, dass alles bedacht ist. Für jeden wichtigen Aspekt gibt es eine Vorgabe. Wenn wir etwas Eigenes entwickeln wollen, müssen wir beachten, dass wir iterativ vorgehen, regelmäßig das Produkt bzw. unsere Ergebnisse überprüfen, regelmäßig unser eigenes Vorgehen hinterfragen, regelmäßig in den Austausch mit Kunden und/oder Anwender gehen. Allein für diese Dinge brauchen wir feste Regeln und natürlich auch jemanden, der darauf achtet, dass diese Regeln eingehalten werden.
Seid vorsichtig mit Formulierungen wie »bei Bedarf«. Die sind immer eine blöde Idee, weil sie nur dazu führen, dass man das, was man machen will und sollte, immer seltener macht. Wenn man etwas nicht zeitlich festzurren will, dann kann man es anlassgetrieben machen, z.B. immer dann, wenn ein Ticket der Klasse X abgeschlossen ist, gehen wir mit dem Kunden in den Dialog, um dieses abnehmen zu lassen.
So hätten wir eine Regel geschaffen, die zwar zeitlich offen aber von anderen Faktoren abhängig ist, die uns dazu zwingen, mit dem Kunden in den Dialog zu gehen, womit zu einem Kernpunkt dieser Überlegungen ankommen: wir müssen Zwänge schaffen. Ohne die wird unser Haus zusammenbrechen. Dahinter steckt die ganz einfache Überlegung, dass wir etwas anders machen wollen, weil wir irgendetwas umgehen möchten. Wenn wir uns das Umgehen von Regeln und Zwängen aneignen, können wir es auch gleich lassen. Und der Wunsch, etwas anders zu machen, ist der erste Schritt auf diesem Weg.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Scrum zeichnet sich dadurch aus, dass Events, Rollen und Artefakte definiert sind. Genau dies drei großen Felder müssen wir ebenfalls bespielen, wenn wir erfolgreich sein wollen. Ich benötige Events, um meine Artefakte zu befüllen (oder mit ihnen zu arbeiten) und Rollen, die das tun.
Vielleicht möchte ich kein Backlog haben, vielleicht möchte ich – aus welchen Gründen auch immer – mit einem Meilensteinplan arbeiten. Dazu muss ich wissen, wie mit diesem Meilensteinplan gearbeitet wird, und wer wann was macht. Wann und wie verändert sich dieser Plan? Wer darf ihn verändern?
Und regelmäßig sein eigenes Vorgehen zu hinterfragen und zu überprüfen, ist doch immer eine gute Idee, oder?
Natürlich kann dies hier nur den Einstieg und die initialen Überlegungen ein wenig erleichtern. Etwas völlig Neues und Eigenes zu entwickeln, ist keine einfache Aufgabe und sollte nicht auf die leichte Schulter genommen werden. Wenn Ihr das tun müsst (weil Ihr dazu gezwungen werdet), wird Eure Lösung den einzigartigen Einschränkungen und Eigenheiten Eures Unternehmens folgen müssen, daher solltet Ihr zunächst die genauen Punkte in Eurer Organisation identifizieren, die Euch daran hindern, Scrum einzusetzen, und von dort starten.
Noch einmal: Findet eine geeignete Regel für jeden Aspekt von Agilität – Iterationen, kontinuierliches Lernen durch Beobachten und Überprüfen (sowohl Produkt als auch Arbeitsweisen), Zusammenarbeit mit dem Kunden/Benutzer und Selbstorganisation.
Danach werden Euch Lücken auffallen – natürlich ist das so – und an denen werdet Ihr die Detailarbeit machen.
Kernaussagen: Man kann ein komplett eigenes System entwickeln, um agil zu arbeiten. Die Gefahr, dabei Agile Kernpunkte nicht zu beachten oder sogar bewusst zu umgehen, ist jedoch ausgesprochen groß und erfordert damit viel Disziplin. Die bessere Alternative ist es, etwas Bekanntes zu nehmen und es ggf. abzuwandeln.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
