Ich kann es nicht mehr hören. Scrum funktioniert nur für Softwareentwicklung oder vielleicht noch für irgendwelche anderen Entwicklungsprojekte, aber bei uns geht das nicht, weil … [bitte beliebiges generisches Argument einfügen]. In dieser Diskussion ist die Organisation selbst immer ganz vorn dabei. HR, Controlling, wer auch immer. Scrum ist nix für die Organisation. Ich bin da ganz anderer Meinung.
Scrum funktioniert für mich besser, ganz generell, in Entwicklungsthemen als in Maintenance-Themen. Schon darüber könnte man sich in epischer Breite streiten, aber darauf verzichten wir heute einmal. Den Begriff »Entwicklung« möchte ich aber allgemein und breit gefasst wissen. Wir sind da in vielen Fällen viel zu engstirnig, und damit stehen wir uns selbst im Weg.
Ich kann ein Produkt entwickeln – und dabei ist es mir vollkommen egal, ob wir über Software oder irgendetwas Anderes sprechen – oder mich selbst. Und genau dieses »oder mich selbst« ist auf der einen Seite interessant, auf der anderen Seite vergessen wir das ständig. In meinen Augen eines der Kernprobleme der meisten Unternehmen. Die Frage, ob Scrum auch für weitere Bereiche in einer Organisation funktioniert oder geeignet ist, muss ich also viel breiter aufziehen.
Zuallererst mache ich mir klar, was ich wo überhaupt tue. Welches Team sitzt an welchen Themen? Welches dieser Dinge kann ich als Entwicklungsthema betrachten, weil dort komplexere Dinge umgesetzt werden. Im allgemeinen werde ich Mischformen haben. Teams beschäftigen sich mit Standardaufträgen oder -anforderungen (rein, machen, raus, nächstes) und gleichzeitig mit komplexeren Aufgabenstellungen. Sie entwickeln Lösungen, die vielleicht irgendwann zu solchen Standardaufträgen werden.
Diese komplexen Dinger ziehen sich über einen längeren Zeitraum, drehen viele Runden mit vielen Personen und sind schwer planbar, weil man noch nicht weiß, wohin die Reise geht. Fragt einfach mal Eure Personaler. Bei denen sieht das ganz genau so aus. Ich wette darauf.
Genau hier sind so unfassbar viele Unternehmen so unfassbar schwach. Diese Dinge, die in den einzelnen Abteilungen und Teams laufen, diese komplexeren Anforderungen, sind Organisationsentwicklung ich kann das stiefmütterlich betrachten oder richtig machen. Und wenn ich es richtig mache, dann brauche ich ein Vorgehen, das mich dabei unterstützt. Habe ich das nicht, werden diese Dinge immer unorganisiert sein, und immer hinten an stehen. Die Ergebnisse werden dann niemals so gut sein, wie sie sein könnten. Bei der Organisationsentwicklung ist das etwas, was ich nicht will. Ich weiß nicht, wie es Euch geht, aber mir ist das zu wichtig, als dass ich es im Tagesgeschäft untergehen lassen möchte.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Schön und gut. Vielleicht haben wir das schon lange erkannt und uns darauf geeinigt, Entwicklungsthemen auch in den internen Abteilungen richtig zu planen und einzutakten. Frage: warum dann nicht Agile? Wenn wir schon verstanden haben, dass Agilität – Plan-Do-Check-Act, der Kreislauf aus Erfahrung, Lernen und Anpassung – eine gute Idee ist. Warum tun wir das dann nicht auch in den internen Abteilungen?
Ich werde die Frage für Euch beantworten: weil wir zu faul dazu sind. Ist so. Streitet das nicht ab. In den internen Abteilungen muss ich endlose zermürbende Diskussionen führen, warum das eine gute Idee ist und dass Scrum nicht exklusiv Softwareentwicklung ist. In den internen Abteilungen sind die Widerstände meistens noch viel größer als irgendwo anders. Da kann man sich die Zähne ausbeißen und manchmal verzweifeln.
Das Argument, das ich am häufigsten höre, lautet: klingt ja schön, kann man bei uns aber nicht machen, weil wir nur ein wenig Weiterentwicklung machen, ansonsten ist alles Standardworkflow. Das Standardzeug macht in Scrum keinen Sinn.
Darauf lautet die Antwort: es ist weit weniger Standard als Ihr denkt. Und genau dieses Standardzeug muss ich in Scrum auch nicht abbilden. Das ist der eine Strang in diesem Team, und den anderen Strang mit den komplexeren Themen machen wir entweder richtig und planen ihn vernünftig, oder wir machen das ungeplant und schaden uns damit selbst.
Ein Beispiel: HR oder Personal (ich mag den Begriff Human Ressources nicht) hat immer auch den Auftrag der Mitarbeiterentwicklung. Das ist im allgemeinen nicht Standard. Das ist ein fortlaufendes, sich ständig weiter entwickelndes Projekt. So eine Sache schreit danach, iterativ betrachtet zu werden. Einen Schritt gehen, sich Feedback holen, daraus lernen und mit dem Gelernten die nächste Iteration anzugehen.
Klingt für mich sehr nach Scrum, oder?
Diese Dinge, diese fortlaufenden Projekte, habe ich in jeder internen Abteilung. All das ist Organisationsentwicklung und damit ist es auch sinnvoll, es iterativ empirisch zu betrachten. Ich habe lediglich das Problem, in diesen Teams und Abteilungen, Standardaufträge und projekthaftes Arbeiten unter einen Hut zu bringen. Das schaffe ich aber an anderer Stelle auch.
Zuerst einmal muss ich mir klar machen, was ich eigentlich alles tue. Was ist tatsächlich wiederkehrender Standard (wo ich eine ganze Menge Kanban-Fragen stellen könnte, in denen es mir also darum geht, den Durchfluss zu optimieren) und was ist projekthaft. ich möchte mich über Mengen und Aufwände unterhalten können. Ich möchte zunächst wissen, welche Kapazitäten sind aktuell in den Standards gebunden. Auch wenn diese Größe ein wenig schwanken mag, habe ich hier einen ersten Ansatz, mit dem ich starten kann.
Alle Nicht-Standard-Aufgaben, die dieses Team hat, packe ich in eine Liste, um einen allerersten Überblick zu bekommen. Das ist mein Proto-Backlog. Diese Liste werde ich in den nächsten Schritten verfeinern und priorisieren, um daraus ein echtes Backlog zu machen.
Ich weiß jetzt, mit welchen Kapazitäten ich an welchen Themen in Scrum arbeiten werde. Ich weiß noch nichts über die Rollen, und ich weiß noch nichts über den Kunden. Diese Dinge sollte ich jetzt klären.
Stakeholder und Kunden werden meist intern sein. Es sind aber auch Verbindungen nach außen möglich – z.B. im Einkauf oder im Support. Für uns ist wichtig, dass wir uns klar machen, wer das alles ist. Auch mit denen müssen wir über den sich ändernden Modus sprechen, um unterschiedlichen Erwartungen entgegen zu wirken. Wie wird also hier die Zusammenarbeit aussehen? Das müssen wir klären.
Dies sollten Scrum Master und Product Owner tun, womit klar wird, dass wir diese Rollen besetzen müssen. An dieser Stelle muss ich wieder davor warnen, Rollen unüberlegt mit den bekannten Würdenträgern zu besetzen. Ein Product Owner braucht andere Eigenschaften als beispielsweise ein Projektmanager.
Als Grundsatz gilt immer: überstürzt es nicht. Das bedeutet nicht, dass ich endlos warten und planen muss, aber gerade bei der Auswahl der Rollen kann ich sehr viel falsch machen und damit große Probleme verursachen. Was ist mit den Rollen verbunden? Wie macht man das? Wer will es tun? Wer kann es tun? Wer sollte es tun? Drückt nicht einfach irgendjemandem eine Rolle auf, die er nicht ausfüllen kann oder will. Da würden nur ganz viele ganz dumme Dinge geschehen.
Mein nächster Schritt wäre also, Scrum, die Rollen und deren Zusammenarbeit allen klar zu machen. Dort mache ich zwar eine kleine Standardschulung, nehme mir aber auch genug Zeit für Dialog. Die Internen, diejenigen, die innerhalb der Organisation arbeiten, haben ganz andere Fragen als die klassischen Entwicklungsprojekte. Die haben auch oftmals ganz andere Formen der Zusammenarbeit – sowohl innerhalb des Teams als auch mit den Stakeholdern. Die Transformation ist also aus vielerlei Gründen damit oft schwieriger und auch langwieriger.
Sind die Rollen geklärt, legen wir los.
Auf der Organisationsebene macht Scrum immer dann Sinn, wenn ich nicht ausschließlich in Standardvorgängen arbeite. Sobald ich Aufgaben aus der Organisationsentwicklung habe, würde ich darüber nachdenken, ob ein iteratives empirisches Vorgehen sinnvoll ist. Wenn ja, dann macht auch Scrum Sinn.
Die Antwort auf die Frage, ob Scrum dann funktioniert, hängt dann nicht von der Organisatio ab, sondern von den Menschen. Ich muss davon ausgehen, mit massiven Widerständen kämpfen zu müssen. Habe ich jedoch Veränderungsbereitschaft, funktioniert Scrum auf Organisationsebene ebenso gut, wie in der klassischen Entwicklung.
Wenn Ihr Fragen habt, fragt – habt aber bitte Geduld. Antworten können länger dauern. Ich habe viel zu tun. Und mit »länger« meine ich nicht ein paar Stunden, sondern ein paar Tage.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
