Agile Verwaltung

Martin Bartonitz Veronika Lévesque Thomas Michl Wolf Steinbrecher Cornelia Vonhof Ludger Wagner Hrsg.

Agile Verwaltung Wie der Öffentliche Dienst aus der Gegenwart die Zukunft entwickeln kann

Agile Verwaltung

Martin Bartonitz · Veronika Lévesque Thomas Michl · Wolf Steinbrecher Cornelia Vonhof · Ludger Wagner (Hrsg.)

Agile Verwaltung Wie der Öffentliche Dienst aus der Gegenwart die Zukunft entwickeln kann

Hrsg. Martin Bartonitz Produktmanagement c/o OPTIMAL SYSTEMS GmbH Berlin, Deutschland Veronika Lévesque Forum Agile Verwaltung e. V. Basel, Schweiz Thomas Michl Forum Agile Verwaltung e. V. Weinsberg, Deutschland

Wolf Steinbrecher Common Sense Team GmbH Forum Agile Verwaltung e. V. Karlsruhe, Baden-Württemberg, Deutschland Cornelia Vonhof Hochschule der Medien Stuttgart Forum Agile Verwaltung e. V. Stuttgart, Baden-Württemberg Deutschland Ludger Wagner Beratung Ludger Wagner Forum Agile Verwaltung e. V. Berlin, Deutschland

ISBN 978-3-662-57698-4 ISBN 978-3-662-57699-1  (eBook) https://doi.org/10.1007/978-3-662-57699-1 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Gabler © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichenund Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein Teil von Springer Nature Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany

Vorwort

Wer sind die Herausgeber? Wer sind wir, die Herausgeber, und was hat uns bewogen, dieses Buch zu schreiben? Diese beiden Fragen wollen wir Ihnen, liebe Leserin und lieber Leser, in den folgenden Zeilen kurz beantworten und Sie damit gleichzeitig neugierig machen auf das, was Sie in den Kapiteln des Buches an agiler Geisteshaltung, Methodik und Praxis erfahren und gemeinsam mit Ihrem Team im Alltag nutzen können. Am 11. Februar 2016 traf sich zum ersten Mal eine Gruppe enthusiastischer Agilisten aus Deutschland und der Schweiz. Alle Teilnehmer des Treffens verband, dass sie entweder selbst im öffentlichen Dienst tätig sind oder als Dienstleister für diesen arbeiten. Das tägliche Erleben der Herausforderungen, denen sich die öffentliche Hand heute und morgen stellen muss, war das, was diese Gruppe angetrieben hat. Hier entstand die Idee, die Geisteshaltung des agilen Manifests mit den darauf basierenden Werkzeugen und Vorgehensweisen für die öffentliche Verwaltung ur- und nutzbar zu machen. Es war die Geburtsstunde des Forums Agile Verwaltung. Das Forum Agile Verwaltung ist ein Netzwerk von Praktikerinnen und Praktikern zur ganz konkreten gegenseitigen Unterstützung, ein Forum im klassischen Sinne, ein Marktplatz der Begegnungen, auf dem man sich – auch physisch – trifft und Erfahrungen und Standpunkte austauscht. Es ist offen für alle Interessierten aus der öffentlichen Verwaltung, aber auch für Kommunalpolitiker und andere Entscheidungsträger und interessierte Bürgerinnen und Bürger. Es ist transparent und agil – ganz im Sinne des agilen Manifests, das die Leitplanken der Aktivitäten des Forums bildet. Agilität ist für die Aktiven dieses Forums kein Schlagwort, sondern eine Haltung, eine Idee und eine Richtschnur, um der wachsenden Komplexität des Verwaltungshandelns gerecht werden zu können. Agilität hilft dabei, in einer sich dramatisch verändernden Umwelt adäquat und nutzerzentriert, also bürgerzentriert, agieren zu können. Wenn wir von öffentlicher Verwaltung sprechen, so verstehen wir darunter alle Organisationen, die aufgrund eines gesellschaftlichen Auftrags handeln und nicht aufgrund eines privatwirtschaftlichen Rechtsgeschäfts mit zahlenden Kunden. Das umfasst alle Bereiche der Kernverwaltung – also die Gemeinde-, Länder-, Kantons- und V

VI

Vorwort

Bundesverwaltungen –, aber auch die eher betriebsförmig organisierten Einrichtungen der öffentlichen Daseinsvorsorge: Stadtwerke, Bauhöfe, Abfallwirtschaftsbetriebe, den ÖPNV sowie Krankenhäuser, Schulen, Hochschulen, Bibliotheken und Museen. Auch Kirchenverwaltungen oder Pflegeeinrichtungen, insofern sie ihre Existenz nicht in erster Linie auf die Erwirtschaftung von Nutzungsentgelten auf dem Markt gründen, sondern sich aus öffentlichen Mitteln finanzieren, gehören für uns dazu. Sie alle sind Teil eines „Öffentlichen Dienstes“ (engl. Public service, franz. Service public), und sie stehen – bei allen Unterschieden –in der Zukunft vor ähnlichen Herausforderungen. Das Forum Agile Verwaltung, das seinen Fokus auf diesen Sektor richtet, ist mittlerweile ein eingetragener Verein, Veranstalter einer jährlichen Konferenz und ein Forum für interessierte Mitstreiter, das Unterstützung auch jenseits der öffentlichen Verwaltung erfährt. Regelmäßige Neuigkeiten rund um Agilität und Verwaltung veröffentlichen wir seit Anfang 2016 auf unserem Blog: www.agile-verwaltung.org.1 Getragen wird das Forum bis heute von freiwillig engagierten, unentgeltlich tätigen Agilisten, die davon überzeugt sind, dass die agile Geisteshaltung dazu beiträgt, die anstehenden und mannigfaltigen Herausforderungen der öffentlichen Verwaltung im Heute und Morgen mit Bravour zu meistern. Mit unserer Begeisterung für die Wirkkraft agiler Werte, Prinzipien und Praktiken wollen wir alle Akteure – ob Verwaltungsmitarbeitende, Führungskräfte und nicht zuletzt die Bürgerinnen und Bürger als Nutznießer der erbrachten Verwaltungsdienstleistungen – anstecken, mitnehmen, begeistern und weiterbringen.

Die Entstehungsgeschichte des Buches Seit unserer Gründung als Forum sind wir immer wieder damit konfrontiert worden, dass es viele sehr gute Bücher, Artikel und andere Medien über agile Methoden gibt – die jedoch alle kaum oder wenig Bezug auf die öffentliche Verwaltung nehmen. Der Transfer der agilen Idee in die öffentliche Verwaltung wird dadurch nicht leichter. Aus vielen Gesprächen und Kontakten wissen wir, dass der Bedarf an entsprechender Hilfestellung groß ist. Dieser Herausforderung stellen wir uns als Mitglieder des Forums Agile Verwaltung und jetzt als Autoren und Herausgeber dieses Buches. Wir freuen uns darüber, schnell einen interessierten Verlag und eine Reihe von sehr kompetenten Mitautoren gefunden zu haben. Sie alle verfügen über fundiertes Wissen und reichhaltige Erfahrung in den Themen, die sie Ihnen in diesem Buch vorstellen.

1Auf

www.agile-verwaltung.org finden sich derzeit über 200 Artikel zu Agilität, Werkzeugen und Methoden, die regelmäßig ergänzt werden. Sie können über diese Webseite selbst Kontakt mit uns, den Mitgliedern des „Forum Agile Verwaltung e.V., aufnehmen. Wir freuen uns, wenn Sie uns Themen vorschlagen, Blogbeiträge kommentieren und als (Gast-) Autor den Lesern von den Hindernissen und den Erfolgen auf Ihrer Reise in die Welt der Agilität berichten.

Vorwort

VII

Die Gliederung des Buchs Das Buch, das nun vor Ihnen liegt, gliedert sich in drei Teile. Im ersten Teil geht es darum zu erklären, was Agilität ist und warum diese für die öffentliche Verwaltung relevant ist. Im zweiten Teil widmen wir uns einer Auswahl an agilen Methoden und deren Einsatzmöglichkeiten in der öffentlichen Verwaltung. Neben den Klassikern – Kanban und Scrum – sind uns auch einzelne methodische Elemente wichtig, die Sie, geneigte Leserin, geneigter Leser, niederschwellig in Ihre tägliche Arbeit integrieren können. Im dritten Teil werden anhand von Beispielen – aus vielen verschiedenen Bereichen – Möglichkeiten agiler Methoden in der praktischen Anwendung vorgestellt und diskutiert. Je nach Ihrem persönlichen Interesse bietet Ihnen das Buch also verschiedene Einstiegsmöglichkeiten. Sie können sich systematisch nähern: von konzeptionellen Überlegungen über Tools bis zu Anwendungsfeldern. Sie können aber auch das herausgreifen, was Ihnen gerade am naheliegendsten oder am drängendsten erscheint, und so ein Mosaik agiler Verwaltungsarbeit entstehen lassen. Egal, wie Sie das Buch nutzen möchten: Wir freuen uns auf Ihr Feedback und auf Ihre praktischen Erfahrungen, wie Sie mit agiler Haltung, agilen Prinzipien und agilen Methoden arbeiten. Nehmen Sie gerne Kontakt auf mit uns! Sie erreichen uns über die Webseite www. agile-verwaltung.org. Martin Bartonitz Veronika Lévesque Thomas Michl Wolf Steinbrecher Cornelia Vonhof Ludger Wagner

Inhaltsverzeichnis

Teil I  Was ist Agilität? 1

Das agile Manifest – eine Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Thomas Michl

2

Komplexität, VUKA und andere Schlagworte – was verbirgt sich dahinter?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Veronika Lévesque und Cornelia Vonhof

3

Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen? . . . . . 23 Thomas Michl und Wolf Steinbrecher

4

Agilität – die Zukunft der Öffentlichen Verwaltung?. . . . . . . . . . . . . . . . . . 41 Veronika Lévesque und Thomas Michl

Teil II  Agile Methoden und was sie im Verwaltungsalltag bewirken 5

Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise. . . . 55 Frederic Jordan

6

Scrum – in kurzen Iterationen zum Ziel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Jan Fischbach

7

Rollen und situative Funktionen agil souverän eingesetzt . . . . . . . . . . . . . . 75 Veronika Lévesque

8

Skalierung – teamübergreifende Abstimmung. . . . . . . . . . . . . . . . . . . . . . . . 81 Martin Bartonitz

9

Agile Selbst- und Teamorganisation mit Personal Kanban . . . . . . . . . . . . . 89 Thomas Michl

10 Agile Aufwandschätzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Thomas Michl

IX

X

Inhaltsverzeichnis

11 Speed Estimation – viele User Stories in kurzer Zeit schätzen. . . . . . . . . . . 113 Martin Bartonitz 12 Retrospektiven – wir entwickeln uns weiter. . . . . . . . . . . . . . . . . . . . . . . . . . 119 Ludger Wagner 13 Die User Story – eine agile Form der Aufgabendefinition. . . . . . . . . . . . . . . 137 Thomas Michl 14 Prozesse beschreiben mit Story Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Wolf Steinbrecher 15 Gelungene (agile) Kommunikation mit LEGO® Serious Play® . . . . . . . . . . 151 Tobias Seidl Teil III  Praxisbeispiele – Agile Methoden in der Öffentlichen Verwaltung 16 Agile Arbeitsformen im nicht-agilen Umfeld. . . . . . . . . . . . . . . . . . . . . . . . . 163 Veronika Lévesque 17 Bibliotheken und Agilität – Welten begegnen sich?. . . . . . . . . . . . . . . . . . . . 169 Cornelia Vonhof 18 eGovernment: Die digita(gi)le Zukunftsakte. . . . . . . . . . . . . . . . . . . . . . . . . 185 Wolf Steinbrecher 19 Agile Organisationsentwicklung mit Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . 209 Gregor Antochin und Silke Keller 20 Agilisierung einer kommunalen Verwaltung – das Beispiel Ängelholm (Schweden). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Wolf Steinbrecher 21 Agile Pflege bei Buurtzorg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 Martin Bartonitz 22 Agiles Studieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 Detlef Stern 23 Faust, Café Z, das Prinzip Kaktus und die Sache mit dem agil lernen und lehren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Heinz Bayer

Herausgeber- und Autorenverzeichnis

Über die Herausgeber Dr. Martin Bartonitz ist Produktmanager und SCRUM Product Owner bei OPTIMAL SYSTEMS GmbH, Hersteller eines Enterprise Content Management Systems. Er studierte Experimentelle Physik und wechselte nach seiner Promotion 1992 von der Messprozesssteuerung in die Welt der Geschäftsprozessautomatisierung. In seinen über 25 Jahren befasste er sich im Schwerpunkt mit den fachlichen Anforderungen der Dokumentverwaltung und -steuerung, u. a. auch im öffentlichen Sektor. Seit 12 Jahren arbeitet er mit agilen, sich selbstorganisierenden Teams und schreibt über seine hier gemachten Erfahrungen in Blogartikeln. Veronika Lévesque ist seit 1998 aktiv als Spezialistin für Organisationsentwicklung mit den Schwerpunkten Kokre­ ation, adaptive Lösungsentwicklung, Change-Prozesse, Visualisierung, Projekt- und Prozessdesign und Koordination multiprofessioneller Teams sowie (Grossgruppen-) Moderation und (System-) Beratung. Seit 2003 ist sie in der Öffentlichen Verwaltung, vorher in den Branchen Bildungsmanagement, Spedition und Logistik, Softwareentwicklung und Personalberatung unterwegs. Besondere Interessen: Grenzgänge – zwischen Ländern genauso wie zwischen ­Aufgabenbereichen und Kontexten.

XI

XII

Herausgeber- und Autorenverzeichnis

Thomas Michl ist Dipl.-Verwaltungswissenschaftler und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger consulting.

Wolf Steinbrecher ist Volkswirt und Informatiker. Er war lange als Anwendungsentwickler für medizinische Datenbanken und in Systemhäusern tätig. Von 1995 bis 2008 war er Sachgebietsleiter „Organisation und Controlling“ in einer mittelgroßen Landkreisverwaltung (1050 MA). Aus den dortigen Erfahrungen rührt das Interesse an teamzentrierten, agilen Arbeitsweisen. Ein Resultat davon war die Entwicklung des Prozessorientierten Ablagesystems (PAS), das in diversen Büchern dargestellt wird. Seit 2008 selbstständiger Berater. Mitgründer des Forums Agile Verwaltung e. V. Prof. Cornelia Vonhof  ist Professorin für Public Management an der Hochschule der Medien Stuttgart. Sie ist Bibliothekarin und Betriebswirtin und war als Bibliotheksleiterin und Organisationsberaterin in internationalen Unternehmensberatungen für den öffentlichen Sektor tätig. Sie lehrt im Studiengang Informationswissenschaften und nimmt daher vor allem die Entwicklungen und Veränderungsprozesse von Bibliotheken und Informationseinrichtungen als Organisationen des öffentlichen Sektors und als meistgenutzte, stark kundenorientierte Bildungs- und Kultureinrichtungen in den Blick.

Herausgeber- und Autorenverzeichnis

XIII

Ludger Wagner begleitet als freiberuflicher Agile Coach und Scrum Master Menschen und Teams in kleinen und ­großen Unternehmen, NGOs und in der Öffentlichen Verwaltung auf ihrem Weg zu mehr Agilität und Kundenorientierung. Er unterstützt sie dabei ungenutzte Potentiale zu entdecken und zu nutzen. Nach dem Informatikstudium 1998 gestaltete er in verschiedenen Firmen Veränderungen mit. Er begann in einem Bildungsverlag, kämpfte sich durch den Prozessdschungel großer, multinationaler Konzerne im schönen, fernen Spanien, um dann in kleinen und groß gewordenen Berliner Startups agile Werte, Prinzipien und Praktiken anzuwenden. „Menschen vor Prozesse“ – das erste Agile Wertepaar – ist dabei Richtschnur seiner Haltung und seines Handelns.

Autorenverzeichnis Gregor Antochin  Bistum Fulda, Fulda, Deutschland, [email protected] Dr. Martin Bartonitz  Produktmanagement, c/o OPTIMAL SYSTEMS GmbH, Berlin, Deutschland, [email protected] Heinz Bayer  Forum agil lernen und lehren, Freiburg, Deutschland, [email protected] Jan Fischbach Common Sense Team GmbH, Karlsruhe, Deutschland, j.fischbach@ commonsenseteam.de Frederic Jordan  Jordan Consulting, Stäfa, Schweiz, [email protected] Silke Keller  Bistum Fulda, Fulda, Deutschland, [email protected] Veronika Lévesque  Forum Agile Verwaltung e. V., Basel, Schweiz, veronika.levesque@ agile-verwaltung.org Thomas Michl  Forum Agile Verwaltung e. V., Weinsberg, Deutschland, thomas.michl@ agile-verwaltung.org Prof. Dr. Tobias Seidl Professor für Schlüsselkompetenzen, Hochschule der Medien, Stuttgart, Deutschland, [email protected]

XIV

Herausgeber- und Autorenverzeichnis

Wolf Steinbrecher  Common Sense Team GmbH, Forum Agile Verwaltung e. V., Karlsruhe Baden-Württemberg, Deutschland, [email protected] Prof. Dr. Detlef Stern Hochschule Heilbronn, Heilbronn, Deutschland, detlef.stern@ hs-heilbronn.de Prof. Cornelia Vonhof  Hochschule der Medien Stuttgart, Stuttgart, Deutschland, [email protected] Ludger Wagner Beratung Ludger Wagner, Forum Agile Verwaltung e. V., Berlin, Deutschland, [email protected]

Teil I Was ist Agilität?

1

Das agile Manifest – eine Einführung Thomas Michl

Zusammenfassung

Was ist Agilität? Auf diese Frage gibt es keine einfache Antwort. Was wir als Herausgeber unter Agilität verstehen, ergibt sich aus dem agilen Manifest der Softwareentwicklung, das in den 90er Jahren entwickelt wurde. Das agile Manifest fußt auf 12 Prinzipien als Ausfluss einer Geisteshaltung, die den Fokus auf Ergebnisse, Kommunikation und Interaktion richtet. Das soziale in Projekten ist kein Hindernis, sondern Teil des Projekterfolgs. Interdisziplinarität, Cross-Funktionalität und die Bereitschaft, sich – in ganzheitlichem Sinne – ständig fortzuentwickeln, sind wesentlicher Teil dieser Haltung, bei der die Methode an sich lediglich ein Hilfsmittel ist. Erst die ­Geisteshaltung des agilen Manifest ist es, die die agile Methode mit Leben befüllt. Oft taucht die Frage auf: Was ist eigentlich Agilität? Es gibt leider keine einfache Definition. Zumindest nicht in dem Sinne, wie wir den Begriff im Forum Agile ­Verwaltung verstehen. Agilität ist für uns eine Geisteshaltung. Eine Geisteshaltung, die auf dem agilen Manifest (der Software-Entwicklung) und seinen definierten 12 ­Prinzipien basiert.1 Wenn der Begriff Agilität aus der Software-Entwicklung stammt, was hat dies mit der öffentlichen Verwaltung zu tun? Dieser Frage müssen wir uns des Öfteren ­stellen. Werfen wir daher einen kurzen Blick auf das agile Manifest.

1Quelle:

http://agilemanifesto.org/iso/de/manifesto.html.

T. Michl (*)  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_1

3

4

T. Michl

1.1 Das Agile Manifest Die Komplexität, mit der wir zu kämpfen haben, gewinnt täglich an Fahrt. Sie ist nicht neu. Sie war schon immer da. Neu ist aber die extrem hohe Veränderungsgeschwindigkeit, mit der wir uns zunehmend auseinandersetzen müssen. Noch während wir Entscheidungen beraten, verändert sich die Faktenlage und wir müssen erneut umdenken. Diese Veränderung trifft nahezu alle Branchen, so auch die öffentliche Verwaltung. Ein extremes Beispiel durften wir im Rahmen der sogenannten Flüchtlingskrise erleben, die sich zu einer waschechten Verwaltungskrise ausgewachsen hat und über Monate hinweg sichtbar gemacht hat, wie wenig gut die öffentlich-rechtlichen Strukturen auf plötzlich auftretende Herausforderungen und extreme Veränderungen der Rahmenbedingungen reagieren können. Mit einer ähnlichen Komplexität hat die Software-Entwicklung bereits seit einigen Jahren zu kämpfen. Und immer wieder stellten Softwareentwickler fest, dass klassische Denkweisen nicht geeignet waren und sind, die daraus resultierenden Schwierigkeiten zu lösen. Auch dort hatten Entwickler schwer mit überbordenden Prozessen und Hindernissen zu kämpfen, die mit der eigentlichen Entwicklungsarbeit wenig bis gar nichts zu tun hatten, und die Qualität bezogen auf das Ergebnis (im Sinne einer Zufriedenheit aller Beteiligten) schwer getrübt haben. Dies war Anlass genug für die Software-­ Entwickler, die Frage aufzuwerfen, wie sie trotz dieser Rahmenbedingungen zu besseren Ergebnissen im Sinne aller Beteiligten kommen.2 Ihre Erkenntnis ist einfach zusammengefasst: Nur wenn alle Beteiligten (Entwickler, Kunden, Lieferanten) gemeinsam an einem Strang ziehen, kann es gelingen, unter den Bedingungen höchster Komplexität echten Nutzen für alle Beteiligten zu stiften. Aus dieser Erkenntnis entstand das Agile Manifest (ich habe im Folgenden zum besseren Verständnis und zur einfacheren Übertragbarkeit den Begriff Software durch Dienstleistung ersetzt): Wir erschließen bessere Wege, Dienstleistungen zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: • • • •

Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Dienstleistungen mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.3

2Jeff

Sutherland (2015). http://agilemanifesto.org/iso/de/manifesto.html.

3Quelle:

1  Das agile Manifest – eine Einführung

5

Um Missverständnissen vorzubeugen: Die Autoren des Manifests verteufeln die rechte Seite nicht. Sie legen lediglich einen höheren Wert auf die Werte der linken Seite. Agilität in diesem Sinne heißt, die soziale Dimension der Arbeit und Zusammenarbeit mit allen Beteiligten höher zu bewerten, als die rein technischen Aspekte. Prozesse und Werkzeuge sind Hilfsmittel, die von Menschen ausgeübt werden. Sie dürfen aber nicht zum Selbstzweck werden. Der Fokus liegt auf den Bedürfnissen aller Beteiligten und dem Stiften von Mehrwert oder Nutzen. Echtem Nutzen. Prozesse nur der Prozesse willen zu etablieren schafft keinen Nutzen. Eine umfassende Dokumentation eines Vorgangs löst das Problem nicht. Und obrigkeitsstaatlich von oben herab dem Bürger zu diktieren, was er zu tun und zu lassen hat, funktioniert in den meisten Fällen kaum – insbesondere, wenn wir auf seine Mitwirkung angewiesen sind. Agilität bedeutet, dass der Fokus der Arbeit nicht auf seitenlanger Befriedigung des bürokratischen Papierdrachens liegt. Bürokratie in diesem Sinne ist ein notwendiges Übel, dass es zwar braucht, aber das nicht zum Selbstzweck werden darf. Aber genau dies erscheint allzu oft der Fall zu sein. Nicht nur zum Leidwesen der Bürger, sondern auch der Mitarbeiter in der öffentlichen Verwaltung.

1.2 Fokus „Kundennutzen“ Auch wenn der Kundenbegriff nicht immer und nicht ohne Weiteres in der öffentlichen Verwaltung anwendbar zu sein scheint und bedauerlicherweise in der Vergangenheit viel Schindluder getrieben wurde, es geht letztendlich immer um den Fokus auf den Kunden oder Auftraggeber, der zu jeder Zeit mit eingebunden werden soll. Kommunikation ist daher ein zentrales Element agiler Methoden – und zwar nicht nur innerhalb des Teams, sondern mit allen Projektbeteiligten. Der Auftraggeber wird beim Abschluss eines jeden Zwischenschritts informiert und hat die Möglichkeit, Rückmeldung zu geben. In dem bekanntesten agilen Projektmethodenansatz – SCRUM – erfolgt dies immer am Ende eines Sprints (einer maximal vierwöchigen Planungs- und Arbeitsphase) als Teil des sogenannten Sprint Reviews. Kundenfokus heißt auch – und da können wir noch sehr vieles aus der Lean-Welt lernen, insbesondere dort, wo die Grundideen des Toyota-Prinzips gelebt werden – ­Prozesse/Abläufe danach auszurichten, ob sie einen Nutzen für die Zielgruppe stiften. Es geht darum, nicht in die Falle des Prozesses um des Prozesses Willen zu tappen, sondern tatsächlich in jedem Schritt zu bedenken: welcher Weg ist der für die Zielpersonen, die damit arbeiten müssen, sinnvoll und einfach zu bewältigen, und schafft tatsächlich einen Nutzen. Der wesentliche Fokus liegt demnach im Mehrwert oder Nutzen, der für die Zielgruppe erreicht wird. Ich möchte dies an einem realen Beispiel näher beleuchten, ohne den Namen der Behörde zu nennen. Ein Landkreis hat beschlossen, die Möglichkeit zu schaffen, ­Fahrzeug online abzumelden. An und für sich eine feine Sache. Nur wunderten sich die Verantwortlichen, dass nach erfolgreichem Abschluss des Projekts gerade einmal ein Prozent der Abmeldungen online erfolgten, wo es doch viel einfacher wäre, vom heimischen PC aus die Abmeldung durchzuführen. Die Lösung des Rätsels: Bei der

6

T. Michl

Gestaltung des gesamten Prozesses, der hier zugrunde liegt, wurden derart viele Hürden für die Anwender eingebaut, dass diese am Ende entschieden, dass der klassische Weg, die persönliche Abmeldung, weniger aufwendig und wesentlich einfacher ist als der Weg über das Online-Portal. Was ist also passiert? Zu keiner Zeit wurde im Projekt die Sicht der Anwender berücksichtigt. Der Fokus lag ausschließlich auf der Rechtmäßigkeit der Abwicklung, nicht aber auf dem Nutzwert für den Anwender. Wäre im Entwicklungsprojekt bereits zu Beginn die Sichtweise der Anwender berücksichtigt worden, wäre bereits in einem frühen Stadium erkannt worden, dass die eingeschlagene Richtung nicht zum gewünschten Erfolg führt.

1.3 12 agile Prinzipien Die Autoren des agilen Manifests haben basierend auf den oben genannten Werten 12 Prinzipien definiert, die diese Wertehaltung nochmals ausformulieren (zum besseren Verständnis habe ich auch hier die Software-Begrifflichkeiten entsprechend ersetzt): 1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung unseres Produkts/unserer Dienstleistung zufrieden zu stellen.

Im klassischen Projektmanagement bekommt der Kunde üblicherweise das Endprodukt am Ende der Projektphase präsentiert. Agile Methoden wie Scrum, Kanban4 u. ä. folgen einem anderen Ansatz. Hier werden kontinuierlich, d. h. in regelmäßigen Abständen fertige Teilentwicklungen präsentiert und vorgestellt, um bereits in der Entwicklungsphase und vor allem früh Rückmeldungen des Auftraggebers oder der Zielgruppe zu gewinnen, die ihrerseits wiederum in die Entwicklung einfließen können. Auf diese Art und Weise sollen Missverständnisse minimiert, neue Erkenntnisse berücksichtigt und verändernde Rahmenbedingungen bereits im Entwicklungsprozess selbst antizipiert werden. In der klassischen Entwicklung erfolgt die Auslieferung am Ende und dann passiert, was wir alle kennen: am Ende haben wir zwar, was wir bestellt haben – stellen aber fest, dass es nicht wirklich dem entspricht, was wir eigentlich bräuchten: Rahmenbedingungen haben sich verändert, neue Erkenntnisse führen zu neuen Bewertungen von Sachverhalten und v. m. Sprich, wir haben Zeit und Geld in etwas investiert, das am Ende doch nicht dem entspricht, was wir benötigen.

4Das

agile Kanban ist eine Abwandlung von Kanban aus dem Lean-Bereich, das hierfür Pate gestanden hat. Es gibt trotz der Ähnlichkeit allerdings minimale Unterschiede. Das Kap. 7 von Frederic Jordan gibt einen sehr guten Überblick über die Entwicklung.

1  Das agile Manifest – eine Einführung

7

Abb. 1.1  Planungszyklen in Iterationen

2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile ­Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Folglich sind Änderungen der Anforderungen jederzeit willkommen, sie werden nicht als lästig empfunden. Ganz im Gegenteil: Das Ziel ist es, unter den gegebenen Rahmenbedingungen möglichst das Beste zu schaffen, das zum aktuellen Zeitpunkt für den K ­ unden/ Auftraggeber den maximalen Nutzen stiftet. Ein agiler Grundsatz lautet: Scheitere früh, scheitere schnell. Je früher wir erkennen, dass etwas nicht zielführend ist, desto früher ­können wir gegenwirken und den Kurs neu bestimmen. 3. Liefere funktionierende Produkte/Dienstleistungen regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Die Punkte 1. und 2. können nur dann funktionieren, wenn die Ergebnisse in regelmäßigen und möglichst kurzen Abständen präsentiert werden (Abb. 1.1). Scrum zum Beispiel sieht einen solchen Zyklus mit einer Gesamtlänge von m ­ aximal 4 Wochen5. In jedem dieser Abschnitte wird ein voll „funktionsfähiger“ Teilaspekt präsentiert, getestet und begutachtet. Daraus lässt sich dann für die folgenden Schritte ableiten, ob und inwieweit Anpassungsbedarfe bestehen und sich neue Erkenntnisse ableiten lassen, die dazu führen, am Ende eine bessere Leistung zu liefern. Durch die kurzen Intervalle, in denen Ergebnisse präsentiert werden, können zum einen bereits in einem frühen Stadium Fehlentwicklungen sichtbar gemacht werden, was wiederum das frühzeitige Gegensteuern entwickelt, zum anderen wird verhindert, dass Ressourcen verschwendet werden. Gleichzeitig bietet dieses Vorgehen auch die Möglichkeit,

5Ken

Schwaber und Jeff Sutherland (2016, S. 8).

8

T. Michl

Abb. 1.2  Silos

flexibel auf veränderte Anforderungen und Rahmenbedingungen, als auch neue Erkenntnisse zu reagieren. 4. Fachleute aus den verschiedenen Bereichen müssen während des Projektes täglich zusammenarbeiten.

Agile Teams sind interdisziplinäre Teams. Alle erforderlichen Funktionen, die zur Erstellung eines Produkts oder einer Dienstleistung erforderlich sind, sind Teil des Projektteams. Damit die Abstimmung im Team funktioniert, treffen sich die Teammitglieder täglich zu einer kurzen Abstimmungsrunde. Auf diese Weise wird sichergestellt, dass Jeder vom Jedem weiß, was dieser gerade macht, und wo es eventuell Überschneidungen, Probleme oder Unterstützungsbedarf gibt. Das Team „synchronisiert“ sich selbst. In aller Regel reicht dafür eine Timebox6 von ca. 15 min aus (Abb. 1.2). Gerade bei den Problemstellungen, denen sich die öffentliche Verwaltung zu stellen hat, ist Interdisziplinarität zwischenzeitlich extrem wichtig geworden. Statt, dass wie

6Eine

Timebox ist ein fest umrissener zeitlicher Rahmen, innerhalb dessen eine Aufgabe ausgeführt sein muss. Die Limitierung hat den Effekt, dass sich die Beteiligten relativ knapphalten und auf das Wesentliche konzentrieren. Es ist empfehlenswert, durch einen Zeitnehmer, der für alle Beteiligten einsehbar ist, die entsprechende Transparenz zu schaffen.

1  Das agile Manifest – eine Einführung

9

bisher Fachbereiche in Silos abgekapselt ihre einzelnen Teilbereiche abarbeiten, geht es darum, auch gemeinsam das große Ganze im Auge zu behalten, sodass mögliche Probleme bereits in einer frühen Phase erkannt und bearbeitet werden können. Die unterschiedlichen Fachleute der verschiedenen Bereiche müssen sich dabei eng abstimmen und regelmäßig „synchronisieren“. 5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Agile Methoden gehen davon aus, dass jeder von sich aus motiviert und deshalb auch in der Lage ist, nach bestem Wissen und Können seine Fähigkeiten in das Team einzubringen. Alles, was es hierfür braucht, ist ein geeignetes Umfeld, das den Rahmen hierfür bietet. Ein solches Team muss nicht an die Hand genommen werden, sondern braucht eine klare „Produktvision“, die es dann eigenständig umsetzt. Permanente Kontrolle wirkt in einem solchen Team kontraproduktiv. Das Team spricht von sich aus auftretende Probleme an und wird entsprechend an das Management herantreten, das die Rahmenbedingungen zu schaffen hat, wenn es das Problem nicht selbst beheben kann. Aufgabe des Managements oder der Führung ist es daher, den Raum zu schaffen, der es dem Team erlaubt, sich voll und ganz auf seine ­Aufgabe zu konzentrieren. Im Gegenzug kann das Management darauf vertrauen, dass das Team die entsprechenden Aufgaben meistert. Hier zeigt sich, dass anders als gerne kolportiert wird, mit agilen Methoden Führung eben nicht obsolet wird, sondern ganz im Gegenteil, Führung anspruchsvoller wird. Das Konzept der dienenden Führung (Servant ­Leadership)7 ist nicht ohne Grund im agilen Umfeld entstanden. 6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Teams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Auch wenn es lapidar klingen mag – die Praxis zeigt, dass dies ein großes Thema ist: Kommunikation von Angesicht zu Angesicht. Sicherlich kann Mensch das eine oder andere per E-Mail oder über das Intranet kommunizieren. Aber bei komplexen Sachlagen ist die Kommunikation von Angesicht zu Angesicht nach wie vor der effizienteste und qualitativ beste Weg. Und da agile Methoden einen besonders hohen Wert auf Kommunikation legen, ist natürlich auch naheliegend, dass das Thema entsprechend gewürdigt wird. Statt über Aktenvermerke und E-Mails langwierig zu kommunizieren, treffen sich agile Teams täglich. 15 min sind ausreichend. Was ist seit gestern passiert, was ist für heute geplant und wo gibt es Herausforderungen sowie Bedarf für vertiefenden Informationsaustausch.

7Der

Begriff des Servant Leadership oder auch dienenden Führung geht auf Robert Greenleaf zurück. Führung in diesem Sinne wird als Dienst an den Geführten verstanden. Führungskräfte konzentrieren sich darauf, die Rahmenbedingungen für die Geführten zu schaffen, damit diese selbst organisiert die gestellten Aufgaben ausführen können.

10

T. Michl

So ist jeder im Team im Bilde. Gemeinsam wird am Ende der Woche geplant und in einer gemeinsamen Rückschau überlegt, was künftig verbessert werden kann. Informationen fließen schneller, das gemeinsame Verständnis wird verbessert. Durch die enge Kommunikation mit den Betroffenen – also auch mit dem Auftraggeber, Kunden, Beteiligten aus anderen Abteilungen durch regelmäßige „Rückschauen“ auf einen bestimmten Zeitraum – erschließen sich Informationsquellen, die Aufschlüsse über Verbesserungspotenziale, Anpassungsbedarfe und mögliche Herausforderungen liefern. Aber auch das gemeinsame Verständnis aller Beteiligten wird deutlich verbessert, weil alle Beteiligten die Hintergründe besser verstehen. Das erleichtert Vieles. 7. Funktionierende Dienstleistungen/Produkte sind das wichtigste Fortschrittsmaß.

Hier geht es darum, möglichst einen Nutzen für den Auftraggeber bzw. für den Kunden zu schaffen. Dieser ist das Maß aller Dinge. Nicht die überkorrekt ausgefüllte Dokumentation, das exakte Reporting ist das Maß guter Projektarbeit, sondern einzig und allein das Ergebnis. Was haben wir von dem erreicht, was wir in diesem Planungszeitraum erreichen wollten. Wie oft wird gemessen, wie lange wer für was braucht und wie oft irgendetwas von a nach b geschafft wird – ohne jedoch drauf zu achten, was am Ende dabei ­herauskommt? Das Dokumentieren von Arbeitsschritten erscheint oft wichtiger als letztendlich das Ergebnis, das erzielt worden ist. Diesem Ungleichgewicht stellt sich das 7. Prinzip entgegen. 8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, das Team und die Nutzer der Dienstleistung sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten ­ ­können.

Agilität vermeidet falsches Heldentum, im Sinne von „Verausgaben“ (Überstunden, 12-h-Arbeitstage oder gar nachts durcharbeiten sind tabu). Sämtliche agilen Methoden und Ansätze gehen davon aus, dass ein kontinuierlicher, gleichbleibender Rhythmus gesünder und produktiver ist und bessere Ergebnisse zeitigt als „Hauruckverfahren“, die letztendlich dazu führen, dass die Beteiligten verbrannt werden und dauerhaft in Leistungstiefs fallen. Der regelmäßige Rhythmus gibt darüber hinaus die Möglichkeit, ein gewisses Maß an Verlässlichkeit zu schaffen und unnötigen Arbeitsdruck zu vermeiden. In diesem Sinne werden Arbeitsspitzen als Warnsignale verstanden, die darauf hindeuten, dass irgendetwas nicht funktioniert und daher näher betrachtet werden muss. 9. Ständiges Augenmerk auf fachliche Exzellenz und gute Gestaltung der Arbeitsabläufe fördert Agilität.

Wesentliche Voraussetzung, damit dies alle funktionieren kann, ist – wie sollte es auch anders sein – dass jedes Teammitglied über einen hohen Grad an fachlichem, sozialem und organisatorischem Können verfügt. Nur so erkennt das Team Handlungsmöglichkeiten und auch Herausforderungen und kann adäquate Lösungen erarbeiten. Die kontinuierliche Weiterentwicklung der Teamfähigkeiten, der internen Arbeitsabläufe und

1  Das agile Manifest – eine Einführung

11

die permanente Weiterentwicklung der „Werkzeugkiste“ ist Voraussetzung für die Agilität, da nur so auf die möglichen Veränderungen reagiert werden kann. 10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Es mag im ersten Moment etwas kurios klingen, dass die Kunst darin besteht, die Menge der nicht getanen Arbeit zu maximieren. Aber beim genaueren Überlegen wird klar, was damit gemeint ist: Es geht darum, Nutzen zu stiften und unnötige Arbeiten zu vermeiden, die keinen Nutzwert schaffen. Statt vieler Zwischenschritte, die sich als unnötig erweisen, geht es darum, die Dinge möglichst einfach zu machen, zu „verschlanken“, wo es geht. Sprich: Alles „über Bord“ zu werfen, was nichts zum gewünschten Ergebnis beiträgt. D. h. auch zu hinterfragen, ob das, was Mensch tut, tatsächlich auch zum Ergebnis beiträgt oder nur aus „Tradition“ so gemacht wird. In eine ähnliche Richtung geht auch das 12. Prinzip, auf das wir noch eingehen werden. 11. Die besten Arbeitsrahmen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams.

Agile Teams sind selbstorganisiert. Sie wissen am besten, welchen Arbeitsrahmen sie zur Lösung brauchen und wie sie sich selbst organisieren, damit sie zusammenarbeiten können. Da sich das Team täglich mit dem gemeinsamen Thema auseinandersetzt, verfügt es auch über die Expertise, die es benötigt, um Anforderungen, Entwürfe und Arbeitsrahmen so zu gestalten, dass am Ende ein für alle befriedigendes Ergebnis herauskommt. Das Team fixiert sich nicht auf Stellenbeschreibungen, die im Detail festlegen, wer was zu tun hat. Sondern das Team definiert sich über Rollen. Nehmen wir Scrum – eine der bekanntesten Methoden der agilen Produktentwicklung. Dort wird zwischen drei Rollen unterschieden.8 Mehr nicht. Es gibt einen sogenannten Scrum Master, der das Team begleitet, unterstützt und berät. Es gibt den Produkteigentümer (Product Owner), der innerhalb des Teams die Interessen des Auftraggebers vertritt und auch den Kontakt nach außen hin zum Auftraggeber sicherstellt, und es gibt das Entwicklerteam. Das Entwicklerteam setzt sich aus allen Funktionen, die zu Erfüllung der Aufgaben erforderlich sind, zusammen. Alle verfügen im Idealfall über eine breite Grundkenntnis und jeweils Spezialkenntnisse, sodass jeder im Team andere Teammitglieder unterstützen kann. Gemeinsam mit dem Scrum Master und dem Produkteigentümer bildet das Entwicklerteam ein Scrumteam. 12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Die kontinuierliche Verbesserung des Teams und seiner Zusammenarbeit ist von zentraler Bedeutung. Ein neues Team funktioniert nicht von Anfang an perfekt. Es muss sich finden. Es muss sich selbst mit den sich verändernden Rahmenbedingungen entwickeln,

8Der

Scrum Guide (2016).

12

T. Michl

wenn es sich einmal gefunden hat. Im Lean Management wurde der Begriff Kaizen9 geprägt. Die Idee des Kaizens spiegelt sich auch im agilen Manifest wieder. Es gibt keine Perfektion, sondern immer nur die im Augenblick beste Lösung. In diesem Sinne ist die kontinuierliche Weiterentwicklung ein zentrales Element, dem mit regelmäßigen Teamreflexionen Rechnung tragen. Zusammengefasst: Verbesserung heißt hier nicht einfach nur Prozesse und Strukturen fortzuentwickeln, sondern im ganzheitlichen Sinne voranzuschreiten. Die Zusammenarbeit zwischen allen Beteiligten zu verbessern, die soziale Ebene miteinzubeziehen und als eine der wichtigsten Stellschrauben zu sehen.

1.4 Resümee Wie sich hoffentlich gezeigt hat, legt das agile Manifest einen großen Wert auf die soziale Dimension der Arbeit. Kommunikation zwischen allen Beteiligten im Sinne einer maximalen Nutzenstiftung für den Auftraggeber wird zum zentralen Kriterium. In der guten Zusammenarbeit aller Beteiligten liegt nach dieser Geisteshaltung die Lösung komplexer Sachverhalte, denen wir uns letztendlich nur Schritt für Schritt annähern können. Das agile Manifest erfindet das Rad nicht neu. Es führt nur verschiedene Erkenntnisse aus den verschiedensten Bereichen zusammen. Agile Methoden in diesem Sinne sind Hilfsmittel, die die Geisteshaltung des agilen Manifests mit Leben füllen und unterstützen sollen. Aber nicht die Methode ist das Ausschlaggebende sondern die Geisteshaltung. Eine Geisteshaltung, die sich offen gegenüber Veränderungen zeigt und alle Betroffenen zu Beteiligten macht. Aber nur so lassen die künftigen Herausforderungen der öffentlichen Verwaltung stemmen und das Feld der Herausforderungen ist breit. Selbst der Teil, den wir bereits überschauen können. Ganz zu schweigen von den Teilen, die wir bei weitem noch nicht überschauen, geschweige denn erahnen können.

Literatur Schwaber K, Sutherland J (2016) Der Scrum Guide, Deutsche Fassung aus 2016 Sutherland J (2015) Scrum – a revolutionary approach to building teams, beating deadlines, and boosting productivity. Random House UK Ltd., London

9Der

Begriff Kaizen stammt aus dem Japanischen und wie viele andere Begriffe aus dem Lean Management. Er bedeutet Streben nach kontinuierlicher und unendlicher Verbesserung. Leider wurde er im Laufe der Zeit und durch die Übernahme in den westlichen Kontext verkürzt. Das tradierte Verständnis betrachtet den permanenten Verbesserungsprozess jedoch aus einer ganzheitlichen Sicht, die über die Adaption in Form des „Kontinuierlichen Verbesserungsprozesses“ hinausgeht.

1  Das agile Manifest – eine Einführung

13

Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger ­consulting.

2

Komplexität, VUKA und andere Schlagworte – was verbirgt sich dahinter? Veronika Lévesque und Cornelia Vonhof

Zusammenfassung

Die öffentliche Verwaltung, egal ob auf kommunaler Ebene, auf Landes-, Kantonsoder Bundesebene, sieht sich zunehmend Herausforderungen gegenüber, die sie mit den üblichen Methoden und vor allem mit den bisherigen Strukturen nicht zufriedenstellend bewältigen kann. Dies ist eine Rückmeldung, die wir auf Workshops und Konferenzen von Vertreterinnen und Vertretern aus der öffentlichen Verwaltung immer wieder erhalten. Die Welt hat sich im Zuge der verschiedenen „-ierungen“ wie Globalisierung und Digitalisierung und über eine Innovationsgeschwindigkeit, die höher ist als je zuvor und schneller als je zuvor in die Alltagskultur eines jeden Einzug hält, in den letzten 3 Jahrzehnten enorm verändert. Was heißt das konkret und wie ist damit umzugehen?

V. Lévesque (*)  Forum Agile Verwaltung e. V., Basel, Schweiz E-Mail: [email protected] C. Vonhof  Hochschule der Medien Stuttgart, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_2

15

16

V. Lévesque und C. Vonhof

2.1 Herausforderungen aller Orten Der demografische Wandel sowohl bei der Bevölkerung wie auch bei den eigenen Mitarbeitenden, die sich zunehmend öffnende Schere zwischen hoheitlichen Aufgaben und dem Selbstverständnis als Dienstleisterin1, die gestiegenen Erwartungen der Bürger an Beteiligung, die gewachsene Zahl der Flüchtlinge, die sich beschleunigende Digitalisierung, die sich abzeichnende Schwierigkeit, freiwerdende Stellen wieder zu besetzen… dies sind nur einige Herausforderungen, die Verwaltungen bewältigen sollen, müssen oder wollen. Betrachtet man – unabhängig von inhaltlichen Aspekten – die Gemeinsamkeiten dieser Ausgangslage, so haben wir festgestellt, dass drei Dinge, von denen man oft ausgeht, auch weil sie in der Theorie vielfach so gelehrt werden, in erster Linie eben nur in der Theorie zutreffen: • Der Auftraggeber weiß was er will. • Die Umsetzenden wissen, wie das Problem bzw. der Auftrag zu lösen ist. • Während des Projektverlaufs ist dem Plan zu folgen, d. h. es ändert sich nichts. Dabei stehen die Begriffe „Auftraggeber“, „Umsetzende“ und „Projektverlauf“ nur stellvertretend für übliche Rollen. So kann ein „Auftraggeber“ der Vorgesetzte, die Referatsleitung, die Kundin oder die Politik sein. Ein Auftrag kann sich auch aus gesetzlichen Vorgaben ergeben. Es sind komplexe Umweltbedingungen und Anspruchsstrukturen, in denen Verwaltungen agieren. Der Begriff „Umsetzende“ steht als Platzhalter für interne Rollen wie Sachbearbeiter, Projektleiterin oder eine sonstige Fachperson. „Projekt“ kann auch eine beliebige fachliche Fragstellung sein, ein Geschäftsprozess oder auch ein Kriseneinsatz. Zumeist aber stellt sich die Realität anders dar und präsentiert Umstände, mit denen wir umgehen müssen: • Die auftraggebende Person entdeckt erst unterwegs genauer, was sie wirklich benötigt – denn sie eignet sich unterwegs neues Wissen an, versteht den Weg und die Zusammenhänge im Verlauf zunehmend besser, die Ziele schärfen sich zunehmend. • Die Umsetzenden entdecken Schritt für Schritt, welche Optionen es gibt, um das ­Problem zu lösen oder den Auftrag umzusetzen – denn sie wissen mit jedem Schritt mehr und können auch die spezifischen Umstände der aktuellen Situation immer ­besser einschätzen. • Vieles ändert sich im Verlauf – denn die Welt dreht sich außerhalb des Auftrages unbeirrt weiter.

1In

der Schweiz werden alle Angebote der öffentlichen Hand „service public“ bezeichnet.

2  Komplexität, VUKA und andere Schlagworte …

17

Weiterhin oft genannt wird der Aspekt: Es wird alles immer komplexer. Wir wissen gar nicht, wie wir das bearbeiten sollen. „Komplex“ ist etwas Anderes als „kompliziert“. Während es für komplizierte Fragestellungen meist mindestens eine zutreffende Antwort gibt, funktionieren komplexe Fragestellungen anders. Komplizierte Fragen lassen sich mit Wissen beantworten. Sie setzen lediglich wesentlich mehr Wissen als einfache Fragen voraus. D. h. auf komplizierte Fragen, können wir durch ein Mehr an Wissen reagieren. Anders jedoch bei komplexen Fragestellungen. Jede Teilentscheidung in einem komplexen Prozess hat Konsequenzen, die richtungsweisend wirken und so eine neue Dynamik anstoßen kann. Das heißt kurz gesagt, dass Ursachen und Wirkungen in komplexen Umgebungen erst rückblickend sichtbar werden. Komplexität bedeutet demnach, eine Gleichung mit mehreren Unbekannten beantworten zu müssen. In a complicated context, at least one right answer exists. In a complex context, however, right answers can’t be ferreted out. It’s like the difference between, say, a Ferrari and the Brazilian rainforest. Ferraris are complicated machines, but an expert mechanic can take one apart and reassemble it without changing a thing. The car is static, and the whole is the sum of its parts. The rainforest, on the other hand, is in constant flux—a species becomes extinct, weather patterns change, an agricultural project reroutes a water source—and the whole is far more than the sum of its parts (Snowden und Boone 2007, Harvard Business Review, S. 69–76).

Komplex ist also nicht einfach „besonders schwierig“. Sondern anders. Deshalb verzerrt der Versuch der Komplexitätsreduktion, nur um einen leichteren Umgang mit der Situation zu simulieren, die tatsächlich bestehende Realität. Trivialisierung ist nicht der adäquate Weg, um mit komplexen Sachverhalten umzugehen. Häufig hilft im Umgang mit Komplexität eben gerade nicht ihre Reduktion, sondern die kollaborative, koordinierte Arbeit. Koordination in einem multiprofessionellen Team und eine adaptive Etappierung sowie die Taktung des Arbeitsprozesses entlang des Zuwachses an Erkenntnissen. So können Erkenntnisfelder gesucht und gefunden werden, dann pragmatisch und realitätsnah bearbeitet werden. Die These, dass speziell die öffentliche Verwaltung in der Auseinandersetzung mit Neuem mit besonderen branchenspezifischen Schwierigkeiten zu kämpfen hat, scheint aus unserer Sicht plausibel und deckt sich zugleich mit unserer Innensicht als Mitarbeitende im öffentlichen Sektor: • Der grundsätzliche Auftrag von Verwaltung ist es, für Stabilität, Verbindlichkeit, Rechtstreue (im Sinne Rechtsstaatlichkeit) und vor allem für Verlässlichkeit zu sorgen. • Die öffentliche Verwaltung ist weniger darauf angewiesen, sich permanent mit Innovationsdruck, mit sich ständig verändernden Kundenanforderungen oder Kundenwanderungen – ausgedrückt in variablem Kaufverhalten oder unmittelbaren Konkurrenzkämpfen mit Mitanbietern – auseinanderzusetzen und darin erfolgreich zu bestehen.

18

V. Lévesque und C. Vonhof

Weil das so ist, fehlt oft ein routiniert einsetzbares Instrumentarium und Erfahrung, um mit Veränderungsanforderungen selbstverständlich, gelassen und kreativ umzugehen. Gleichwohl ist keineswegs so, dass die beschriebenen Herausforderungen allein für Verwaltungen gälten und dass nur Verwaltungsorganisationen mit hohem Veränderungsdruck und zugleich Veränderungsresistenz zu kämpfen hätten. Dies gilt ebenso für Unternehmen aller Branchen. Ansätze, die im Management für einen Umgang mit solchen Situationen diskutiert werden, lassen sich unter der großen Überschrift „agile Methoden“ zusammenfassen. Eine wesentliche Überzeugung, die dem Einsatz agiler Methoden zugrunde liegt, ist die, dass es gerade in VUKA-Umwelten (Bennett und Lemoine 2014, Business Horizons, S. 311–317) weder einem Kunden noch einem Anbieter möglich ist, zu Beginn eines Entwicklungsprozesses genau zu formulieren, wie dessen Ergebnis – ein neues P ­ rodukt oder eine neue Dienstleistung – aussehen, oder wie das richtige Vorgehen bei einer Problemlösung sein soll. Für den Kontext öffentlicher Verwaltungen müssen jedoch Fokus und Wording der agilen Prinzipien, wie sie in Kap. 1 beschrieben sind, erweitert und zugeschnitten werden. Wir haben daher in folgenden Leitsätzen unsere Prinzipien agiler Verwaltung formuliert: • • • • • •

Das Ganze in den Blick nehmen, cross-funktionale verantwortliche Teams bilden, die Anspruchsberechtigten einbeziehen, mit überschaubaren Änderungen und Teilergebnissen experimentieren, sich regelmäßiges Feedback von innen und außen verschaffen, das System so immer angemessener machen.

2.2 Ein paar Stichworte zu den Prinzipien 2.2.1 Das Ganze in den Blick nehmen Die Ausgangslage einer VUKA-Umwelt wurde oben beschreiben. So schön es auch wäre: Komplexität lässt sich nicht sinnvoll reduzieren, weil die Realität komplex ist. Komplexität kann aber gemeinsam von verschiedenen Fachpersonen, Blickwinkeln und Ebenen aus erfasst und bearbeitet werden. Die agile Herangehensweise empfiehlt, einerseits diese Komplexität und zugleich einen längeren Zeitraum in den Blick zu nehmen. So können Schlüsselrisiken besser erkannt und Vorsorge getroffen werden. Dann kann man „auf Sicht steuern“ und dennoch die grobe Richtung beibehalten. Agilität bedeutet die Fähigkeit, schnell zu handeln. Aber diese muss eingebettet sein in klare Vorstellungen über die großen Entwicklungsrichtungen.

2  Komplexität, VUKA und andere Schlagworte …

19

2.2.2 Cross-funktionale verantwortliche Teams bilden Hier sei auf das oben bereits Gesagte verwiesen: Komplexität kann gemeinsam von verschiedenen Fachpersonen, Blickwinkeln und Ebenen erfasst und bearbeitet werden. Ein zentrales Kulturmuster unserer Verwaltungen ist jedoch das Denken in Zuständigkeiten. Für jede Aufgabe gibt es eine zuständige Verwaltungsebene und in dieser eine zuständige Behörde, ein Amt oder Sachgebiet. Komplexe Aufgaben werden so gut es geht in Einzelhäppchen zerteilt, die auf die Zuständigkeiten zurechtgeschnitten werden. Das Denkmuster ist die Reduktion von Komplexität durch Zerteilung. Agiles Vorgehen bedeutet, bei derartigen Aufgaben, Teams interdisziplinär und zuständigkeitsübergreifend zu bilden. Das Team als Ganzes ist für die korrekte Auftragsbearbeitung und die Fristeinhaltung verantwortlich. Es steht im regelmäßigen Kontakt und sucht bei auftretenden Hindernissen gemeinsam nach Ideen zu ihrer Beseitigung. Es hilft dabei, aus der Position des isolierten Einzelkämpfers herauszufinden und Unterstützung im Team zu finden.

2.2.3 Die Anspruchsberechtigten einbeziehen Auch Verwaltungen arbeiten nicht im luftleeren Raum, sondern für Anspruchsberechtigte (Kunden, Bürger, Klienten…). Bei öffentlichen Großprojekten ist es schon ins Bewusstsein gedrungen, dass die Einbeziehung der Betroffenen von Anfang an den Projekterfolg nur selten behindert, ihn aber oft genug erst ermöglicht. Agile Verwaltungen dehnen dieses Prinzip auf alle diejenigen Aufgaben aus, bei denen es praktisch möglich und rechtlich zulässig ist.

2.2.4 Mit überschaubaren Änderungen und Teilergebnissen experimentieren Dass oft am Anfang nicht klar ist, worin das gute Ende bestehen könnte, wurde oben beschrieben. Also was tun? Wie sieht ein Projektplan oder ein Vorgehenskonzept dann aus? Hier erfolgt ein radikaler Bruch mit gewohnten Denkmustern: Es werden keine umfangreichen Pläne ausgearbeitet, die für ein ganzes Jahr oder länger gelten. Sondern das Team arbeitet bewusst in einem Experimentiermodus, wertet Erfahrungen schnell aus, verstärkt Erfolgreiches, verwirft Wirkungsloses. Eine der bekanntesten agilen Methoden heißt „Scrum“. Bei Scrum gibt es zu jedem Vorgang und jedem Projekt ein Umsetzungsteam. Dieses Team organisiert sich in festen Zeitintervallen, „Sprints“ genannt. Nach jedem Intervall sollen, wo immer möglich und sinnvoll, in sich abgeschlossene und bereits nutzbare und umsetzbare Zwischenergebnisse abgeliefert werden. Die Vereinbarung fester Abstimmungstermine spart Koordinationsaufwand, der feste Arbeitsrhythmus

20

V. Lévesque und C. Vonhof

tut dem Team gut. Die Zwischenergebnisse machen Nachsteuern und Verbessern möglich und greifbare Teilergebnisse motivieren zum Weitermachen. Wenn es gelingt, die Arbeit in kurzen Etappen oder ‚Sprints‘ zu organisieren und am Ende dieser Etappe ein Produkt steht, dass in sich einen Wert hat, wie ein Baustein, der später mit anderen Bausteinen zu einem Gebäude wird, dann können folgende Mechanismen wirksam werden:

2.2.4.1 Praxisbezug und Brauchbarkeit Die Arbeiten innerhalb eines jeden Sprints sind auf ein konkretes Produkt – zugleich ein Baustein für das Gesamtergebnis – ausgerichtet. Das bedeutet, dass für die gemeinsame Arbeit Praxistauglichkeit und kluge, realitätsbewusste Prioritätensetzung einen hohen Stellenwert haben. 2.2.4.2 Anpassungsvermögen Wenn ein Produkt sich in eine falsche Richtung entwickelt oder sich während der Arbeit Auftrag oder Umstände verändern, dann ist maximal die Arbeit des letzten Sprints „verloren“. Denn das Ergebnis des vorgehenden Sprints ist als Ergebnis immer noch vorhanden und auf ihm kann weiter aufgebaut werden. Im nächsten Sprint kann auf die Anpassungsbedürfnisse eingegangen werden. Das „nicht passende“ Produkt eines Sprints kann vielleicht sogar anderorts noch einen Wert entwickeln. Für die Verwaltung ist es gewöhnungsbedürftig, in dieser Form auf eigenständige, mehrfachnutzbare Zwischenprodukte hinzuarbeiten – hier braucht es allenfalls etwas Beratung. Möglich ist es durchaus. 2.2.4.3 Fehlerkultur und kreative Problemlösung Fehler sind weniger gravierend, wenn durch die kurzen Etappen und durch den Anspruch an die Nutzbarkeit jedes Teilergebnisses ihre negativen Auswirkungen eingeschränkt sind. Wenn etwas falsch läuft, ist so nie das ganze Projekt gefährdet, sondern nur der letzte Teilschritt. Das gibt Freiraum für das Arbeiten oder für kreative alternative Wege zur Problemlösung. Der Druck von Fehlervermeidung um fast jeden Preis nimmt so ab: Ein geringeres Fehlervermeidungsbedürfnis bedeutet mehr Entwicklungs- und Handlungsoptionen. Und auch Fehler können Gewinn bringen. Nämlich dann, wenn man zulassen kann, dass sie passieren und dann damit etwas macht. Viele innovative Produkte, Post-its2 zum Beispiel, sind so entstanden.

2.2.5 Regelmäßiges Feedback von innen und außen verschaffen Hier kommen die kurzen Intervalle und das bewusste Erstellen von Zwischenergebnissen zum Tragen. Die Teilergebnisse der einzelnen Intervalle sind auf Nutzbarkeit ausgerichtet,

2Vgl.

Dazu: https://www.3mdeutschland.de/3M/de_DE/post-it-notes/contact-us/about-us/.

2  Komplexität, VUKA und andere Schlagworte …

21

auch wenn das „Gesamtprodukt“ noch nicht fertig ist. Diese Teilergebnisse kann man ausprobieren und sich Feedback der Betroffenen, der Zielgruppe, der Kunden holen. Fällt das Feedback negativ aus, dann hat man nur einen kurzen Sprint lang in eine falsche Richtung gearbeitet und nicht eine gesamte Projektlaufzeit. Dieses Prinzip reflektiert v. a., dass Anspruchsberechtigte zu Beginn eines Projektes oft nicht verlässlich und belastbar formulieren können, welche Anforderung sie an eine Lösung stellen. Lastenhefte werden zwar routinemäßig erstellt, aber häufig mit Hingabe nachjustiert oder gleich ad acta gelegt. Agile Methoden ermöglichen das gemeinsame Lernen von Anspruchsberechtigten, Auftraggebern und Realisierer.

2.2.6 Das System so immer angemessener machen Durch die oben genannten Prinzipien wird ein ständiger Lern- und Verbesserungsprozess in Gang gesetzt. Die Vorgehensweise ist iterativ und geprägt vom Grundsatz „Experimentieren statt streiten“. So entsteht stabiles Systemwissen, ohne in Routinen zu verfallen, die nicht mehr reflektiert werden oder nach dem Motto funktionieren: „Wenn ich einen Hammer habe, wird jedes Problem zum Nagel“.

Literatur Bennett N, Lemoine GJ (2014) What a difference a word makes. Understanding threats to performance in a VUCA world. Bus Horiz 57:311–317 Snowden DJ, Boone ME (2007) A leader’s framework for decision making. Harv Bus Rev 85(11):69–76 (PMID 18159787)

Veronika Lévesque ist seit 1998 aktiv als Spezialistin für Organisationsentwicklung mit den Schwerpunkten Kokreation, adaptive Lösungsentwicklung, Change-Prozesse, Visualisierung, Projekt- und Prozessdesign und Koordination multiprofessioneller Teams sowie (Grossgruppen-) Moderation und (System-) Beratung. Seit 2003 ist sie in der Öffentlichen Verwaltung, vorher in den Branchen Bildungsmanagement, Spedition und Logistik, Softwareentwicklung und Personalberatung unterwegs. Besondere Interessen: Grenzgänge – zwischen Ländern genauso wie zwischen Aufgabenbereichen und Kontexten.

22

V. Lévesque und C. Vonhof Prof. Cornelia Vonhof  ist Professorin für Public Management an der Hochschule der Medien Stuttgart. Sie ist Bibliothekarin und Betriebswirtin und war als Bibliotheksleiterin und Organisationsberaterin in internationalen Unternehmensberatungen für den öffentlichen Sektor tätig. Sie lehrt im Studiengang Informationswissenschaften und nimmt daher vor allem die Entwicklungen und Veränderungsprozesse von Bibliotheken und Informationseinrichtungen als Organisationen des öffentlichen Sektors und als meistgenutzte, stark kundenorientierte Bildungs- und Kultureinrichtungen in den Blick.

3

Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen? Thomas Michl und Wolf Steinbrecher

Zusammenfassung

Ein Grundprinzip des Arbeitens in Verwaltungen stellt das Denken in Einzelzuständigkeiten dar. Auch komplexe Aufgaben werden in „kleine Häppchen“ ­zerteilt und jedes Häppchen einem zuständigen Sachgebiet oder auch einer anderen beteiligten Behörde und darin jeweils einer Person zugeordnet. Diese Arbeitsweise ist über 200 Jahre alt und in vielen Situationen der heutigen Zeit nicht mehr angemessen. Sie führt zu widersprüchlichen Ergebnissen, permanenten gegenseitigen Behinderungen und extrem langen Bearbeitungszeiten. Auch die Digitalisierung eines solchen mangelhaften Prozesse führt nicht weiter: Man erhält dann einen digitalisierten, mangelhaften Prozess. Agile Grundsätze zielen hingegen auf Verhaltens- und Haltungsänderungen der Beteiligten und sind so nachhaltiger.

3.1 Herausforderungen – und ob wir uns ihnen stellen sollen Verwaltung ist Teil eines Gesamtsystems, das hochgradig komplex ist. Sie ist eingebettet in eine Gesellschaft, die sich permanent im Umbruch befindet. Es mag unterschiedliche Einschätzungen geben, ob sich diese Änderungen schneller als in der ­Vergangenheit

T. Michl (*)  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] W. Steinbrecher  Common Sense Team GmbH, Forum Agile Verwaltung e. V., Karlsruhe, Baden-Württemberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_3

23

24

T. Michl und W. Steinbrecher

v­ ollziehen.1 Aber, dass die Änderungen eine ständige Herausforderung für die ­Verwaltung darstellen, ist Teil eines allgemeinen Konsenses. Beschränken wir uns an dieser Stelle auf drei Beispiele für aktuelle Trends: • Seit spätestens Herbst 2015 spaltet das Thema Flüchtlingsmigration die deutsche Gesellschaft. Diese „Flüchtlingskrise“, wie sie auch genannt wurde, wurde von wissenschaftlichen Experten als eine „Verwaltungskrise“ bezeichnet2. Sie hat, so der Normenkontrollrat, vor Augen geführt, dass die öffentliche Verwaltung auf plötzliche Herausforderungen nur schwerfällig reagieren kann. Sie hat auch verdeutlicht, dass die Entscheidungswege in der Verwaltung oft zu lang sind, um zeitnah adäquat Lösungen für akute und dringliche Probleme zu entwickeln. Diese Einschätzung stellt aber durchaus keinen gesellschaftlichen oder verwaltungspraktischen Konsens dar. Vielmehr wird das Thema vorwiegend theoretisch-ideologisch abgehandelt. Zwei einfache Lösungen behaupten sich im öffentlichen Diskurs: Abschottung („Obergrenze“) und undifferenzierte Aufnahme („Willkommenskultur“). Beide diffamieren sich gegenseitig als „fremdenfeindlich“ oder „blauäugiges Gutmenschentum“ und stabilisieren sich so wechselweise. Hier käme der Verwaltung eigentlich eine wichtige Funktion zu: aus ihrer Expertenposition heraus wäre sie prädestiniert, ein einigermaßen objektiv belegtes, nach Migrantengruppen differenziertes Konzept (oder auch Konzeptvarianten) zu erstellen, wie wertemäßige, bildungsmäßige, ökonomische, kulturelle und soziale Aufnahme einer großen Anzahl von Migranten zu organisieren ist. Damit würde die Verwaltung auch einen Beitrag zu einer anderen ihrer Aufgaben leisten, nämlich einen stabilen sozialen Rahmen zu gestalten und über Spaltungslinien hinweg die gesellschaftliche Kohäsion zu ihrer Richtschnur zu machen. • Die regionale Differenzierung im Bundesgebiet – also seine Aufteilung in Pole der Attraktivität und Zonen des Niedergangs – ist ein nicht mehr zu übersehender, wichtiger Trend. Viele Folgetendenzen werden von diesem Trend regiert: die stark auseinanderdriftende Entwicklung der Immobilienpreise, die demografische Entwicklung mit unterschiedlichen Nachfrageprofilen nach öffentlichen Versorgungsangeboten, die finanzielle Ausstattung der Kommunen usw. Auch hier verfestigt sich der Eindruck,

1Unbestritten ist, dass die Herausforderungen einer globalisierten Welt und der aktuelle technologische Wandel unser Aufnahmevermögen und unser Anpassungsvermögen fordern und tendenziell überfordern. Lokale Ereignisse erzeugen weltweite Wellen und Disruptionen, deren Auswirkungen wir nicht absehen können. Aber ist das wirklich neu? War die Welt früher vorhersehbarer, als sie es heute ist? War der Zweite Weltkrieg, um nur ein Beispiel zu nennen, weniger „disruptiv“, sein ­Ausgang besser zu prognostizieren als es heute die Entwicklung der Künstlichen Intelligenz ist? Darüber wäre ein fundierter Austausch vor schnellen Antworten wünschenswert. 2So die Einschätzung des deutschen Normenkontrollrats; vgl. Hahlen (2016).

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

25

dass eine systematische Beschäftigung mit diesem Thema über die drei staatlichen Ebenen hinweg eher unsystematisch und sporadisch erfolgt.3 • Nach unserem Eindruck gibt es einen subjektiven Trend, der schwieriger zu verifizieren oder gar zu quantifizieren ist als die beiden eben genannten: Das ist die wachsende „Anspruchshaltung“ der Bürger. Der Begriff „Anspruchshaltung“ wird in der öffentlichen Diskussion oft kritisch gefärbt, als handele es sich um etwas Unziemliches, etwas das denjenigen, die Ansprüche formulieren, nicht zukommt. So ist er hier aber nicht gemeint. Vielmehr scheint es uns durchaus angemessen, wenn Bürger neue Ansprüche an Geschwindigkeit und Qualität der Verwaltungsprozesse haben, die sie in Anspruch nehmen wollen oder müssen. Und dass sie vor allen Dingen dort, wo es Sinn macht, an der Lösungsfindung beteiligt und nicht nur Empfänger behördlicher Entscheidungen sein wollen: Also der Anspruch auf ein höheres Maß an Transparenz und aktiver ­Mitsprache bei behördlichen Entscheidungswegen. Bei derartigen Themen erleben wir es nur selten, dass sich die Verantwortlichen in der ­Verwaltung und den zugeordneten politischen Gremien durch diese Trends zu grundlegenden Überlegungen über die funktionale Weiterentwicklung unserer Verwaltungsapparate herausgefordert fühlen. Können wir denn wirklich davon ausgehen, dass unsere tradierten Regelwerke, Prozesse und Arbeitsabläufe in der Regel adäquate Antworten für den Einzelfall bereithalten? Ist unser Verwaltungsalltag in diesem Sinne „modern“? Was wir erleben, ist keine Beschäftigung mit derlei Fragen. Es werden keine Lösungen für anstehende Probleme gesucht (oder auch nur eine strukturierte Diskussion geführt, was denn diese Probleme sein könnten). Sondern es werden die aktuellen technologischen Entwicklungen gescannt, um zu diesen neuen Lösungen Probleme zu finden, die passen könnten. Dabei werden nicht nur alte Probleme nicht gelöst, sondern neue Probleme zusätzlich geschaffen.

3.2 Lösungen auf der Suche nach Problemen Es ist auffällig, wie die öffentliche Diskussion um die Verbesserung von Verwaltungshandeln sich an temporären technischen Innovationen orientiert. Nehmen wir zum Beispiel die Initiative „Digitale Stadt“.4 Durch sie soll ab 2018 der Ausbau von Darmstadt zu einer 3Siehe

z. B. die Privatinitiative zur Wiederbelebung verödender Dörfer (DORV 2017). handelt es sich um einen Wettbewerb, der Ende November 2016 durch den Lobbyverband Bitkom in Zusammenarbeit mit dem Deutschen Städte- und Gemeindebund (DStGB) gestartet worden war. An diesem Wettbewerb konnten sich mittelgroße Städte mit rund 100.000 bis 150.000 Einwohnern beteiligen, die noch eine Reihe anderer Voraussetzungen erfüllen mussten (z. B. gute Verkehrsanbindung, Nähe zu einer Hochschule usw. – also nicht objektiver Bedarf, sondern überschaubarer Lösungsaufwand). Im Juni 2017 setzte sich Darmstadt gegen 13 andere Bewerberstädte durch. Siehe http://www.digitalestadt.org/bitkom/org/Presse/Presseinformation/ Darmstadt-gewinnt-Wettbewerb-Digitale-Stadt.html, abgerufen am 26.12.2017. 4Dabei

26

T. Michl und W. Steinbrecher

digitalen Modellstadt erfolgen. Dieser Ausbau wird gesponsert durch große Unternehmen der Digitalbranche wie Deutsche Telekom, Hewlett Packard, SAP, DocMorris, eBay usw., die sich hier Referenzanwendungen und damit die Erschließung neuer kommunaler Kundensegmente erhoffen. Das Projekt umfasst zehn Themenfelder wie Bildung, Gesundheit, Verkehr usw. – und eben auch das Feld „Verwaltung“.5 Dazu kündigt die Initiative folgende Ziele des digitalen Ausbaus an: • Umstieg auf weitgehend elektronische Kommunikation mit der Stadtverwaltung: „kaum jemand muss mehr ‚zum Amt‘“. • Ein persönliches digitales Bürgerkonto, mit dem jeder Bürger Zugriff auf seine Stammdaten, Dokumente und Bescheide hat. D. h. ein Bürger braucht z. B. seine Geburtsurkunde keinem Antrag mehr beizufügen. „Stattdessen tauschen Verwaltungen notwendige ­Nachweise durch intelligente Registerabfragen selbstständig untereinander aus.“ • Ein intelligentes Terminmanagement sorgt für geringere Wartezeiten, wenn doch ein Gang zu Behörde nötig wird. • „Mobiles Arbeiten wird auch für Verwaltungsangestellte zur Normalität und erhöht so die Motivation und Mitarbeiterzufriedenheit.“ 6 Diese Maßnahmen sind ja durchaus nicht alle falsch oder überflüssig. Aber die Frage ist: gemessen an den aktuellen Problemstellungen – welcher Anteil von diesen wird denn durch die angebotene Lösungspalette abgedeckt? Die Grundfragestellung des Projekts „digitale Stadt“ wird dann schief, wenn der zugrunde liegende Ansatz „was heutzutage bereits technologisch möglich wäre“ verabsolutiert und zu „der“ hauptsächlichen oder gar einzig erfolgversprechenden, pragmatischen Entwicklungsstrategie der Verwaltung (v)erklärt wird. In seinem Buch „Fortschrittsgeschichten. Für einen guten Umgang mit Technik“ nennt Marcel Hänggi diese Herangehensweise unilinear7. Sie ist gar nicht sehr neu. Hänggi zitiert das Motto der Weltausstellung 1933/34, die unter dem Titel „Century of Progress“ in Chicago stattfand: Die Wissenschaft entdeckt, das Genie erfindet, die Industrie wendet an, und der Mensch passt sich den neuen Dingen an oder wird von ihnen geformt.

Der Mensch oder gar seine Pluralform als Gesellschaft kommt in dieser Sichtweise nicht aktiv vor (nur in der Form des „Genies“, das ja bekanntlich außerhalb der Gemeinschaft steht). Das einzige, was er tun kann: sich den „neuen Dingen“, die als externe Ereignisse ohne menschliches Zutun in die Welt kommen, anzupassen.

5Siehe

http://www.digitalestadt.org/bitkom/org/Digitale-Stadt/Sponsoren-Partner/.

6Ebda. 7Hänggi

(2015).

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

27

Fortschritt entsteht als Abfolge von wissenschaftlicher Erkenntnis, die Innovationen auslöst, welche schließlich die Gesellschaft weiterbringen.8

Hänggi macht darauf aufmerksam, dass das unilineare Entwicklungsmodell durch ein semantisches Abrutschen begleitet, begünstigt oder auch ermöglicht wird: durch die fortschreitende Ersetzung des Wortes „Fortschritt“ durch „Innovation“.9 Bis in die 1980er Jahre hinein war das Wort „Fortschritt“ vorstellungsbildend. Fortschritt kennt ein Gegenteil – nämlich den Rückschritt. Danach wurden sogar politische Strömungen eingeordnet: die progressiven (dem Fortschritt verpflichteten) und die konservativen bis „reaktionären“. Im Begriff der Innovation wird diese Zweipoligkeit ausgelöscht. „Der Fortschrittsbegriff denkt mit, dass Wandel auch in die falsche Richtung zielen kann. Zur ‚Innovation‘ gibt es höchstens den Gegenbegriff der ‚Stagnation‘, aber Stagnation ist nicht Wandel in eine ­falsche Richtung, sondern sein bloßes Fehlen.“10

3.3 Weg vom Arbeiten in Silos hin zu gesellschaftlicher Kooperation 3.3.1 Agilität ist eine Arbeitshaltung – nicht die Anwendung eines Tools Agilität stellt nicht oder nicht in erster Linie eine Modernisierung der Verwaltung bei der Anwendung „moderner digitaler Techniken“ dar. In der öffentlichen Diskussion haben wir bislang den Eindruck, die öffentliche Verwaltung hinke der Privatwirtschaft vor allem bei der Verwendung digitaler Medien hinterher – und die Herausforderung bestehe darin, nun die Versorgungsdichte der Mitarbeiter mit Diensthandys und Tablet-PCs zu erhöhen. Das ist nicht das, was wir unter „Agilisierung der Verwaltung“ verstehen. Agilisierung bedeutet nach unserer Vorstellung eine ganz grundlegende Änderung der Arbeitskultur in der öffentlichen Verwaltung – nämlich der (weitgehende) Übergang von der Arbeit in Einzelzuständigkeiten und „Silos“ zu einer Arbeit in kollaborativen Zusammenhängen, in Teams. Dazu müssen wir etwas ausholen und darstellen, wie die Arbeit der öffentlichen ­Verwaltung gegenwärtig strukturiert ist.

8Hänggi

(2015). (2015, S. 27 ff.). 10Das., S. 28. Auch Jill Lepore bemerkt in ihrer vernichtenden Kritik des Disruptionsmodells: „Replacing “progress” with “innovation” skirts the question of whether a novelty is an improvement: the world may not be getting better and better but our devices are getting newer and newer.“ (Lepore 2014). 9Hänggi

28

T. Michl und W. Steinbrecher

Abb. 3.1  Der Standard-Bearbeitungsgang

3.3.2 Der Ursprung des Zuständigkeitsdenkens Beim Standard-Bearbeitungsgang (Abb. 3.1) ist ein Sachbearbeiter für die Bearbeitung eines Vorgangs verantwortlich. Der folgt dem Schema: • Der Bürger stellt sein Begehren in schriftlicher Form dar, oft indem er eine Vorlage ausfüllt, und bringt es der Verwaltung zur Kenntnis. • Dort wird die Zuständigkeit geklärt und der Vorgang einem Sachbearbeiter zugeordnet. • Der Sachbearbeiter prüft den Antrag und verfasst einen Beschluss, der die Annahme oder Ablehnung des Antrags vorsieht. • Der Beschluss wird dem Vorgesetzten zugeleitet, der zeichnungsberechtigt ist und letztendlich über den Antrag entscheidet. So werden gleichzeitig das Vier-Augen- und das hierarchische Prinzip gewährleistet. • Der vom Vorgesetzten unterzeichnete Beschluss wird an den Sachbearbeiter ­zurückgegeben, der ihn an den Bürger schickt. • Eine Kopie des Beschlusses wird zu den Akten genommen. Diese Vorgehensweise stellt das Grundschema dar für alle möglichen Arten und Weisen, wie ein Bürger mit der Verwaltung in Kontakt tritt: ob er einen Führerschein beantragt oder eine Baugenehmigung oder einen neuen Personalausweis oder Sozialhilfe oder oder – das Grundschema bleibt immer das gleiche. Es entspricht den Grundregeln der preußischen Bürokratie und ist über 200 Jahre alt.11

11Vgl.

dazu Miller (1997) über die preußische Registratur. Siehe auch Weber (2002, S. 125).

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

29

Abb. 3.2  Die Prüfung auf Zuständigkeit

Es ist ein bewährtes Schema. Dadurch, dass es regelbasiert ist, garantiert es die Gleichbehandlung. Durch das Vier-Augen-Prinzip wird der Vetternwirtschaft ein ­ Riegel vorgeschoben. Die Schriftlichkeit des Verfahrens ermöglicht Nachvollziehbarkeit, ­Transparenz und letztlich eine gerichtliche Überprüfung. Es wäre völlig fahrlässig und hätte nichts mit Agilität zu tun, diese Prozeduralität irgendeinem „schlankeren“ ­Verfahren zu opfern.

3.3.3 Die Grenzen der Einzelzuständigkeit Aber das Verfahren stößt an seine Grenzen – in einer zunehmend vernetzten Welt an zunehmende Grenzen –, und auch diese gilt es zu betrachten. Bevor nämlich ein Sachbearbeiter sich dem Antrag widmet, prüft er erst, ob er das überhaupt tun muss (Abb. 3.2). Wenn er zu dem Schluss kommt, das sei nicht der Fall, dann erklärt er dem verdutzten Bürger, die ganze Angelegenheit gehe ihn nichts an und überlässt es diesem selbst, sich einen anderen Behördenmitarbeiter für sein Anliegen zu suchen. Für die Klärung der Zuständigkeit ist nämlich in der klassischen Behördenwelt niemand zuständig. Und es war ein ganz wichtiger und anerkennenswerter Reformschritt, als die ersten Kommunen in den 1990er Jahren Bürgerbüros einrichteten, zu deren Aufgabe es unter anderem gehörte, keinen Bürger unverrichteter Dinge abzuweisen, ohne ihm zumindest eine zuständige Stelle für sein Anliegen genannt zu haben. Jetzt aber zu den substanzielleren Mängeln der klassischen innerbehördlichen Arbeitsteilung. Wie in allen größeren Organisationen, unterscheidet man auch in der öffentlichen Verwaltung zwischen stark und schwach strukturierten Prozessen (Abb. 3.3).12

12Vgl.

dazu BMI (2005), Abschn. 3.3.

30

T. Michl und W. Steinbrecher

Abb. 3.3  Stark strukturierte Prozesse und schwach strukturierte Prozesse

3.3.4 Stark strukturierte Prozesse: Wenig Bedarf an Agilität Als stark strukturierte Prozesse bezeichnet man solche, bei denen die Bearbeitung des Vorgangs durch den Sachbearbeiter immer den gleichen, einfachen Schritten folgt und wenig Variationen links und rechts der ausgetretenen Pfade vorkommen. Abb. 3.3 zeigt drei Beispiele solcher Prozesse: a) Wenn ein Bürger einen Antrag auf Erteilung eines Führerscheins stellt, dann dürfte der Sachbearbeiter nur äußerst selten auf einen Zweifelsfall stoßen. In der Regel reicht es aus, die Ergebnisse der theoretischen und der praktischen Prüfung zu lesen und dann den Antrag an die Bundesdruckerei weiterzuleiten. b) Auch ein interner Prozess, der nur in der Behörde selbst abläuft, kann stark strukturiert sein. Ein Mitarbeiter stellt einen Urlaubsantrag bei seinem Vorgesetzten. Dieser prüft, ob für die Abwesenheit eine Vertretung zur Verfügung steht und genehmigt den Antrag. Auch hier dürfte es kaum Zweifelsfälle geben. c) Schließlich gibt es einen internen Beschaffungsantrag, bei dem ein Mitarbeiter einen Gegenstand bestellt, den er für seine Arbeit benötigt, und dieser Gegenstand von einem anderen Mitarbeiter einer anderen Abteilung – z. B. des Einkaufs oder der Beschaffungsstelle – besorgt wird.

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

31

Stark strukturierte Prozesse machen schätzungsweise 50 bis 70 % der Arbeit einer kommunalen Verwaltung aus. Sie werden sehr oft durch sogenannte Fachverfahren unterstützt. Diese erleichtern den Mitarbeitern die Arbeit unter zwei Gesichtspunkten: 1. Sie bieten vorgefertigte Dokumentvorlagen und Checklisten, die immer wiederkehrende Tätigkeiten unterstützen oder durch Auswahl aus Katalogen von Textbausteinen die ­Formulierung von Bescheiden rationalisieren. 2. Sie unterstützen das Treffen von Entscheidungen, indem sie Gesetzestexte und ­Entscheidungen zum jeweiligen Sachgebiet bereitstellen (z. B. zum Sozialgesetzbuch II) und immer aktuell halten.

3.3.5 Einbeziehung der Bürger auch in schwach strukturierten Prozessen Agile Methoden dürften hier in der Regel wenig Ansatzpunkte bilden. Vielleicht mit einer Ausnahme: der agile Grundsatz, die Anspruchsberechtigten in eine Entscheidung einzubeziehen, kann die Behördenmitarbeiter vor zu schematischen Entscheidungen bewahren und deren Akzeptanz befördern. Beispiel: Eine Baugemeinschaft stellt beim Bauamt der Gemeinde einen Antrag auf Genehmigung eines Mehrfamilienhauses mit 12 Wohnungen. Auf dem Gartenanteil des Grundstücks ist seitens der Antragsteller kein Kinderspielplatz vorgesehen. Die Bauvorschriften der Stadt besagen aber: „Bei Gebäuden mit mehr als 3 Wohneinheiten ist ein ausreichend großer Kinderspielplatz nachzuweisen. Die Mindestgröße beträgt 60 m2“. Der Sachbearbeiter fügt diese Auflage in seinen Genehmigungsbescheid ein. Die Besonderheit des Hauses war aber: es handelte sich um eine Seniorengemeinschaft, die ein Projekt für das gemeinsame Wohnen im Alter plante. Das Spielen im Sandkasten gehörte nicht zu den geplanten Freizeitaktivitäten. Ein nachträglicher Hinweis beim Sachbearbeiter führte zu keinem Resultat. Als sich der Bürgermeister einen Monat später (pressewirksam) zum ersten Spatenstich auf dem Baugelände einfindet, um die Unterstützung der Gemeinde für dieses innovative Projekt zu dokumentieren, wird ihm ein Plastikschäufelchen mit einigen Sandformen überreicht.

Was dieses Beispiel bereits deutlich macht: Im Zusammenklang zwischen Verwaltung und Bürgern geht es nicht in erster Linie um digitale Technik. Im Konzept der „Digitalen Stadt“, das wir oben zitiert haben, wird angekündigt: „Die Stadtverwaltung hat jederzeit ein Echtzeitbild über ihre Verwaltungsvorgänge, kann Ressourcen besser planen und macht nicht-vertrauliche Daten der Allgemeinheit zugänglich und visualisiert sie gegebenenfalls.“13

13Siehe

bitkom (2017).

32

T. Michl und W. Steinbrecher

Das klingt noch sehr vage, aber man könnte sich darunter vorstellen, dass damit auch eine Art „Verlaufsinformation“ über den Stand eines Vorgangs für den antragstellenden Bürger gemeint ist (so wie dies z. B. bei Sendungen durch Versandhändler schon jetzt der Fall ist). Das würde vor allem die Verwaltung von lästigen telefonischen Nachfragen entlasten. Das wirkliche Problem in diesem Beispiel – die rein formale, sachfremde Entscheidungsfindung durch die Behörde – wird jedoch durch die schöne neue Digitalwelt überhaupt nicht adressiert. Das neue Anspruchsdenken der Bürger, die sich – vor allem in der jüngeren Generation – mit solchen Verfahren nicht mehr anfreunden können, kann nicht durch oberflächliche Einführung neuer Techniken befriedigt werden. Im Gegenteil, durch die neuen Techniken kann die Distanz zwischen Verwaltung und Bürger eher größer werden – sie kann durchaus zu einem Mittel werden, mit dem die Verwaltung sich die Bürger vom Leibe hält.

3.4 Die Möglichkeit agiler Verwaltung in schwach strukturierten Prozessen 3.4.1 Das Beispiel „Entscheidung über einen Windpark“ An den Anfang wollen wir – statt langwieriger theoretischer Erörterungen – wieder ein Beispiel aus der Praxis setzen. Beispiel: Im Bundesland Brandenburg ist das Landesumweltamt zuständige Genehmigungsbehörde für die Anträge auf die Errichtung größerer Windparks. An einem solchen Antrag sind aber bis zu 12 weitere Behörden als sogenannte „Träger öffentlicher Belange“ zu beteiligen. Dazu gehören regelmäßig – also bei jedem „raumbedeutsamen“ Vorhaben - die Regionale Planungsstelle und die Gemeinsame Landesplanungsabteilung. Darüber hinaus aber auch • verschiedene Abteilungen der Landratsämter, die z. B. Statikprüfungen vornehmen, • die Untere Naturschutzbehörde, die das eventuelle Vorhandensein gefährdeter Tier- und Pflanzenarten im betroffenen Gebiet begutachtet.

Die Fragestellungen, die aus dem Genehmigungsantrag erwachsen, werden nun in 13 (scheinbar) eigenständige Pakete aufgeteilt und an 13 Sachbearbeiter in 13 Behörden oder Ämtern vergeben. Diese Sachbearbeiter sehen sich in der Regel nie, sondern arbeiten ihre jeweiligen ToDo’s parallel und unabhängig voneinander ab (siehe Abb. 3.4). Die Unabhängigkeit der zu prüfenden Sachverhalte ist aber sehr oft nur scheinbar gegeben. Wenn jetzt z. B. die Naturschutzbehörde relativ schnell zum Schluss kommt, dass fünf der 25 Windräder auf ihrem Standort wegen einer geschützten Tierart nicht genehmigt werden können, dann würde es ja Sinn machen, dass die anderen 12 Kollegen

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

33

Abb. 3.4  Genehmigungsverfahren für einen Windpark

davon relativ schnell in Kenntnis gesetzt werden. Aber das ist nicht der Fall. Sie prüfen weiter ihre Sachverhalte bis zum Ende. Wenn ein Sachbearbeiter in einem Landratsamt für länger erkrankt und Fristüberschreitung droht, erfahren dies seine Projektkollegen ebenfalls nicht – bis zum Ablauf der Frist. Geschweige denn, dass sie sich rechtzeitig um Abhilfe kümmern könnten, indem sie z. B. einen Fachmann aus einem anderen Landratsamt herbeiziehen. Angenommen, der Antrag wird am Ende der Frist abgelehnt, aus den genannten Gründen des Naturschutzes. Dann wird sich natürlich der Betreiber mit diesem Bescheid nicht zufriedengeben. Er wird seinen Antrag auf 20 Windräder reduzieren oder versuchen, das Baugebiet um 500 m nach Osten zu verschieben, wo die geschützte Tierart nicht vorkommt. „Halt!“, ruft angesichts des neuen Antrags der Geologe, „500 Meter nach Osten ist ausgeschlossen! Da ist ein besonderer Sandboden, der eine viel stärkere Gründung des Fundaments erfordert. Also einfach verlegen geht gar nicht!“

3.4.2 Komplexität tritt auf, wenn wir Entscheidungen treffen wollen Die verschiedenen Sachverhalte sind voneinander unabhängig, wenn man sie in der objektiv gegebenen Welt verortet: die geschützte Tierart nistet dort, der problematische Sandboden ist hier – alles unabhängig voneinander, keine Wechselwirkungen, kein VUKA. Erst in der Welt der Lösungen wird es komplex, wenn es darum geht, die verschiedenen „Constraints“, denen das Windparkprojekt unterliegt, unter einen Hut zu bekommen.14

14Zum

Zusammenhang zwischen Komplexität und aktiver Lösungssuche siehe Morner (2017). Vgl. auch Steinbrecher (2017).

34

T. Michl und W. Steinbrecher

Abb. 3.5   Ein Mobile stellt eine komplexe Struktur mit vielfältigen Wechselwirkungen dar

Dann auf einmal tritt ein Lösungsvorschlag aus einem Fachgebiet in Widerspruch zu den Anforderungen eines anderen Fachgebiets. Eine solche Situation tritt nicht nur bei großen Genehmigungsverfahren auf, sondern auch in ganz anderen Prozessen. So z. B. in der Jugendhilfe, wenn ein Jugendlicher in einer Problemfamilie aufwächst, bereits drogengefährdet ist und Probleme hat, einen Ausbildungsplatz zu finden. Diese Prozesse sind vergleichbar einem Mobile. Ein Mobile ist eine Struktur aus 20 oder mehr Einzelteilen, die in einer herabfallenden Baumstruktur miteinander vernetzt sind. Wenn Sie ein beliebiges Teil des Mobiles bewegen, dann können Sie nicht mehr genau berechnen, wie sich ein beliebiges anderes Teil bewegen wird. Sie wissen auch nicht, welche Tänze das von Ihnen bewegte Teil – einmal losgelassen – weiterhin vollführen wird. Man spricht von komplexen Wechselwirkungen (Abb. 3.5). Zuständigkeitsregelungen versuchen, einzelne Teile des Mobiles in die Verantwortung einzelner Akteure zu legen. Jeder Akteur sieht den Teil des Mobiles, für den er sich zuständig sieht, den er kennt und den er – meist fachlich hervorragend – beherrscht. Dass jede Bewegung eines dieser Zuständigkeitselemente die jeweils anderen beeinflusst – oft nicht unerheblich heftig – spielt bei dieser Betrachtungsweise eine untergeordnete Rolle. Oft geht das nicht gut aus. Statt, dass wir das Mobile in den Griff bekommen, zwingt es uns seine erratischen Bewegungen auf. Im Rahmen eines komplexen Problems treten dauernd neue Herausforderungen auf. Und das zwingt die Akteure zu dauernd neuen Verhandlungen, wer denn dafür nun wieder zuständig ist. Ein Großteil der Energie fließt in die Aufrechterhaltung der Regelungen statt in die Lösung des Problems.

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

35

3.4.3 Agile Alternativen Der agile Ansatz in einem solchen Fall besteht in der Bildung eines „cross-­funktionalen“ Teams. An dieser Stelle treffen wir auf ein Beispiel, in dem Erfahrungen aus der ­Softwareindustrie beinahe Eins zu Eins in die Problemlösungsstrategien von ­Verwaltungen übersetzbar sind. Die Softwareentwicklung war in den 1990er Jahren in eine Sackgasse geraten. Die Projekte, in denen Softwarefirmen für Kunden maßgeschneiderte Programme entwickelten, wurden kaugummiartig in die Länge gezogen. Kaum ein Termin wurde eingehalten, die Budgetgrenzen regelmäßig gesprengt, und die gelieferte Qualität war trotzdem oft unterirdisch – die Fehlerzahlen waren einfach zu hoch. In dieser Situation fiel einigen Projektverantwortlichen ein bemerkenswerter Umstand auf: die Unterschiede zwischen verschiedenen Programmierteams waren sehr hoch, oft um den Faktor der Größenordnung 1:100. Es gab Teams, die unter den beschriebenen Problemen litten; es gab aber auch hoffnungsvolle Gegenbeispiele, die schnell weitgehend fehlerfreien Programmiercode lieferten. Was war deren Geheimnis? Das Geheimnis hieß: Abkehr vom isolierten Spezialistentum und direkte Zusammenarbeit der Fachprogrammierer in einem gemeinsamen Team. Die Erfahrungen dieser Arbeitsweise wurden von Ken Schwaber und Jeff Sutherland systematisch ausgewertet und führten Anfang der 2000er Jahre zu ersten Versionen einer Arbeitsstruktur, die von ihren Erfindern „Scrum“ genannt wurde. Diese Arbeitsstruktur wird im sog. „Scrum Guide“ beschrieben, der detailliert auf das Thema „Teamarbeit“ eingeht.15 Die dort entwickelte Teamstruktur kann unmittelbar auf schwach strukturierte Prozesse in Verwaltungen übertragen werden.16 Damit einher geht eine ganz grundlegende Umwälzung in der behördlichen Arbeitskultur. Versuchen wir einmal, die Scrum-Methodik der Teambildung gedanklich auf unsere Antragsbearbeitung für eine Windparkanlage zu übertragen. Was wäre anders? 1. Das fachübergreifende Team – wir nennen es ein „Vorgangsteam“ – muss die Fähigkeit haben, den jeweiligen Fall abschließend zu bearbeiten. Das betrifft nicht nur die inhaltlichen Fähigkeiten – also, dass das Team einen Statiker und einen Naturschützer und einen Gemeindevertreter als Sachwalter der Anwohnerinteressen umfasst. Sondern es betrifft auch die nötigen Entscheidungskompetenzen. Ein Entwicklungsteam kann niemals unter „Absegnungsvorbehalt“ arbeiten. Die 13 Sachbearbeiter haben 13

15Zur deutschen Version des Scrum-Guides vgl. Schwaber (2017). Das Rahmenwerk Scrum wird genauer von Jan Fischbach in Kap. 6 dieses Buchs behandelt. 16Siehe dazu das Kap. 20 des vorliegenden Buchs zu den „Arenen“ in der schwedischen Kommune Ängelholm.

36

T. Michl und W. Steinbrecher

Vorgesetzte, die gewohnt sein mögen, alle Teilentscheidungen ihrer Mitarbeiter zu kontrollieren und ggfls. nach subjektivem Gutdünken zu korrigieren.17 Diese Rechte fallen nun fort. Wenn ein Team zu einer Lösung gelangt ist, muss es diese Lösung auch in Kraft setzen dürfen. Jedes Drehen weiterer Entscheidungsschleifen würden die von Schwaber und Sutherland evozierten Synergien zunichtemachen. 2. Das Vorgangsteam arbeitet zusammen bei der Lösungssuche und bezieht auch den Antragsteller mit ein. Das setzt regelmäßige Treffen voraus, bei denen Einwände, Hindernisse und Störungen (wie z. B. der Ausfall eines Teammitglieds) besprochen und auf gemeinsame Resultate hin diskutiert werden. Ob diese Treffen physisch oder in einer Videokonferenz stattfinden, ist sekundär. 3. Das Vorgangsteam als Ganzes ist für die korrekte Antragsbearbeitung und die Fristeinhaltung verantwortlich. Es sollte möglichst vermieden werden, auftretende Hindernisse dem „schuldhaften Verhalten“ Einzelner zuzurechnen. Vielmehr hilft das Prinzip der Gesamtverantwortung den Teammitgliedern, aus der Position des isolierten Einzelkämpfers herauszufinden und Unterstützung bei Kollegen zu finden. Der Übergang zur Teamarbeit ist überhaupt nicht trivial. Er verlangt allen Beteiligten – ob Mitarbeitern oder Führungskräften – grundlegende Haltungsänderungen ab. Aber Teamarbeit hält auch Belohnungen für diejenigen bereit, die sich ihrer Mühen unterziehen. In einem unserer Projekte tauchte ganz zu Beginn eine kleine Aufgabe für das neu gebildete Team auf: Es sollte eine Liste aller Vorlagen, die zu einem Thema in der Abteilung in Umlauf waren, in Form einer kleinen Excel-Tabelle erstellt werden. Damit es nicht zu langweilig würde, wurden zwei Kolleginnen im Vorgangsteam ausgewählt, die bis zum nächsten Treffen die Liste erstellen sollten. Bei diesem Treffen zwei Wochen später stellten die Mitarbeiterinnen ihr Ergebnis vor und nahmen mit Genugtuung das Lob der Gruppe entgegen. Und dann sagte die eine von ihnen einen bemerkenswerten Satz: „Und wisst ihr, das ist das erste Mal, dass wir beide zusammen zwei Stunden lang an einem Tisch gesessen haben und gemeinsam an einer Aufgabe gearbeitet haben. Und das hat uns so glücklich gemacht, das könnt ihr euch gar nicht vorstellen.“ Die beiden waren seit 12 Jahren Zimmernachbarinnen im gleichen Sachgebiet. Soweit auch zum Thema „Motivation bei der Arbeit“, die durchaus nicht nur aus dem neuen Umgang mit mobilen Devices zu tun hat.

17Das ist das „Prinzip der Amtshierarchie“: „Aus dem Hierarchieprinzip als dem Fundament des Verwaltungshandelns folgen Einzelrechte (Evokationsrecht, Kassationsrecht, Weisungsbefugnis des Vorgesetzen, etc.), die auf die Vorgangsbearbeitung erheblichen Einfluss haben und die Bearbeitung von nicht genau kalkulierbaren Ereignissen abhängig werden lassen.“ (BMI 2005, S. 24). – Gerade diese „nicht kalkulierbaren Ereignisse“ müssen in einem agilen Handlungsrahmen ausgeschlossen werden.

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

37

3.5 Das Ganze in den Blick nehmen In Abb. 3.3 haben wir zwei Themen aufgenommen – nämlich „Neue Führungsstruktur etablieren“ und „Mobilitätskonzept 2030 erarbeiten“ –, die aus dem übrigen Schema heraustreten. Sie haben nämlich keinen Auslöser. Bei den anderen Beispielen gibt es ein auslösendes Ereignis, das die Verwaltung zwingt – eine zutreffende Zuständigkeitsprüfung vorausgesetzt –, sich damit zu beschäftigen. Das ist bei einer internen Organisationsentwicklungsmaßnahme oder auch bei einer zukunftsgestaltenden Aufgabe wie einem Mobilitätskonzept anders: niemand weist die Verwaltung (bzw. die ihr zugeordneten politischen Gremien) an, sich diesem Thema zuzuwenden. Und, wie eingangs bemerkt, Verwaltungen tun dies oft auch nur sporadisch und unsystematisch. Ein ganzes Theoriegebäude ist um diese Beobachtung herum gebaut worden (und dies nicht neuerdings, sondern schon Anfang der 1970er Jahre): das „­Mülleimer-Modell“18. Die Entwickler dieses Models, Cohen, March und Olsen, charakterisieren große Organisationen, darunter auch Verwaltungen, als Beispiele „organisierter Anarchie“. Weit entfernt sei die Realität vom Modell des rational choice, in dem rationale Akteure aufgrund klarer Zielvorstellungen versuchen, die Probleme ihrer Organisationen in den Griff zu bekommen. In seinem aktuellen Buch „Verwaltung verstehen“ stellt Wolfgang Seibel dieses ­„garbage can model“ folgendermaßen dar: Eine Organisation arbeitet auf der Basis einer ganzen Reihe von inkonsistenten und unzureichend definierten Präferenzen. Sie kann eher als eine lose Ansammlung von Ideen denn als kohärente Struktur beschrieben werden; sie entdeckt eher Präferenzen durch Handlungen, als dass sie auf der Basis von Präferenzen handelt. (…) Obwohl eine Organisation es schafft, zu überleben und sogar produktiv zu sein, bleiben die Prozesse der Organisation durch ihre eigenen Mitglieder unverstanden. (…) Im Ergebnis sind die Organisationsgrenzen unsicher und wechselhaft, während das Publikum und die Entscheidungsträger für die einzelnen Entscheidungssegmente ebenfalls auf unberechenbare Weise wechseln. (…) Unter diesem Gesichtspunkt ist eine Organisation eine Ansammlung von Wahlmöglichkeiten, die nach Problemen Ausschau halten, Problemen und Gefühlslagen, die nach Entscheidungssituationen suchen, in denen sie zum Tragen kommen könnten, Lösungen, die nach Problemen suchen, auf die sie eine Antwort geben könnten, und Entscheidungsträgern auf der Suche nach Betätigung. Daher die Metapher der garbage can, also des Mülleimers: Das letztlich verlässlich strukturierende Element im Handlungsablauf einer Organisation sei die Entscheidungsgelegenheit (choice opportunity), und diese werde genutzt, um dort alle möglichen Probleme und Lösungen auf weitgehend unkoordinierte Weise abzuladen, so wie man Abfall in einen Abfalleimer wirft.19

Damit sind wir in der Theorie wieder an dem Punkt, den wir am Beispiel „Digitale Stadt“ als „Lösungen auf der Suche nach Problemen“ verortet hatten. 18Vgl.

Cohen (1972). (2016, S. 96 f.).

19Seibel

38

T. Michl und W. Steinbrecher

Was wäre ein Alternative? Welche strategischen Fragen stehen für die öffentliche Verwaltung an? Wie könnte sie sich ihrer systematisch annehmen? Im Februar 2016 haben wir vom Forum Agile Verwaltung einen Workshop durchgeführt „Auf welche Trends muss sich die Verwaltung in den nächsten Jahren einstellen?“ und die Ergebnisse auf unserem Blog dokumentiert und zur Diskussion der Leser gestellt.20 Wir kamen auf 13 Themen: 1. Komplexität der Fälle nimmt zu 2. plötzliche Herausforderungen 3. Die Dynamik insgesamt nimmt zu. 4. Schere zwischen arm und reich öffnet sich weiter. 5. Zunehmender (Rechts- und Links-)Extremismus und -terrorismus. 6. Finanzausstattung wird schlechter 7. Polarisierung: zu jeder Entwicklung bildet sich eine Gegenentwicklung 8. Bürger fordern Einbeziehung 9. „Vergreisung“ 10. Zunehmende funktionale Spezialisierung bringt Notwendigkeit zur silo-über greifenden Zusammenarbeit 11. Weisungsgebundenheit als Hindernis 12. eGovernment und Übergang zur eAkte 13. Komplizierte Zuständigkeitsregeln Aus heutiger Sicht kommen noch einige Themen hinzu: 1. Ausdifferenzierung nach „Milieus“ (vgl. die „Sinus-Studie“); 2. Umwelt und Klimawandel werden zu kommunalen Themen 3. Urbane Mobilität und Elektromobilität Die Liste ist noch nicht gut systematisiert (äußere und innere Themen überschneiden sich). Aber für einen ersten Anhaltspunkt mag sie genügen. Können nun agile Herangehensweise und die dahinterliegende Geisteshaltung eine Richtschnur bieten, um aus diesen Problemstellungen wieder aktive Handlungsfelder zu gestalten? Dazu ein paar Thesen: a) Es bedarf eines strukturierten Prozesses, um systematisch strategische Herausforderungen zu identifizieren und zum Gegenstand von Planungen zu machen. Das heißt, für diese Art schwach strukturierter Prozesse „Auslöser“ zu definieren, die uns zur Beschäftigung mit diesen Themen führen.

20FAV

(2016).

3  Wozu kann unsere Gesellschaft eine „agile Verwaltung“ brauchen?

39

Denn es bleibt nach unserer Auffassung die Aufgabe der öffentlichen Verwaltung, zu den zentrifugalen Kräften in der Gesellschaft (Märkte und Milieus) einen zentripetalen Gegenpol des Ausgleichs (Herstellung gleichartiger Lebensverhältnisse und Sicherung des sozialen Friedens) zu bilden. b) Eine Gemeinsamkeit all dieser Trends ist die Unvorhersehbarkeit der Auswirkungen. Wir haben es mit einer großen Unschärfe zu tun, was die genauen Folgen betrifft. Wir können zwar erkennen, dass wir vor großen Veränderungen stehen, aber welche Wirkung diese im Details auslösen werden, ist kaum vorhersehbar. Das Unplanbare, das Unvorhersehbare, das Unbekannte nimmt zu. c) Die aufgelisteten Themen können deshalb nicht isoliert bearbeitet werden; sie widersetzen sich der Zuordnung von Zuständigkeitssilos. Es gibt vielfältige Wechselwirkungen: das Mobilitätskonzept hat Auswirkungen auf die Wohnungspreise, und beides kann Umzugsbewegungen der Senioren auslösen usw. Was oben zu schwach strukturierten Prozessen ausgeführt wurde, gilt hier in verstärktem Maße. d) Die agile Herangehensweise besteht unter anderem darin, einen dauerhaften Anpassungs- und Veränderungsprozess zu initiieren, bei dem Lösungen für ein Gesamtpaket an Fragestellungen beschlossen, die (z. T. unerwarteten) Ergebnisse ausgewertet, angepasst und so iterativ immer weiter verbessert werden. So würde die öffentliche Verwaltung wieder schlagkräftig und handlungsfähig für die Zukunft, gerade weil sie ständig offen für zielgerichtete Experimente bleibt.

Literatur bitkom (Hrsg) (2017) „Digitale.Stadt“. http://www.digitalestadt.org/bitkom/org/Digitale-Stadt/ Digitale-Stadt/Verwaltung/index-2.html. Zugegriffen: 24. Jan. 2018 BMI Bundesministerium des Innern (Hrsg) (2005) „DOMEA-Konzept. Organisationskonzept 2.1. Dokumentenmanagement und elektronische Archivierung im IT-gestützten Geschäftsgang“. Schriftenreihe der KBSt, Bd 61, November 2005, 157 Seiten, ISSN 0179-7263 Cohen MD, March JG, Olsen JP (1972) A garbage can model of organizational choice. Adm Sci Q 17(1):1–25 DORV (Hrsg) (2017) Lebenslang in der sozialen Umgebung leben können. http://www.dorv.de/ konzept-idee/index.php FAV (Forum Agile Verwaltung) (2016) Auf welche Trends muss sich die Verwaltung in den nächsten Jahren einstellen? Ergebnisse des Gründungsworkshops am 11. Februar 2016. http:// agile-verwaltung.org/2016/03/13/auf-welche-trends-muss-sich-die-verwaltung-in-den-naechsten-jahren-einstellen-ergebnisse-des-gruendungsworkshops-am-11-februar-2016/ Hahlen J, Kühn H (2016) Die Flüchtlingskrise als Verwaltungskrise – Beobachtungen zur Agilität des deutschen Verwaltungssystems. Verwalt Manage 22(3):157–168. http://dx.doi. org/10.5771/0947-9856-2016-3-157 Hänggi M (2015) Fortschrittsgeschichten. Für einen guten Umgang mit Technik. Fischer, Frankfurt a. M. Lepore J (2014) The disruption machine. What the gospel of innovation gets wrong. In: The New Yorker, 23. Juni 2014 Miller T (1997) The German Registratur. Dissertation, University of Britisch Columbia (Kanada)

40

T. Michl und W. Steinbrecher

Morner M, Misgeld M (2017) Selbststeuerung als Lösungsansatz. Innovative Verwalt 2017 (7–8):10–12 Schwaber K, Sutherland J (2017) Der Scrum Guide™. Der gültige Leitfaden für Scrum: Die Spielregeln; entwickelt und kontinuierlich verbessert von den Scrum-Erfindern Ken Schwaber und Jeff Sutherland. Deutsche Ausgabe, November 2017 Seibel W (2016) Verwaltung verstehen: Eine theoriegeschichtliche Einführung. Suhrkamp, Berlin Steinbrecher W (2017) Rezension: Komplex ist, wenn wir etwas tun wollen. www.agile-verwaltung. org, http://agile-verwaltung.org/2017/11/02/rezension-komplex-ist-wenn-wir-etwas-tun/ Weber M (2002) Wirtschaft und Gesellschaft. Grundriß der Verstehenden Soziologie, 5. rev Aufl. Mohr Siebeck, Tübingen

Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger ­consulting.

Wolf Steinbrecher  ist Volkswirt und Informatiker. Er war lange als Anwendungsentwickler für medizinische Datenbanken und in Systemhäusern tätig. Von 1995 bis 2008 war er Sachgebietsleiter „Organisation und Controlling“ in einer mittelgroßen Landkreisverwaltung (1050 MA). Aus den dortigen Erfahrungen rührt das Interesse an teamzentrierten, agilen Arbeitsweisen. Ein Resultat davon war die Entwicklung des Prozessorientierten Ablagesystems (PAS), das in diversen Büchern dargestellt wird. Seit 2008 selbstständiger Berater. Mitgründer des Forums Agile Verwaltung e. V.

4

Agilität – die Zukunft der Öffentlichen Verwaltung? Warum eigentlich agil? – Laut nachgedacht entlang diskussionsbestimmender Stich- und Schlagworte Veronika Lévesque und Thomas Michl

Zusammenfassung

Warum interessieren sich Unternehmen und auch Verwaltungen so zunehmend für agile Arbeitsweisen? Speziell die öffentliche Verwaltung hat in der Auseinandersetzung mit Neuem, mit besonderen „branchenspezifischen“ Schwierigkeiten zu kämpfen. Sie sorgt für eine angemessene Gegenwart und die Einhaltung des Geltenden. Während die Politik stets an der Entwicklung der unmittelbaren und der weiteren Zukunft arbeitet und dabei tagtäglich – auch über Führungsstrukturen – Einfluss auf die Verwaltung nimmt. Der grundsätzliche Auftrag der Verwaltung ist es, für Stabilität, Verbindlichkeit, Rechtstreue und vor allem Verlässlichkeit zu sorgen. Ihr fehlt – zu Recht – die Routine mit Veränderungen und stetigen Anforderungsänderungen und Neuerungen umzugehen. Die öffentliche Verwaltung ist weniger als die private Wirtschaft darauf angewiesen, sich quasi permanent • mit Innovationsdruck: „neuer und besser“, • mit sich ständig verändernden Kundenanforderungen und dem variablen Kaufverhalten oder • mit unmittelbaren Konkurrenzkämpfen von Mitanbietern

V. Lévesque (*)  Forum Agile Verwaltung e. V., Basel, Schweiz E-Mail: [email protected] T. Michl  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_4

41

42

V. Lévesque und T. Michl

auseinanderzusetzen und dagegen erfolgreich zu bestehen. Ihr fehlt also an Erfahrung, mit solchen Phänomenen selbstverständlich und routiniert umzugehen. Vielleicht können agile Arbeitsweisen hier etwas Linderung verschaffen.

4.1 Was macht ‚Verwaltung‘ zur ‚Verwaltung‘ … Letzten Mittwoch. Es ist wieder passiert… Es fällt der Satz: „Die Verwaltung muss Entwicklungsabteilungen haben. Dann wird alles besser. Man sieht doch an Google, wie die Zukunft gemacht ist: Digitalisierung, Innovation, Entwicklung, Erfindungsgeist. Da muss es hingehen (Abb. 4.1).“ Am nächsten Morgen auf einer Veranstaltung zu Design Thinking – Versicherungen, IT-ler, alle möglichen Industrien. Das Namensschild weist unsere Herkunft als Vertreter der öffentlichen Verwaltung aus. Nach einem Blick auf das Schild: „Was machen SIE denn HIER?“. Ja, was denn nun? Die Erwartung erfüllen und als Verwaltungsmensch teilhaben an dem, was da draußen passiert? Oder anerkennen, dass Verwaltung so ganz anders tickt als der Rest der Welt und daraus schließen, dass wir da eigentlich gar nicht hin- und schon gar nicht dazugehören?

Abb. 4.1  Aufbruch

4  Agilität – die Zukunft der Öffentlichen Verwaltung?

43

Was kann soll und muss die Verwaltung und ihre Mitarbeitenden? Firmen wie Google leben von neuen, vorher so nicht dagewesenen Produkten. Google bewegt sich in einem Markt, der überraschen will. Ein Markt, der Zukunft baut, die es noch nicht gibt. Der die Zukunft immer neu erfindet. Der ausreizt, was möglich sein wird, können sollen. Google nimmt Grenzen dabei nur peripher und eher ungern wahr – schon weil das nicht innovativ ist. Und es ist ein Markt, auf dem sich noch andere tummeln, die das alles auch wollen – schneller, besser und origineller als die Mitbewerber. Und: Google hat Geld. Ist das, was Verwaltung will, kann und soll? Jeder Betrieb – Großindustrie, Handwerksfirma desgleichen – muss ein Angebot haben, braucht eine Produktion, einen Vertrieb, einen Verkauf, um an die Kundschaft zu kommen. Unterschiedlich ist – je nach Branche oder Produkt oder Größe des Betriebes – Umfang und Rolle des Managements oder die Notwendigkeit einer innovativen Entwicklungsabteilung. Was quasi alle haben, sogar Einzelfirmen, ist eine Administration. Was macht die? Die verwaltet das, was die anderen Bereiche getan haben oder gerade tun (Abb. 4.2).

Abb. 4.2   Eckpfeiler

44

V. Lévesque und T. Michl

4.1.1 Verwalten. Verwaltung. Was ist die zentrale Aufgabe der öffentlichen Verwaltung? Innerhalb der öffentlichen Verwaltung treffen ebenfalls unterschiedliche Aufgabenbereiche aufeinander. Es sind zum Beispiel diese drei: Der hoheitliche Anteil der Aufgaben der öffentlichen Verwaltung ist der kulturprägende und zentrale Auftrag, die ursprüngliche Existenzberechtigung für einen Verwaltungsapparat. Er ist der Gegenwart verpflichtet und soll das, was demokratischen Weges entschieden wurde, umsetzen. Oder dafür sorgen, dass anderswo im Rahmen der gemeinsamen Regeln gemeinwohltauglich umgesetzt wird. Dass gilt, was gilt. Der Grundanspruch an öffentliche Verwaltung ist, Konformität statt Willkür, Verlässlichkeit und Verbindlichkeit als stabilen Rahmen des öffentlichen Lebens, Sicherheit und Nachvollziehbarkeit des staatlichen Handelns zu bewerkstelligen. Oberste Direktive ist die Sicherstellung des rechtsstaatlichen Handelns. Das, was gesetzt wurde, zu schützen und zu bewahren – so lange, bis von der Politik etwas anderes gesetzt und gültig wird. Die Verwaltung war und ist immer ein Stabilitätsfaktor. Über alle Krisen des Staates hinweg ist es die moderne Verwaltung gewesen, die die Infrastruktur aufrechterhalten und gesichert hat. Kurz: Es geht darum, die Gegenwart und ihre geltenden Regeln in Anwendung zu bringen. Der, zugegebenermaßen etwas abstrakte Auftraggeber für den hoheitlichen Teil ist das gesetzte, geltende Recht. Gesetze und ihre Folgeerlasse – aus ihnen müssen Handlungen abgeleitet werden. Weitergedacht ist der Auftraggeber also im Ursprung das Volk und die von ihm zur Zeit der Rechtssetzung gewählten politischen Verantwortlichen. Dann ist da zusätzlich der politische Anteil, der heißt, im Auftrag der aktuell vom Volk gewählten Repräsentanten diese dabei zu unterstützen, die nahe und ferne Zukunft zu bauen, in großen oder kleinen Würfen. Die Verwaltung hat hier eine neutral-fachliche Rolle zu spielen. Denn die Verwaltung hat eine hohe Fachlichkeit, die den politischen Kräften zur Verfügung stehen muss. Auftraggeber für den politischen Teil ist die derzeit vom Volk gewählte politische Hierarchie. Und der kundenorientierte Anteil: der ‚Service Public‘ (CH) oder ‚Public Service‘. Aufgabe ist, als Dienstleister für die Bürgerinnen und Bürger Leistungen zu erbringen – auf Basis dessen, was definiert ist. Dazu gehört auch, für Angebote zu sorgen, die nicht marktfähig sind: Angebote, deren Wert sich nicht rein in Finanzen rechnet oder rechnen sollte, Angebote für Minderheiten, Nothilfe in gesellschaftlichen oder personbezogenen Krisensituationen etc. Die öffentliche Schule ist hier schon ein Grenzfall: In erster Linie hoheitlich verordnete Schulpflicht, die erfüllt werden muss. Oder aber ein Angebot der öffentlichen Hand, das nicht in erster Linie vom wirtschaftlichen Erfolg der Einrichtung geprägt sein soll? Je nachdem, wo sich Politik und Verwaltung zur Schule stellen, wird sie sich

4  Agilität – die Zukunft der Öffentlichen Verwaltung?

45

u­ nterschiedlich verhalten: Ein Obligatorium für alle durchsetzen oder ein Angebot mit hohem gesamtgesellschaftlichen Wert und Nutzen zur Verfügung stellen. Auch die Ansprüche der Bürgerinnen und Bürger verändern sich – die gestiegenen Erwartungen der Bürger an Beteiligung und Transparenz oder an Geschwindigkeit sind ein Beispiel. Gleichzeitig verändert sich die Erlebenswelt der Bürgerinnen und Bürger, die Gesellschaft und das Umfeld, in dem die Verwaltung eingebettet ist in einer rasanten Geschwindigkeit. Moderne Technik erlaubt Wege der Bürgerkommunikation, die noch vor wenigen Jahren undenkbar waren. Die digitale Technik eröffnet neue Möglichkeiten zur Prozessoptimierung nach innen und außen. Damit wachsen aber auch die Anforderungen der Bürgerinnen und Bürger an die Verwaltung, eben auch über diese Wege von der Verwaltung und quasi jederzeit bedient zu werden. Für den öffentlichen Dienst ist der unmittelbar Auftraggebende – zumindest in deren eigenen Wahrnehmung – oft eine Einzelperson, die eine Leistung benötigt oder erwartet. Und die sich eventuell in ihrer momentanen persönlichen akuten Situation nur sehr eingeschränkt um die Grenzen und Möglichkeiten schert, die sich aus dem hoheitlichen und politischen Teil der Arbeit der Verwaltung im Auftrag des Volkes als Ganzes ergeben. Wollen Sie Ihr Auto anmelden, interessiert Sie als Bürger zunächst die datenschutzkonforme Abwicklung im Hintergrund wenig. Doch diese hat auch Auswirkungen auf die Art und Weise der Beziehung zwischen Verwaltung und Bürger. Zusammengefasst: Auftrag

Hoheitlich

Politisch

Public Service

Aufgaben

Gegenwartsschutz

Zukunftsgestaltung

Gesamtgesellschaftlich relevante Angebote, Einzeldienstleistungen

Aktuelle Politik

Volk, Einzelperson

Auftraggeber Geltender rechtlicher Rahmen

4.2 „Wenn der Spagat im Schritt schmerzt…“ Bisweilen ist der Spagat zwischen diesen Ansprüchen schwierig. Denn teilweise sind die Ansprüche an die Verwaltung ja gegenseitig widersprüchlich. Das Geltende zu schützen und politische Entwicklungen, die davon abweichen, zu begleiten. Individuelle Ansprüche kundenorientiert entgegenzunehmen und dem Gemeinwohl verantwortlich zu sein. Werden die hoheitlichen, politischen, fachlichen und dienstleistenden Aufgabenebenen vermischt, besteht wegen der inneren Widersprüche die Gefahr, keinem der unterschiedlichen Ansprüche wirklich gerecht zu werden – der Vorwurf der Ineffizienz, der die Verwaltung immer wieder trifft, könnte auch hier eine Wurzel haben.

46

V. Lévesque und T. Michl

Die drei Kernaufgaben der Verwaltung sind unterschiedlichen Auslösern und ­ ahmensituationen verpflichtet. Und dies benötigt – so die These – jeweils unterschiedR liche Handlungsansätze, Arbeitsweisen und Expertisen. Aber dafür muss klar werden, welche der Aufgabenebenen im gegebenen Fall handlungsweisend ist. Ein hilfreicher Schritt könnte sein, in der alltäglichen Verwaltungsarbeit zwischen den unterschiedlichen Aufgabenebenen gezielt zu unterscheiden. Sich bewusst zu sein, auf welcher Ebene wir gerade agieren. Oder – ganz einfach – in einem Team Rollen zuzuteilen, festzulegen, wer welche Ebene vertritt, und auszuprobieren, wo sich die Handlungen je nach Ebene unterschiedlich gebärden. Ob und wie passen sich die Ebenen im gegebenen Fall aufeinander an oder widersprechen sich gar? Wo Konsequenzen entstehen, die sich auf einer der anderen Aufgabenebenen auswirken. Und dann wissender das weitere Vorgehen zu gestalten. Entscheidungen zu treffen. Schon allein das Anerkennen, dass Verwaltungsaufgaben divers sind und dass es je nach Ebene Handlungsalternativen geben muss, löst viel aus – wie zum Beispiel Ängelholm (siehe Kap. 20) zeigt… . Besonders häufig genannt werden die folgenden drei Themen und Anliegen, die für die Verwaltung in ihrer aktuellen Situation und im aufscheinenden Interesse an agilen Vorgehensweisen eine wichtige Rolle zu spielen scheinen.

4.2.1 Komplexität – „die Anforderungen an uns werden immer komplexer…“. Komplexität bedeutet die Zunahme von Vernetzung und damit den Umgang mit Rückkopplungen und Querbeziehungen. Diese Anforderungen sind lokal vielleicht verschieden oder unterschiedlich ­gewichtet. Generell aber sind die Ansprüche an die (und das Selbstverständnis der) Verwaltung aktuell weniger stabil und glasklar, als sie es lange Zeit waren. Das Unberechenbare, Unvorhersehbare wird immer öfter Teil des Verwaltungshandelns. Zunehmend viele Themen und Projekte wollen einfach nicht in die gewohnte Struktur passen. Gewohnte, stark strukturierte Prozesse und Routinen greifen nur zum Teil oder gar nicht. Neue Techno­ logien oder technische Möglichkeiten – oder Moden – gehören zum Beispiel zu dieser Art Anforderungen: Ständige Erreichbarkeit der Verwaltung und ihrer Dienste über Apps und Internet verändern die Arbeit der Verwaltung deutlich. Und die Erwartungen – und Auswirkungen, die damit an sie gestellt werden, sind schwer vorherzusagen und erstrecken sich in kaum abschätzbare Bereiche. Gewisse Themen sind nicht eindeutig einer Zuständigkeit oder ­Organisationseinheit zuzuordnen; sie haben aber dennoch Einfluss auf die Anforderungen, die durch die öffentliche Verwaltung bearbeitet werden müssen: Neue ‚junge‘ Alte oder auch neue ‚alte‘ Eltern und ihre jeweiligen nicht-traditionellen Ansprüche an das Gemeinwesen sind hier nur ein Beispiel von vielen.

4  Agilität – die Zukunft der Öffentlichen Verwaltung?

47

Solche Anforderungen werden deshalb oft über lange Zeit als ‚zusätzlich‘ oder einfach als ‚speziell‘ wahrgenommen oder bisweilen gar als ‚nicht zur Aufgabe gehörend‘ abgetan. Manche Aufgabenstellungen sind in Art ihres Aufkommens oder inhaltlich neu und bewegen sich im Querschnitt verschiedener Bereiche. D. h. in diesem Fall Themen, die so in der Linienstruktur nicht abgebildet sind und daher Einheiten übergreifend und damit innerhalb mehrerer Zuständigkeiten und Hierarchien bearbeitet werden müss(t) en – der Umgang mit einer größeren Anzahl Flüchtlinge kann hier als Beispiel dienen. Im drei Ebenen-Modell der bundesdeutschen Verwaltung sind hier Bundes-, Landes- und Kommunalbehörden darauf angewiesen zusammenzuarbeiten. Und doch fehlen nach wie vor die rechtlichen Rahmenbedingungen, der Aufgabe wirklich gerecht zu werden. Ein Dickicht aus Zuständigkeitsfestlegungen, das behindert die Zusammenarbeit. Andere Dinge sind wieder nirgendwo geregelt und entsprechende Angelegenheiten drohen im Kompetenzwirrwarr der organisierten Unverantwortlichkeit zum Opfern zu fallen, da sich niemand zuständig und verantwortlich wähnt und glaubt, dies würde in die Zuständigkeit anderer Stelle fallen. Immer deutlicher wird in den letzten Jahren, dass solche Themen gekommen sind, um zu bleiben. Und dass das Aufscheinen immer neuer komplexer Anforderungen voraussichtlich nicht aufhören, sondern immer stärker den Alltag prägen wird. Das heißt, dass der Umgang damit nichts Besonderes ist, sondern in unsere Kernkompetenzen gehören wird. ‚Komplex‘ ist dabei anders als ‚kompliziert‘. Während es für komplizierte Frage­ stellungen meist mindestens eine zutreffende Antwort gibt, funktionieren komplexe ­Fragestellungen anders. Kompliziert lässt sich mit Wissen lösen. Wissen, das vorhanden und abrufbar ist. Komplizierte Vorgänge lassen sich mit den entsprechenden Kenntnissen voraussagen und zielgerichtet steuern. Komplexität jedoch bedeutet, dass jede Teilentscheidung in einem komplexen ­Prozess Konsequenzen hat, die richtungsweisend wirken und so eine neue Dynamik anstoßen. Konsequenzen, die wir aber nicht absehen können. Das Unvorhersehbare wird zum ­Normalzustand. Aber wenn wir nicht wissen, was uns erwartet, können wir nicht voraussagen, was passieren wird. Wir können nicht prognostizieren, ob die Erwartungen erfüllt werden, die wir formuliert haben. Uns bleibt lediglich das Herantasten durch Versuch und Irrtum. Die Komplexität reduzieren oder trivialisieren zu wollen, hilft im Umgang mit ­Komplexität deshalb nicht weiter. Sondern eine Vorgehensweise, die der Komplexität, der Unvorhersehbarkeit der Zukunft Rechnung trägt. Zwei – auch miteinander kombinierbare – agile Zugänge zur Arbeit im und MIT dem Komplexen sind zum Beispiel die folgenden: • die kollaborative koordinierte Arbeit als multiprofessionelles Team und • eine adaptive Etappierung und Taktung des Arbeitsprozesses entlang der Erkenntnisse.

48

V. Lévesque und T. Michl

Beide zielen darauf, dass in der Kombination der Kompetenzen und der Erfahrungen Erkenntnisfelder gesucht und gefunden werden und dann pragmatisch und realitätsnah bearbeitet werden. Wir tasten uns an die bestmöglichste Lösung heran, in dem wir empirisch vorgehen. Wir erstellen eine Hypothese, überprüfen diese an Hand der Wirklichkeit, passen die Hypothese an, überprüfen sie erneut.

4.2.2 Führung – „Unsere Leitung verlangt, dass wir mehr leisten. Aber mehr von dem, was schon jetzt nicht gut funktioniert, hilft uns nicht weiter…“ Führung ist eine Funktion in einem Betrieb. Je mehr eine Führungsperson wichtige Entscheidungen auf sich vereint, desto deutlicher ist der Betrieb so gut wie diese Person bzw. umso limitierter. Aber Wissen, Erfahrung, ja selbst Intuition sind begrenzt. In einer komplexen Welt ohnehin. Niemand verfügt allein über das Wissen, die Kompetenz, in komplexen Situationen effektiv und effizient entscheiden zu können. Hilfreich ist die Fähigkeit zur Gestaltung von organisatorischer und personen­ bezogener Anpassung an situative Fragestellungen und Ziele. Diese Fähigkeit ist nicht abhängig von einer Führungsperson. Sie kann auch von zuständigen Teams ­übernommen werden. Ja, sollte sogar von diesen übernommenen werden. Unter Einbezug ganz verschiedener Fachlichkeiten und Blickwinkel – aber ein gemeinsames Projekt. In der Zusammensetzung, die der gegebenen Situation am sinnvollsten angepasst erscheint. Nicht einfach feste Abteilungen und Hierarchien, sondern gemeinsame, bewusst ­zusammen gesetzte Teams mit adaptierten Rollen – und Verantwortung. Interdisziplinari­ tät – jenseits der klassischen Zuständigkeitsgrenzen und -silos – ermöglicht einen ganzheitlichen Blick auf eine Problemstellung und damit andere, vernetzte Problemlösungen. Verschiedene Fachlichkeiten beleuchten verschiedene Aspekte. Das Handlungsteam hat so die Zutaten, die es braucht, um Einsichten zu gewinnen, zu analysieren, abzu­ wägen, aufeinander zu reagieren, voneinander zu wissen, zu nuancieren und abgestützte und tragfähige Lösungen zu diskutieren – alles das, was auch Teil der „klassischen“ ­Führungsaufgabe ist. Wenn das Team in dem verantwortlich handeln kann, was geschieht – das heißt im Rahmen bestimmter Voraussetzungen und Vorgaben entscheiden und realisieren kann – dann kann neben einer großen Bandbreite unterschiedlicher Sachkenntnis und ­Erfahrung auch Identifikation und Interesse an der Gesamtlösung entstehen. Das ist eine gute Voraussetzung für eine der Situation adaptierte sinnvolle Auseinandersetzung – punktu­ elle abstrakte Loyalitäten, wie eine verordnete Ablehnungsquotenerhöhung, ­bekommen einen anderen Kontext zugunsten von Entscheidungsmarge und Bezug zur realen ­gegebenen Situation. Führung wird damit nicht obsolet. Sie wird anders. Ein interdisziplinäres, selbst organisiertes und agiles Team hat andere Ansprüche an Führung als im klassischen Umfeld. Führung wird zur dienenden Aufgaben, zur „Serverant Leadership“.

4  Agilität – die Zukunft der Öffentlichen Verwaltung?

49

4.2.3 Planung – „Es geht alles so schnell. Wir können kaum noch planen…“ Planung ist wichtig. Allerdings nicht in erster Linie in die langfristige Zukunft gerichtet – „so wird es sein“ – sondern besonders, um aus dem Verlauf unserer Arbeit zu lernen und uns der Realität anzupassen. Dieses organisatorische Lernen ist eines der wesentlichen Elemente der agilen Denkweise. Im angelsächsischen Sprachraum wird von „inspect and adapt“ gesprochen, also vom Prüfen und Anpassen. Kurze, detaillierte Planungsphasen werden in festen Zyklen überprüft, ehe die nächste Planungsphase erstellt und entsprechend angepasst in Angriff genommen wird. Teil dieser Lernzyklen ist die Ein­ bindung aller Anspruchsberechtigten mit dem Ziel, früh Rückmeldungen zu erzeugen. Die meisten der Führungskader und kulturprägenden Personen der Verwaltung sind im tayloristischen Paradigma einer mechanischen, stabilen Welt geprägt. Sie wurden für die Herausforderungen einer stabilen Umwelt mit Ziel der Rechtssicherheit, der Vereinheitlichung der Prozesse und Abläufe ausgebildet und auch beruflich sozialisiert. Einer Denkweise, die auf strikter Arbeitsteilung, hierarchischer Trennung der Verantwortlichkeit basiert. Hier geht es also auch um Glaubenssätze und Reflexe im Umgang mit Aufgaben. Wir haben gelernt, dass Standardisierung, Routinen und solide Planung erfolgreiche Instrumente für Stabilität und Wohlstand darstellen. In den ersten drei Jahrzehnten nach dem Krieg waren stabile Wachstumsraten, Verlässlichkeit und strategische Langzeitplanung bewährte Erfolgsfaktoren. Aber: Dies trifft im Kielwasser von Digitalisierung, Globalisierung und VUCA-Umwelten (siehe Kap. 2) immer weniger zu. Pläne, Planungsvorgaben, Standards, Routinen, Regulierung und geformte, vor­ gefertigte Prozesse haben Vorteile wie Sicherheit, Nachvollziehbarkeit, Vergleichbarkeit. Aber auch Nachteile! Komplexität ist – wie oben gezeigt – mit zu starr geplanten Vor­ gehensweisen nur sehr bedingt oder gar nur scheinbar beizukommen. Die Gefahr besteht, an komplexen, aktuellen Realitäten mit starr geplantem oder Vorgefertigtem gezielt vorbei zu handeln, da die Gleichung viele Unbekannte hat. Unbekannte, die wir nicht kennen und die nicht kompatibel mit den tradierten Regelungen und Vorgaben sind. Darüber hinaus gehen die erlernte Theorie und die erlernten Planungsannahmen oft von idealisierten Umständen aus. Viel Energie im Alltag geht ins Ausbalancieren der Zusatzaufwände und der Unsicherheiten, die durch die Unterschiede zwischen Planung und ­tatsächlicher Situation entstehen. Auch lässt sich ein Lerneffekt der Organisation vermissen. Ein ­Lerneffekt, der zur Anpassung der Organisation, des organisatorischen Rahmens an die jeweils verändernden Rahmenbedingungen führt. Statt mit dem einen großen Wurf eine theoretisch valide Lösung zu planen und zu verfolgen – und eventuell immer wieder auf dieser Basis flicken und nachbessern zu müssen ohne viele weitere Optionen –, kann es hilfreich sein, kleinschrittiger vorzugehen. Dabei immer wieder – in festgelegten periodischen Abschnitten – innezuhalten und zu prüfen, ob der eingeschlagene Weg tatsächlich die gewünschten Ergebnisse zeitigt. In Arbeits­ situationen herauszufinden, wie die aktualisierte Situation ist und wie nicht (mehr). Bessere

50

V. Lévesque und T. Michl

oder dem aktuellen Zustand angemessenere Varianten zu erkennen, nachzujustieren oder nach kurzer Zeit festzustellen, dass der letzte Versuch ein falscher Weg war und einen anderen suchen zu können – weil noch keine allzu früh in der Planung gestellte Weiche anderes versperrt. Für den Menschen, dem der behördliche Prozess dient, aber auch zum Schutz einzusetzender Mittel und der Verwaltungsmitarbeiter Planung steht im ständigen Gegenüber dessen, was die Realität gerade tut. Der Unterschied zwischen Planung, Realität und Ziel ist das wichtigste Informations- und Lernfeld. Dieses stetige Lernen beeinflusst das Vorgehen. Also ist das Weiterentwickeln des Plans, bzw. die Dokumentation der Auswirkung des Dazulernens auf das aktuelle Vorgehen der Normalzustand. Das heißt, selbst wenn der Plan nicht allein bestimmend und Änderungen unterworfen ist, braucht es ihn. Fang an, hör auf, prüfe – und tue dies sinnvoll immer wieder!

4.3 Also, Verwaltung? Was jetzt? Für die Verwaltung bedeutet das einen Rollenwechsel: aus dem Denken in festen Ver­ läufen, Systemen und Dezernaten wird das stetige Gestalten von angepasster Organisation mit netzwerkartigen Strukturen, eben agiles Handeln. Natürlich kann und soll sich die Verwaltung Entwicklungen und Erfolgen der sie umgebenden Welt – und denen von Firma wie Google – nicht ausschließlich ver­ schließen. Warum denn nicht mit Entwicklungsabteilungen für Verwaltungen arbeiten? Darauf hinarbeiten, dass Verwaltung ihre Aufgaben schlank und passend auf neuen Wegen erfüllt und nicht vornehmlich das Tagesgeschäft abwickelt? Als Verwaltung, die ihr Gegenwartshüterwissen und ihre Fachlichkeit nutzt, um gezielt Optionen und Varianten für die Gegenwarts- und Zukunftsbewältigung zu designen? Agil zum Beispiel? Und gleichzeitig sollte die öffentliche Verwaltung sich immer selbstbewusst genug sein, zu wissen, dass sie neben Vergleichbarem eben auch ganz andere Aufgaben und Ziele (mit-)zu verfolgen hat, als die erfolgreiche freie Wirtschaft. Denn die Verwaltung ist der Gesellschaft verpflichtet, der sie dient. Sie ist der infrastrukturelle Rahmen, der eben jener Wirtschaft erlaubt erfolgreich zu sein, weil sie den institutionellen Rahmen schafft, der vertrauensvolles Zusammenarbeiten der gesellschaftlichen Akteure überhaupt erst erlaubt. Wie innovierend, agierend und selbstaktiv getrieben kann und soll eine Verwaltung also sein? Diese Frage müssen wir stellen und sie muss uns in unserer Arbeit stetig begleiten. Aber eine einfache, schwarz-weiße Antwort: „Macht es wie Google“ oder „Bleibt bei Euren Leisten, das hat nix mit Euch zu tun“ gibt es nicht. Die Wahrheit liegt auch hier irgendwo dazwischen.

4  Agilität – die Zukunft der Öffentlichen Verwaltung?

51

Veronika Lévesque ist seit 1998 aktiv als Spezialistin für ­Organisationsentwicklung mit den Schwerpunkten Kokreation, adaptive Lösungsentwicklung, Change-Prozesse, Visualisierung, Projektund Prozessdesign und Koordination multiprofessioneller Teams sowie (Grossgruppen-) Moderation und (System-) Beratung. Seit 2003 ist sie in der Öffentlichen Verwaltung, vorher in den Branchen Bildungsmanagement, Spedition und Logistik, Softwareentwicklung und Personalberatung unterwegs. Besondere Interessen: Grenzgänge – zwischen Ländern genauso wie zwischen Aufgabenbereichen und Kontexten.

Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger ­consulting.

Teil II Agile Methoden und was sie im Verwaltungsalltag bewirken

5

Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise Frederic Jordan

Zusammenfassung

In diesem Teil des Buches soll ein Thema näher betrachtet werden, welches in der Praxis häufig zu Missverständnissen führt. Es geht um den Begriff „Kanban“, w ­ elcher in der japanischen Sprache „Schild“, „Karte“ oder „Kärtchen“ bedeutet. In den nachfolgenden Erläuterungen wird der Lesende erkennen, dass die Karte bei allen erwähnten Varianten eine wichtige Rolle spielt.

5.1 Einleitung Kaum ein Begriff teilt die agile Gemeinschaft stärker von derjenigen des Lean Management. Ursprünglich wurden beide Seiten von erfahrenen Experten auf- und ausgebaut. Jeder verstand die Idee hinter der jeweiligen Variante und es konnte jederzeit ein Austausch stattfinden. Der heutige Zeitgeist lässt Menschen jedoch lieber kopieren anstatt zu kapieren. Zu oft werden heute falsche oder unvollständige Texte von nicht ausreichend ausgebildeten Menschen übernommen und manchmal direkt als „Expertenwissen“ verkauft oder vermittelt. Diese Möglichkeit ist für die künftigen Generationen alles andere als ein Glücksfall. Wie festgestellt wurde, können junge Menschen immer weniger zwischen Realität und Fiktion unterscheiden. Das wird zunehmend und höchstwahrscheinlich dazu führen, dass unterschiedlichste Bereiche und Themen stark vermischt und verfälscht

F. Jordan ()  Jordan Consulting, Stäfa, Schweiz E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_5

55

56

F. Jordan

werden. Bis zur Unkenntlichkeit hin. Das vorliegende Werk wird, egal in welcher Form, diesem Trend entgegenhalten. Nachfolgend widmen wir uns einigen, nicht allen, Aspekten von Kanban, dessen ­Auslegungen, der Herkunft sowie der Wirkungsweise. Eines kann an dieser Stelle bereits gesagt werden: Jede Art von Kanban ist eine tolle Sache.

5.2 Verständnis entwickeln Wie bereits erwähnt, wir leben in einer Welt, in der sich die Themen immer stärker vermischen. Dies hat mehrheitlich einen negativen Einfluss auf unseren Alltag, denn der Großteil der Anwender hat kein umfassendes Wissen über die verschiedenen Methoden und Vorgehensweisen. Die Menschen vertrauen sehr stark auf das Internet und dessen Inhalt. Gerade junge Menschen haben oft Schwierigkeiten zu verstehen, dass das Internet eine hervorragende Recherchemöglichkeit darstellt, aber der Inhalt stets mit Vorsicht zu genießen ist. Methoden sind stets nur eine Krücke zum Ziel. Die Entwicklung der eigenen Haltung, besser gesagt der eigenen Geisteshaltung – auch Mindset genannt – gegenüber diesen Themen, ist bedeutend wichtiger. Damit überhaupt ein tieferes Verständnis für eine Materie entstehen kann, muss diese zuerst einmal in seine einzelnen Bestandteile zerlegt werden. Dies erleichtert den Überblick zu behalten und die Teile am Ende passgenau zusammenzufügen. Kanban stammt ursprünglich aus dem Lean Management und wurde später, zumindest dem Namen nach, von der agilen Gemeinde übernommen. Gerade der identische Name führt in der Praxis oft zu Uneinigkeit. Alleine der Mindset eines Software-Entwicklers und dem eines Ingenieur ist stark voneinander abweichend. Doch auch die Methoden an sich vertragen sich nicht zwingend in den gegenüberliegenden Bereichen. Ein sehr wichtiger Punkt ist, dass die Wirkungsweise unterschiedlich ist. Nur oberflächlich betrachtet stehen die gleichen Ideen dahinter. Deshalb ist es wichtig, die Arten nachfolgend zu trennen.

5.3 Kanban im Lean Management 5.3.1 Hintergrund Der Vater des Toyota-Produktions-System (kurz TPS), Taiichi Ono (1912–1990), ­entwickelte Methoden und Vorgehensweisen, um die Produktion zu vereinfachen und ­flexibler zu gestalten.

5  Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise

57

Einerseits erfand er die autonome Automation, hierzulande bekannter unter dem japanischen Namen „Jidoka“. Andererseits steht das „Jasuto in taimu seisan shisutemu“, ­welches wir unter „Just-in-Time“ kennen. Das Just-in-Time-Konzept, so sein ursprünglicher Gedanke, sollte ein Auto auf „Fingerschnipsen“ hin zusammenfügen. Genau dann, wenn der Kunde dieses bestellt. Dies ist natürlich nicht möglich, aber legte die Grundlage für die Denkweise und die spätere Umsetzung aller heute bekannten Vorgehensweisen. Vorratshaltung und Lagerung sollten damit überwunden werden, da beide mehrheitlich unnötige Kostenfaktoren sind und er sich diese damals aufgrund der Wirtschaftslage nicht leisten konnte. Eine Just-in-Time-Fertigung bedeutet, dass alle benötigen Teile und Leistungen in einem Rutsch durchlaufen, ohne dass es Engpässe oder Überproduktionen gibt. Das Ziel war eine völlige Kontrolle während des gesamten laufenden Produktionsprozesses. Um dies zu ermöglichen, wurde eine Vielzahl von Methoden und Vorgehensweisen erschaffen. Eines der wichtigsten Grundprinzipien im Lean-Management, gleichgültig welcher Ausrichtung auch immer, ist das Zieh-Prinzip, auch Pull-Prinzip genannt. Dieses zieht sich einem Ruderer gleich ans Ziel, die Sicht immer gegen den Start gewandt. Kerngedanke ist und war, dass die Kundenbestellung den ganzen Prozess anstößt. Alle nötigen Teile fließen von ihrem Ausgangspunkt zum Endpunkt, der Übergabe an den Kunden. Dieser gab den alleinigen Ausschlag. Ohne passiert nichts. Niemand verschiebt ohne Zug seitens des Kunden bzw. dessen Auftrages etwas. Dieser Punkt unterscheidet sich im Wesentlichen vom Kanban im agilen Bereich. Auch auf diese Aussage wird später vertieft Bezug genommen. Kanban basiert im Lean auf dem erwähnten Pull-Effekt, ist aber nicht der Effekt selbst.

5.3.2 Wichtiger Hinweis Kanban ist, wie jede Methode, nur eine Krücke, ein reines Hilfsmittel zum angestrebten Ziel. Perfekt wäre das System, wenn diese Hilfe gar nicht nötig wird. Kaban transportiert eine Information bzw. ein Gut, dies kann theoretisch mit ganz anderen Lösungen ermöglicht werden. Auch in diesem Zusammenhang ist tiefes Verständnis für die Materie wichtig, denn eine Methode zu kopieren und einsetzen bedeutet, nicht zwingend Erfolg damit zu haben. Die Methode besitzt Ausprägungen, welche sich selbst langjährigen Lean-Anwendern nicht immer erschließen. Jede Variante hat ihre Besonderheiten und eignet sich nicht zwingend für andere Anwendungen. Man spricht in diesem Zusammenhang auch von der Kanban-Steuerung, damit ist die Steuerung der Karte gemeint. Diese wird so angelegt, wie es das jeweilige System der Unternehmung benötigt.

58

F. Jordan

Auch führt die Nutzung von Kanban im Lean nicht automatisch zu dem häufig erwähnten Flusseffekt. Dies ist abhängig davon, wie viele andere Teile des Just-in-Time-Konzeptes ­vorhanden sind und wie diese miteinander funktionieren bzw. ineinandergreifen. Auch hier gilt: Die reine Anwendung der Methode führt nicht zwingend zum Erfolg. Die Effektivität hat Priorität. Effizienz entsteht durch diese.

5.4 Vorteile Richtig eingesetzt zeigen sich u. a. folgende Vorteile: • • • • •

Reduzierte Lagerbestände Vereinfachte Bestandes-Überwachung und -Kontrolle Verkürzte Durchlaufzeiten Kürzere Lieferzeiten Fehler werden rascher erkannt.

5.5 Essenzielle Maßnahmen Die Einführung und der Betrieb eines Kanban-Regelkreises benötigt einige Maßnahmen, damit dieser funktioniert. Einige Beispiele: • Fließfertigung • Bedarfsgemäße Produktion • Kleine Losgrößen • Geglättete Produktion • Kürzere Transportzyklen • Einheitliche Zyklen • Gleichmäßige Auslastung der Produktion • Visualisierung • Zweckdienliche Behälter • Tief greifende Schulung aller Beteiligten

5.6 Funktionsweise Kanban funktioniert anhand eines Regelkreises. Der Auslöser ist stets ein Auftrag eines Kunden. Ohne diesen agiert das System nicht und ruht in sich.

5  Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise

59

Abb. 5.1  Kanban Regelkreis

An dieser Stelle wird darauf verzichtet, Kanban in allen Ausprägungen zu erklären. Stattdessen steht die grundsätzliche Funktionsweise im Vordergrund. Abb. 5.1 soll den Mechanismus verdeutlichen. Ablauf (Theorie): • • • •

Der Kunde (1) gibt einen Auftrag an die Produktion. Die Endmontage (2) gibt den Impuls an die Bauteile-Stelle weiter. Die Bauteile-Stelle (3) leitet diesen weiter zu den Einzelteilen (4) Letzteres sendet die geforderte Menge und Art der Teile in Richtung der Bauteile-Verarbeitung. Danach stellt sie die Aktivität umgehend ein. • Diese erstellt alle nötigen Bauteile und gibt diese an die Endmontage weiter. Auch hier wird danach nichts mehr gemacht. • Das fertige Produkt wird an den Kunden geliefert. Keine der Stellen hat ohne den Impuls seitens des Kunden etwas getan, weder vorher, noch nachher, noch von sich aus. Hinweis: Der Kunde kann sowohl interner wie externer Natur sein. Auch muss kein Mensch den Auftrag erteilen, es kann ein elektronischer Impuls erfolgen.

5.7 Kanban in der IT 5.7.1 Hintergrund Aufgrund der zunehmenden Verbreitung der IT und der damit einhergehenden Software-Entwicklung standen die Experten dieses Bereiches rasch einmal an den Grenzen, welche ihnen die bislang bekannten Vorgehensweisen boten. Sei dies in der Entwicklung selbst, im dazugehörenden Projektmanagement sowie im mit einhergehenden Change Management bei der späteren Einführung. Während die damaligen Methoden mehrheitlich von Punkt zu Punkt sprangen, war es in der Software-Entwicklung ganz anders. Ständig konnte der Kunde, das Umfeld oder Innovationen direkten wie starken Einfluss auf die Entwicklung der Lösung haben.

60

F. Jordan

Die Geschwindigkeit nahm vergleichsweise rasant zu, was dazu führte, dass nach neuen und flexibleren Methoden gesucht wurde. Daraus entstand mit der Zeit das, was wir heute unter Agile verstehen. Kanban in der IT bediente sich dabei Methoden und Denkweise, die verfügbar waren und auf das Umfeld passten. Es ist bereits hier anzumerken, dass sich dieses über all die Jahre laufend und manchmal gegenteilig entwickelt, was es auch für fachkundige Anwender nicht einfach macht. Es wurde nicht nur der Name Kanban übernommen, sondern auch sonstige Teile des Lean Managements. Einige Prinzipien daraus wurden verändert übernommen, ergänzt um die Theory of Constraints1 sowie dem klassischen Risikomanagement. Ziel war es, Produkte in wesentlich kürzeren Zeiten zu entwickeln. Als Begründer gilt David Anderson, der dieses Konzept erstmals 2007 vorstellte. Entwickelt hat er es angeblich bereits 2004, als er bei Microsoft arbeitete.

5.7.2 Praktiken Im Gegensatz zum japanischen Kanban, welches aufgrund von Prinzipien funktioniert, basiert das agile Kanban auf sechs Praktiken, welche David Anderson aufgestellt hat. Diese sind nicht Kern von Kanban, sondern sind notwendig, um es im Unternehmen anzuwenden. Ein interessanter Ansatz, da ohne die Außenwirkung (vergleiche Lean) nichts passiert bzw. nicht das Gewünschte. Auflistung 1. Visualisiere den Fluss der Arbeit 2. Begrenze die Menge angefangener Arbeit 3. Miss und steuere den Fluss 4. Definiere die Regeln für den Prozess explizit 5. Fördere Leadership in der Organisation 6. Verwende Modelle, um Chancen für gemeinsame Verbesserungen zu erkennen Die wichtigsten beiden Punkt sind das Kanban-Board, welches die Zusammenhänge visualisiert sowie der WIP (Work in Progress oder der Umlaufbestand. Meist falsch als Ware-in-Arbeit übersetzt. Letzteres wäre Work-in-Process). WIP bedeutet in der Betriebswirtschaftslehre die Menge an Beständen, welche durch freigegebene Aufträge in den verschiedenen Stufen einer Produktion in der laufenden Entwicklung oder der Produktion gebunden sind. Dazu gehören alle Bestände, welche bearbeitet werden, in Puffern bereitliegen oder in Wartschlaufen zur Bearbeitung bereitstehen. 1Die Theory

of Constraints (TOC), auch Engpasstheorie oder Durchsatz-Management, bezeichnet die Gesamtheit der Denkprozesse und Methoden zur Verbesserung der Leistungsfähigkeit (Durchsatz) von Systemen basierend auf den Ideen Eliyahu M. Goldratts.

5  Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise

61

Durch die unter Punkt 2 erwähnte Begrenzung der Menge wird der Umlaufbestand gesenkt, was in einer Produktion in erster Linie auf die Kosten niederschlägt, in der Entwicklung aber ganz klar auf die Zeit einwirkt. Zu viele Auftragseinheiten lassen sich schlechter kontrollieren und meist weniger rasch bearbeiten. Die mögliche gegenseitige Abhängigkeit verschlimmert das Ganze. Damit die Beteiligten diese Menge unter visueller Kontrolle haben, wurde das Kanban-Board geschaffen.

5.8 Kanban-Board Das Board oder auch die Tafel ist ein Werkzeug der oben genannten Entwicklungsmethode. Anstelle der ursprünglichen Signalkarten werden beim Kanban-Board Post-it, Stattys, Magnete und sonstige haftende Materialien verwendet. Damit werden die Arbeitselemente dargestellt. Jedes Objekt ist ein Teil des Herstellungs- bzw. des Entwicklungsprozesses und durchläuft von links nach rechts alle Abschnitte des Boards. Die Aufteilung kann sehr einfach gehalten sein, z. B. mit drei Spalten (Offen, in Arbeit, Fertig) oder eben ausführlicher. Beispielsweise mit Spalten wie: Backlog, Bereit, Entwickeln, Testen, Freigabe, Fertig. Je nach Situation vor Ort sowie den notwendigen Schritten des Teams kann das Board minimiert oder ausgedehnt werden. Durch den Punkt 1 „visualisiere den Fluss“ ist es auch erlaubt, Unklarheiten weiter zu unterteilen. So kann die Spalte „Entwicklung“ nochmals in „in Arbeit“ und „Erledigt“ unterteilt werden. Das bedeutet dann, dass die Elemente in der zweitgenannten Spalte noch nicht zum Testen weitergereicht wurden. Eine mögliche Darstellung sieht man in Abb. 5.2.

5.8.1 Vorteil und Gefahren Der klar ersichtliche Vorteil ist, dass ein solches Board mit einfachstem Material hergestellt und betrieben wird. Jeder kann mitmachen und versteht die Methode für sich alleine in wenigen Minuten. Der visuelle Überblick kann gemeinsam besprochen werden oder alleine nachvollzogen werden. Einer der Nachteile ist, dass in der Praxis die Aufteilung der Spalten rasch ein vernünftiges Maß übersteigt. Die Idee des Boards ist, sofort zu erkennen, was abgeht. Eine zu stark zerstückelte Darstellung lässt die Anwender mehr Zeit mit der korrekten Platzierung sowie dem Aufbau verbringen, als mit der Arbeit selbst. Wie im Lean ist das Board ein reines Mittel zum Zweck. Was darüber hinausgeht, entspricht beiden Ausrichtungen in keiner Art und Weise.

62

F. Jordan

Abb. 5.2  Beispiel eines Kaban-Boards

5.9 Personal Kanban Die dritte bekannte Methode, welche im Namen das Wort „Kanban“ trägt, ist das Personal Kanban. Dazu gibt es ein eigenes Kapitel unter der Selbst- und Teamorganisation von Thomas Michl (Kap. 9)

5.9.1 Unterschiede der Prinzipien Jede Kanban-Methode bezieht sich auf den sogenannten Pull-Effekt (Zug-Effekt). Das ist jedoch nicht korrekt. Nur im Lean ist ein Pull-Effekt vorhanden. Im Agile wirkt ein Push-Effekt (Schiebe-Effekt – siehe Tab. 5.1). An dieser Stelle sollte erwähnt werden, dass diese Unterscheidung keinen direkten Einfluss auf die Wirksamkeit der Methode selbst hat. Das Erkennen, worin sich Pull und Push diesbezüglich unterscheiden, ist wichtig für das Verständnis sowie für die Weiterentwicklung. Beide Methoden wurden bereits erläutert, deshalb wird mehrheitlich nur auf den Effekt bzw. deren Auslöser eingegangen. In der Praxis gibt es häufige Diskussionen darüber, ob nicht beide Varianten dem Pull-Effekt unterliegen. Tatsächlich ist das eine berechtigte Frage. An dieser Stelle wird deshalb empfohlen, sich beide Varianten – am besten in der gleichen Unternehmung – direkt anzuschauen. Erfahrungen zeigen, dass der Betrachter den Unterschied auf diese Art und Weise sofort realisiert.

5  Kanban: Ursprung, Gemeinsamkeiten, Unterschiede, Wirkungsweise

63

Tab. 5.1  Der Pull- und Push-Effekt Kanban – Lean/Pull (Ziehen)

Kanban – Agile/Push (Schieben)

Der Regelkreis ruht so lange, bis ein interner oder externer Kunde den Impuls aussendet, dass er etwas benötigt. Die vorgelagerten Stellen agieren nach dem gleichen Prinzip. Fehlt ein Bestandteil oder eine Information, wird dies zu sich gezogen. Der Kunde zieht somit seinen Wunsch zu selbst zu sich. Das System ist so ausgelegt, dass niemand etwas Zusätzliches einschieben muss. Neuerungen oder Veränderungen lassen sich in diesem Kanban nur mit viel Mehraufwand bearbeiten, da auf die Massenfertigung ausgelegt

Der Kundenwunsch wird gemäß den Vorstellungen der Entwickler auf Karten aufgeteilt. Diese werden von den bearbeitenden Leuten nach Erledigung selbst nach Vorne oder allenfalls nach Hinten geschoben. Der Kunde gibt den Auftrag, aber setzt keinen direkten Zug-Impuls. Es ist kein System vorhanden, welches dies ermöglicht. Deshalb schieben die Beteiligten die einzelnen Teile zum Kunden hin. Neuerungen oder Veränderungen lassen sich rasch einbinden, da kein standardisierter Rahmen vorhanden ist

5.10 KVP, Kaizen, ständige Verbesserung Mit dem Ende dieses Kapitels wird auf den wohl wichtigsten Teil hingewiesen: Die ständige Verbesserung. Ob es um Qualitätsmanagement, um Qualitätsnormen, Lean oder Agile geht, alle stellen die Basis auf dem KVP ab, dem Kontinuierliche Verbesserungs-Prozess. Wobei hierbei die Bandbreite der Auslegung dieses Begriffes stark auseinanderdriftet. Während der KVP einen Prozess darstellt, ist Kaizen eine reine Denkweise/-haltung. Durch die Vermischung in der Literatur werden beide Begriffe synonym verwendet, was jedoch nicht zu empfehlen ist. Denn Kaizen verbindet den KVP mit einer sehr wichtigen Sache, dem Respekt. Was damit gemeint ist und wie dieses Wissen für beide Methoden, ja grundsätzlich für jede Arbeit verwendet werden kann, wird nachfolgend kurz erläutert. Um das Jahr 2000 herum wurde eines der „Geheimnisse“ von Toyota für Nicht-Japaner aufgeschrieben und bekannt gemacht. Bekannt geworden als der „Toyota-Weg“. Dieser besteht aus zwei Säulen oder besser aus zwei Kreisen. Ein Kreis steht für den Respekt gegenüber allen Beteiligten, der andere Kreis für den Prozess der kontinuierlichen Verbesserung. Ganz besonders im Lean-Bereich wird der Respekt oft vergessen, was zum „Fake Lean“ führt. Der Anwendung von Methoden ohne Mindset, ohne Herz und ohne Verständnis darüber, was wirklich wichtig ist. Der Respekt hat verschiedene Aspekte und Tiefen – nicht nur in Japan – deren Erklärungen den Rahmen sprengen würden. Zusammengefasst kann gesagt werden, dass jeder Mensch mit größtem und ehrlichem Respekt behandelt werden sollte. Das gilt für den Kunden, den Lieferanten, die Mitarbeitenden sowie allen anderen Beteiligten. So ist es beispielslos, respektlos einen Lieferanten absichtlich im Preis zu drücken oder dem Kunden mehr als notwendig zu verrechnen. Ebenso zeugt es von einer schlechten

64

F. Jordan

­ altung, einen Mitarbeitenden als Wegwerfartikel zu sehen. Einzelpersonen, Teamkollegen, H Vorgesetzen, jeder Mensch ist wichtig in der Unternehmung sowie im Ablauf. Jeder ist so wahrzunehmen und zu behandeln. Der KVP ist eine rein methodische wie logische Vorgehensweise, um bestmögliche Resultate hervorzubringen. Was besonders in der DACH-Region teilweise bis an die Obergrenze des Möglichen ausgebaut wurde. Aber ohne den Respekt, wird das mögliche Potenzial niemals ausgeschöpft. Das Bindeglied – der Klebstoff – zwischen beiden Kreisen ist Kaizen. Die ­Haltung oder das Mindset jedes Beteiligten jeden Tag ein wenig besser zu werden, ­Veränderungen zu suchen und gemeinsam umzusetzen. Kaizen verbindet beide Seiten, was auf Dauer den maximalen Nutzen entstehen lässt. Somit kann gesagt werden: Egal, welche Variante oder Methode von Kanban angewandt wird. Alles steht und fällt mit dem gegenseitigen Respekt und dem Mindset der Beteiligten. Dies gilt ­generell für alles, was wir tun. Methoden sind vergänglich und austauschbar. Dies darf nie ­vergessen werden.

Frederic Jordan  ist selbstständiger Berater, Coach und Dozent mit langjähriger Erfahrung und ausgeprägter Expertise im Bereich des Lean und Change Managements. Er lebt und arbeitet in der Schweiz.

6

Scrum – in kurzen Iterationen zum Ziel Jan Fischbach

Zusammenfassung

Der agile Arbeitsrahmen Scrum (engl. für Gedränge) von Jeff Sutherland und Ken Schwaber ist sehr populär. Dieser Arbeitsrahmen wirkt mit drei Rollen, drei sog. Artefakten und fünf Ereignissen sehr einfach. Trotzdem tun sich viele Organisationen im Alltag schwer, echte Scrum Teams zu bilden. Daher lohnt sich ein Blick auf die Hintergründe.

6.1 Scrum im Überblick Scrum ist im sog. Scrum Guide beschrieben. Jeder kann sich den Guide in deutscher oder englischer Sprache kostenlos und ohne Registrierung herunterladen1. Scrum sieht bestimmte Rollen, Artefakte und Ereignisse vor (Abb. 6.1 und 6.2). Kern von Scrum sind interdisziplinäre Entwicklungsteams (engl. Development Team). Ein Entwicklungsteam ist so zusammengesetzt, dass es als Ganzes in kurzen Abständen Ergebnisse liefern kann. Inhaltlich wird die Arbeit von einem Produktverantwortlichen (engl. Product Owner) gesteuert. Er sortiert die Ideen, bringt sie in eine gute Reihenfolge und bereitet sie so vor, dass sie umgesetzt werden können. Der Scrum Master achtet darauf, dass sich die Beteiligten an die Empfehlungen des Scrum

1Siehe

http://scrumguides.org.

J. Fischbach ()  Common Sense Team GmbH, Karlsruhe, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_6

65

66

J. Fischbach

Product Owner

Development Team

Scrum Master

€ Zusammen: Scrum Team Abb. 6.1  Rollen in Scrum

Sprint-Ziel Zu tun

PBI Product Backlog

In Arbeit

Fertig 1

2 3

Aufgabe

Sprint

Inkrement

Sprint Backlog

Abb. 6.2  Artefakte in Scrum

Guides halten. Er coacht, räumt Hindernisse aus dem Weg und kümmert sich um stetige ­Verbesserung. Der Product Owner sammelt alle Ideen in einer Anforderungsliste, dem Product Backlog. Für einen Sprint wird ein konkreter Umsetzungsplan, das Sprint Backlog erarbeitet. Am Ende eines Sprints sieht sich Scrum Team den aktuellen Stand, das sog. Inkrement an. Die Arbeit in Scrum wird auf mehrere Sprints aufgeteilt. Alle Sprints sind gleich lang. Jeder Sprint beginnt mit einem Sprint Planning, in dem das Sprint Backlog erstellt und das Sprint Ziel festgelegt wird. Jeden Tag trifft sich das Entwicklungsteam, um festzustellen, ob es das Sprint Ziel noch erreicht. Am Ende gibt es die Ereignisse Sprint Review und Sprint Retrospektive. Im Review sieht sich das Scrum Team das Produkt an, in der Retrospektive den Arbeitsprozess. Die Retrospektive dient dazu, Verbesserungsideen zu formulieren, die im nächsten Sprint konkret umgesetzt werden. Alle Ereignisse (Abb. 6.3) sind in der Länge begrenzt, um ein zügiges Abarbeiten zu fördern.

6  Scrum – in kurzen Iterationen zum Ziel

67

Abb. 6.3   Ereignisse in Scrum Sprint Planning Max. 8 h

Daily Scrum Max. 15 min. Sprint 1-4 Wochen

Sprint Retrospektive Max. 3 h

Sprint Review Max. 4 h

Im Vergleich zu anderen Arbeitsweisen gibt der Scrum Guide sehr konkrete Empfehlungen für die Zusammenarbeit: legt die drei Rollen fest, legt eine Taktung fest und plant die Scrum Ereignisse entsprechend. Nutzt die Artefakte, um die Arbeit zu planen und den Fortschritt zu bewerten. Scrum ist einfach zu lernen, aber schwer zu meistern. Wer zum Erreichen seiner Ziele Scrum nutzen will, hat einen Vorteil, wenn er die Hintergründe versteht.

6.2 Ist die Lage wirklich linear und überschaubar? Dietrich Dörner hat ein gutes Buch2 über unseren Umgang mit komplexen Problemen geschrieben. Er beobachtete Testpersonen bei elektronischen Planspielen. Unser Gehirn mag besonders gern lineare und überschaubare Vorgänge. Das wird in komplexen Situationen schwierig, weil unser Gehirn weiterhin lineare und einfache UrsacheWirkungs-Beziehungen vermutet. Dörner fasst unsere Unzulänglichkeiten im Umgang mit komplexen Problemen so zusammen: • • • • • • • •

Ziele werden nicht konkretisiert. Widersprüchliche Ziele werden nicht als solche erkannt. Es werden keine klaren Schwerpunkte gebildet. Modelle werden entweder gar nicht oder nur unzureichend gebildet. Informationen werden nur einseitig oder unzulänglich gesammelt. Zeitverläufe werden falsch aufgefasst. Es wird falsch oder gar nicht geplant. Fehler werden nicht korrigiert.

2Siehe

Dörner, Dietrich. Die Logik des Misslingens: Strategisches Denken in komplexen Situationen. Rowohlt Verlag GmbH, 2011.

68

J. Fischbach

Hinzu kommt, dass wir uns in vielen Situationen in komplex-adaptiven System befinden. In komplexen Systemen sind Ursache und Wirkung nicht einfach erkennbar. Ein adaptives System kann bis zu einem gewissen Grad Impulse von außen kompensieren. Es sieht also so aus, als hätten bestimmte Aktionen keine Effekte. Um das Verhalten von solchen Systemen zu verändern, braucht es Änderungen, die an den Systemdynamiken selbst ansetzen. Soziale Systeme wie Unternehmen oder Verwaltungseinheiten sind ebenfalls komplex-adaptive Systeme. Der Appell, man möge doch bitte schneller arbeiten, verpufft deshalb. Wie geht man mit solchen Systemen um, wenn einem der stabile Systemzustand nicht gefällt? Diese Frage beschäftigte Jeff Sutherland und seine Kollegen seit Mitte der 1980er Jahre. Verschiedene Versuche haben schließlich zu dem geführt, was wir heute Scrum nennen.

6.3 Wie schätzt man Situationen ein? Ein erster Schritt in Richtung Agilität ist unsere eigene Fähigkeit, zwischen verschiedenen Situationen zu unterscheiden. Das in diesem Buch schon öfter zitierte Cynefin-­Framework3 von David Snowden ist ein Modell, um Situationen und das Verhalten von Systemen abzuschätzen. Es definiert fünf unterschiedliche Umgebungsarten: • Einfache Umgebungen (engl. simple contexts): einfache Umgebungen sind stabil und Ursache-Wirkungsbeziehungen sind klar zu erkennen. • Komplizierte Umgebungen (engl. complicated contexts): in komplizierten Umgebungen kann es oft mehrere richtige Antworten geben. Es gibt zwar klare Ursache-Wirkungsbeziehungen, aber nicht jeder sieht diese Zusammenhänge. • Komplexe Umgebungen (engl. complex contexts): in komplexen Umgebungen gibt es keine allgemein akzeptierte Wahrheit. Das ganze System ist in ständiger Bewegung. Warum Dinge passieren, lässt sich erst im Nachhinein erkennen. Neue Dinge und neue Muster ergeben sich mit der Zeit (Emergenz). • Chaotische Umgebungen (engl. chaotic contexts): in chaotischen Umgebungen ist es sinnlos nach der richtigen Antwort zu suchen. Weil das System ständig in Veränderung ist, ist es nicht möglich, Wirkungen und ihre Ursachen zu erkennen. • In der fünften Umgebungsart (engl. disorder) herrscht einfach nur Unordnung. Das Schwierige ist, zu erkennen, dass man gerade in dieser Situation ist.

3Siehe

Snowden 2007: David J. Snowden & Mary E. Boone: A Leader’s Framework for Decision Making. In: Harvard Business Review. November 2007, S. 69–76.

6  Scrum – in kurzen Iterationen zum Ziel

69

In einfachen und komplizierten Umgebungen kann man gut planen. Aber in komplexen Situationen verändert sich das System selbst immer wieder. Wer erfolgreich sein will, schafft es irgendwie, schnell genug zu reagieren und seinen Plan anzupassen. Im Kontext von Projekten können wir uns bei Aaron Shenhar und Dov Dvir bedienen. Die beiden Herren haben viel über den Zusammenhang von Planung und Projekterfolg geschrieben. Das Buch „Reinventing Project Management“4 ist eine gut lesbare Zusammenfassung ihrer Tätigkeit. Ein Projekt zu führen bedeutet, Ergebnisse unter Unsicherheit zu liefern. Wir kennen viele Formen von Unsicherheit. Interessant ist, dass Shenhar und Dvir von – nur – vier Arten von Unsicherheit ausgehen: • Neuartigkeit: Wie gut kann der Kunde beschreiben, was er will bzw. wie gut kann der Lieferant darstellen, was er liefert? • Technologie: Wie gut kennt sich das Umsetzungsteam mit den Techniken, Methoden, Systemen oder Werkstoffen aus, die es benutzt, um das Projektproblem zu lösen? • Komplexität: Wie stark hängt die Funktionsfähigkeit des Gesamtergebnisses von der Integration der Einzelleistungen der Umsetzer ab? Wie stark müssen sich die Beteiligten abstimmen, damit das Ganze funktioniert? • Zeitdruck: Wie hoch ist der echte Zeitdruck, d. h. wie hoch ist der Schaden, wenn nicht rechtzeitig reagiert wird? Ihre Empfehlung: je höher die Unsicherheit ist, desto häufiger brauchen wir nützliches Feedback, um die nächsten Schritte festzulegen. Und damit kommen wir zu Scrum.

6.4 Sprints sind dazu da, um regelmäßig Feedback einzuholen Ein wichtiges Element von Scrum sind die sog. Sprints mit einer maximalen Länge von einem Kalendermonat. Dabei sind Sprints nicht mit einer Projektphase, sondern mit einer Taktung gleichzusetzen. Die Länge des Taktes orientiert sich an den Projektrisiken und an anderen Ereignissen in der Organisation. Je höher die Risiken sind, desto kürzer sollte die Taktung sein. Eine Sprintlänge von zwei Wochen bedeutet, dass sich das Scrum Team alle zwei Wochen zusammensetzt. Es stellt fest, wo es wirklich steht und wie die Planung für die nächsten zwei Wochen aussieht. Sutherland und seine Kollegen beobachteten, dass die Entwickler ihre Zeit in sehr vielen Besprechungen verbrachten. Um aber Dinge abzuschließen, war es nötig, die Zahl der Besprechungen drastisch zu reduzieren. Welche Besprechungen sind unbedingt nötig, um das Liefern von Ergebnissen zu steuern? 4Siehe

Shenhar und Dvir 2007: Shenhar, Aaron J., und Dov Dvir. Reinventing Project Management: The Diamond Approach to Successful Growth & Innovation. 1st ed. Mcgraw-Hill Professional, 2007.

70

J. Fischbach

Jeder Sprint beginnt mit einem Sprint Planning und der Vereinbarung eines SprintZiels. Jeder Sprint endet mit einem Sprint Review und einer Sprint Retrospektive. Im Review sieht sich Scrum Team zusammen mit anderen wichtigen Feedbackgebern den aktuellen Stand an und spricht über die weitere Entwicklung. In der Retro sucht es nach 1–2 Verbesserungsmaßnahmen, um die Lieferfähigkeit im nächsten Sprint zu erhöhen. Dazwischen treffen sich die Umsetzer täglich im sog. Daily Scrum, damit sie das Sprintziel nicht aus den Augen verlieren. Das häufige Feedback und die darauf folgenden Anpassungen machen es möglich, dazu zu lernen und Fehler zu korrigieren. Die Beteiligten können Zusammenhänge testen und ihre Planung modifizieren.

6.5 Scrum definiert nur drei Rollen: Entwicklungsteam, Product Owner und Scrum Master Kommen wir zur Ausgangsfrage zurück: Wie ändert man ein stabiles System? ­Sutherland und seine Kollegen wussten aus Forschungsergebnissen, dass die Produktivität sinkt, je mehr unterschiedliche Rollen beteiligt sind. Sie wussten auch, dass ein gutes Team aus 3–9 Personen besteht. Um Komplexität zu reduzieren, wurde ein interdisziplinäres Entwicklungsteam aus den Experten gebildet, die ein funktionierendes Ganzen bauen konnten. Aus einem Aufsatz aus dem Harvard Business Review über Produktentwicklung5 wusste man ebenfalls, dass gute Teams gemeinsam am Ergebnis arbeiten (statt einzelne Spezialisten nacheinander zu beauftragen). Damals wurde der Teamleiter damit beauftragt, die neuen Abläufe zu überwachen, damit das Scrum Team nicht in alte Gewohnheiten zurückfällt. Zudem sollte er das Team zu kontinuierlicher Verbesserung anhalten. Aus diesem Teamleiter wurde die Rolle Scrum Master. Das Scrum Team hatte aber noch keinen Weg gefunden, mit den ganzen Ideen umzugehen, die in sein Produkt einfließen sollten. Aus diesem Grund wurde eine Person gebeten, sich in die Rolle eines internen Unternehmers zu versetzen. Dieser Unternehmer sollte sich überlegen, welche Ideen das Produkt erfolgreich machen. Er musste sich am wirtschaftlichen Erfolg messen lassen. So entstand die Rolle Product Owner. Seine Arbeit besteht vor allem darin, Ideen zu verfeinern und in eine Reihenfolge zu bringen. Durch die bewusste Festlegung von Rollen wurde das Systemverhalten manipuliert. Statt individueller Ziele für jeden Mitarbeiter gab es nun gemeinsame Ziele für das ScrumTeam. Statt die einzelnen Mitglieder im Team zu stören, liefen alle Gesprächsfäden beim

5Siehe

Takeuchi, H., und I. Nonaka. „The new new product development game.“ Harvard Business Review (1986).

6  Scrum – in kurzen Iterationen zum Ziel

71

Product Owner zusammen. Der Product Owner legt Schwerpunkte für die Arbeit fest. Aber wie geht das praktisch? Dazu gibt es drei sog. Artefakte.

6.6 Product Backlog, Sprint Backlog und Inkrement In einfachen Umgebungen kann eine Kunde sehr gut beschreiben, was er möchte. In einfachen Umgebungen kann ein Projektteam gut beschreiben, wie es sein Projektproblem löst. In komplexen Umgebungen ist das anders. Wir können viel aus dem Bereich der Softwareentwicklung lernen, weil dieser Bereich ein Beispiel für komplexe Umgebungen ist. In solchen Situationen kann der Auftraggeber nicht 100%ig spezifizieren, was er möchte. Hadar Ziv hat sich das genauer angesehen und dazu einen Beitrag veröffentlicht6. Die Kernaussage ist, dass Spezifikationen niemals vollständig verstanden werden können („Ziv’s Law“). Peter Wegner hat einen Betrag veröffentlicht, in dem er beschreibt, dass sich interaktive Systeme nie vollständig durch Algorithmen beschreiben und damit auch nicht vollständig testen lassen („Wegner’s Lemma“)7. Wie gehen wir also mit einem Problem um, dessen Merkmale und dessen Lösung wir nicht vollständig beschreiben können? Scrum wählt hier einen einfachen Weg: sammelt alle Ideen in einer Liste und passt diese Liste an, wenn ihr dazugelernt habt. Diese Liste ist das Product Backlog. Damit die Ideen abgearbeitet werden können, legt der Product Owner die Reihenfolge der Ideen fest. Was am wichtigsten ist, steht oben. Das, was am wichtigsten ist, wird auch als nächstes so gut vorbereitet, dass es bearbeitet werden kann. In der Sprint Planung erstellt das Entwicklungsteam einen Plan, der zeigt, wie es das Sprintziel erreicht. Neben den Ideen aus dem Product Backlog – den einzelnen Product Backlog Items (oder User Storys) – finden sich in diesem Plan alle Einzelaufgaben zur Umsetzung. Das ist das Sprint Backlog. Während das Product Backlog mithilfe einer Tabellenkalkulation verwaltet wird, ist das Sprint Backlog eine große Tafel, auf der alle Beteiligten sehen können, wie gearbeitet wird. In komplexen Situationen brauchen wir Feedback. Das Entwicklungsteam erstellt zu diesem Zweck ein Inkrement. Das Inkrement ist eine passende Form von Zwischenstand, die im Review begutachtet werden kann. Das Inkrement soll das Gespräch anregen. Es soll uns zeigen, wie gut wir unsere Ziele erreichen.

6Siehe

Ziv, Hadar, Debra Richardson, und Rene Klösch. „The uncertainty principle in software engineering.“ submitted to Proceedings of the 19th International Conference on Software Engineering (ICSE'97). 1997. 7Siehe Wegner, Peter. „Why interaction is more powerful than algorithms.“ Communications of the ACM 40.5 (1997): 80–91.

72

J. Fischbach

6.7 Scrum will die interne Organisation verbessern Wir hören immer wieder, das Scrum eine IT-spezifische Methode sei, die nicht zum normalen Alltag in einer großen Organisation passe. Scrum ist nicht entstanden, weil die ersten Scrum Teams ein Softwareproblem zu lösen hatten. Scrum ist entstanden, weil das Softwareproblem der Teams ein komplexes war. Die Frage ist also nicht, ob mein Problem ein IT-Problem ist. Die Frage ist, ob mein Problem einfach oder komplex ist. Wenn es komplex ist, können wir uns an den Empfehlungen des Scrum Guides orientieren. Die Frage ist auch nicht, wie man Scrum einführt. Die Frage ist, wie wir das aktuelle Arbeitssystem so modifizieren können, dass wir unsere komplexen Probleme lösen können. In dieser Hinsicht stellt der Scrum Guide oft unser bisheriges Denken infrage. Eine mechanische Sicht auf einen „Scrum-Prozess“ reicht nicht, um grundsätzliche Veränderungen in der Organisation auszulösen. Es reibt die Mitarbeiter und Führungskräfte nur noch mehr auf, weil sie den Erwartungen, die Agilität vermeintlich verspricht, nicht gerecht werden.

6.8 Scrum an einem Beispiel Sehen wir uns dazu ein softwarenahes Beispiel an. Eine Verwaltungseinheit beschließt, ein Dokumentenmanagementsystem (DMS) einzuführen. Der Anlass waren mehrere Korruptionsfälle, die zeigten, dass die internen Kontrollsysteme nicht wirksam waren. Der Projektauftrag ist nicht, eine DMS-Software technisch einzuführen. Der Projektauftrag ist, auf Basis einer gemeinsam genutzten DMS-Software die Abläufe so zu verändern, dass die internen Kontrollmechanismen wieder wirken können. Das Projekt ist nicht fertig, wenn alle Anwender die neue Software benutzen können. Das Projekt ist fertig, wenn alle Anwender sie tatsächlich benutzen. Ist dies ein einfaches oder komplexes Problem? Folgen wir den Vorschlägen von Shenhar und Dvir, stellen wir eine höhere Unsicherheit in drei Bereichen fest: • Neuheit: Wir lösen kein bestehendes System ab. Wir wissen zwar im Prinzip, was ein DMS ist, aber wir kennen nicht alle Details. • Technologie: Die Umsetzer kennen sich zwar grundsätzlich mit der Technologie aus, aber nicht im Detail. Signifikante Teile und Vorgaben sind neu. Die Umsetzer ­brauchen mehrere Zyklen, um festzustellen, was ein gutes Design ist. • Komplexität: Wir arbeiten mit einem neuen Lieferanten zusammen, dessen Sprache wir nicht verstehen. Um zu wissen, ob das DMS wirklich effektiv die internen Kontrollen unterstützt, müssen wir viel lernen. Nur durch schnelles und häufiges Feedback lernen die Beteiligten, ­worauf sie besonders achten müssen. Wie können wir die Rollen besetzen? Wer profitiert am meisten vom Ergebnis? In diesem Fall wäre es wohl eine Führungskraft. Vielleicht ein Bereichsleiter oder ein

6  Scrum – in kurzen Iterationen zum Ziel

73

Geschäftsführer. Hat diese Person Zeit, um Anforderungen zu formulieren und zu priorisieren? Wenn ja, übernimmt sie die Product Owner Rolle. Wenn nicht, muss sie einen Stellvertreter finden, mit dem sie sich eng abstimmt. Was steht im Product Backlog? Dort werden nicht die technischen Umsetzungsschritte aufgelistet. Stattdessen werden die wesentlichen Geschäftsprozesse aufgeführt, bei denen wir eine wirksame Kontrolle brauchen. Dies betrifft vor allem die Vergabe von größeren Aufträgen. Wer ist im Umsetzungsteam? Im Umsetzungsteam brauchen wir nicht nur IT-­Spezialisten. Wir brauchen Fachanwender, die die neuen Prozesse sinnvoll gestalten. Sie experimentieren mit der neuen DMS-Software, um ein gutes Maß zwischen Freiheit und Vorgaben zu finden. Vielleicht brauchen wir auch Experten für Datenschutz, Compliance oder Korruptionsprävention. Sicherlich wird die Zusammensetzung des Teams sich mit der Zeit verändern, weil unterschiedliche Geschäftsprozesse von der Software unterstützt werden. Aber es wäre ganz gut, wenn 1–2 Teammitglieder das Projekt kontinuierlich begleiten. Brauchen wir einen Scrum Master? Abgesehen davon, dass diese Rolle das Team durch den Scrum-Prozess führt, hat der Scrum Master eine wichtigere Aufgabe: Dinge infrage stellen. Wem vertrauen Product Owner und Team so weit, dass sie sich unangenehme Fragen gefallen lassen? Was ist das Inkrement? Das Inkrement dient dazu, sich Feedback zu holen. Wir wollen wissen, ob wir wie geplant weitermachen können oder ob wir nachregeln müssen. Deshalb besteht das Inkrement nicht nur aus einer erweiterten Software. Dazu gehören auch die veränderten internen Richtlinien. Qualität bedeutet nicht nur, dass die Technik fertig ist. Dazu gehört mehr. Zum Beispiel: • • • • • • • •

Die Software ist aktualisiert. Alle Menüs wurden mit sinnvollen Vorgabewerten gefüllt. Die veränderten Abläufe wurden an verschiedenen Beispielen getestet. Die betroffenen Bereiche waren an der Prozessgestaltung beteiligt. Die rechtlichen Vorgaben sind bekannt und wurden umgesetzt. Vorgänge sind im Rahmen der rechtlichen Vorgaben nachvollziehbar und dokumentiert. Kritische Vorgänge fallen auf, sodass Führungskräfte wissen, dass und wie sie reagieren. Die Benutzer der betroffenen Bereiche haben Zugriff und sinnvolle Zugriffsrechte.

Nur wenn echte Anwender das neue System benutzen, wissen wir, ob es wirklich f­ unktioniert. Wie viel Zeit sollten die Umsetzer in dieses Projekt stecken? Sollen sie Vollzeit oder nur zeitweise mitarbeiten? Das Unsicherheitsprofil zeigt, dass man solch ein Projekt nebenbei mitmachen könnte8. Die Umsetzer können sich an die normalen Entscheidungsmechanismen hängen.

8Anders

sieht es aus, wenn es harte zeitliche Vorgaben gäbe. Das wäre der Fall, wenn eine ­Aufsichtsbehörde anordnen könnte, die Organisation zu schließen.

74

J. Fischbach

Um diese Fragen zu beantworten, müssen wir uns darüber Gedanken machen, was eigentlich der geschäftliche Nutzen (engl. business value) ist. Unabhängig von dem politischen und finanziellen Schaden beim Auftreten von weiteren Korruptionsfällen, stellen wir weitere Effekte fest. Entlassene Mitarbeiter müssen ersetzt werden. Entweder wird die Arbeit auf die bisherigen Mitarbeiter verteilt oder es werden neue Mitarbeiter eingestellt. Wenn die bisherigen Mitarbeiter die Arbeit übernehmen: gibt es wichtige Vorgänge, die nun liegen bleiben? Wie lange dauert es, bis Mitarbeiter Fehler wegen Überlastung machen? Verzögern sich Durchlaufzeiten? Wenn neue Mitarbeiter eingestellt werden: Wie lange dauert die Einarbeitung? Wer übernimmt die Einarbeitung? Welche Vorgänge müssen wegen der Einarbeitung warten? Wie bewertet man das Betriebsklima? Stehen jetzt alle Mitarbeiter unter Generalverdacht der Korruption? Bewerben sich Mitarbeiter weg? Werden sie krank? Es kann also viel passieren, bis die neue Software funktioniert. Im Zweifel sollten Sie sich für eine kürzere Taktung und für einen höheren Zeitanteil entscheiden. Ein Team schafft mehr Ergebnisse, wenn es vier Wochen halbtags zusammenarbeitet, als wenn es die halben Tage auf zwanzig Wochen verteilt.

6.9 Zusammenfassung Scrum ist populär, weil es einen einfachen überschaubaren Rahmen für agiles Arbeiten bietet. Wer Scrum erfolgreich einsetzt, versteht die Hintergründe für die Rollen, die Ereignisse und die Artefakte. IT-Projekte können mit Scrum bearbeitet werden. Im Product Backlog stehen aber nicht technische Aufgaben, sondern Geschäftsprozesse, die künftig anders ablaufen.

Jan Fischbach hilft als Berater, Scrum Master und Trainer Teams und Organisationen dabei, agiler zu werden. Nach dem Studium der Elektrotechnik war er in verschiedenen Fach- und Führungspositionen bei einer Unternehmensberatung und bei IT-Serviceunternehmen tätig. Heute ist er Geschäftsführer der Organisationsberatung Common Sense Team GmbH in Karlsruhe und Trainer für die HLSC GmbH in Stuttgart. Jan Fischbach schreibt regelmäßig im Teamworkblog. Er lebt an der Nordseeküste.

7

Rollen und situative Funktionen agil souverän eingesetzt Veronika Lévesque

Zusammenfassung

In den verschiedenen Kapiteln dieses Buches sind diverse Methoden und Aspekte agilen Arbeitens Thema. Wichtig ist bei vielen dieser methodisch-organisatorischen Ansätze, dass sie agiles Arbeiten ermöglichen, ohne zwingend in Widerspruch oder Konkurrenz zur gegebenen Struktur einer Behörde zu treten. Es ist möglich, grundlegend agil zu handeln und dabei Bestehendes nicht in komplett auf den Kopf zu stellen. So können sich Wege öffnen, ohne Brücken abzubrechen. Ein Beispiel für solche Herangehensweisen ist die Organisation der Arbeit entlang von Rollen und situativen Funktionen. Dazu gehören zum Beispiel • temporäre Teams als Lösungsansatz und Lernplatz im Umgang mit Veränderung • Tandems mit geteiltem Lead von zwei (oder mehr) Personen mit unterschiedlicher Fachlichkeit • die Etappierung des Leads je nach Schwerpunkt der aktuellen Arbeitslage Eine der großen Schwierigkeiten in der Auseinandersetzung mit Neuerungen ist der Schutz des Vorhandenen. So schwierig der bestehende Alltag sein mag, so sehr hat er einen gewichtigen Vorteil: Man kennt ihn. Man hat Strategien und Reflexe entwickelt, die „mehr oder weniger aber immerhin“ funktionieren. Was passieren wird, ist in einem gewissen Maß berechenbar – und „lieber weiß ich, dass es mühsam und schwierig ist, als dass ich gar nicht einschätzen kann was passiert.“

V. Lévesque (*)  Forum Agile Verwaltung e. V., Basel, Schweiz E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_7

75

76

V. Lévesque

Abb. 7.1  Raumsoziogramm

Hier liegt ein wichtiger Aspekt im Umgang mit Agilität, wenn sie neu eingeführt wird. Soll eine gesamte Verwaltung sich auf ein neues „Betriebssystem“ einstellen, wachsen mit den Ansprüchen an „alles anders“ auch der Widerstand und der Beharrungswille. Und die Frage stellt sich, wer wie während der Umstellungszeit auf „das Neue“ eigentlich die Arbeit macht …? Wenn es aber gelingt, einzelne Aspekte agiler Arbeitsweisen in die bestehenden Vorgänge und Strukturen aufzunehmen und sie funktionieren dann, dann tut Entwicklung und die damit einhergehende Veränderung vielleicht weniger weh (Abb. 7.1).

7.1 Temporäre Teams In neuen, temporären Zusammensetzungen als multiprofessionelles Team in Kontakt mit anderen Sichtweisen zu kommen, ist, selbst wenn manchmal vor allem zu Beginn ungewohnt und schwierig, doch auch hilfreich, hoffentlich lösungsnützlich und vielleicht auch bereichernd – und erhöht kurz- und auch mittelfristig das Systemwissen ungemein. Kurzgefasst, könnte man es so ausdrücken: …Wenn ich weiß, was ich tue, und was die anderen tun und wie und warum so, dann ergeben sich neue Handlungsvarianten. Und da es ja ein temporäres Team ist, ist es auch nicht gar so gefährlich, sich für gewisse Zeit darauf einzulassen. Versuchen und ­ausprobieren, immer

7  Rollen und situative Funktionen agil souverän eingesetzt

77

wieder justieren und anpassen. Mit dem Rest meiner Zeit kann ich mich immer noch am Bekannten orientieren und meine gewohnte Arbeit verrichten. Ich kann dann herausfinden, was ich im Koffer sicher mitnehmen möchte, weil es auf dem Weg egal wohin nicht verloren gehen darf, und was ich zugunsten des Neuen zurücklassen werde können. ….

Persönliche Erfahrung mit Vorgehensweisen – und im Idealfall sogar positive – sind ein wunderbares Mittel, mit Ängsten vor dem Verlust der bewährten Strategien und Reflexe umzugehen. Gleichzeitig im bekannten Jetzt und mit dem anderen Fuß in einer möglichen Zukunft zu agieren, hilft dabei, vertraut und kompetent zu werden im Umgang mit beiden. Denn die Zukunft hat immer heute schon angefangen.

7.2 Beispiele für temporäre Teams 7.2.1 Tandems Zuständige Tandems im Lead für eine Aufgabe oder ein Vorhaben können auf dem Weg, die Automatismen der starren Zuständigkeit, Führung und Funktionen zu lockern, unterstützen. Die Leitung eines zeitlich begrenzten Projekts, einer Projektphase oder eines Geschäftes mit einer Doppelspitze zu besetzen, kann ein Zwischenschritt hin zu zuständigen, selbst organisierten Teams sein. Wichtig dabei: Praxisnah und situationsadäquat. Um das Feld aufzuspannen und breit an ein Thema zu gehen, eignen sich polare Tandems (z. B. aus Stab einerseits und Linie anderseits). Für den Einbezug oder die Entwicklung von Netzwerken oder partizipativen Prozessen können komplementäre Paarungen, die sich ergänzen und integrierend wirken können, hilfreich sein. Und wenn es zum Beispiel um Innovationswege geht, könnten es auch situative oder gar personenbezogene Kombinationen sein. Hier liegt Spielraum.

7.2.2 Etappierte Leads In einem, nennen wir es „Verlaufsteam“, finden sich verschiedene Abteilungs- oder Anspruchsgruppenvertretende – und das heißt ja immer auch Experten – zusammen. Sie haben sich bereits darauf eingelassen, gemeinsam an einer Problemlösung, an einem Geschäft, an einem Querschnittsthema oder an einem Projekt zu arbeiten. Sie haben im Rahmen des Anliegens aufgrund ihrer Funktionen eine Rolle erhalten. Selbstverantwortliche Teams ohne innere Hierarchien sind ein hoher Anspruch. Es gehört viel gegenseitiges Vertrauen dazu. Auch ist das eigene Arbeiten ohne vorgesetzten Anführer und ohne untergeordnete Ausführenden durchaus nicht einfach so machbar, wenn man andere Strukturen gewöhnt ist und gelernt hat, sich auf Hierarchien zu verlassen. Hier braucht es neben dem Willen auch Übung, Erfahrung und Zeit zum Lernen. Wo sollen die nun herkommen?

78

V. Lévesque

In Anerkennung der unterschiedlichen Expertisen der verschiedenen Mitglieder eines Verlaufsteams könnte anstelle eines selbst organisierten Teams ohne Lead, je nach dem derzeitigen Arbeitsschwerpunkt des Teams, der Lead wechseln. Geht es zum Beispiel um eine Konzeptentwicklung, könnte während der Voranalyse und der Erhebung des IST-­ Zustands eine Person aus dem Stab den Lead übernehmen und die Arbeiten des Teams koordinieren. Wenn die inhaltliche Modellentwicklung ansteht, wandert der Lead weiter an ein Teammitglied mit der entsprechenden Fachlichkeit – die anderen arbeiten ihm zu. Sobald es darum geht, das nun schon recht weit gedrungene Konzept umsetzungs- oder publikationsreif zu machen, übernimmt mit Unterstützung des Teams jemand aus dem Amt, das später hauptsächlich umsetzen wird oder aber vielleicht ein Teammitglied aus dem Referat Öffentlichkeitsarbeit den Lead. Kurz zusammengefasst: • Für die IST-Darstellung jemand analysestarkes aus Stab X. • Während der Modellentwicklung des neuen Konzeptes jemand fachstarkes aus Abteilung A. • Für die Redaktion der Vorlage jemand schreibstarkes, nämlich Person YZ. • Für die Begleitung des politischen Prozesses jemand querschnittsstarkes vom Amt B • Und schlussendlich zur Umsetzung und Realisierung jemand umsetzungsstarkes aus der Dienststelle D, bei der das Thema im folgenden normales Tagesgeschäft sein wird. Die Auswahl wieder mit Blick auf die reale realistische Situation und das Ziel hin. Schon sehr früh, bei der Konstituierung des Teams, können solche Überlegungen eine Rolle spielen und bereits in der Planung den Umsetzungsaspekt verankern. Selbst in Verwaltungen, in denen Wasserfallprojekte oder Prozessvorgaben bestehen, können so erste Samen gestreut werden, die das Bestehende erfüllen und gleichzeitig Handlungsoptionen bieten. Und der hierarchische Sockel bleibt zwar erhalten, wird aber adaptiv – oder gar agil? – der jeweiligen Phase der Erarbeitung sinnvoll angepasst. Alle Mitglieder des Verlaufsteams haben durch den wechselnden Lead ein vertieftes Wissen zum laufenden Geschäft. Die Zusammenarbeitsform wechselt, aber alle sind mal Teammitglieder, mal im koordinierenden Lead. Im besten Fall bildet das Vertrauen. In jedem Fall konzentriert es die Arbeiten auf das Ziel und das Produkt hin. Seine Bedürfnisse stehen im Vordergrund und seine Umsetzung ist im Fokus – beide bestimmen die innere Organisation des Teams. Im Idealfall führt die etappierte Zuständigkeit vielleicht sogar auf Dauer dazu, dass sich eine hierarchiefreiere, stärker selbst organisierte Zusammenarbeit ohne Bedarf nach Leads einstellt (Abb.7.2).

7  Rollen und situative Funktionen agil souverän eingesetzt

79

Abb. 7.2   Struktur

Veronika Lévesque ist seit 1998 aktiv als Spezialistin für Organisationsentwicklung mit den Schwerpunkten Kokreation, adaptive Lösungsentwicklung, Change-Prozesse, Visualisierung, Projekt- und Prozessdesign und Koordination multiprofessioneller Teams sowie (Grossgruppen-) Moderation und (System-) Beratung. Seit 2003 ist sie in der Öffentlichen Verwaltung, vorher in den Branchen Bildungsmanagement, Spedition und Logistik, Softwareentwicklung und Personalberatung unterwegs. Besondere Interessen: Grenzgänge – zwischen Ländern genauso wie zwischen Aufgabenbereichen und Kontexten.

8

Skalierung – teamübergreifende Abstimmung Martin Bartonitz

Zusammenfassung

In diesem Kapitel wird am Beispiel von SCRUM eine Möglichkeit vorgestellt, wie mehrere parallel arbeitende Gruppen ohne zu großen Kommunikationsaufwand so koordiniert werden können, dass nicht aneinander vorbei gearbeitet wird und die für alle zuträglichsten Entscheidungen gefunden werden.

8.1 Einleitung Wer seine Organisation in Richtung auf agile, sich selbstorganisierende Teams transformieren will, fängt in der Regel mit einem Team an. Hat sich ein Team in das neue Regelwerk, z. B. in die SCRUM-Rituale gut eingefunden, werden weitere Teams entwickelt. Im Prinzip sollte das dann ein Selbstläufer werden, wenn das erste Team sich gut gefunden hat und begeistert über das neue Zusammenwirken berichtet. Teams sollten so gebildet sein, dass sie die Aufgabe, die sie übertragen bekommen, in großen Teilen unabhängig von anderen Teams erledigen können. In der Software-­ Entwicklung bedeutet dies, dass die Mitglieder unterschiedlichste Fähigkeiten einbringen. Es wird hier mit Blick auf die Anwendungsarchitektur von vertikaler Team-Bildung gesprochen: es braucht das Wissen darum, wie Datenbanken optimal anzusprechen sind, wie Services gebaut werden und wie Anwendungsoberflächen gestaltet werden.

M. Bartonitz ()  Produktmanagement, c/o OPTIMAL SYSTEMS GmbH, Berlin, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_8

81

82

M. Bartonitz

Ein Beispiel im öffentlichen Dienst wäre die Einführung von eGovernment, speziell Dokumentenmanagement. Ein solches Projekt kann bei großen Verwaltungen sehr komplex werden und mehrere Teilprojekte mit eigenständigen Teams umfassen: • Business Case aufstellen und pflegen (Leitungsteam); • Standards definieren: Aktenplan, Metadaten und Rechtemanagement; • rechtliche Anforderungen definieren: Informationssicherheit, Datenschutz, Compliance, Archivierung und Mitbestimmung; • DMS ausschreiben und beschaffen; • ersetzendes Scannen organisieren mit Schwerpunkt Posteingang der zentralen Einrichtungen und Services; • die technische Plattform bereitstellen und entwickeln; • das DMS an SAP anbinden; Nutzung zur Belegablage u. a. für Eingangsrechnungen, im Beschaffungsprozess und beim Reisekostenworkflow; • den Prozess „Baugenehmigungen“ ins DMS überführen (mit Anbindung an BAU3000); • den Prozess „Großprojekte“ ins DMS überführen (mit Anbindung externer Beteiligter); • den Prozess „Sozialfonds-Fördermittel einwerben“ ins DMS überführen (incl. Anbindung an die zentrale EU-Plattform); • und noch 40 weitere Prozesse. Die optimale Größe von sich selbst organisierenden Teams liegt je nach Tätigkeitsbereich zwischen 8 und 12 Mitgliedern. In diesen Teams ist eine umfassende Kommunikation das wichtigste Werkzeug, d. h. wenn alle Mitglieder einen guten Wissensstand über das haben, was gerade anliegt, werden die optimalen Lösungen gefunden. Was aber, wenn viele Teams im Unternehmen an Komponenten arbeiten, die sich am Ende zu einem Große und Ganzen zusammenfügen müssen. Erinnern wir uns an die Herkules-Aufgabe, die unsere Kommunen bei der Bewältigung der Flüchtlingsströme geleistet haben. Hier mussten sich ebenfalls viele Teams abstimmen, sodass die Übergaben reibungslos funktionieren konnten. Im Folgenden sollen beispielhaft die in SCRUM angewendeten Rituale erklärt werden, wie sich Abstimmungen zwischen den Teams organisieren lassen, ohne dass gleich alle Mitglieder aller Teams zeitraubend involviert werden müssen.

8.2 Scrum of Scrums (SoS) Im SCRUM haben sich für die Skalierung sogenannte Scrum of Scrum Meetings als nützlich herausgestellt. Diese SoS können seitens der beteiligten Product Owner genutzt werden, um die voneinander abhängigen Stories zwischen den Teams für die nächste Iteration gemeinsam abzustimmen. Sie können aber auch von Delegierten der Teams nach den täglichen Stand-Up-Meetings genutzt werden, um die abhängigen Stories zwischen den Teams im Tagesverlauf besser abzustimmen.

8  Skalierung – teamübergreifende Abstimmung

83

Die SoS der Product Owner finden in der Regel einen Tag vor dem Sprint-Wechsel sowie nach den Planning 2 der neuen Iteration statt. Im 1. Meeting werden die möglichen Abhängigkeiten geklärt. In den Plannings kann es aber dazu kommen, dass die Teams eine abhängige Story nicht mit in die nächste Iteration nehmen können. Dann brauchen auch die anderen Teams Bescheid, dass sie diese Änderungen entweder benötigen oder sie doch noch nicht angegangen werden können und stattdessen die nächste anstehende Story mit in den Sprint genommen wird.

8.3 Community of Practice (CoP) Neben den SoS, die sich auf die konkret anstehenden Aufgaben des nächsten Sprints beziehen, werden oft auch noch sogenannte Communities of Practice, kurz CoPs, eingerichtet. Hier treffen sich die Mitglieder der Teams, die an gleichen Themenschwerpunkten arbeiten. In der Software-Entwicklung seien beispielhaft die CoPs für Architektur, Continuous Integration, Test/QS, Datenstrukturen oder User Experience genannt. In anderen Bereichen ließe sich Themen wie Compliance/Recht, Standards, Kommunikation/Marketing oder Bürger-Integration einrichten. CoPs bilden sich häufig auch in den Unternehmen, in denen Teams parallel an eigenen Produkten arbeiten. Ziel ist dann i. d. R. der Wunsch, teamübergreifend voneinander zu lernen und Synergien nutzen zu können. CoPs werden in Unternehmen z. T. aber auch eingesetzt, um generell dem Thema „Agilität“ im Unternehmen ein Forum zu geben.

8.3.1 Organisation der CoPs In der Praxis lassen sich folgende Organisationsformen finden: • In Unternehmen, die insgesamt eher „klassisch-hierarchisch“ aufgebaut sind, entstehen die CoPs oft aus den funktionalen Organisationseinheiten, denen die Mitarbeiter disziplinarisch zugeordnet sind. Aus diesen Einheiten werden sie in die agilen Teams entsandt, arbeiten dort, bleiben aber ihrer Gruppe oder ihrem Referat zugeordnet. Der CoP-Leiter verantwortet dabei als Linienverantwortlicher das Thema, moderiert die Diskussion und hat das letzte Wort bei Entscheidungen, die sich auf die Mehrzahl oder sogar auf alle Teams auswirken. In der Praxis entstehen bei diesem Konstrukt aber oft Probleme: Wenn neben der Arbeit im agilen Team noch operative Tagesarbeit anfällt, geraten die Teammitglieder dadurch leicht in Ressourcen- und Interessenskonflikte. Hier „gewinnt“ meist die disziplinarische Heimat. Dominiert zusätzlich der Linienverantwortliche und CoP-Leiter die Diskussionen und Entscheidungsprozesse, bleibt für selbstverantwortliche Arbeit der Team-Vertreter im CoP wenig Raum. Die CoP-Leiter selbst haben oft auch Interessenskonflikte, die bspw. durch Zielvereinbarungen entstehen, die mit den Themen der Team-Vertreter schwer in Einklang zu bringen sind.

84

M. Bartonitz

• Damit die CoPs selbst organisiert und damit entsprechend der agilen Werte arbeiten können, gehen Unternehmen zunehmend andere Wege: Die cross-funktionalen agilen Teams bilden die disziplinarische Heimat und die CoPs sind „virtuelle“ Konstrukte. Manchmal erhalten die CoPs einen offiziellen fachlichen Leiter zugeordnet. Für diesen können aber die gleichen Interessenkonflikte wie für einen disziplinarisch verantwortlichen CoP-Leiter entstehen. • Eine gute Übergangslösung für die „virtuellen CoPs“ ist es, diesen einen Moderator zur Verfügung zu stellen, der den Teamvertretern hilft, im CoP zu einer guten Form der Zusammenarbeit und Selbstorganisation zu finden. Dies kann bspw. ein erfahrener Scrum Master sein, der das CoP in seinen Meetings unterstützt, der die Diskussion moderiert und das CoP anleitet, einen guten Entscheidungsprozess zu entwickeln. • Erfahrene CoPs wählen sich einen Moderator aus den eigenen Reihen; diese Rolle kann auch rotierend (bspw. jeweils nach 3 CoP-Meetings) weitergereicht werden. Der Nachteil dabei ist, dass der jeweilige Moderator in seiner Rolle neutral bleiben muss und nicht gut selbst fachlich mitdiskutieren kann. Damit bleibt immer ein Team im CoP ohne Repräsentanten. Deshalb sind auch reife CoPs gut beraten, wenn sie für Meetings mit strittigen Themen auf einen neutralen Moderator aus dem Kollegenkreis zurückgreifen. • Eine weitere Variante ist, dass die Team-Vertreter für die CoPs ab und zu wechseln. Das beugt der Gefahr vor, dass ein CoP zum elitären Expertenzirkel mutiert. Obwohl die Gefahr dafür tatsächlich im Normalfall gering ist, denn alle Team-Vertreter arbeiten ja weiterhin in ihren Teams. Sie treffen sich in den CoPs nur für Erfahrungsaustausch, Beratung und Abstimmung. Aber das Wechselprinzip bringt für die Team-Mitglieder selbst auch Entlastung und in die CoPs mehr unterschiedliche Sichtweisen und Lebendigkeit. Allerdings sollte man nicht zu häufig wechseln, denn die CoPs brauchen auch Kontinuität und ein gemeinsames Verständnis ihrer Teilnehmer, damit der Austausch noch effektiv bleiben kann.

8.3.2 Das Ringen um die richtige Entscheidung Die Art und Weise, wie in den CoPs gearbeitet wird und vor allem wie Entscheidungen getroffen werden, kann in selbst organisierten CoPs ganz unterschiedlich sein. Das jeweils praktizierte Verfahren hat erheblichen Einfluss auf die Effizienz eines CoPs und die Zufriedenheit aller Beteiligten, worunter auch die agilen Teams, die ihre Vertreter in die CoPs entsenden, zählen. Schauen wir uns im Folgenden einige Verfahren an.

8.3.2.1 Entscheiden via Konsens Es werden auf die Tagesordnung gehobene aktuelle Problem gemeinsam diskutiert und um eine Lösung gerungen, die alle Team-Vertreter befürworten. Die gute Absicht dabei: Die Lösung soll möglichst die beste und zugleich möglichst die beste für alle Teams sein, die von der Entscheidung betroffen sind. Gründe für das Vorgehen können

8  Skalierung – teamübergreifende Abstimmung

85

auch sein, dass die agile Arbeitsweise generell noch in der Einführung und für viele Mitarbeiter relativ neu ist; vielleicht kennen sich auch die Team-Vertreter noch nicht so gut und wollen sich in der Startphase des CoP erst mal freundlich „beschnuppern“. Auch die Unternehmenskultur spielt eine Rolle. In manchen Organisationen ist es „guter Ton“, Konflikte zu vermeiden; in anderen Organisationen wollen die Team-Vertreter aber auch in ihren Teams und im CoP eine Harmonie erzeugen, die sie im übrigen Unternehmensalltag bisher eher vermissen. In der Praxis führt dieses Konsens-Prinzip in der Regel nicht zur besten, sondern – wenn überhaupt – zur zweit- oder drittbesten Lösung. Grund: Es werden faule Kompromisse ausgehandelt oder aus Harmoniebedürfnis vorschnell wichtige Argumente aufgegeben. Oder es wird endlos diskutiert, weil immer irgendeinem Team-Vertreter noch ein Aspekt einfällt, der vor der finalen Entscheidung zu behandeln wäre. Diese Strategie eignet sich nicht nur für die fast endlose Suche nach der besten Lösung, sondern auch zum geschickten Blockieren des gesamten CoPs. Für die Teams, die darauf warten, dass ihr Vertreter eine Entscheidung mitbringt, ist das natürlich unbefriedigend. Es mag CoPs geben, die mit Konsens sehr gut zurechtkommen. Auch kann ein erfahrener Scrum Master als Moderator das CoP bei der Konsens-Findung mit Fragen, Spiegeln des Diskussionsverlaufs und mit „Timeboxing“ gut unterstützen. Ein wirklich guter Scrum Master wird das CoP aber schnell davon überzeugen, dass Konsens nicht der beste Weg ist.

8.3.2.2 Entscheiden via demokratische Abstimmung In diesem Verfahren werden Sichtweisen und Argumente ausgetauscht und schließlich wird mit einer Mehrheit die Lösung gekürt. Die Entscheidung basiert also auf den Interessen und Sichtweisen der Mehrheit. Meistens ist die demokratische Abstimmung schneller bewerkstelligt als eine Konsensfindung. Für viele Teams ist das ein gutes Vorgehen. Zur Schieflage kommt es aber, wenn wichtige Argumente einzelner Team-Vertreter zu wenig Gehör finden. Möglicherweise ist ja auch nur eine Minderheit der Teams von den negativen Konsequenzen einer CoP-Entscheidung betroffen. Manche CoPs führen deshalb zusätzlich das Veto-Prinzip ein. Wer gravierende Bedenken gegen einen Vorschlag hat, kann einen Mehrheitsentscheid mit seinem Veto verhindern. Das führt dann im CoP entweder zur Blockade oder zu einer erneuten Diskussion, bis eine mehrheitsfähige neue Lösung entwickelt ist. Und es gibt auch das Phänomen, dass geschickte Team-Vertreter im Vorfeld in bilateralen Gesprächen die erforderlichen Mehrheiten schmieden, um ihren Vorschlag im CoP durchzusetzen. Das ist dann zwar „politisch geschickt“, aber für das CoP sowie alle betroffenen Teams nicht unbedingt nützlich. Und selbst wenn der Vorschlag objektiv sachlich ein sehr guter war, besteht die Gefahr, dass sich die Team-­ Vertreter und Teams der überstimmten Minderheit hintergangen fühlen. Auch beim Einsatz der demokratischen Abstimmung ist es also hilfreich, wenn CoPs durch einen erfahrenen Scrum Master moderiert werden, der zu Fairness, Ehrlichkeit und Transparenz anhält.

86

M. Bartonitz

8.3.2.3 Entscheiden via Konsent Das Konsent-Prinzip kehrt die gewohnte Form des Entscheidungsprozesses quasi um, denn es wird nicht nach der Zustimmung gefragt, sondern nach einem gravierenden Einwand, der zu begründen ist. Eine Grundannahme im Konsent ist, dass jeder eingebrachte Vorschlag automatisch angenommen ist, wenn nicht etwas wirklich Schwerwiegendes dagegenspricht. Zugleich wird jeder Einwand als wertvoller Beitrag, als ein Geschenk an die Gemeinschaft betrachtet – das ist die zweite Grundannahme: Jeder Einwand hat eine gute Absicht. Eine dritte Grundannahme ist, dass es nicht notwendig ist, die beste Lösung zu finden, sondern überhaupt eine Lösung zu haben und mit dieser wieder einen Schritt weiter voranzukommen. Damit erhält im Konsent nicht automatisch die Mehrheit die Macht, sondern die Position jedes Einzelnen wird gestärkt und zugleich eine Blockade verhindert. Das Konsent-Prinzip wurde von den Machern der Soziokratie1 entwickelt und später in die von ihr abgeleitete Holokratie2 weiter übernommen. Die Entscheidungsfindung durchläuft dabei folgende Schritte: • Ein Vorschlag oder Antrag wird von einem Team-Vertreter vorgestellt und kurz erläutert. Im Architektur-CoP könnte es sich bspw. um eine grundlegende Architektur-Entscheidung handeln, die sich eines der agilen Teams als gute Lösung für die eigene Arbeit überlegt hat, die aber auch Konsequenzen für die Arbeit vieler oder sogar aller agilen Teams hat. • Im nächsten Schritt dürfen alle anderen Team-Vertreter im CoP dem Vorschlaggeber reihum Verständnisfragen stellen. Der Vorschlaggeber beantwortet die Fragen jeweils sofort. • Dann gibt es eine Runde zur Meinungsäußerung, damit alle CoP-Mitglieder gemeinsam einen Überblick darüber erhalten, wie jeder über den Vorschlag denkt. Es schließt sich eine zweite Meinungsrunde an, denn das Hören aller Sichtweisen in der ersten Runde kann ja bei jedem Mitglied zu einer Meinungsänderung führen.

1Mitte

des 20. Jahrhunderts aktualisierte der Reformpädagoge Kees Boeke die Ideen von Ward und erweiterte sie erheblich. Boeke sah Soziokratie als eine Form der Regierung oder des Managements an, die von einer Gleichberechtigung der Individuen ausgeht und auf dem Prinzip des Konsens beruht. Diese Gleichberechtigung wird im Unterschied zur Demokratie nicht durch den Grundsatz „Ein Mensch – eine Stimme“ verkörpert, sondern durch den Grundsatz, dass eine Entscheidung nur getroffen werden kann, wenn niemand der Anwesenden einen schwerwiegenden und begründeten Einwand im Sinne der gemeinsamen Ziele hat. Die Entscheidungen bekommen eine hohe Akzeptanz und werden auch von den Ausführenden mitgetragen solange sie sich als hilfreich erweisen (Wikipedia). 2Holokratie/Holacracy ist eine von dem Unternehmer Brian Robertson aus Philadelphia (USA) in seiner Firma Ternary Software Corporation entwickelte Systemik, die Entscheidungsfindungen „mit durch alle Ebenen hindurch gewünschter  Transparenz  und  partizipativen  Beteiligungsmöglichkeiten“ in großen Netzwerken und vielschichtigen Unternehmen eine günstige Struktur gibt (­Wikipedia).

8  Skalierung – teamübergreifende Abstimmung

87

• Daran schließt sich eine Runde an, in der alle Team-Vertreter gefragt werden, ob sie einen schwerwiegenden Einwand haben. „Gefällt mir nicht“ oder „Finde ich nicht gut“ zählen dabei nicht als Einwände im Sinne des Konsent. Ein gravierender Einwand zeigt vielmehr auf, dass der Vorschlag, so wie er jetzt vorliegt, daran hindert, das vereinbarte Ziel zu erreichen, und damit zu einem Schaden für die Organisation oder für Teile davon führen würden. Wenn es keinen gravierenden Einwand gibt, ist der Vorschlag automatisch angenommen. • Gibt es einen echten und begründeten Einwand, bspw. in unserem Architektur-CoP die Konsequenz, dass einzelne Teams künftig erhebliche Mehrarbeit haben oder bereits geplante Arbeiten neu konzipieren müssen, dann gibt es einen weiteren Schritt: Der Moderator fragt zunächst den Einwandgeber, dann den Vorschlaggeber, ob er eine Idee hat, wie der Einwand in den Vorschlag integriert werden kann. Wenn dann noch etwas offen ist, geht die Frage an alle Team-Vertreter weiter. Idealerweise gelingt die Formulierung eines neuen, integrierten Vorschlags innerhalb des laufenden CoP-Meetings, manchmal muss das aber auch bis zum nächsten Meeting vorbereitet werden. Für den modifizierten Vorschlag werden dann die o. g. Schritte nochmal durchlaufen. • Hat ein Entscheidungsvorschlag Konsent erhalten, wird dieser normalerweise mit einem “Ablaufdatum” versehen. Spätestens zu diesem Termin wird die Entscheidung geprüft und Lessons Learned abgeleitet. Und dann wird ein modifizierter Vorschlag vorgestellt oder die bisherige Entscheidung verlängert. • Sind CoPs mit dem Konsent-Prinzip gut vertraut, suchen Vorschlaggeber im Vorfeld bereits das Gespräch mit den anderen Team-Vertretern, um etwaige Einwände schon vor einem CoP-Meeting konstruktiv integrieren zu können. Dann geht die Entscheidungsfindung im CoP sehr schnell. Und doch hinterlässt sie bei den Beteiligten kein „Geschmäckle“ wie dies oft bei der „politischen Mehrheitsbildung im Vorfeld“ beim demokratischen Verfahren eintritt. Das Konsent-Prinzip braucht etwas Übung, Disziplin und einen erfahrenen Moderator. Ungewohnt ist vor allem, dass für die Konsent-Entscheidung nicht diskutiert wird; die Teilnehmer sprechen vielmehr nacheinander im Kreis. Das führt zu einer hohen Transparenz, welche verschiedenen Sichtweisen und Meinungen zu einem Vorschlag bestehen. Und es ist sehr wertschätzend allen Teilnehmern gegenüber, denn jeder kommt zu Wort. Ist Konsent erst einmal vertraut, führt es gerade in agilen Organisationen rasch zu einem guten Arbeitsfluss von Teams und CoPs. Denn es gilt noch eine vierte Grundannahme – alle Vorschläge dürfen immer weiterentwickelt werden: Hat jemand die Idee für eine noch bessere Lösung, bringt er diesen Vorschlag selbstverständlich ins CoP ein. Kein Vorschlag wird mit dem Argument „Das haben wir doch kürzlich erst entschieden…“ abgeblockt. Und wenn nach dem CoP-Meeting in einem Team ein wichtiges Hindernis gefunden wird, darf aus diesem Team heraus jederzeit der Konsent wieder zurückgezogen werden.

88

M. Bartonitz

Damit harmoniert Konsent sehr gut mit selbst organisierten, soweit möglich autonom entscheidenden Teams. Und es passt zu dem adaptiv-inkrementellen Vorgehen und den Prinzipien transparency, inspect and adapt von Scrum. CoPs, die eine gute Reife an Selbstorganisation erreicht haben und routiniert mit Konsent arbeiten, können sich mit dem gleichen Verfahren auch einen CoP-­Moderator selbst wählen: Jeder Team-Vertreter kann einen Kollegen aus der CoP-Runde als Moderator für eine fest definierte Zeit vorschlagen. Und wenn weder er selbst noch ein anderer Team-Vertreter einen stichhaltigen Einwand dagegen hat, gilt der Vorschlag als angenommen. Genauso wird in den agilen Teams dann auch der Team-Vertreter bestimmt, der das Team im CoP vertritt.

Dr. Martin Bartonitz ist Produktmanager und SCRUM Product Owner bei OPTIMAL SYSTEMS GmbH, Hersteller eines Enterprise Content Management Systems. Er studierte Experimentelle Physik und wechselte nach seiner Promotion 1992 von der Messprozesssteuerung in die Welt der Geschäftsprozessautomatisierung. In seinen über 25 Jahren befasste er sich im Schwerpunkt mit den fachlichen Anforderungen der Dokumentverwaltung und -steuerung, u. a. auch im öffentlichen Sektor. Seit 12 Jahren arbeitet er mit agilen, sich selbstorganisierenden Teams und schreibt über seine hier gemachten Erfahrungen in Blogartikeln.

9

Agile Selbst- und Teamorganisation mit Personal Kanban Thomas Michl

Zusammenfassung

In diesem Kapitel wird die Grundstruktur des Personal Kanbans dargestellt. Dabei zeige ich auf, wie sich Personal Kanban in der Teamorganisation anwenden lässt und runde diesen Artikel mit einem kleinen Einblick in meine persönliche Selbstorganisation mit Personal Kanban ab. Der Umfang dieses Artikels bietet lediglich den Einstieg in die Thematik und kann daher nur als Anregung dienen. Aber Personal Kanban bietet sich als methodischer Einstieg ein, da es vergleichsweise einfach in den Alltag zu integrieren und im einem hohen Maße anpassungsfähig ist.

9.1 Einleitung Kanban – wie es bereits im Kapitel von Frederic Jordan vorgestellt wurde – hat seine Wurzeln im Lean Management und der Produktionswirtschaft der Industrie. Die Grundprinzipien des Lean Management sind den Prinzipien des agilen Manifests ähnlich. Und tatsächlich fußt die agile Idee in weiten Teilen auf eben jenen Ansätzen, die im Lean Management zu den wesentlichen Kernpunkten gehören. Hier ist unter anderem die Orientierung an Wertströmen und das Prinzip Kaizen, also das ganzheitliche Bestreben des sich Weiterentwickelns, besonders hervorzuheben. Personal Kanban ist eine Adaption des Kanban-Ansatzes für die Selbstorganisation, der sich aber auch eignet, um die Zusammenarbeit in Teams zu koordinieren. Bekannt gemacht wurde die Idee von Personal Kanban von Jim Benson (der auch Mitentwickler von Lean

T. Michl (*)  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_9

89

90

T. Michl

Coffee ist) und Tonianne DeMaria. Von den beiden Autoren stammt das Buch „Personal Kanban“ (Benson und Barry 2012), das die Methode erstmalig umfassend beschreibt. Sie betreiben gemeinsam einen Blog unter dem gleichnamigen Titel, der vertiefende und weiterführende Hilfen für Anwender bietet. Die Grundprinzipien des Kanban, wie sie im Lean Management formuliert und für das sogenannte Software Kanban übernommen wurden, werden hierbei auf den Themenkomplex des Selbstmanagements übertragen. Ein besonderer Vorteil von Personal Kanban liegt darin, dass es sich auch in nicht-­ agilen Umfeldern für die eigene Selbstorganisation adaptieren lässt. So kann ein agiler Einzelkämpfer sich agiler Herangehensweisen bedienen und durch aktives Vorleben seine Kollegen inspirieren. Gleichzeitig lässt sich dies auch als gute Vorübung für die Übertragung auf das Team ansehen.

9.2 Grundstruktur von Personal Kanban Kernelement von Kanban ist die Visualisierung. Zum einen die Visualisierung der Prozesse und der Abläufe, aber auch der jeweiligen Sachstände und der „Aufgaben“. Ein hohes Maß an Transparenz spielt hierbei eine wichtige Rolle, was es mitunter gerade in Teams mit einem hohen Anteil an Skeptikern schwierig macht. Transparenz kann auch vermeintlichen Druck erzeugen, insbesondere wenn die Zielgruppe vorgeprägt ist und negative Erfahrungen mit Transparenz gesammelt hat. Dieser Problematik sollte Mensch sich bei der Einführung in einem Team daher nicht nur bewusst sein, sondern sie sollte offen angesprochen werden. Kanban aber alleine auf die „Verfolgung“ von Aufgaben im Arbeitsfluss zu reduzieren, wäre etwas zu einfach. Das kann jedes sogenannte Ticketsystem. Nein, es geht um Einiges mehr. Kanban und Kaizen sind Begriffe, die nicht ohne Grund eng verknüpft sind. Kanban ist darauf gerichtet, einen permanenten, gleichbleibenden Arbeitsfluss zu gewährleisten. Der harmonische Arbeitsrhythmus fördert die Produktivität dauerhaft. Extreme Spitzen nach oben oder unten sind Belege für Veränderungsbedarf, die darauf schließen lassen, dass Abläufe nicht aufeinander abgestimmt sind oder das Arbeitssystem als Ganzes bzw. einzelne Teile überlastet sind. Hier greift Kaizen – gerne in unserer westlichen Welt auf den kontinuierlichen Verbesserungsprozess reduziert. Dies ist allerdings eine Verkürzung der ganzheitlichen Vorstellung von Kaizen im ursprünglichen Sinne, die über das prozessuale Denke hinaus geht, und – wie kaum ein anderer Ansatz – alle Betroffenen zu echten Beteiligten macht.1

1Kaizen

bezeichnet sowohl eine japanische Lebens- und Arbeitsphilosophie als auch ein methodisches Konzept, in deren Zentrum das Streben nach kontinuierlicher und unendlicher Verbesserung steht. Die Verbesserung erfolgt in einer schrittweisen, punktuellen Perfektionierung oder Optimierung eines Produktes oder Prozesses.

9  Agile Selbst- und Teamorganisation mit Personal Kanban

91

Ein weiteres Kernelement von Kanban ist die Fokussierung, die durch eine Begrenzung der im Augenblick in Bearbeitung befindlichen Aufgaben erzielt wird. Dies erfolgt durch die sogenannte „WiP-Limitierung“. „WiP“ bedeutet „Work in Progress“. Diese Limitierung soll den bereits erwähnten gleichmäßigen Arbeitsfluss bei einer gleichzeitigen Fokussierung auf das „Hier und Jetzt“ gewährleisten. Durch die Bündelung sämtlicher Potenziale auf möglichst wenige Aufgaben wird ein schädliches „Multitasking“ verhindert, das nicht nur die Produktivität behindert, sondern auch die Fehlerwahrscheinlichkeit erhöht. Die Erfahrungen zeigen, dass die Fokussierung auf nur wenige Aufgaben im wahrsten Sinne des Wortes erhebliche Produktivitätssteigerungen erzeugt. Wesentliches Kernelement von Personal Kanban ist das Kanbanboard (Abb. 9.1), eine Tafel, die auf folgender Grundstruktur pro Bearbeiter basiert: • Aufgabenspeicher (Backlog/To do) • In Bearbeitung (In progress) • Erledigt (Done) Es gibt viele elektronische Hilfsmittel, die für eine virtuelle Kanbantafel verwendet werden können. Die Erfahrung aber zeigt, dass eine analoge Tafel für den Einstieg am besten geeignet ist. Dafür braucht es nicht gleich ein Whiteboard. Ein großes Plakat reicht aus. Für die Aufgabenkarten sind häufig schon Post-its ausreichend. Im Aufgabenspeicher werden alle Aufgaben gesammelt, die anfallen und bearbeitet werden sollen. Die Spalte „In Bearbeitung/In Progress“ beinhaltet alle Aufgaben, die

Abb. 9.1  Beispiel für ein Kanbanboard

92

T. Michl

gerade im Augenblick bearbeitet werden. Die Spalte  „Erledigt“  hingegen umfasst alle Aufgaben, die abgeschlossen wurden. Diese Struktur lässt sich übrigens beliebig anpassen, sodass die einzelnen Bearbeitungsschritte ebenfalls in eigenen Spalten dargestellt werden können. So lassen sich über das Kanbanboard auch ganze Arbeitsabläufe visualisieren. Interessant ist dies insbesondere dann, wenn es darum geht, wiederkehrende Abläufe zu visualisieren und transparent zu machen. Dann bietet es sich an, die Spalten entsprechend anzupassen. Für den Anfang empfiehlt es sich jedoch, mit der einfachen Gliederung aus Backlog – In Bearbeitung/In Progress – Erledigt/Done zu b­ eginnen.

9.3 Aufgabenbeschreibung Für jede Aufgabe wird eine Karte erstellt, die die Aufgabe beschreibt. Die beschriebene Aufgabe sollte nach Möglichkeit innerhalb eines Tages bearbeitet werden können. Ist dies nicht möglich, empfiehlt es sich, die Aufgabe in einzelne Teilaufgaben zu zerlegen. Auf jeder Karte steht nur jeweils eine formulierte Aufgabe. Im agilen Umfeld haben sich hierfür die sogenannten User Stories bewährt. Allerdings sind sie kein Muss. Wichtig ist, dass klar und deutlich wird, was getan werden soll. Selbst wenn Sie auf User Stories setzen wollen, lassen sich auch andere Darstellungsformen einsetzen, die zu einem besseren Verständnis der Aufgabe führen. Das Maß aller Dinge sollte immer sein, dass sich die ganze agile Organisation danach ausrichtet, das jetzt im Augenblick beste Ergebnis zu erzielen. Was für Projekte gilt, ist auch für die Produktivität im Team und für die persönliche Produktivität hilfreich: das Formulieren von zukünftigen Ergebnissen statt klassischer Aufgabendefinition. Definieren wir Aufgaben als Vorwegnahme eines Ergebnisses, hat dies mehrere Vorteile: • Wir bekommen ein klareres Bild von dem, was wir erreichen möchten und von den Zusammenhängen. • Wir priorisieren die Qualität des Ergebnisses vor Termin. • Wir motivieren uns selbst. • Wir erhalten uns unsere Agilität. Im Vordergrund steht ein gewünschter Zielzustand. Die Umsetzung bleibt dabei offen. Es geht darum, zunächst ein klares Bild davon zu erhalten, was wir erreichen wollen. Je klarer das Bild, desto klarer werden die einzelnen Schritte dahin. Statt beispielsweise Tagesziele auf klassische Art zu definieren, sollten wir Tagesergebnisse definieren. Was wollen wir am Ende des Tages, der Woche oder des Monats erreicht haben? Was ist der gewünschte Zielzustand?

9  Agile Selbst- und Teamorganisation mit Personal Kanban

93

9.4 Beispiel einer User-Story Delegieren wir Aufgaben als Ergebnis und nicht als Arbeitspakete, lassen wir den Mitarbeitern offen, wie sie den Weg zum Ergebnis beschreiten. Wir vertrauen auf ihre Problemlösungskompetenz. Durch die ganzheitliche Betrachtung und Formulierung ergibt sich ein besseres Verständnis, auch der Zusammenhänge, die sonst nicht transparent und sichtbar werden. So verhindern wir, dass wichtige Aspekte im Zug des Delegationsprozesses verloren gehen. Selbst wenn wir Aufgaben nicht delegieren, sondern selbst ausführen, hilft uns die Formulierung als Ergebnis, uns stärker auf das zu fokussieren, was wir erreichen wollen. Wir arbeiten motivierter, da wir eine Vorstellung davon haben, was am Ende herauskommen soll. Ein klares Bild vom Zielzustand, die bildhafte Beschreibung, trägt dazu bei, motivierter bei der Sache zu sein. Ein psychologischer Kniff, der sich im Übrigen in zahlreichen Publikationen der Produktivitätsliteratur findet. Adaptieren wir das Prinzip der User Story, heißt dies für uns: Wir formulieren eine Zukunftsvision eines Ergebnisses bzw. eines Zielzustandes. Von diesem leiten wir ab, welche Schritte notwendig sind, um diesen Zielzustand zu erreichen. Gleichzeitig erhalten wir unsere Agilität im Umsetzungsprozess, die wir brauchen, um auf neu erworbene Erkenntnisse im Umsetzungsprozess zu reagieren. Was im Großen gilt, gilt auch im Kleinen. Wenn wir jeden einzelnen Schritt als Aufgabe formulieren, zementieren wir geistig bereits fest, wie wir vorgehen wollen – erhalten uns aber nicht die Flexibilität auf neue Erkenntnisse zu reagieren. Insbesondere dann, wenn das gewünschte Ergebnis noch in weiter Ferne liegt und wir im Augenblick andere Ergebnisse erzielen müssen. Im Grundsatz gilt: je höher eine „Aufgabe“ priorisiert wird, desto klarer formulieren wir sie. Ähnlich wie wir es aus dem Scrum-Backlog kennen. Aufgaben, die wir jetzt im Augenblick noch nicht konkret angehen, müssen wir zum jetzigen Zeitpunkt auch noch nicht präzise formulieren. Durch die Formulierung als Ergebnis erhalten wir auch die notwendigen Anhaltspunkte zu Überprüfung unseres Ergebnisses. Die Qualitätskriterien werden klarer und verständlicher. Sie lassen sich wesentlich leichter ableiten und helfen uns später zu verorten, ob wir mit unserem Arbeitsergebnis zufrieden sind. Im Team hilft uns dies darüber hinaus ein klares Verständnis davon zu bekommen, was wir anstreben. Beispiel: Wenn der Tag heute zu Ende gegangen ist, möchte ich einen Blogbeitrag zum Thema Personal Kanban in der Teamorganisation für den Blog Forum Agile Verwaltung geschrieben und eingestellt haben.

94

T. Michl

9.5 Aufgaben priorisieren Wie bereits erwähnt, werden im Aufgabenspeicher (in der Literatur häufig Backlog genannt) die Optionen, d. h. mögliche relevante Aufgaben gesammelt. Erst danach wird entschieden, welche Aufgaben bearbeitet werden. Da nicht alle Aufgaben auf einmal abgearbeitet werden können, heißt es nach dem Sammeln zunächst einmal zu priorisieren. Die Priorisierung der Aufgaben erfolgt gemeinsam im Team. Gemeinsam wird dabei festgelegt, welche Aufgaben heute ausgeführt werden sollen. Was ist heute wichtig, sollte die oberste Frage des Teams dabei lauten. Prioritäten sind jedoch nicht in Stein gemeißelt. Neue Erkenntnisse können täglich dazu führen, dass die Prioritäten neu geordnet werden müssen (Abb. 9.2). Die Priorität einer Aufgabe – auch im Themenspeicher – lässt sich an der Reihenfolge ablesen. Die am höchsten priorisierten Aufgaben hängen ganz oben, die am niedrigsten priorisierten Aufgaben hängen unten. Bei der Festlegung der maximalen Arbeitsmenge ist zu berücksichtigen, dass im Laufe eines Tages immer wieder unerwartete und ungeplante Aufgaben hinzukommen können. Es bietet sich an, den WIP zunächst bei fünf Aufgaben pro Person anzusetzen und ihn dann Abb. 9.2   Priorisierung

9  Agile Selbst- und Teamorganisation mit Personal Kanban

95

entsprechend der Erfahrung des Teams noch oben oder unten anzupassen. Die Begrenzung der Aufgabenmenge trägt dazu bei, dass sich das Team Gedanken machen muss, welche Prioritäten es setzen möchte. Die entsprechenden Aufgaben werden dann für den Tag in die Spalte „In Bearbeitung/ In Process“ umgehängt. Idealerweise hat jedes Teammitglied eine eigene Unterspalte, sodass auf einen Blick sichtbar wird, wer gerade an was arbeitet. Sind übrigens die Aufgaben abgearbeitet, heißt es noch lange nicht, dass sich das entsprechende Teammitglied den Rest des Tages einen schönen Lenz macht. Entweder es hilft den anderen Teammitgliedern bei der Lösung ihrer Aufgaben oder es schnappt sich aus dem priorisierten Aufgabenspeicher die nächste Aufgabe. Fertig gestellte Aufgaben werden in die Spalte „Erledigt/Done“ verschoben. In der Erledigt-Spalte gibt es die Unterscheidung nach Teammitgliedern nicht. Die geleistete Arbeit ist eine Teamleistung und wird auch als solche visualisiert. Um die Priorisierung vorzunehmen, bietet es sich an, sich am „Nutzen“ eines bestimmten definierten Ergebnisses für das Team, die Gesamtorganisation oder die Zielgruppe zu orientieren.

9.6 Tägliche Synchronisierung des Teams Wichtig ist, dass das Team sich täglich – am besten zur gleichen Uhrzeit zusammenfindet und gemeinsam jeden Tag aufs Neue plant, welche Aufgaben erledigt werden sollen. Neben der gemeinsamen Priorisierung sollte auch immer kurz darüber gesprochen werden, was das Team am Vortag erreicht hat und welche Hindernisse aufgetreten sind. Damit die Runde nicht ausufert, bietet sich eine Zeitlimitierung (eine sogenannte „Timebox“) von 15 min an. Über Problemlösungen wird dabei nicht gesprochen, denn diese sind Gegenstand einer eigenständigen Besprechung der Beteiligten. Es geht darum, dass sich das Team gegenseitig darüber informiert, was ansteht und was zu tun ist. Gemeinsam wird festgelegt, was als Nächstes gemacht werden muss, sodass jeder im Bilde über den Fortschritt ist.

9.7 Kontinuierliche Verbesserung nach Kaizen Wesentliches Element von Personal Kanban ist auch die kontinuierliche Verbesserung der eigenen Zusammenarbeit im Sinnen von Kaizen. Ähnlich wie bei Scrum empfiehlt es sich, Zeit für eine Teamretrospektive einzuplanen. Am besten am Ende der Arbeitswoche. Auch hier ist eine Zeitlimitierung hilfreich, um sich auf das Wesentliche zu fokussieren. Leitfragen wie zum Beispiel • • • •

Was hat diese Woche gut funktioniert? Was hat diese Woche weniger gut funktioniert? Was wollen wir beibehalten? Was wollen wir ändern?

96

T. Michl

Abb. 9.3  Beispiel für eine Retrospektivensammlung

helfen dabei, das Verbesserungspotenzial zu heben. Auch hier gilt: eine Zeitlimitierung hilft, ausufernde Diskussionen vorzubeugen und sich auf das Wesentliche zu konzentrieren. Eine Timebox von 30 min bietet sich daher an (Abb. 9.3). Auch hier ist eine Visualisierung hilfreich, wie im gezeigten Beispiel. Der Gedanke von Kaizen impliziert, dass die Retrospektive2 keine Sache einer einzelnen Person ist, sondern Aufgabe des gesamten Teams. Schuldzuweisungen haben in einer Retrospektive nichts verloren. Es geht nicht darum, einen Schuldigen zu finden, sondern gemeinsame Lösungen zu entwickeln. Dies impliziert natürlich einen Umgang mit „Fehlern“, der durch einen offenen Umgang miteinander geprägt ist und sich durch gegenseitigen Respekt auszeichnet. Idealerweise wird die Retrospektive daher von einem Teammitglied moderiert, das das Vertrauen aller anderen genießt.

2Die

Sprint Retrospektive steht am Ende eines Planungszyklus. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Scrum Team darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist eine gemeinsame Aktivität des Scrum Teams.

9  Agile Selbst- und Teamorganisation mit Personal Kanban

97

9.8 Wochenplanung Bisher hat sich die Arbeitsplanung auf der Mikroebene bewegt – damit fehlt ein wenig der Überblick. Manche bedienen sich daher bei der Wochenplanung eines weiteren Boards, auf dem die übergeordneten Themen (wie z. B. Projekte) einmal pro Woche innerhalb des Teams in den Fokus gestellt werden. Die Vorgehensweise ist dabei weitgehend identisch mit der Tagesplanung, nur dass eben in diesem Fall nicht die Aufgaben im oben beschriebenen Sinne betrachtet werden. Betrachtet wird dabei die „Projektplanung“ aus Sicht des Gesamtteams. Auch bietet sich an, einmal in der Woche den Aufgabenspeicher des Aufgabenboards auf Vordermann zu bringen. D. h. Ergänzungen vorzunehmen, Priorisierungen zu ändern oder nicht mehr notwendige Aufgaben aus dem Aufgabenspeicher zu entfernen.

9.9 Personal Kanban in der Selbstorganisation Im bisherigen Verlauf des Kapitels wurden die Grundzüge von Personal Kanban in Bezug auf die Anwendung auf der Teamebene vorgestellt. In der Selbstorganisation, also auf der individuelle Ebene, sind die Bedürfnisse andere als im Team.3 Das möchte ich anhand des vorliegenden Beispiels aus meiner persönlichen Praxis aufzeigen:

9.9.1 3 Boards Kern des Systems bilden insgesamt drei Kanbanboards. 1. Projekte 2. Ergebnisse 3. Irgendwann Die Boards Projekte und To dos/Ergebnisse umfassen unterschiedliche Planungsebenen und -tiefen. Jedes der beiden Boards hat eine Spalte „Eingang“ (neu, noch nicht priorisiert/eingeplant), eine Spalte „Erledigt“ (für den Rückblick wichtig) und „Wartet auf“ (abhängig von Anderen/delegiert). Das Board „Projekte“ umfasst größere Aufgabenblöcke im Sinne der Projektdefinition nach David Allan. Hier unterscheide ich nach dem Planungshorizont langfristig – ­mittelfristig (in den nächsten 3 Monaten) – demnächst (in den nächsten 4 Wochen) – aktuell (in Bearbeitung). Im Board „Projekte“ werden die Aufgabenblöcke inhaltlich noch relativ knappgehalten. Das Projekt-Board ist Basis meiner wöchentlichen und monatlichen ­Planung.

3Zur

Vertiefung, wie sich der agile Mindeset in die persönliche Selbstorganisation integrieren lässt, bittet sich auch das Buch von Meiser (2010) an, dass umfassende weitere Ratschläge enthält.

98

T. Michl

Das Board „To dos/Ergebnisse“ erfasst hingegen die einzelnen „Aufgaben“. Hier wird nach „Dieses Quartal“, „Diesen Monat“, „Diese Woche“ und „Heute“ unterschieden. Je fortgeschrittener die Planung, desto detaillierter wird hier die Aufgabenkarte beschrieben. Dabei greife ich auf das bei User-Stories übliche Muster (Beispiel: „[BLOG] Ich habe einen Blogbeitrag zum Thema partizipative Methoden wie agile und Art of Hosting geschrieben und veröffentlicht.“) zurück, indem ich die Aufgabe als „Ergebnis“ beschreibe und Unteraufgaben als Checkliste einfüge. Das Aufgabenboard ist Basis meiner täglichen Arbeitsplanung. Insbesondere die Spalte „Heute“ wird täglich neu geplant. So habe ich jeden Tag aufs Neue die Chance, auf Änderungen zu reagieren und bleibe agil im Sinne von Offenheit für neue Erkenntnisse und Veränderungen.

9.9.2 Work in Progress Wichtig ist der sogenannte „WIP“ (Work in Progress), was zu einer Limitierung führt. Hierdurch wird die Priorisierung der Projekte und Aufgaben erleichtert und gefördert. Grundsätzlich gilt auch, dass ich die Planung täglich und wöchentlich neu erstelle. Die Prioritäten können sich tagtäglich verschieben, weil Rahmenbedingungen oder andere Ereignisse nicht mehr passen. Der maximale WIP beträgt für die Spalte „Aktuell“ bzw. „Heute“ 5 Karten. Die von mir verwendete Software erlaubt die Kennzeichnung mit Farblabeln. Diese verwende ich zur Unterscheidung in „Privat“ und „Büro“. Durch die Label-­ Kennzeichnung lassen sich die Boards gut filtern. Terminierte Aufgaben sind ebenso möglich. Diese Funktion nutze ich zwar nicht sonderlich häufig, aber es gibt Projekte, die an einem bestimmten Tag fällig sind.

9.9.3 Tages-/Wochen- und Monatsplanung Die Tagesplanung erfolgt in aller Regel am Vortag mithilfe des Aufgabenboards und des Kalenders (ca. 10 min täglich). Hierzu erstelle ich mir eine tägliche Übersicht der Aufgaben und Termine, die im Laufe des Folgetages um Ideen, Anregungen und weitere Aufgaben für den täglichen Rückblick (max. 5 bis 10 min täglich) ergänzt werden. Gibt es Verbesserungsideen oder Auffälligkeiten, werden diese als Projekt/Aufgabe in die Planung aufgenommen und entsprechend priorisiert. Der Wochenrückblick mit Durchsicht aller Listen nimmt in etwa 30 bis 45 min in Anspruch und erfolgt bei mir in aller Regel am Freitag. Im Rahmen des wöchentlichen Rückblicks und der Wochenplanung gehe ich entsprechend die üblichen Posteingänge durch, um zu prüfen, ob und inwieweit noch offene Punkte zu ergänzen sind.

9  Agile Selbst- und Teamorganisation mit Personal Kanban

99

Einmal monatlich greife ich mir die Jahresziele heraus, schaue auch diese Liste durch und passe entsprechend die Planung an. Eine Zielmarke für den monatlichen Rückblick ist die Verbesserung einer Gewohnheit jeden Monat, was mir – ehrlich gesagt – nicht immer gelingt. Sie können also beruhigt sein. Es ist vollkommen normal.

9.10 Abschließender Hinweis Wie bereits eingangs erwähnt, bietet das Kapitel keine abschließende Abhandlung zur Methodik, sondern nur einen Einblick in die Grundstruktur. Personal Kanban ist darüber hinaus „nur“ ein Werkzeug, ein Hilfsmittel, das hilft, die agile Geisteshaltung mit Leben zu füllen. Die Anwendung der Methode selbst macht jedoch keinen echten Agilisten aus.

Literatur Anderson DJ, Carmichael A (2016) Essential kanban condensed. Blue Hole Press, Seattle Benson J, Barry TD (2012) Personal Kanban. dpunkt-Verlag, Heidelberg Meiser JD (2010) Getting results the agile way: a personal results system for work and life. Innovation Playhouse, Bellevue

Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für ­borisgloger consulting.

Agile Aufwandschätzungen

10

Thomas Michl

Zusammenfassung

Die agile Aufwandsschätzung setzt – im Gegensatz zur klassischen Schätzung in absoluten Zahlen – auf relationale Beziehungen zwischen den verschiedenen Bezugspunkten. Diese Art der Aufwandsschätzung ist oft genauer, klarer und verlässlicher als klassische Ansätze der Aufwandsschätzung. Hilfsmittel dabei sind sogenannte Storypoints, die diese Beziehung sichtbar machen. Beliebte Ansätze im Zuge der agilen Aufwandsschätzung sind das sogenannte Planning Poker und die Schätzung in T-Shirt-Größen. Die #NoEstimate-Bewegung verzichtet sogar ganz auf die Aufwandsschätzung und fokussiert sich vollständig auf den Output, der in agilen Arbeitsprozessen entsteht, als Maß der Dinge.

10.1 Einleitung Zu Beginn jedes Projekts und jeder Aufgabe steht immer die Frage, wie viel Aufwand entsteht und was muss gesetzt werden, um das gewünschte Ziel zu erreichen. Diese Frage zu beantworten ist wichtig, um zum einen bewerten zu können, ob der Aufwand und das Ergebnis in einem Verhältnis stehen, dass vertretbar ist, zum anderen aber auch um den Projektfortschritt messen zu können. Die Aufwandsschätzungen ist daher ein wichtiges Teilelement der (Projekt-)Planung – auch der agilen Planung. In der klassischen Sicht werden die Anforderungen analysiert und den Anforderungen zu Beginn der Projektplanung entsprechende Aufwände zugeordnet. Aufgrund des

T. Michl (*)  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_10

101

102

T. Michl

Abb. 10.1   Das unbekannte Land: Komplexität

i­terativ-inkrementellen Vorgehens erfolgt die Schätzung bei den agilen Methoden im laufenden Umsetzungsprozess zu Beginn jeder Planungsperiode. Ein weiterer wesentlicher Unterschied zwischen klassischen Schätzverfahren und agilen Herangehensweisen liegt insbesondere in der Unterscheidung zwischen Komplexität und Aufwand. Agile Ansätzen greifen nicht auf den Aufwand als Schätzbasis zurück, sondern knüpfen an der Komplexität an (Abb. 10.1). Komplexität in diesem Sinn bedeutet – anders als Kompliziertheit – dass wir es mit eine Vielzahl von Faktoren zu tun haben, die wir nicht kennen bzw. deren Verhalten wir nicht einschätzen können. Ein weiterer Unterschied zwischen klassischen Methoden und der agilen Aufwandsschätzung ist darin zu suchen, dass die agilen Ansätze nicht nach absoluten Werten basiert, sondern sich relationaler Ansätze bedient. Im Folgenden werden wir aufzeigen, dass die agile Aufwandsschätzung auf relationalen Schätzwerten basiert und welche Schätzmethoden sich in der agilen Praxis bewährt haben.

10.2 Das Problem der Aufwandsschätzung Das Problem bei Schätzungen ist, dass sie bestenfalls auf Erfahrungswerten der Vergangenheit basieren und damit mit einem hohen Unsicherheitsfaktor behaftet sind. Zu komplex sind die Einflussgrößen, um eine verlässliche Schätzung in abstrakten Zahlen liefern zu können. Insbesondere dann, wenn wir etwas gänzlich Neues erstellen. Um eine präzise Schätzung des Aufwands abliefern zu können, müssten wir eine Vielzahl von vergleichbaren und gleichartigen Referenzen besitzen, die wir in der Praxis in aller Regel nicht haben. Und selbst wenn doch, so werden wir – insbesondere bei hochkomplexen Sachverhalten – mit Einflussfaktoren konfrontiert, die uns häufig nicht bekannt sind oder zumindest deren Wirkung wir nicht einschätzen können. Daher werden Schätzungen – nach der agilen Lehre – ausdrücklich nicht als Verpflichtungen verstanden (im Gegensatz zum iterativen Ziel, das eine echte Verpflichtung darstellt). Eine Schätzung ist ein Richtwert, eine Orientierungsmarke, die auch nicht

10  Agile Aufwandschätzungen

103

in Stein gemeißelt ist, sondern sich dem wachsenden Erkenntnisstand anpasst und sich weiterentwickeln darf. Da zu Beginn eines agilen Projekts obendrein nur eine relativ ungenaue Vorstellung darüber besteht, was tatsächlich erreicht werden soll, ist es zusätzlich nahezu unmöglich zu erfassen, wie hoch der Aufwand ist, der durch die Erreichung des gewünschten Ergebnisses entsteht. Das inkrementelle, iterative Vorgehen, welches alle agilen Methoden im Wesentlichen kennzeichnet, geht auch von der Annahme aus, dass wir in der Arbeit mit großer Unschärfe dessen konfrontiert werden, was wir im Detail in den einzelnen Schritten tatsächlich tun und erzielen müssen, um unser Ziel zu erreichen. Wir tasten uns im Zuge des agilen Entwicklungsprozesses an das Ergebnis heran, bis wir ein zufriedenstellendes Ergebnis erzeugen, dass den Bedürfnissen der Anspruchsberechtigten begnügt. Dies wiederum führt dazu, dass wir den Aufwand über einen längeren Zeitraum oder über mehrere kurze Planungsperioden ohnehin nicht genau abschätzen können. Wir wissen zum diesem Zeitpunkt noch nicht im Detail, was wir erreichen wollen und was wir im Detail haben. Auf dieser Annahme lässt sich schwerlich exakt beziffern, wie viele Arbeitsstunden notwendig sind, um ein Ergebnis zu erzielen, das wir zu diesem Zeitpunkt in der Tiefe noch nicht erfassen können. Die Auswirkungen, wenn man Schätzungen als „Verpflichtung“ betrachten würde, wären fatal, wie die Praxis – auch außerhalb des agilen Umfeldes – immer wieder aufzeigt. Bewusst oder unbewusst werden zum Beispiel Qualitätskriterien unterlaufen, um im geschätzten Aufwandsrahmen zu bleiben u. ä., und letztendlich damit das Hauptziel gefährdet: die Kundenzufriedenheit. Nicht die Kundenzufriedenheit oder Nutzen, der gestiftet wird, rückt in den Fokus der Projektsteuerung, sondern allein der Zeitplan und der Ressourcenverbrauch. Die Qualität wird nachrangig. Schätzung in absoluten Werten sind oft – wie bereits erwähnt ungenau – und basieren auf historischen Daten. Die häufig zu beobachtenden Abweichungen zwischen den geschätzten Werten und den tatsächlich eingetretenen Aufwänden sind ein Indiz dafür, dass die klassischen Methoden der Aufwandsschätzung sehr unzuverlässig sind. Beobachtungen zeigen tatsächlich, dass es uns schwerfällt, Aufwände in absoluten Werten zu erfassen und einzuschätzen. Ein weiteres Element, das wir im Vergleich zwischen klassischen und agilen Methoden noch nicht berücksichtigt haben, aber ein Kernelement der agilen Herangehensweise darstellt: die Aufwandsschätzung erfolgt nicht im stillen Kämmerlein durch einen Projektleiter, sondern immer in der Gesamtheit des Teams, das die jeweilige Aufgabe wahrnimmt. Durch die Einbeziehung mehrere Personen in den Schätzungsvorgang nivelliert sich das Risiko der Fehlschätzung.

104

T. Michl

10.3 Vergleichende Schätzung ist Trumpf Wie bereits erwähnt haben empirische Beobachtungen gezeigt, dass durch relationale Schätzungen schnellere und oft bessere Ergebnisse erzielt werden als unter Zuhilfenahme von absoluten Schätzwerten. Ein kleiner Praxistest, der gerne zur Illustration in Workshops zum Einsatz kommt, soll uns dabei helfen zu illustrieren, was damit gemeint ist (Abb. 10.2).

Abb. 10.2  Die 10 größten deutschen Städte

In Abb. 10.3 sind die 10 größten Städte in bunter Reihenfolge dargestellt. Abb. 10.3   Auflösung: die Reihenfolge der 10 größten deutschen Städte

10  Agile Aufwandschätzungen

105

Wenn wir eine Gruppe von Menschen bitten, die Städte im Hinblick auf ihre Einwohnerzahl zu schätzen und sie auf dieser Basis dann in eine Reihenfolge nach Größe zu bringen, ist erfahrungsgemäß die Trefferquote wesentlich schlechter, als wenn wir sie bitten, die genannten 10 Städte nach Ihrer Größe ohne die Schätzung der Einwohnerzahl zu sortieren, in dem sie die Städte untereinander ins Verhältnis setzen. Auffällig ist – neben der höheren Trefferquote – dass der Aufwand in der ersten Variante viel höher, obwohl das Ergebnis schlechter ist. Das Beispiel zeigt uns also, dass das vergleichende Schätzen zu deutlich schnelleren und besseren Ergebnissen führt. Hierfür sprechen auch die zahlreichen Beobachtungen aus der Praxis, die eben diesen Zusammenhang bestätigen. Während wir bei der Schätzung in absoluten Werten auf historische Werte zurückgreifen und diese analysieren – damit Aufwand erzeugen – ist das relative Schätzen intuitiv und damit schneller und verlässlicher. Insbesondere dann, wenn wir – ein weiterer Unterschied des agilen Schätzens in Vergleich zur klassischen Aufwandsschätzung – auf die Teamkompetenz setzen. Denn in allen agilen Ansätzen wird grundsätzlich das ganze Team beteiligt. Die Schätzung findet im Dialog statt. Auf diese Weise wird das gemeinsame Verständnis im Team für die Aufgaben gestärkt, aber auch die Erfahrung aller Teammitglieder eingebunden und eine genauere Schätzung des Aufwands erzielt. Letzteres ist gerade bei komplexen Sachverhalten nicht zu unterschätzen. Zusammengefasst lassen sich folgende Vorteile der relational-vergleichende Schätzung feststellen: 1. Sie sind schneller durchführbar als absolute Größen. Uns fällt es oft einfacher, Dinge in Relation zueinander zusetzen und so zu erkennen, was größer oder kleiner ist, als in die Benennung in absoluten Werten. Das Schätzen ist intuitiver, effizienter. 2. Relationale Schätzungen müssen nicht permanent durch Neuschätzungen korrigiert werden. Die Komplexität ändert sich nicht. Und da diese der Bezugspunkt der Schätzung ist, sind Anpassung nicht notwendig. Anders, als wenn wir den Aufwand in absoluten Werten wie Zeit geschätzt hätten. Hier bleibt der wachsenden Erfahrungsund Kenntnisstand im Zuge des Projekts als Variable erhalten und führt zum permanenten Anpassungsbedarf. 3. Durch die Trennung von Komplexität und Aufwand können Schätzungen erstellt werden, ohne dass wir alle Faktoren detailliert kennen. Das bezieht auch die Individuen im Team ein, die aufgrund ihrer Erfahrungen und ihres können unterschiedliche Leistungsgrade mitbringen können. 4. Durch die Diskussion mit und in dem Team über die geschätzte Aufgabe bekommt das Team ein gemeinsames Verständnis von der Anforderung, die erreicht werden soll. Unklarheiten werden früh erkannt und offene Fragen in einem frühen Stadium mit allen Anspruchsberechtigten geklärt werden.

106

T. Michl

10.4 Storypoints als Maßeinheit Ein wesentlicher Unterschied zwischen „klassischen“ und agilen Methoden bei der Schätzung ist auch, dass „agile“ Schätzungen in aller Regel keine abstrakten Schätzwerte zugrunde legen, sondern den jeweiligen Aufwand für eine Anforderung untereinander in Beziehung setzen. Gelegentlich werden noch Idealtage für die Schätzung verwendet. Allerdings hat sich in der Praxis gezeigt, dass die Schätzung in Idealtagen im Sinne von Fehlinterpretationen risikobehaftet ist. Zu sehr besteht hier wieder die Neigung, die Schätzung als Verpflichtung anzusehen (weiter oben wurden die Folgen bereits thematisiert). Daher haben sich als Maßeinheit die sogenannten Storypoints in vielen agilen Projekten durchgesetzt. Der Begriff Storypoints lehnt dabei an der sogenannten User Story an, die sich als Hilfsmittel zur Beschreibung von Anforderungen im agilen Umfeld durchgesetzt und bewährt hat. Diese stellen wir im Kap. 13 nochmals etwas ausführlicher dar. Storypoints sind eine abstrakte Maßeinheit, die sich nicht ohne Weiteres beziffern lässt. Was ein Storypoint ist, richtet sich dabei nach verschiedenen Faktoren, unter anderem nach der Komplexität und Struktur der User Storys (und Epics). Dabei geht es nicht um eine Zeiteinheit, sondern ausschließlich um die Struktur und Größenrelationen zueinander. Das hört sich zunächst schwierig an, erschließt sich aber zumeist aus der Praxis und den Schätzverfahren selbst. Im ersten Moment mag die Frage im Raum stehen, was denn nun ein Storypoint ist. Gerade wenn Menschen es gewohnt sind, mit klassischen Schätzungen zu arbeiten, kann es hier zu Irritationen kommen. Hier ist der Moderator gefragt. Sinnvoll ist, sich eine Referenz wie z. B. die kleinste User Story, die dann als Bezugspunkt für den Vergleich mit den anderen dient.

10.5 Schätzmethoden – zwei Beispiele Im Folgenden stellen wir zwei weitverbreitete Schätzmethoden vor, die häufig zur Anwendung kommen. Einmal die sogenannte T-Shirt-Methode und zum anderen das sogenannte Planning Poker:

10.5.1 T-Shirt-Methode Eine sehr einfach nachvollziehbare Methode der Aufwandsschätzung basiert auf einer alltäglichen und daher für viele sehr leicht nachvollziehbaren Darstellung in Anlehnung an die amerikanischen T-Shirt-Größen. Hierbei werden die bekannten T-Shirt-Größen (S, M, L, XL, XXL) zugrunde gelegt und als „Schätzwerte“ verwendet, um die einzelnen User Storys in Beziehung zu setzen. Vorteil dabei ist, dass sich auf Basis der Metapher mit den T-Shirt-Größen relativ schnell

10  Agile Aufwandschätzungen

107

Abb. 10.4   Storypoints nach T-Shirtgrößen

ein gemeinsames Verständnis herstellen lässt. Jeder hat eine ungefähre Vorstellung darüber, was S oder XL bedeutet und in welcher Beziehung die Größen zueinander stehen (Abb. 10.4). Die Teammitglieder schätzen gemeinsam, wie sie das Verhältnis zwischen den verschiedenen zu bearbeitenden Anforderungsblöcken bewerten. Allerdings hat diese Vorgehensweise, trotz der ihr bestechenden Einfachheit, einen Haken. Sie ist besonders anfällig für gruppendynamische Prozesse wie Groupthink1 u. ä. Phänomene, die zu Verzerrungen führen können.

10.5.2 Planning Poker Etwas aufwendiger aber weitverbreitet ist das sogenannte Planning-Poker (Abb. 10.5). Das Planning-Poker hat sich bewährt und geht auf James Grenning zurück, der die Methode 2002 erstmalig vorstellte. Mike Cohen, ein agiles Urgestein, hat die Methode 2008 mit seinem damals erschienen Buch2 populär gemacht, die dann rasant Verbreitung in der agilen Szene fand. Die Planning-Pokerdecks bedienen sich der sogenannten

1Gruppendenken ist

ein Prozess, bei dem eine Gruppe von an sich kompetenten Personen schlechtere oder realitätsfernere Entscheidungen als möglich trifft, weil jede beteiligte Person ihre eigene Meinung an die erwartete Gruppenmeinung anpasst. Daraus können Situationen entstehen, bei denen die Gruppe Handlungen oder Kompromissen zustimmt, die jedes einzelne Gruppenmitglied unter anderen Umständen ablehnen würde. 2Mike Cohen, Agile Estimation, Prentice Hall (2006).

108

T. Michl

Abb. 10.5  Planning Poker. (Quelle: wikipedia, public domain)

Fibonnacci-Folge3. Einer Zahlenfolge, bei der die Summe zweier aufeinanderfolgender Zahlen die unmittelbar danach folgende Zahl ergibt. Anders als bei der Schätzung nach T-Shirt-Größen ist die Abstraktion hier etwas größer, was sicherlich den Einstieg etwas erschwert. Jedes Teammitglied erhält einen Satz Planungskarten. Der Scrum Master (in scrumgeführten Projekten) leitet das Team an. Die Regeln sind relativ einfach zusammengefasst: 1. Der Product Owner (PO) wählt aus dem Product Backlog eine User Story aus, die geschätzt werden soll, und stellt dieses dem Team vor. 2. Die Teammitglieder haben jetzt die Möglichkeit, dem PO Fragen zu stellen und über die User Story zu diskutieren, um ein gemeinsames Verständnis über den zu schätzenden Umfang zu entwickeln. Hierbei ist es wichtig, dass noch nicht bis in alle Feinheiten die Lösung konzeptioniert wird, da dies viel zu lange dauern würde.

3Benannt

nach dem Mathematiker Leonardo Fibonacci.

10  Agile Aufwandschätzungen

109

3. Jedes Teammitglied wählt im Anschluss eine Karte aus, die seiner Meinung (Intuition/ Bauchgefühl) dem Aufwand entspricht, und legt diese zunächst verdeckt vor sich hin. Haben alle Teammitglieder ihre Entscheidung getroffen, werden die Karten aufgedeckt. 4. Sind die Schätzwerte identisch, besteht ein Konsens und damit ist die Schätzung für die ausgewählte User Story abgeschlossen. Gibt es keinen Konsens, wird im Team nochmals diskutiert, um die Hypothese zu prüfen und Missverständnisse auszuräumen. Danach wird erneut geschätzt. Dieser Schritt wird solange wiederholt, bis das Team einen Konsens beim Schätzwert erzielt. Damit nicht mehr so viel diskutiert wird, sagen Jene mit den wenigsten und meisten Punkten, warum sie so bewertet haben. Wichtig ist sich immer wieder vor Augen zu führen, dass es hierbei nicht darum geht, den Aufwand in Stunden oder anderen Werten zu erfassen, sondern einen Bezug zwischen den unterschiedlichen Arbeitspaketen herzustellen. Gerade in der Anfangsphase, wenn mit agiler Schätzung gearbeitet wird, ist die Versuchung groß, wieder zur Schätzung in absoluten Werten zurückzukehren. Je länger ein Team zusammenarbeitet, umso größer ist der Fundus von erledigten Stories, die als Referenzen dienen. Neben den hier genannten Methoden kommen auch das sogenannte Estimation Game oder Speed-Estimation häufig zu Einsatz. Der Bedeutung von Speed Estimation entsprechend, haben wir dem Thema ein eigenes Kapitel eingeräumt, in dem Martin Bartonitz die Methode ausführlich darstellt.

10.6 Wann und wie oft wird geschätzt? Gerne wir kolportiert, dass die Aufwandsschätzung ausschließlich im Rahmen des Backlog Refinement, also der Pflege der Liste an Anforderungen und Aufgaben in der Warteschleife, und im Zuge des periodischen Planungsphase (bei der Anwendung von Scrum wäre dies im Sprint Planning der Fall) stattzufinden hat und sonst keine Aufwände geschätzt werden.4 Es bietet sich natürlich an, eben an diesen Stellen die Aufwandsschätzung vorzunehmen und als Teil des Planungsprozesses anzusehen. In Scrum wird daher oft – zusätzlich zu den Besprechungen, die im Scrum Guide eingeführt sind – auch noch das Estimation Meeting5 eingeführt, in dem die genannte Backlog-Pflege stattfindet. Allerdings gilt auch hier: Schätzungen sind nicht in Stein gemeißelt. Zeichnet sich im Folge fortschreitender und neuer Erkenntnisse ab, dass die Einschätzung nicht korrekt war oder ist, ist es jederzeit erlaubt, die Aufwandsschätzung zu korrigieren. Ja, es ist sogar nicht nur erlaubt, sondern ausdrücklich erwünscht.

4Vergl. 5Vergl.

Rubin (2017, S. 2019 ff.). Dräther et al. (2013, S. 71 ff.) und Gloger (2016), S. 154 ff.

110

T. Michl

10.7 #NoEstimates – ganz ohne Schätzung Es gibt allerdings auch Stimmen, die ganz auf eine Aufwandschätzung verzichten. Diese argumentieren – obwohl sie Verständnis für den Hintergrund der Aufwandschätzung aufbringen – damit, dass der Prozess der Aufwandsschätzung unproduktiv sei. Hintergrund ist, wie auch schon eingangs erwähnt, dass Schätzungen eine hohe Unschärfe aufweisen. Insbesondere in Entwicklungsprojekten, die in aller Regel darauf abzielen, etwas Neues zu schaffen, gibt es keine verlässlichen Erfahrungswerte, auf die zurückgegriffen werden könnte. Schätzungen sind daher per se fehlerbehaftet und Verschwendung, da sie darüber hinaus keine Wertschöpfung erzeugen. Sie sind „Wombat“ (=Waste of money, buget and time).6 Vertreter dieses Ansatzes setzen daher besonders ihr Augenmerk auf die kontinuierliche Auslieferung von fertigen

Abb. 10.6  Wombat – Alfred Edmund Brehm (1829–1884) – Brehms Thierleben 1829–1884. (Wikpedia: https://commons.wikimedia.org/wiki/File:Brehms_Tierleben_-_Wombat_1884.jpg)

6Der Begriff Wombat ist aus dem Lean Management entlehnt und steht für extreme Verschwendung im Sinne von „nicht-wertschöpfend“.

10  Agile Aufwandschätzungen

111

Teilpaketen. Ein Vergleich zwischen geschätztem Wert und tatsächlich erreichten Wert als Messgrad der Produktivitätsentwicklung im Team wird hier abgelehnt (Abb. 10.6). Der kontinuierliche Fluss der ausgelieferten und akzeptierten Teilpakete ist nach dieser Auffassung ausreichend, da es ohnehin in erster Linie darum geht, den Kundenbedürfnissen gerecht zu werden. Aufwandsschätzungen werden daher in diesem Sinne als sinnlos und nicht wertschöpfend erachtet. Daher kann auf sie verzichtet werden. Die Transparenz im Dialog zwischen Auftraggeber und Team gibt darüber hinaus hinreichend Hinweise zu Verbesserungspotenzialen. Alle zusätzlichen Quantifizierungsmaßnahmen tragen nicht maßgeblich dazu bei, einen Mehrwert zu schaffen, der den zusätzlichen Aufwand rechtfertigt.

Literatur Cohen M (2006) Agile estimation. Prentice Hall, New Jersey Dräther R, Koschek H, Sahling C (2013) Scrum – kurz und gut. O’Reiley, Köln Gloger B (2016) Scrum. Hauser, München Rubin K (2017) Essential Kanban. MITP Verlags GmbH, Frechen

Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger consulting.

Speed Estimation – viele User Stories in kurzer Zeit schätzen

11

Martin Bartonitz

Zusammenfassung

In diesem Kapitel wird eine Methode beschrieben, wie viele SCRUM User Stories mit dem Team, das diese umsetzen wird, mit wenig Aufwand und in kürzester Zeit für eine grobe Planung ausreichend gut geschätzt werden können.

11.1 Einleitung In der Regel steht ein Projektleiter am Anfang vor einem großen Berg an zu erledigenden Aufgaben, die am Ende in Zeit und Budget zu einem befriedigenden Abschluss für alle Beteiligten führen sollen. Der übliche Weg ist es, die einzelne Aufgabe komplett in ihre kleinen Einzelteile zu zerlegen und diese dann abzuschätzen. Dieses Vorgehen ist allerdings sehr zeitintensiv, und da aber gerade in agilen Projekten im Laufe der Umsetzung immer wieder Änderungen an den Annahmen getroffen werden, ist es besser, sich nicht zu sehr in den Details der Planung zu verlieren. Die im Folgenden vorgestellte Methode ist inzwischen mehrfach mit Erfolg ausprobiert worden, um im Team die für das nächste Jahr umzusetzenden User Stories des Backlogs abzuschätzen. Die Schätzung hilft, den ungefähren Fertigstellungszeitpunkt auf Basis der Team-Geschwindigkeit errechnen zu können. Diese Methode ist zwar im Kontext der Software-Entwicklung angewandt worden, sie sollte aber in allen anderen Kontexten genauso gut funktionieren.

M. Bartonitz ()  Produktmanagement, c/o OPTIMAL SYSTEMS GmbH, Berlin, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_11

113

114

M. Bartonitz

11.2 Zum Hintergrund am Beispiel eines konkreten Projekts Wir hatten begonnen, einen neuen Browser-basierten Client für unser Enterprise Content Management System zu entwickeln. Welche Funktionen in diesem Client zur Verfügung stehen sollten, war offensichtlich: Er sollte möglichst das können, was schon mit dem alten Client verfügbar war. Allerdings war ein neues Team zusammengestellt worden, das den Client auf Basis neuer Technologie entwickeln sollte. Und so war das Wissen um die Funktionen bei den meisten Teammitgliedern entweder kaum oder doch eingeschränkt vorhanden. Denn auch die Zusammenstellung des Teams war neu: Es waren sowohl Entwickler für die Oberfläche als auch für die Service-Infrastruktur dabei. Und so war meist nur ein gewisser Ausschnitt der Funktionen bekannt. Das Team arbeitete inzwischen 3 Monate zusammen, die Infrastruktur war geklärt, und der Rumpf des Clients war funktionstüchtig. Für die Firma neu war die agile Entwicklungsmethodik SCRUM, die wir als erstes Team erproben durften. Inzwischen arbeiten alle 6 Entwicklungsteams der Firma nach dieser Methode. Erste Erfahrung mit den Schätzungen von Storypoints waren vorhanden. Und nun konnte begonnen werden, den Umfang des gesamten Vorhabens zu verstehen. Sprich, es stand der Blick auf alle User Stories, die ich inzwischen für das erste Entwicklungsjahr geplant hatte, nach und nach an das Team zu Abschätzung zu geben, an. Es waren über 150 Stories. Und da das übliche Verfahren eines Refinements1 einer einzigen Story zwischen 30 und 90 min lag, um eine fundierte Schätzung abgeben zu können, musste ein geeignetes Verfahren her, in kürzester Zeit dennoch zu einer Schätzung zu kommen.

11.3 Der vom Team vergebene Name der Methode: SPEED ESTIMATION Wir hatten von einer ähnlichen Methode gehört (leider kann ich mich nicht mehr erinnern, woher), dann einige Anpassungen vorgenommen, und dem Kind einen passenden Namen gegeben.

1Das

Product Backlog Refinement (auch Backlog Grooming genannt) ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören: Ordnen der Einträge, Für die Gestaltung des Produkts und des Product Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product-Backlog-Refinement-Treffen zusammen mit ausgewählten Stakeholdern. Das Product Backlog Refinement sollte nicht mehr als 10 % der Zeit des Entwicklungsteams in Anspruch nehmen.

11  Speed Estimation – viele User Stories in kurzer Zeit schätzen

115

11.3.1 Räumlichkeit Getroffen haben wir uns in einem Raum mit einem großen Tisch. Die Stühle wurden an den Rand gestellt, sodass alle bequem um den Tisch herumlaufen konnten. Auf dem Tisch lagen gleichmäßig verteilt Zettel mit den für SCRUM typischen Storypoints 1, 2, 3, 5, 8, 13, 20, 40, 100, ?. Das Team hatte inzwischen eine Vorstellung davon, welche Komplexität zu den unterschiedlichen Storypoints passt. An dem einen Kopf des Tisches hatte ich mich mit dem Stapel der vorbereiteten Stories positioniert. Noch ein Hinweis zu den Storypoints. Die User Stories werden nicht in Personentagen geschätzt, sondern in den oben aufgezählten Komplexitätsgraden. Das Team hatte schon einige Stories umgesetzt und hatte damit eigene Erfahrungen, wie es Komplexitäten beurteilt.

11.3.2 Vorbereitung der Stories Ich hatte jede Story auf einem Zettel so groß wie ein 1/4 DIN-A4-Blatt ausdrucken lassen und auf einem Stapel unsortiert liegen. Auf jedem Blatt stand ein Satz: „In der Rolle des XYZ möchte ich die FUNKTION, sodass der ZWECK erreicht ist.“. Anschließend hatte ich den Ablauf des Schätzens mit dem Team geklärt.

11.3.3 Ablauf der Schätzung „Timeboxing“ ist hier die Basis! Es waren 8 Teammitglieder anwesend. Ich hatte innerhalb von 3 min insgesamt 8 Stories vom Stapel genommen und kurz vorgestellt. Eines der Team-Mitglieder hat dann den Zettel mit der gerade vorgestellten Story übernommen. Meist Jener, der die beste Vorstellung von der Komplexität hatte. Nachdem der letzte der 8 Zettel übergeben war, wurde die Stoppuhr mit erneut mit 3 min gestartet. In dieser Zeit hat jeder seinen Zettel vor einen der oben beschriebenen Storypoint-Zettel gelegt, der ihm passend erschien. Anschließend sind alle nochmals herumgegangen und haben ggf. bei einem scheinbar unpassend gelegten Zettel kurz mit dem Legenden diskutiert, sodass noch ein Verrücken möglich war. Nach Ablauf der Zeit wurden die Story-Zettel dann hinter die Storypoint-Zettel zur Mitte des Tisches gelegt.

116

M. Bartonitz

11.3.4 Abschlussarbeit Es gab drei User Stories, die zum Fragezeichen gelegt wurden. Diese User Stories hatten wir beschlossen, in einer eigenen Sitzung zu schärfen, da ihre Komplexität auf Basis von zu wenig Wissen noch nicht eingeschätzt werden konnte.

11.4 Zusammenfassung und Erkenntnisse So wurden pro 6 min jeweils 8 User Stories geschätzt, also waren die über 150 Stories in 120 min durch. Nun war das Team mit mir auf Augenhöhe, was das gesamte Vorhaben betraf. Und ich war mir sicherer als zuvor, was die Menge an anstehender Arbeit betraf, und dass wir nur wenige der optionalen User Stories nicht schaffen würden. Versuchen wir noch einen Transfer mit ein wenig Abwandlung auf eine konkrete Anforderung im öffentlichen Dienst:

11.5 Einführung eines Dokumentenmanagementsystems – #eGovernance Ein kleine Kommune stellt dem Umsetzungsteams die Frage: Wie lange wird es dauern, bis das DMS flächendeckend eingeführt ist? Und wie hoch wird unser Ressourcenverbrauch sein (=Projekt-Manntage)? Dabei lässt sich folgendermaßen vorgehen • Schätze den Aufwand „1 Prozess ins DMS überführen“ im Projektteam. Führe dazu eine Checkliste aus 13 Schritten, die den Ablauf eines Bausteins „1 Prozess ins DMS überführen“ darstellt. Der Aufwand pro Schritt ist aber sehr variabel, je nachdem, wie komplex der Prozess ist. Also lasse für jeden Baustein drei Varianten „einfach“, „mittel“, „komplex“ schätzen und nehme den Mittelwert dieser Varianten (dabei wird die mittlere Variante doppelt gewichtet). Aus der Summe ergibt sich eine grobe Aufwandschätzung. • Schätze die Zahl der Prozesse in der Verwaltung. Dazu gibt es Erfahrungswerte aus vergangenen Projekten. Die Anzahl der Prozesse einer Verwaltung hängt von der Ebene ab (kleine Gemeinde, Stadtkreis, Landkreis). • Dann schätze die Rüstkosten pro Abteilung. Jede Abteilung, die in das Projekt aufgenommen wird, braucht ca. 1,5 Tage an Einstiegsschulung in Projektmanagement, Kennenlernen des Rahmen-Aktenplans, wie man ihn an die eigenen Bedürfnisse anpasst usw.

11  Speed Estimation – viele User Stories in kurzer Zeit schätzen

117

• Dann kommt noch der Aufwand für Rüst- und Beratungskosten der Gesamtverwaltung hinzu (Bericht vor dem Bürgermeister, vor dem Gemeinderat oder Ausschuss, Projektcontrolling). Das setze mit 10 % an (knapper Erfahrungswert bei gut laufenden Projekten, wo die Führungskräfte nicht mit Mikromanagement stören). Mit diesem Verfahren steht am Ende eine Summe an Personentagen, gegliedert nach Umsetzungsteam und Tagen, die von Mitarbeitern der Fachabteilungen geleistet werden.

Dr. Martin Bartonitz ist Produktmanager und SCRUM Product Owner bei OPTIMAL SYSTEMS GmbH, Hersteller eines Enterprise Content Management Systems. Er studierte Experimentelle Physik und wechselte nach seiner Promotion 1992 von der Messprozesssteuerung in die Welt der Geschäftsprozessautomatisierung. In seinen über 25 Jahren befasste er sich im Schwerpunkt mit den fachlichen Anforderungen der Dokumentverwaltung und -steuerung, u. a. auch im öffentlichen Sektor. Seit 12 Jahren arbeitet er mit agilen, sich selbstorganisierenden Teams und schreibt über seine hier gemachten Erfahrungen in Blogartikeln.

12

Retrospektiven – wir entwickeln uns weiter Ludger Wagner

Zusammenfassung

Retrospektiven sind für mich das zentrale Element, um Veränderungen anzustoßen und den Wandel hin zu agilerem persönlichen Arbeiten oder Arbeiten im Team zu bewirken. Ebenso sind sie das entscheidende Werkzeug, um den Wandel einer Organisation hin zu den agilen Werten zu befördern, der in der Literatur oft als Agile Transition beschrieben wird. Was siehst du aber den Splitter in deines Bruders Auge, wirst aber nicht gewahr des Balkens in deinem eigenen Auge? Matthäus 7:31

1http://bibeltext.com/matthew/7-3.htm.

L. Wagner ()  Beratung Ludger Wagner, Forum Agile Verwaltung e. V., Berlin, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_12

119

120

L. Wagner

12.1 Warum Retrospektiven? Eine Einleitung Retrospektiventechniken sind nach dem Verständnis und dem Befolgen der agilen Werte, Prinzipien2 und Praktiken das zentrale Instrument im „Agilen Management“3. Erst durch sie wird Veränderung überhaupt möglich und kann gelingen. Retrospektive bedeutet das Zurücktreten vom Tagesgeschäft, der Hektik und Betriebsamkeit des Alltags. Es ist einfach wichtig, sich regelmäßig Zeit zu nehmen, um eine Bestandsaufnahme auf das „Was war?“ zu machen. Durch diesen Abstand und das Betrachten des Prozesses von „außen“ wird es möglich zu erkennen: 1. was derzeit gut läuft, 2. was schlecht und verbesserungswürdig ist und 3. was Sie verändern möchten. Und dabei sind wir auch schon bei den drei oft verwendeten Fragen für die Gestaltung von Retrospektiven. Stellen Sie sich bereits selbst regelmäßig diese drei Fragen? Sehen Sie selbst schon immer, was hervorragend funktioniert hat und was nicht so gut gelaufen ist? Nehmen Sie sich Veränderungen vor und führen Sie diese in ihrem Leben und Ihrer Arbeit auch stetig durch? Lernen Sie hierdurch jeden Tag, jeden Monat, jedes Jahr und Jahrzehnt – also Ihr Leben lang dazu, entwickeln sich weiter und schreiten voran? In diesem Fall, liebe Leserin und lieber Leser, machen Sie selbst bereits alles richtig und brauchen das folgende Kapitel über Retrospektiven nicht mehr zu lesen.

12.2 Der Start: Die persönliche Retrospektive In meiner Arbeit als Scrum Master und Agile Coach habe ich schon viele Retrospektiven für verschiedenste Teams, in sehr unterschiedlichen Kontexten moderiert und durchgeführt. Was ich persönlich allerdings erst seit meiner selbstständigen Tätigkeit mache, ist, mir für mich und meine Arbeit, ganz persönlich Zeit zu nehmen, um Rückschau zu halten. Dabei betrachte ich mein eigenes Arbeiten, hinterfrage und verändere es. Diese persönlichen Retrospektiven führe ich seit kurzem durch und möchte Ihnen hier meine

2Agile

Werte, Prinzipien sind im Agilen Manifest beschrieben: http://agilemanifesto.org/iso/de/ manifesto.html. 3Mit dem Begriff „Agiles Management“ bezeichne ich in meinem Alltag gerne alles rund um meine Arbeit als Agile Coach. Ich habe die Erfahrung gemacht, dass ich mit dem Begriff meinen Arbeitsschwerpunkt für Personen, die bisher noch nicht mit der „Agilen Welt“ in Berührung gekommen sind, gut beschreiben kann.

12  Retrospektiven – wir entwickeln uns weiter

121

Erfahrungen damit beschreiben. Nicht als agiler Coach, sondern als Berater, der Ihnen Mut machen möchte, es selbst für sich zu versuchen. Zu Beginn jeder Woche nehme ich mir etwa 30 min Zeit, um mir die folgenden drei Fragen zu stellen: 1. Rückschau: Wie war für mich die letzte Woche? 2. Erkenntnisse: Was lerne ich daraus? (Hier frage ich nach dem „Warum“, solange bis mir nichts Neues mehr einfällt). 3. Veränderungen: Was möchte ich verändern? Wie verändern diese regelmäßigen persönlichen Retrospektiven mein Arbeiten? Ich habe für mich gelernt, was mir wichtig ist und was schon gut funktioniert. Das hilft mir dabei, das Gute beizubehalten. Ich habe aber auch gemerkt und musste mir eingestehen, wo meine Schwächen liegen. Ich überlege mir immer wieder, was ich versuchen kann, um mit diesen meinen (unvorteilhaften) Eigenschaften klarzukommen. Wie kann es mir gelingen, meine Freude an der Arbeit nicht zu verlieren und gute Ergebnisse zu erzielen? Ich komme immer wieder zu neuen Erkenntnissen und schreibe meine (selbst gesteckten) Vorsätze in Form von eigenen Verhaltensregeln (in Englisch Working Agreements) mit der Methode „KEEP, START, STOP“4 auf. Ich schreibe sie gut sichtbar auf eine hinter meinem Arbeitsplatz angebrachte Glastafel. Sie begleiten mich die folgende(n) Woche(n) über. Ich versuche sie jeden Morgen, aber auch manchmal, gerade wenn ich zwischendurch genervt oder unzufrieden bin, zu lesen und auf diese Weise beim täglichen Arbeiten zu beachten und sie zu verinnerlichen. Zu Beginn meiner „persönlichen Retrospektive“ habe ich 2–3 Mal an denselben Themen gearbeitet, zum Beispiel: Fokus auf das Wichtige behalten, nicht zu viel gleichzeitig machen und nicht zu viel machen wollen (keine Überplanung). Das habe ich inzwischen einigermaßen in den Griff bekommen. Ich setze mir jetzt Wochenziele und priorisiere diese. Ich schaue mir meine Wochenziele zu Beginn jedes Arbeitstages an. Dadurch weiß ich stets, was kommt und was ich noch schaffen möchte oder muss, um mein Ziel zu erreichen und meine Woche erfolgreich abzuschließen. Ich nehme mir nicht mehr so viel vor. Das schafft mir Freiräume und ich gerate weniger in negativen Stress. So kann ich mich auf die wirklich wichtigen Ziele (und Aufgaben) konzentrieren. Nach den ersten 2–3 Wochen mit meinen persönlichen Retrospektiven spürte ich bereits deutliche Verbesserungen bei meinem Arbeitsprozess bei meiner eigenen Priorisierung, Planung und Fokussierung. So bin ich jetzt in der Lage, in die Zukunft gerichtete

4Methode

START KEEP STOP: Mit dieser Methode können sich persönliche Verhaltensregeln aufschreiben und über einen längeren Zeitraum aktuell halten lassen. Unter START oder „Beginnen mit“ stehen alle Punkte, die ich neu einüben möchte. Unter KEEP oder „behalten“ stehen die Punkte, die gut funktionieren, auf die ich weiter achten und die ich ausbauen möchte. Unter STOP oder „aufhören“ schreibe ich Punkte, die ich nicht mehr so fortführen möchte.

122

L. Wagner

Aufgaben in meine Wochenziele einzuplanen. Bei mir ist das derzeit z. B. Zeit fürs ­Lernen, die fachliche Weiterentwicklung. Ich habe jetzt mehr Zeit für mich persönlich und für meine Nebenprojekte sowie meine Familie.

12.3 Kriterien für eine gute Retrospektive Was braucht es, damit die (persönliche) Retrospektive gelingen kann? Wichtig ist vor allem der Mut, es mit Retrospektiven und der (persönlichen) Weiterentwicklung zu probieren und diese anzugehen. Dann natürlich braucht es den Willen durchzuhalten und nicht nach der ersten oder zweiten Retrospektive wieder aufzuhören. Nach meinen Erfahrungen hilft es (besonders in Teams, die gerade erst mit Retrospektiven beginnen) gleich zu Beginn sofort erste sichtbare Erfolge zu haben. Wenn alle Beteiligten sofort spürbare Verbesserungen erleben, steigt die Motivation mit Retrospektiven weiterzumachen ebenso wie das Vertrauen in die eigene Leistungsfähigkeit. • Nehmen Sie sich ausreichend Zeit für die Retrospektive. Mit der Zeit und der entsprechenden Erfahrung und Übung werden Sie sie bald auch zügiger durchführen können. Hin und wieder ist es aber auch später sinnvoll, sich hierfür wieder ein größeres Zeitfenster einzuräumen. • Nehmen Sie sich regelmäßig Zeit für die Retrospektive. Wenn Sie dies nicht tun, dann sind Retrospektiven zwar auch gut, aber meiner Erfahrung nach längst nicht so wirkungsvoll5. • Gehen Sie wohlwollend mit sich um (und mit anderen, siehe Kapitel „Retrospektiven im Team“). Vergessen Sie nicht zu schauen, was alles schon gut läuft. Gutes sollten Sie unbedingt weiter stärken, genießen und ausbauen. • Nehmen sie sich nicht zu viele (große) Veränderungen auf einmal vor. Meine Praxis zeigt, dass es am nachhaltigsten ist, höchstens ein bis zwei Veränderungen bei einer Retrospektive ins Auge zu fassen. • Schauen Sie bei der nächsten Retrospektive, was die Auswirkungen der Änderungen waren und justieren Sie gegebenenfalls nach. Manche Änderungen brauchen allerdings Zeit. Legen Sie fest, wie lange Sie eine Veränderung durchhalten wollen, bis Sie sie beurteilen und wieder verwerfen.

5Als

Negativbeispiel für Retrospektiven kennen Sie vielleicht die eigene Jahresendretrospektive zu Silvester oder am Neujahrstag: die guten Vorsätze. Wie oft und wie lange halten Ihre Vorsätze? Wie oft überprüfen Sie ihre Wirkung und Beibehaltung? Wie oft passen Sie ihr Verhalten in kleinen Schritten an um Ihre Ziele (die Vorsätze) zu erreichen? Regelmäßigkeit und Kleinschrittigkeit sind also meiner Erfahrung nach sehr wichtig und hilfreich für das Gelingen von Veränderungen.

12  Retrospektiven – wir entwickeln uns weiter

123

12.4 Retrospektiven im Team Bisher habe ich viel über persönliche Retrospektiven geschrieben. Ich halte diese für sehr geeignet, um sich an das Thema „Retrospektiven“ heranzutasten, erste Versuche zu starten und Erfahrungen zu sammeln. Alle beschriebenen Kriterien und auch die Vorgehensweisen kann man aber ebenso auf Retrospektiven im Team übertragen und dort anwenden. Ich denke, es hilft, sich persönlich dem Veränderungsprozess zu stellen und sich weiterzuentwickeln. Allerdings arbeiten wir meistens nicht nur für uns selbst, sondern im Kontext mit anderen Menschen, in festen, aber auch in temporären sich verändernden Teams. Hier ist das Anwenden und regelmäßige Durchführen von Retrospektiven besonders herausfordernd, aber auch besonders wirkungsvoll. Wenn ich mich verändere, ist das gut, wenn ich aber noch meine Umgebung, meine engen Kollegen, mein Team, meine Abteilung, meinen Bereich, mein Amt, meine Kommune, meinen Landkreis, mein Bundesland, mein Land, meinen Kontinent, regelmäßig betrachte und verändere, dann habe ich das Potenzial, damit die Welt zu verändern. Gewohnte Wege zu verlassen und neue zu beschreiten fällt oft nicht leicht. Es verlangt häufig Mut und viel Durchhaltevermögen. Das kennen Sie vermutlich aus eigener Erfahrung. Besonders im Team ist es wichtig, behutsam zu beginnen. Dafür braucht es als Grundlage das Vertrauen der Teammitglieder untereinander, wie auch zum eventuell begleitenden Coach oder Moderator.

12.4.1 Retrospektiven in einem nicht agilen Umfeld Arbeitet ein Team nach Scrum, sind Retrospektiven fester und wichtiger Teil des Prozesses und haben damit dort ihren festen Raum, ein extra dafür eingeplantes Zeitfenster (etwa eine Stunde pro Woche, also 1/40 der regulären Arbeitszeit). Wenn Sie allerdings noch ganz am Anfang stehen, ist es oft sehr schwer, die Kollegen zu überzeugen, sich wertvolle Retrospektivenzeit zu nehmen. Der Wert einer Retrospektive ist noch nicht bekannt und oft wird die Retrospektive als zusätzlicher Aufwand neben der alltäglichen Arbeit empfunden. Retrospektivenzeit ist jedoch Arbeitszeit und als solche wertvoll und sinnvoll. Dieses Verständnis muss allerdings erst selbst erlebt und verstanden werden. Dazu müssen möglichst schon in der ersten Retrospektive für alle die Verbesserungen sichtbar werden. Ich empfehle Ihnen, mit regelmäßigen Besprechungen zu beginnen, dies können auch bereits bestehende Termine sein wie ein wöchentlicher Jour Fixe oder eine ­monatlich stattfindende Arbeitssitzung. Reservieren Sie sich dort einen Teil der Zeit für „Veränderungen und Verbesserungen“ und erläutern Sie den Sinn dahinter.

124

L. Wagner

In der Scrum Literatur wird dabei oft von „Inspect and Adapt“6 gesprochen. Hinter diesen zwei Begriffen stecken die beiden wesentlichen Teile einer Retrospektive. Inspect bedeutet hierbei das Anschauen dessen, was gewesen ist. Mit „adapt“ ist die Anpassung des Vorgehens und der Arbeitsweise an neue Erkenntnisse gemeint. Wenn Sie bisher kein regelmäßiges Treffen mit Ihren Kollegen haben, dann initiieren Sie eines. Es wird Ihnen schnell dabei helfen, die eigene Arbeitsweise zu verbessern. Wenn Sie täglich jede Woche ein Statusmeeting mit Ihren Kollegen durchführen, dann versuchen Sie z. B. 20 % der Zeit auf die Reflexion über das gemeinsame Arbeiten und die Definition möglicher Verbesserungen zu verwenden. Bei einem Treffen von einer Stunde wären das z. B. die ersten oder die letzten 10 min des Termins7. Wenn Sie sich einmal im Monat regelmäßig treffen, dann würde ich ebenfalls 20 % des Termins dafür anvisieren. Auch hier gilt wieder die Regel „Inspect und Adapt“. Starten Sie einfach, beobachten Sie, wie die Veränderungen wirken und passen Sie Ihr Vorgehen an, damit Sie (und Ihre Kollegen) den meisten Nutzen daraus ziehen können.

12.4.2 Beispiele einer Retrospektive (von der Konferenz Agile Verwaltung 2018 in Stuttgart) Wie sieht eine professionell moderierte Retrospektive (mit vielen Teilnehmern) aus? Was sind dort mögliche Techniken und Werkzeuge? Wie viel Zeit sollte man einplanen? Was sollte man vorbereiten und bedenken? Was passiert mit den Ergebnissen? Um dies zu zeigen möchte ich Ihnen den Aufbau und die Ergebnisse der Retrospektive im Workshop-Teil der 2. Konferenz „Agile Verwaltung“ vom Februar 2018 in Stuttgart an der Hochschule für Medien vorstellen. Er wurde von Patricia Baumkircher durchgeführt. Es waren ca. 22 aktive Teilnehmer beim Retrospektiven-Workshop dabei. Nur etwa jeder fünfte Teilnehmer hatte bisher schon an einer Retrospektive teilgenommen. Das Zeitfenster, das uns zur Verfügung stand, war mit einer Stunde sehr klein. Neben der inhaltlichen Arbeit der Retrospektive wollten wir den Teilnehmern zusätzlich auf der Metaebene erklären, was eine Retrospektive ist, was sie leistet und wie sich die Teilnahme anfühlt.

6„Inspect

& Adapt“ wird im aktuellen Scrum Guide im Abschnitt Scrum Theory (http://www. scrumguides.org/scrum-guide.html#theory) beschrieben. Um sich stetig zu verbessern, sollen in angemessenen Zeitabschnitten alle Aspekte des Prozesses hinterfragt und, wenn erforderlich, angepasst werden. Mögliche Scrum-Meetings dafür sind die Sprintplanung, Daily Scrum, Sprint Review und die in diesem Beitrag vorgestellte (Sprint) Retrospektive. Scrum wird in diesem Buch in Kapitel 6 Scrum – in kurzen Iterationen zum Ziel vorgestellt und diskutiert. 7Wenn Sie zu Beginn einer Besprechung gute mögliche Verbesserungen finden konnten, dann werden sie die investierte Zeit wahrscheinlich sogar im weiteren Verlauf der Besprechung oder der darauffolgenden Arbeitswoche einsparen können.

12  Retrospektiven – wir entwickeln uns weiter

125

Für so ein sehr ambitioniertes Ziel war eine sehr gute Vorbereitung wie auch viel Erfahrung in der Moderation sowie ein gutes Zeitmanagement notwendig. Patricia hatte die Moderation übernommen und für die einzelnen Phasen separate Flipcharts vorbereitet. Ich achtete während der Durchführung auf die Zeit und unterstützte mit meinen Erfahrungen bei der Durchführung der einzelnen Phasen. Als sogenannter „Timekeeper“ achtete ich auf die Einhaltung des Zeitplans, der sogenannten Timebox, für die jeweilige Phase. Auf diese Weise wurde in der knapp bemessenen Stunde in der großen Gruppe viel über Retrospektiven gelernt und Wissen geteilt. Ausgehend von den Wünschen und Bedürfnissen der Konferenzteilnehmer konnten wir den Konferenzveranstaltern am Ende fundierte Empfehlungen für die Verbesserung der Konferenz im nächsten Jahr geben. Für eine klassische Retrospektive haben sich fünf Phasen bewährt: Zum Einstieg wird die Agenda vorgestellt: Was erwartet die Teilnehmer in der Retrospektive und welche Punkte sind für die Retrospektive geplant (Abb. 12.1).

12.5 Die fünf Phasen der Retrospektive Vorbereitung: 1. Gesprächsklima schaffen 2. Themen sammeln 3. Erkenntnisse gewinnen 4. Entscheidungen treffen 5. Abschluss Nachhaltigkeit sichern.

12.5.1 1. Phase: Gesprächsklima schaffen (Warming Up) Hier geht es darum, die Teilnehmer willkommen zu heißen und den Raum für gemeinsames Arbeiten zu öffnen. Der Moderator sollte bedenken, dass die Teilnehmer wahrscheinlich aus ganz unterschiedlichen Arbeitskontexten zu diesem Retrospektiven-Meeting kommen. Es hat sich bewährt, ein „Warming-Up“ durchzuführen. Alle Teilnehmer werden dort abgeholt, wo sie sind. Sie können sich auf das, was jetzt folgt, einstimmen und einlassen. In unserem Workshop wurden die Teilnehmer zu Beginn gebeten, über einen Zufriedenheitsindex ihre Zufriedenheit mit der Konferenz Agile Verwaltung 2018 zu bewerten.

126

L. Wagner

Abb. 12.1   5 Phasen der Retrospektive

12.5.2 2. Phase: Themen sammeln (Gather Data) Die Teilnehmer werden gebeten, ihre persönlichen Erfahrungen für den betrachteten Zeitraum aufzuschreiben. Dazu liegen für jeden ausreichend Klebezettel und Stifte bereit. Ziel ist es, das individuelle Erleben zu reflektieren und mit der ganzen Gruppe zu teilen. So werden Zusammenhänge deutlich, die in der Teamarbeit entstehen. War eine Person z. B. krank oder konnte durch einen Workshop nicht die ganze Woche mitarbeiten, hat dies evtl. Auswirkungen auf die Arbeit der Teamkollegen. Fehlendes Wissen oder eine Persönlichkeit hat im Team gefehlt oder das eingeplante Arbeitspensum war so nicht zu schaffen. In unserem Fall war das Thema der Retrospektive: „Wie hat Ihnen die Konferenz Agile Verwaltung 2018 gefallen? Was wollen wir den Veranstaltern für die Konferenz im nächsten Jahr empfehlen?“

12  Retrospektiven – wir entwickeln uns weiter

127

Abb. 12.2  Themen sammeln: die 4 Ls

Als Methode wählte die Moderatorin die Vier Ls8 aus (Abb. 12.2). Die Teilnehmer sollten die Fragen „What I Loved, What I Learned, What I Lacked und What I Longed For“ (Was habe ich gemocht, was gelernt, was hat mir gefehlt, was hat mich genervt) beachten.

84Ls

– Loved, Learned, Lacked, Longed for. Wird zum Themen Sammeln in Retrospektiven benutzt. Die Methode wird im Retromat vorgestellt und beschrieben.

128

L. Wagner

In dieser Phase werden Eindrücke noch nicht bewertet oder von der Gruppe kommentiert. Die Teilnehmer bekommen eine begrenzte Zeit, um ihre Gedanken festzuhalten. Die Klebezettel werden vorne auf den Flipchart unter die passende Frage geklebt. Bei unserer großen Gruppe wurden die Punkte von der Moderatorin für alle vorgelesen. Bei kleineren Gruppen lasse ich die Teilnehmer gerne einzeln ihre Punkte vortragen und anheften. Ist genügend Zeit vorhanden, können auch inhaltliche Rückfragen kurz geklärt werden. Am Ende dieser Phase werden evtl. mehrfach vorkommende Punkte von den Teilnehmern (oder stellvertretend durch den neutralen(!) Moderator) zu einem einzigen Punkt zusammengefasst. Die Wichtigkeit der Erkenntnisse wird dann von den Teilnehmern priorisiert. Dies kann z. B. sehr einfach durch eine Punkteabfrage erfolgen. Alle Teilnehmer kommen zum Flipchart und vergeben eine vorher festgelegte Anzahl an Punkten. Bei uns wurden von jedem Teilnehmer 4 Striche auf die jeweilig priorisierten Klebezettel gemalt. Die Striche werden anschließend zusammengezählt. Wichtig ist, dass in dieser Phase keine inhaltliche Diskussion über die Punkte erfolgen soll. Dies ist Teil der nun folgenden Phase.

12.5.3 3. Phase – Erkenntnisse gewinnen (Generating Insights) Wir haben durch die letzte Phase ein gemeinsames Bild über den in der Retrospektive betrachteten Zeitraum geschaffen und kennen jetzt nicht nur unsere eigene Sichtweise, sondern auch die unserer Arbeitskollegen. Die wichtigsten Punkte sind durch die Bewertung der Teilnehmer gefunden. Jetzt geht es darum zu ergründen, was die Ursachen für die beobachteten Phänomene sind. In unserem Beispiel bildeten wir fünf Kleingruppen, die jeweils einen ihnen wichtigen Punkt aus den Beobachtungen für sich bearbeiteten. Als Retrospektiventechnik kam die 5-Warum-Technik nach Toyoda Sakichi9 zum Einsatz. Hierbei wird ein Punkt bzw. eine Aussage immer wieder hinterfragt, um dann nach einiger Zeit (bei uns limitiert auf 5 Phasen) zum eigentlichen Grund, der hinter einem Punkt oder Fakt steht, zu gelangen. Mit dieser Technik will man also die Oberfläche ­verlassen und die tiefer liegenden Ursachen erforschen (Abb. 12.3). Eine Gruppe wollte die Ursache für den Wunsch nach „Zeit zum Austausch“ finden. Sie fragten: • • • •

Warum wollen wir Zeit für Austausch? – Um sich mit Gleichgesinnten auszutauschen. Warum? – Damit wir unseren Horizont erweitern. Warum? – Um zu lernen. Warum? – Um mehr bewirken zu können.

9http://de.wikipedia.org/wiki/Toyoda_Sakichi.

12  Retrospektiven – wir entwickeln uns weiter

129

Abb. 12.3  3. Erkenntnisse gewinnen

Die Ergebnisse der fünf Arbeitsgruppen sind die fünf Ursachen für das auf der Konferenz Agile Verwaltung Erlebte und Erfahrene. Sie stellen die Basis für die nun folgende Phase der Retrospektive dar.

130

L. Wagner

12.5.4 4. Phase: Entscheidungen treffen (Take Actions) Nun geht es darum, mithilfe der Erkenntnisse die möglichst vielversprechendsten und für alle Mitwirkenden gangbaren Änderungen zu finden. Gerade in größeren Teams kann es unterschiedliche Arbeitsweisen der einzelnen Personen geben. Hier werden mögliche Veränderungen besprochen. Es ist hilfreich, neben den Maßnahmen auch die zu erwartenden Verbesserungen aufzuschreiben. Diese sollten dann in der nächsten Retrospektive überprüft werden. Ist die Änderung erfolgreich gewesen oder sollte die Maßnahme weiter verfeinert werden? Als Maßnahmen in Retrospektiven vereinbart man kleinere „Experimente“. Dies nimmt den Druck, gleich auf Anhieb die „richtige“ Lösung finden zu müssen. Es betont, dass Experimente nicht unbedingt erfolgreich sein müssen. Viel wichtiger als sofort eine perfekte Lösung zu finden ist das Lernen im Prozess. Die Verbesserungen passieren dann über die Zeit kontinuierlich, nachhaltig und in den Arbeitsprozess eingebunden. In einer Gruppe von miteinander arbeitenden Menschen gestaltet sich die Veränderung gemeinsamer Verhaltens- und Arbeitsweisen besonders schwierig. Die Änderungen müssen von jedem Einzelnen mitgetragen werden. Die Veränderungen brauchen Zeit, um in der Gruppe als gelebte Praktik eingeübt und verinnerlicht zu werden. Vom Allgemeinen nun zurück zur vierten Phase des Retrospektiven-Workshops. Hier haben die 22 Teilnehmer den Veranstaltern (dem Forum Agile Verwaltung) Empfehlungen ausgesprochen. Dafür wurden die Maßnahmen in 3 Kategorien unterteilt: 1. Mehr von … 2. Beibehalten von … 3. Weniger von … Die vorgeschlagenen Maßnahmen auf dem Bild im Flipchart lassen sich über die Farbe der Klebezettel zu den bearbeiteten Themen der vorherigen dritten Retrospektive-Phase zuordnen. Einige Maßnahmen zu unserem Beispiel lauten: „Mehr Zeit für Austausch“ um „Mehr bewirken zu können“. Den Veranstaltern wurde für die Folgekonferenz vorgeschlagen, eine Plattform zum Austausch auch im Nachhinein zu schaffen. Die Vorträge sollten „interaktiver“, die Pausen länger sein. Die Konferenz soll 2 Tage dauern, davon der erste Tag Konferenz und am zweiten Tag Workshops im Barcamp-Format. Übernachtungen der Teilnehmer könnten an einem Ort zentral erfolgen. Beibehalten werden soll die Vorabendveranstaltung und der Raum, um Methoden lernen zu können. Vorträge sollten kürzer sein und im Anschluss Raum für Fragen und Antworten bieten (Abb. 12.4).

12  Retrospektiven – wir entwickeln uns weiter

131

Abb. 12.4  Entscheidungen treffen

12.5.5 5. Phase – Abschluss/Feedback/Nachbereitung Zum Abschluss sollte Zeit für ein Feedback zur Retrospektive selbst vorhanden sein. Was war gut daran, hat das Format, hat die Zeit gestimmt? Was wollen wir beim nächsten Mal ändern? (Abb. 12.5).

132

L. Wagner

Abb. 12.5   Abschluss/ Feedback/Nachbereitung

Wichtig ist auch die Nachbereitung der Retrospektive. Um die Maßnahmen nicht aus den Augen zu verlieren, bietet es sich z. B. an, sie an einer deutlich sichtbaren Stelle zu veröffentlichen, etwa im gemeinsamen Teamraum oder auch (transparent) im Flur oder in der Teeküche. Sind Punkte oder Arbeitsaufträge vereinbart worden, sollten diese nicht vergessen werden, der Erfolg und die Erledigung oder auch die Schwierigkeiten beim Bearbeiten sollten spätestens in der nächsten Retrospektive besprochen werden. Im Workshop hatten wir für diese Phase leider nur noch sehr wenig Zeit. Wir haben von den Teilnehmern per Handzeichen ihre Einschätzung zur Retrospektive abgefragt. Die Smileys auf dem Flipchart repräsentieren den Grad der Zufriedenheit. Die Moderatorin hat die Meldungen gezählt und auf dem Flipchart zusammengefasst.

12.6 Retrospektiven im nicht agilen Umfeld Wenn Sie selbst in einem nicht agilen Umfeld einer noch nicht agilen Verwaltung tätig sind, dann beachten Sie die Empfehlungen aus dem vorigen Kapitel. Beginnen Sie mit kleinen Experimenten, justieren Sie nach und passen Sie Ihre Retrospektive immer wieder an. Und dies so lange, bis sie gut für Sie funktioniert und Ihnen/Ihren Kollegen (und Ihrem Team) den bestmöglichen Nutzen bringt.

12  Retrospektiven – wir entwickeln uns weiter

133

Wichtig ist es, sich Zeit zu nehmen und wirklich nicht mehr als zwei bis drei Maßnahmen gleichzeitig anzugehen. Eigentlich empfehle ich sogar eine Beschränkung auf ein bis zwei Maßnahmen pro Retrospektive. Die Veränderungen können langsam beginnen. Wenn Sie Ihre Arbeitsprozesse regelmäßig immer wieder ein Stück verbessern, bekommen Sie Übung. Sie wissen, was Sie verändern können, Sie wissen aber auch, wo Sie an Grenzen stoßen und weiter experimentieren müssen, um sich weiterzuentwickeln. Mit der Zeit werden Sie erfahrener im Umgang mit Retrospektiven und Veränderungen. Sie können selbst immer besser mit Veränderungen umgehen. Und Sie können mehr und mehr Leute auf Ihrem Weg mitnehmen.

12.7 Ja, ich will! Wie kann ich jetzt beginnen? Nur Mut, versuchen Sie gerne ein persönliche Retrospektive wie oben beschrieben. Sie können daran für sich selbst in einem sehr geschützten Rahmen die Mechanismen und die Vorgehensweisen erproben und erlernen. Beginnen Sie mit den drei Fragen aus Abschn. 12.2 Der Start: Die persönliche Retrospektive. Wenn Sie im Team beginnen wollen, schauen Sie auf Ihre bisherigen regelmäßigen Termine. Wie lässt sich ein Teil dieser Termine für eine Retrospektive nutzen? Holen Sie sich auf jeden Fall Verbündete mit ins Boot, berichten sie evtl. von den Erfahrungen mit der eigenen persönlichen Retrospektive oder dem hier im Buch beschriebenen Beispiel von der Konferenz Agile Verwaltung. Wenn Sie Verbündete finden und begeistern können und mit denen erste Erfahrungen sammeln, können Sie dort in einem kleinen Kreis lernen und anschließend den Teilnehmerkreis erweitern.

12.8 Herausforderungen, Hindernisse und Grenzen Bei der Einführung von Retrospektiven gibt es eine Vielzahl möglicher Hindernisse und Herausforderungen. Sie werden bei sich selbst, wie auch in Ihrem Umfeld, an Grenzen und Hindernisse stoßen. Ich möchte einige dieser Hindernisse benennen und mögliche Auswege skizzieren: Fehlendes Vertrauen im Team ist ein großes Hindernis für das Gelingen von Veränderungen. Wenn Vertrauen nicht vorhanden ist, dann ist es eine schwierige (Führungs-) Aufgabe, es wiederherzustellen. Im Buch „5 Dysfunktionen im Team“ von Patrick Lencioni ist fehlendes Vertrauen (fehlende Offenheit) als die Basis nicht funktionierender Teams benannt.10 Lencioni beschreibt den Weg von lauter Einzelkämpfern hin zu

10Die

5 Dysfunktionen eines Teams – der Manga: Eine illustrierte Leadership-Fabel – Patrick M. Lencioni.

134

L. Wagner

einem funktionierenden und kooperierenden Team. Die zu meisternden Hindernisse auf dem Weg sind dabei: Furcht vor Konflikt (künstliche Harmonie), Mangel an Selbstverpflichtung auf ein gemeinsames Ziel, keine gegenseitige Verantwortlichkeit, keine Ergebnisorientierung (gelebt werden stattdessen Status und Ego). Grenzen in der Organisation bzw. mit der Hierarchie. In der agilen Welt kann man mit Retrospektiven im eigenen Team beginnen. Gerade aber, wenn hier mit der Zeit wirklich Veränderung und Zusammenarbeit stattfinden, stoßen Teams an neue Grenzen innerhalb der Organisation. Oft kann einiges im eigenen Team verändert werden. Arbeitet man jedoch übergreifend mit anderen Abteilungen oder Organisationseinheiten zusammen, wird es naturgemäß schwieriger. Wer hier auf offene Türen trifft, kann sehr froh sein. Oft wird man bei übergreifenden Veränderungen gegen Mauern anrennen. Was kann man tun? Holen Sie sich Verbündete mit ins Boot. Sprechen Sie mit anderen Teams und Abteilungen. Vergessen sie nicht, auch Ihre Führungskräfte frühzeitig für agile Veränderungen zu begeistern und in den Veränderungsprozess einzubinden. Oftmals ist bei Veränderungen Rückendeckung und Unterstützung von „oben“ mehr als hilfreich. Lesen Sie vielleicht das Kap. 20 über die Agile Sozialverwaltung in der Stadt Ängelholm in Schweden, um weitere Ideen und Anregungen für agile Organisationsstrukturen in der Verwaltung zu bekommen. Zielkonflikte innerhalb der Organisation. Es ist ein langer Weg, besonders für eine große Organisation, an einem gemeinsamen Strang zu ziehen. Oftmals fehlt es an Transparenz über die anzustrebenden Ziele, oder Ziele widersprechen sich geradewegs (Finanzabteilung vs. Innovationsabteilung). Wenn Sie mit mehreren Teams an einem gemeinsamen Ziel und Projekt arbeiten, dann helfen dabei beispielsweise gemeinsame Zeremonien wie im Kap. 8 Skalierung – teamübergreifende Abstimmung von Martin Buchholz beschrieben oder auch gemeinsame Priorisierungen (Kap. 11: Speed Estimation – viele User Stories in kurzer Zeit schätzen). Retrospektiven über Teamgrenzen hinweg sind aufwendiger zu organisieren und zu adressieren als teaminterne, helfen aber genau, Zielkonflikte in der Organisation aufzudecken und gemeinsam abzubauen. Wenn einzelne Kollegen nicht mitmachen wollen, ist dies schwierig. Empfehlen würde ich zunächst, mit den positiv gestimmten Kollegen gemeinsam zu beginnen. Wenn sie eine „Kritische Masse“ an begeisterten Veränderern gefunden haben, werden auch neutrale Kollegen mitmachen und schließlich evtl. sogar die Skeptiker und Bremser. Mangelndes Durchhaltevermögen und das Totschlagargument: „Keine Zeit für eine Retrospektive“. Es gibt dazu eine geniale Geschichte von Stephen R. Covey: Ein Wanderer trifft auf sehr angestrengte und sich schwer abmühende Waldarbeiter an einem sehr großen Holzstapel beim Sägen. Die Arbeiter schimpfen und schwitzen bei ihrer Arbeit. Der Wanderer betrachtet die Situation eine Weile (von außen) und fragt einen Holzarbeiter, warum sie nicht ihre Säge schärfen? Dieser antwortet entrüstet (oder auch genervt, eventuell auch verzweifelt oder gar resigniert): „Wir haben keine Zeit, die Säge zu schärfen, wir müssen doch sägen!“

12  Retrospektiven – wir entwickeln uns weiter

135

12.9 10 Ausblick: Alles muss klein beginnen, lass etwas Zeit verrinnen. Es muss nur Kraft gewinnen, und endlich ist es groß. – Zitat aus einem Lied von Gerhard Schöne.

Der erste Schritt kann jetzt gleich beginnen. Versuchen und probieren Sie eine erste persönliche Retrospektive. Finden Sie Spaß und Freude an den kleinen und größeren Veränderungen und Verbesserungen. Ich wünsche Ihnen dabei viel Freude und Erfolg! Ihre Fragen, Anregungen und Ihr Feedback sind zu jeder Zeit herzlich willkommen11! Ich freue mich über Ihre Nachricht per E-Mail.

Weiterführende Literatur und Hilfreiches Andresen J Das Ebook ‚Erfolgreiche Retrospektiven‘. https://leanpub.com/ErfolgreicheRetrospektiven Ein sehr hilfreiches Werkzeug beim Planen von Retrospektiven ist der sogenannte „Retromat“ (https://plans-for-retrospectives.com). Dies ist eine Sammlung von Methoden zur Planung und Inspiration und zur Planung der klassischen 5 Phasen einer Retrospektive. Löffler M (2014) Retrospektiven in der Praxis. dpunkt-verlag, Heidelberg Michl T Aus der agilen Methodenkiste: Kontinuierliche Verbesserung durch Retrospektiven, Blogbeitrag vom 15. September 2016. https://agile-verwaltung.org/2016/09/15/aus-der-agilen-methodenkisten-kontinulierliche-verbesserung-durch-retrospektiven/ Retrospektiven in agilen Projekten, Judith Andresen (Hansa Fachbuch). http://www.hanser-fachbuch.de/buch/Retrospektiven+in+agilen+Projekten/9783446451674

Ludger Wagner begleitet als freiberuflicher Agile Coach und Scrum Master Menschen und Teams in kleinen und großen Unternehmen, NGOs und in der Öffentlichen Verwaltung auf ihrem Weg zu mehr Agilität und Kundenorientierung. Er unterstützt sie dabei ungenutzte Potentiale zu entdecken und zu nutzen. Nach dem Informatikstudium 1998 gestaltete er in verschiedenen Firmen Veränderungen mit. Er begann in einem Bildungsverlag, kämpfte sich durch den Prozessdschungel großer, multinationaler Konzerne im schönen, fernen Spanien, um dann in kleinen und groß gewordenen Berliner Startups agile Werte, Prinzipien und Praktiken anzuwenden. „Menschen vor Prozesse“ – das erste Agile Wertepaar – ist dabei Richtschnur seiner Haltung und seines Handelns.

11Feedback

ist jederzeit gewünscht und herzlich willkommen. Ganz gleich, ob Sie Fragen zu Ihren ersten oder nächsten Schritten mit Retrospektiven haben oder mir Ergänzungen und Feedback zu diesem Buchkapitel geben oder mir von Ihren eigenen Versuchen und Erfahrungen mit Retrospektiven berichten möchten.

Die User Story – eine agile Form der Aufgabendefinition

13

Thomas Michl

Zusammenfassung

Die User Story findet sich weder im Agilen Manifest noch im Scrum Leitfaden oder anderen grundlegenden Methodenleitfaden. Sie ist das Ergebnis praktischer Erfahrungen agiler Praxis, in der sie sich bewährt hat. Entwickelt wurde das Konzept von Dr. Ivar Jacobson (Jacobson et al., Whitepaper: use-case 2.0 – the guide to succeeding with use cases, Jacobson International, 2011) und Ron Jeffreys (https://ronjeffries. com/xprog/articles/expcardconversationconfirmation/). Die User Story unterscheidet sich von den klassischen Anforderungen dadurch, dass sie vergleichsweise offen formuliert wird. Sie definiert, was zwar am Ende möglich sein soll, lässt aber gleichzeitig das detaillierte „Was“ und „Wie“ offen. Sie bildet die Basis in der Kommunikation.

13.1 Warum ergebnisoffene Anforderungen? Vor geraumer Zeit erzählte mir jemand eine Geschichte, die sehr gut als Einstieg zum Thema „User Story“ passt und verständlich macht, was das Besondere der User Story im Vergleich zur „üblichen“ Definition von Anforderungen ist. In einer sehr großen Organisation erhielt die EDV-Abteilung den Auftrag, für den Vorstand eine automatisierte Abfrage aus dem Finanzwesen zu erstellen, und zwar mit der Anforderung, eine entsprechende Schnittstelle zu schaffen. Dort machte Mensch sich sofort an die Arbeit und schätzte den Aufwand. Die Schätzung lag deutlich im mehrstelligen Stundenbereich. Entsprechend wurde an den Vorstand zurückgespiegelt, dass

T. Michl (*)  Forum Agile Verwaltung e. V., Weinsberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_13

137

138

T. Michl

hierfür Finanzmittel im fünfstelligen Bereich benötigt würden. Die entsprechenden Mittel wurden genehmigt und mit der Umsetzung begonnen. Erst im Nachgang erfuhren die verantwortlich Umsetzenden in der EDV-Abteilung, dass dieser Bericht nur einmal im Jahr benötigt wird. Der Bericht wäre mit einem händischen Arbeitsablauf in einer guten Stunde ebenfalls generierbar gewesen. Was also war hier passiert? Ganz einfach, die EDV-Leute haben das getan, was von  ihnen  erwartet wurde. Sie haben eine vorgegebene Lösung umgesetzt. Hätte Mensch ihnen allerdings gesagt: „Wir brauchen für unser Berichtswesen eine Auswertung bestimmter Daten, und zwar einmal im Jahr“, hätten diese sicherlich verschiedene Optionen erarbeitet und geprüft. Und sie hätten vermutlich statt der Schnittstelle einen anderen Weg vorgeschlagen, der aus wirtschaftlicher Sicht sinnvoller gewesen wäre. Mit der Maßgabe, eine Schnittstelle zu programmieren, war der Weg aber bereits vorgegeben. Damit so etwas nicht passiert, setzen viele Agilisten auf die sogenannte User Story. Wie der Namensbestandteil „User (=Anwender)“ schon andeutet, auch ein Begriff, der im Umfeld der Software-Entwicklung entstanden ist. Das Konzept lässt sich aber auf alle möglichen Situationen, bei denen „Kunden“ einem Dienstleister den Auftrag zur Entwicklung eines „Produkts“ erteilen, mit großem Nutzen anwenden. Also z. B. auch in der Organisationsentwicklung.

13.2 User Story – was ist das? Eine User Story weist in aller Regel folgende Grundstruktur auf: Als „Rolle“ will ich „Handlung“, um „Ergebnis“ zu erzielen. Im oben genannten Beispiel wäre dann die User Story gewesen: „Als Vorstand möchte ich einmal im Jahr folgende Daten zur Erstellung eines Berichts zur Verfügung gestellt haben.“ Eine User Story (Abb. 13.1) könnte Mensch daher als Beschreibung einer Anforderung bezeichnen, die ein Ergebnis definiert und die begründet, warum dieses Ergebnis benötigt wird. Diese Anforderung lässt vollständig offen, wie das Ergebnis erzielt wird. Damit werden keine Lösungen vorgegeben oder determiniert. Sondern im Gegenteil, das „Wie“ bleibt offen, und wer auch immer an die Umsetzung geht, muss sich nicht an eine vorgegebene Lösung halten, die sich möglicherweise als unwirtschaftlich herausstellt.

Abb. 13.1   Grundstruktur der User Story

13  Die User Story – eine agile Form der Aufgabendefinition

139

13.3 Die Vorteile User Storys haben den Vorteil, dass sie leicht für alle Beteiligten zu verstehen sind und einer einfachen Struktur folgen, die dennoch hochgradig effektiv und effizient ist. Sie lassen sich unterschiedlich ausführlich dokumentieren und ganz einfach mit fortschreitendem Projekt verfeinern und anpassen. Sie sind damit ideal, gerade für agile Methoden, bei denen im Laufe der Zeit von grobkörnigen Anforderungen zu feinkörnigen Beschreibungen übergegangen wird. Sprich im Zuge der Fortschreibung des Backlogs – dem Themenspeicher mit den priorisierten Anforderungen – werden die am höchsten priorisierten Anforderungen umso detaillierter beschrieben, je höher sie bewertet werden. Anforderungen detailliert zu beschreiben, die in der Priorität weit unten liegen und auch in den nächsten zwei bis drei Sprints nicht relevant werden, macht wenig Sinn. Denn bis diese zum Zuge kommen könnten, liegen neue Erkenntnisse vor, die zu einer vollkommen neuen Bewertung führen. Die Entwicklung einer User Story ist daher ein dauerhafter Dialog zwischen den Beteiligten. Der Fokus verschiebt sich damit weg vom Schreiben hin zum Dialog im Sinne des Informationsaustausches und der Zusammenarbeit. Ziel ist es, ein besseres Verständnis davon zu entwickeln, was erreicht werden soll. Wesentlicher Teil einer jeden User Story sind die Akzeptanzkriterien. Diese beschreiben, welche Kriterien erfüllt sein müssen, damit der Auftraggeber mit dem Ergebnis zufrieden ist und verhelfen dem Team damit zu einem besseren Verständnis darüber, was gewünscht ist.

13.4 Arten von User Stories User Storys werden häufig unterschieden in sprintfähige Storys, die sich innerhalb einer Planungsphase (Sprint) realisieren lassen. Darüber hinaus werden zusammenhängende Storys (die z. B. funktional zusammengehören) häufig als „Theme“ zusammengefasst. User Storys mit einer Größe, die über mehrere Planungsphasen hinausreichen, tragen häufig die Bezeichnung Epics. Diese Bezeichnungen sind nicht in Stein gemeißelt und können durchaus abweichen, haben aber einen hohen Verbreitungsgrad und werden in der einschlägigen Literatur in aller Regel verwendet. Von den User Storys abzugrenzen sind die Aufgaben. Damit werden Tätigkeiten bezeichnet, die sich in wenigen Stunden erledigen lassen. Also die klassischen „Aufgaben“ der Aufgabenliste, wie wir sie alle kennen. Eine User Story beinhaltet folgende Informationen: • • • •

einen griffigen Titel (Story Name) die Zuordnung zur Funktionalität und Anforderer das sogenannte „Value Statement“, also den Inhalt der User Story sowie Akzeptanzkriterien, die eine definierte Qualität sichern

140

T. Michl

Optional enthält die User Story folgenden Informationen: • Informationsanhänge, die bei der Bearbeitung helfen können • eine Aufwands-/Komplexitätsschätzung (in Story Points) • die Zuordnung zu einem übergeordneten Epic

13.5 Formulierungshilfe Beim Zuschnitt von User Storys gibt es einiges zu beachten. Sie sollte möglichst klein gehalten werden. Was einfach klingt, ist in der Praxis nicht immer so ganz einfach. Von Bill Wake stammen sechs Kriterien für die Formulierung von User Storys, die unter dem Akronym INVEST Verbreitung gefunden haben und sich in der Praxis bewährt haben (Abb. 13.2). Unabhängig in diesem Sinne bedeutet, dass zwischen den User Storys selbst entweder keine oder nur lose Abhängigkeiten bestehen. So, dass jede Story für sich betrachtet und erarbeitet werden kann, ohne Risiken durch zusätzliche komplexe Zusammenhänge berücksichtigen zu müssen. Verhandelbar bedeutet, dass die User Story weiterhin im Dialog weiterentwickelt werden soll. Der Dialog soll nicht behindert werden, sodass Spielräume entstehen, die die Anpassungsfähigkeit an neue Erkenntnisse ermöglichen. Werthaltig bedeutet, dass eine User Story für den „Auftraggeber“ einen Nutzen stiften soll. Der Nutzen ist neben dem Aufwand eines der zentralen Kriterien bei der Bewertung der Priorität. Je höher der Nutzen und damit der Wert und je geringer der Aufwand, desto höher die Priorität innerhalb des priorisierten Themenspeichers (Backlog). Schätzbar bedeutet, dass der Aufwand zur Umsetzung realistisch einschätzbar sein muss. Ist dies nicht der Fall, ist die User Story möglicherweise zu groß und muss in mehrere kleinere Einheiten zerlegt werden. Wie bereits erwähnt, ist der Aufwand – neben dem Wert – einer der zentralen Faktoren zu Priorisierung. Daneben sollten Storys immer

Abb. 13.2   INVEST-Regel

13  Die User Story – eine agile Form der Aufgabendefinition

141

die passende Größe aufweisen. D. h. sie müssen von der Größe dem Planungs- und Umsetzungszyklus entsprechen. Zu guter Letzt ist eine gute User Story prüfbar, sprich es kann mithilfe der definierten Akzeptanzkriterien gegengespiegelt werden, ob die tatsächlich auch alle Kriterien erfüllt sind, wenn die User Story umgesetzt wurde.

13.6 Akzeptanzkriterien – Definition of Done Hilfreich ist das Festlegen von Akzeptanzkriterien, die definieren, wann eine User Story tatsächlich umgesetzt, spricht fertig ist. Der Scrum Leitfaden spricht hier von der Definition of Done1. Die Definition of Done hat den Zweck, ein gemeinsames Verständnis im Team zu entwickeln, wann ein „Auftrag“ tatsächlich fertig ist. Zur Erinnerung: die Aufgabe lautet, im Rahmen eines Sprints potenziell auslieferbare Inkremente zu erstellen.

13.7 Fazit Was können wir für unseren Alltag und die tägliche Praxis daraus mitnehmen? Wie das eingangs beschriebene Beispiel zeigt, neigen wir zu oft dazu, mit der Definition der Anforderungen die möglichen Lösungen vorwegzunehmen und damit bereits einen Lösungsweg zu definieren, der alternative Ansätze ausschließt. Dies kann – muss nicht – dazu führen, dass es zu suboptimalen Ergebnissen kommt, indem wir in der Beschreibung des Wunschergebnisses bereits die Vorgabe der Lösung definieren. Vielversprechender ist es, sich gedanklich auf das „Was wollen wir“ zu konzentrieren und das „Wie erreichen wir es“ zunächst offen zu lassen. Die User Story kann dabei helfen. Sie beschreibt das Ergebnis und gibt dazu Hintergrundinformationen, die bei der Suche nach der besten möglichen Lösung hilfreich sind.

Literatur und Weblinks Jacobson I, Spence I, Bittner K (2011) Whitepaper: use-case 2.0 – the guide to succeeding with use cases, Jacobson International Schwaber K, Sutherland J (2017) The Scrum Guide. https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

1Schwaber

und Sutherland (2017, S. 18 ff.).

142

T. Michl Thomas Michl  ist Dipl.-Verw.Wiss. und MBA. Berufliche Stationen waren unter anderem in der Energiewirtschaft und Strategieberatung. Von 2008 bis 2018 war er für eine Kommunalverwaltung im Bereich Kultur und Bürgerschaftliches Engagement tätig. Seit Juni 2018 arbeitet er als Agile Coach und Scrum Master für borisgloger consulting.

Prozesse beschreiben mit Story Mapping Eine agile Methode, Prozesse zu steuern und anzupassen

14

Wolf Steinbrecher

Zusammenfassung

In den Verwaltungen hält sich hartnäckig die Vorstellung vom Optimierungspotenzial der Workflows, mit denen Prozesse beschrieben, gesteuert und verbessert werden könnten. Aber Erfolgsbeispiele in der Realität gibt es wenige. Das liegt am hohen Aufwand der Erstellung der Flussdiagramme, an ihrer mangelnden Übersichtlichkeit und dem enormen Pflegeaufwand. Aufgrund dieser Erfahrungen wurde in der agilen Welt eine schlanke und sehr effiziente Methode entwickelt, die sogenannten Story Maps.

14.1 Warum komplizierte Beschreibungen nichts taugen Hatten Sie in letzter Zeit einmal etwas im Krankenhaus zu tun? Wenn Sie heutzutage auch nur für einen kleinen, unkomplizierten Eingriff in eine Klinik kommen, wird Ihnen als erstes eine Broschüre übergeben, die Sie über die Risiken der Behandlung informieren soll. Eine solche Broschüre umfasst heute oft hundert Seiten (vor einigen Jahren war es noch ein DIN A 4-Blatt). Wie ist es dazu gekommen? Die Broschüre soll nicht aufklären. Sie soll das Krankenhaus rechtlich absichern. Sie als Patient werden de facto gezwungen, etwas zu unterschreiben, das Sie nicht gelesen haben. Nur damit man später im Falle eines Falles „beweisen“ kann, dass Sie über das entsprechende Operationsrisiko unterrichtet waren. Die Broschüre besteht aus so vielen Einzelheiten, dass der gute Überblick – der dem besorgten Patienten Sicherheit geben

W. Steinbrecher ()  Common Sense Team GmbH, Forum Agile Verwaltung e. V., Karlsruhe, Baden-Württemberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_14

143

144

W. Steinbrecher

könnte – völlig verloren geht. Nur noch Bäume, kein Wald. Das Ziel der umfassenden Aufklärung über alle denkbaren Ereignisse in der Zukunft führt dazu, dass überhaupt keine Aufklärung mehr stattfindet. Auf der anderen Seite wird das einzig wirksame Instrument der Risikoklärung – nämlich das Gespräch mit dem behandelnden Arzt – auf ein Minimum reduziert. Dafür ist die Zeit nicht da, vor allem ist aber wieder das „Risiko“ zu groß: der Arzt ist kein Jurist. Wenn er etwas in Umgangssprache sagt und es sind Zeugen dabei, kann sein, dass ihm später vor Gericht ein Strick daraus gedreht wird. Also lieber weniger sagen als mehr, und vor allem: Keine Ratschläge geben, auf die sich der Patient später berufen könnte. Diese Erfahrungen aus der Alltagswelt haben auch in unseren Verwaltungsprozessen ihre Parallelen. Hartnäckig hält sich der Mythos von der Nützlichkeit von detaillierten Prozessbeschreibungen für deren Verbesserung.1 Und das Verfahren selbst ist sehr aufwendig. Haben Sie schon einmal an einem Workshop zur Prozessanalyse teilgenommen? In dem nach vier Stunden ermüdenden Aufmalens von Flussdiagrammen eine Teilnehmerin entnervt ausruft: „Aber das stimmt doch noch hinten und vorne nicht! Die Möglichkeit, dass auch der Vertreter des Vertreters abwesend ist und der Fall bis nach Fristende völlig unbearbeitet bleibt, haben wir bislang komplett übersehen!“ Aus diesen Gründen wurde im agilen Umfeld eine alternative Methode entwickelt: die Story Map.

14.2 Die Methode im Überblick Ein Flussdiagramm hat den Anspruch, den Ablauf eines Prozesses mit allen Schleifen und Verzweigungen darzustellen2. Diesen Anspruch hat eine Story Map nicht. Storymapping ist eine von Jeff Patton entwickelte Methode, die an bewährte Ansätze aus der agilen Softwareentwicklung anknüpfte und sie erweiterte. Das von ihm „User Story Mapping“ bezeichnete Verfahren war für IT-Produkt-Entwickler gedacht, damit diese ihre Produktentwicklung detailliert am Arbeitsfluss der Nutzer (User) ausrichten können.3 Mit der neuen Methode wollte man die Reihenfolge, mit der Anforderungen in einer Software realisiert werden, besser steuern können. Diese Herangehensweise kann man aber auch für Fragestellungen nutzen, die Thema des vorliegenden Kapitels sind.

1Vgl.

Steinbrecher (2016). (engl. flow charts) stellen eine grafische Darstellungsform von Prozessen dar, in der Regel unter Verwendung der Zeichen nach DIN 66001. Die tabellarische Darstellung, z. B. mit Excel, unterscheidet sich in der grafischen Form. Aber die inhaltliche Struktur ist ähnlich – beide Formen sind ineinander übersetzbar – und der Anspruch der Vollständigkeit der gleiche. 3Vgl. Patton (2014) und Büsse-Voss (2017). 2Flussdiagramme

14  Prozesse beschreiben mit Story Mapping

145

Abb. 14.1  Storymap für den Prozess „Morgens aufstehen“

14.2.1 Tätigkeiten sammeln Eine Story Map ist zuerst einmal eine Auflistung von Tätigkeiten zur Erledigung einer Aufgabe4. Die Liste der Tätigkeiten wird grob geclustert. Statt langer Erklärungen ein Beispiel aus dem täglichen Leben: Nehmen Sie den Prozess „Morgens aus dem Haus gehen“. Auslöser des Prozesses ist „Wecker klingelt“, gefolgt von der Tätigkeit „Wecker ausmachen“ (Prozessvariante: „an die Wand werfen“). Und das Ergebnis des Prozesses, sein Abschluss, ist „Haustür hinter sich schließen“. Abb. 14.1 zeigt eine Story Map von diesem Prozess. Die Tätigkeiten sind auf einer relativ grob granularen Ebene gehalten. Also „Brote für die Kinder“ und nicht • Kühlschrank öffnen • Küchentisch decken • Brot schneiden • Butter draufschmieren • Stefan fragen, ob er heute Marmelade mag • Usw. Die Story Map hält sich auf der Ebene einer Checkliste, das heißt, sie wendet sich an „sachkundige“ Personen, die wissen, wie man „Brote für Kinder“ fabriziert.5 4Korrekt 5Zum

ausgedrückt: zum Abschließen eines Vorgangs als Instanz eines Prozesses.

Unterschied zwischen Checklisten und herkömmlichen Prozessdarstellungen siehe das ausgezeichnete Buch Gawande (2013). Der Autor ist Arzt und schreibt über die Wichtigkeit von Checklisten z. B. bei wichtigen Operationen. Auf Englisch ist es unter dem Schlagwort „Checklist Manifesto“ bekannt.

146

W. Steinbrecher

Im Beispiel erscheinen die Prozessvarianten kommentarlos nebeneinandergestellt. Die Tätigkeiten „schminken“ und „rasieren“ treffen nur sehr selten auf eine Person zu – in der Regel macht man das eine oder das andere. Die Story Map meint dazu: „Wenn du einen Schritt nicht brauchst, überspring ihn halt. Du wirst schon selbst wissen, was für dich richtig ist.“ Deshalb werden auch keine Oder-Verzweigungen dargestellt. Oder-Verzweigungen sind Fragen der Art: • Ist Zahnpastatube schon wieder leer? • Wenn ja: ganz stark draufdrücken. • Noch was rausgekommen? • Wenn nein: Zum Vorratsschrank gehen. • Keine Zahnpasta auf Vorrat gekauft? • Wenn ja: Schuldigen suchen und Streit anfangen. • Usw.

14.2.2 Tätigkeiten ordnen Wenn wir die Tätigkeiten im Team gesammelt haben, dann clustern wir sie. In unserem Beispiel wurden die Aktivitäten nach Zimmern geordnet, aber auch andere Methoden wären denkbar. Ziele der Clusterung sind: 1. Einen besseren Überblick geben. 2. Statusinformationen ermöglichen. Eine typische Statusinformation ist: „Liebling, das Bad ist frei.“ Eine solche Statusinformation ist viel dichter als eine Nachricht der Form „Ich habe mich geduscht und die Zähne geputzt und auch schon rasiert“ – darum geht es ja dem Partner gar nicht. Denn das ist vergangenheitsorientiert. Was ihn interessiert ist die prozessual nach vorne gerichtete Information: „du kannst ins Bad“. Die Basis für eine solche Art der Kommunikation im Prozess wird durch die Clusterung gelegt.

14.2.3 Ein seriöses Beispiel einer Story Map Das Beispiel in Abb. 14.2 zeigt, dass man auch Geschäftsprozesse nutzbringend mit der Methode des Story Mapping darstellen kann.

14  Prozesse beschreiben mit Story Mapping

147

Abb. 14.2  Storymap für den Prozess „Personal einstellen“

14.3 Effizienter als Flussdiagramme Was sind die Unterschiede zwischen Story Maps und Flussdiagrammen? 1. Story Maps verzichten vollständig auf die Darstellung von Verzweigungen. Es sind die Verzweigungen und Schleifenbildungen, die die Flussdiagramme so unübersichtlich machen (siehe Abb. 14.3). Rechnen Sie nach: Wenn Sie einen Prozess haben, der eine einzige Oder-Verzweigung besitzt, haben Sie zwei Prozessvarianten. Wenn der Prozess zwei Verzweigungen hat, die voneinander unabhängig sind, erhalten Sie vier Varianten. Bei drei sind es schon acht Varianten usw. Jede von den anderen unabhängige Verzweigung verdoppelt die Anzahl der Prozessvarianten. Aber: in der Realität kommen nur sehr wenige dieser hypothetischen Varianten auch wirklich vor. Wie oft ist der Vertreter des Vertreters in Urlaub? In 1/1000 der Fälle? Der Anspruch auf „vollständige“ oder perfekte Prozessdarstellung führt dazu, dass Prozessvarianten, die fast nie vorkommen, mit der gleichen Akribie dargestellt werden wie die 95 %-Fälle. Das macht unnötige Arbeit und reduziert die Übersichtlichkeit.

2. Flussdiagramme richten sich an den unkundigen Betrachter. Im Kern geht es darum, einem Software-Programmierer, der einen Prozess überhaupt nicht kennt, ihn aber in einer Programmiersprache nachbilden soll, einen Überblick zu verschaffen. Und dies schriftlich, ohne in Dialog mit dem Anwender zu treten. Es ist der Versuch einer kontextfreien Kommunikation. Er ist zum Scheitern verurteil.

148

W. Steinbrecher

Abb. 14.3  Ein Flussdiagramm wird vor allem durch die vielen Verzweigungen unübersichtlich

3. Story Maps hingegen richten sich an Menschen, die den Prozess kennen … … und sich untereinander – also „unter Eingeweihten“ – verständigen wollen.

4. Story Maps haben nicht den Charakter von Vorschriften. Sie stellen eine good practice dar, die aber von jedem Mitarbeiter jederzeit geändert werden kann. Nehmen wir an, im Prozess „Personal einstellen“ meldet sich kein geeigneter Bewerber. Es handelt sich um eine sehr qualifizierte Stelle im IT-Bereich, und der Arbeitsmarkt ist leer gefegt. Der Personalsachbearbeiter beschließt, einen „Headhunter“ zu engagieren – auf Erfolgsbasis. So etwas ist noch nie gemacht worden in seiner Verwaltung – und wird wohl auch so schnell nicht wieder vorkommen. Er fügt in diesen einen Fall einen neuen Cluster ein: „Headhunter suchen“ – vielleicht ohne diese Einfügung irgendwo zu dokumentieren. Darin ist er frei. Denn die Story Map ist kein festes Korsett. Im Adaptive Case Management6 verwendet man das Bild von den „Leitplanken auf der Autobahn“ – im Unterschied zu den „festen Bahngleisen“ einer Prozessbeschreibung im Sinne eines starren Workflows.

Durch ihre Flexibilität sind Story Maps insbesondere für Wissensprozesse geeignet, die schwach strukturiert sind. Flussdiagramme hingegen wurden im Zeitalter des Taylorismus anhand stark strukturierter Prozesse entwickelt.7

6Zum Adaptive 7Vgl.

Case Management vgl. Palmer et al (2016) und Fischer (2016) und Swenson (2010). England (2013)

14  Prozesse beschreiben mit Story Mapping

149

14.4 Prozessverbesserungen mit Story Maps Herkömmliche Flussdiagramme werden meist nicht gepflegt, weil sie so unübersichtlich sind. Wenn sich am Prozess etwas ändert, wird die Beschreibung meist nicht nachgezogen – der hohe Aufwand stellt eine große Hürde dar. Die Diagramme streben zwar an, alles im Detail darzustellen – aber schnell sind sie veraltet und stimmen dann überhaupt nicht mehr. Mit Story Maps kann man Prozesse hingegen schnell im sinnvollen Maß standardisieren und sie dann auch verbessern (Abb. 14.4). Ihre Übersichtlichkeit macht sie dafür besser geeignet als Flussdiagramme.

Abb. 14.4  In einem Workshop hat das Team Verbesserungsvorschläge rechts neben die Story Map notiert

150

W. Steinbrecher

Story Maps unterstützen die Teams dabei, ins Gespräch zu kommen. Die Cluster mit ihren Bezeichnungen stellen Elemente einer Kunstsprache dar, komprimierte Begriffe, in denen sich die Organisation effizient verständigen kann. Menschen – nicht Tools – machen ein System wie die Verwaltung produktiv. Das Gespräch zwischen Menschen – wir hatten am Anfang dieses Kapitels auf das Arzt-Patienten-Gespräch verwiesen – bringt Prozesse voran. Je mehr eine Methode das Gespräch befördert, umso nachhaltiger dient sie unserer Entwicklung.

Literatur Büsse-Voss M (2017) Unterschiede zwischen Story Mapping und anderen Methoden der Prozessbeschreibung, Semesterarbeit an der HdM, 28. Februar 2018 England R (2013) Plus! The standard+case approach. two hills Ltd, Wellington Fischer L (Hrsg), Keith D Swenson, Nathaniel Palmer, Bruce Silver et al (2016) Taming the unpredictable: real world adaptive case management: case studies and practical guidance. Future Strategies Inc., Florida (2011) Gawande A (2013) Checklist-Strategie: Wie Sie die Dinge in den Griff bekommen. btb, München Palmer N, Swenson KD, Sinur J, Khoshafian S, Chow L et al (2016) Best Practices for Knowledge Workers: Innovation in Adaptive Case Management. Future Strategies Inc., Florida Patton J (2014) User story mapping: discover the whole story, build the right product. O’Reilly, Beijing Steinbrecher W (2016) Statt Workflow-Mythos: Raus aus den Silos! http://agile-verwaltung.org. Zugegriffen: 22. Apr. 2016 Swenson D (2010) Mastering the unpredictable: how adaptive case management will revolutionize the way that knowledge workers get things done. Meghan-Kiffer Press, Florida

Wolf Steinbrecher  ist Volkswirt und Informatiker. Er war lange als Anwendungsentwickler für medizinische Datenbanken und in Systemhäusern tätig. Von 1995 bis 2008 war er Sachgebietsleiter „Organisation und Controlling“ in einer mittelgroßen Landkreisverwaltung (1050 MA). Aus den dortigen Erfahrungen rührt das Interesse an teamzentrierten, agilen Arbeitsweisen. Ein Resultat davon war die Entwicklung des Prozessorientierten Ablagesystems (PAS), das in diversen Büchern dargestellt wird. Seit 2008 selbstständiger Berater. Mitgründer des Forums Agile Verwaltung e. V.

15

Gelungene (agile) Kommunikation mit LEGO® Serious Play® Der Zusammenhang zwischen „agil“ und „Kommunikation“ Tobias Seidl

Zusammenfassung

Eine der Grundvoraussetzungen für erfolgreiches agiles Arbeiten ist eine gelungene Kommunikation zwischen den beteiligten Stakeholdern. Im Beitrag wird mit LEGO Serious Play (LSP) eine Methode vorgestellt, die sich für die Gestaltung von Kommunikationsprozessen im agilen Umfeld eignet. Zunächst werden der theoretische Hintergrund und das Vorgehen bei LSP vorgestellt. Darauf aufbauend werden (erprobte) Einsatzszenarien aus dem öffentlichen Sektor diskutiert.

15.1 Annäherung ans Thema Der Trendbegriff „agil“ wurde ursprünglich im Kontext der Softwareentwicklung geprägt. Im „Manifesto for Agile Software Development“ wurden in den 1990er Jahren innovativen Ideen zur Umgestaltung des Softwareentwicklungsprozesses gebündelt. Für den Kontext der öffentlichen Verwaltung wurden die Ideen des agilen Manifests, sowie Fokus und Wording, durch das Forum Agile Verwaltung (2016) angepasst: • • • • • •

Nimm das Ganze in den Blick, bilde cross-funktionale Teams, experimentiere mit überschaubaren Änderungen und Teilergebnissen, beziehe die Anspruchsberechtigten ein, verschaffe dir regelmäßiges Feedback von innen und außen, mache so dein System immer angemessener.

T. Seidl (*)  Professor für Schlüsselkompetenzen, Hochschule der Medien, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_15

151

152

T. Seidl

Betrachtet man diese Grundsätze genauer und stellt man sich deren Umsetzung im Verwaltungsalltag vor wird schnell klar, dass agiles Arbeiten ohne gelungene Kommunikation nicht funktioniert: Das Ganze kann nur dann in den Blick genommen werden, wenn man sich gemeinsam über verschiedene Perspektiven auf und individuelle Anteile am Thema verständigen kann. Funktionierende cross-funktionale Teams setzen eine klare Kommunikation der eigenen professionellen Sicht, der eigenen Bedürfnisse und der gemeinsamen Vision voraus. Die Einbeziehung von Stakeholdern funktioniert nur dann, wenn eine wertschätzende und dialogorientierte Kommunikationssituation geschaffen werden kann. Feedback zur Prüfung der eigenen Hypothesen und zur Verkleinerung des eigenen blinden Flecks setzt voraus, dass passende Kommunikationskanäle geschaffen worden sind. Die lessons learned mit agilem Vorgehen in ihrem Ursprungsbereich, der Softwareentwicklung, betonen auch die Bedeutung der Kommunikation für den Prozess. Dabei geht es nicht primär um möglichst viel Kommunikation, sondern um qualitativ hochwertige Kommunikation: direkt, offen und ehrlich (Wolf und Bleek 2011). Die Beispiele aus der Praxis zeigen auch, dass gelungene agile Kommunikation neben passenden Methoden die richtige Haltung voraussetzt, denn ohne das richtige Mindset läuft die beste Methode ins Leere. Zum agilen Mindset gehören Respekt, Mut, Fokussierung, Offenheit, Selbstverpflichtung und Vertrauen (Hinz 2017, S. 22). An Kommunikationsmethoden im agilen Arbeitsprozess stellen sich somit verschiedene Anforderungen: • sie müssen die Umsetzung der agilen Prinzipien in der Praxis unterstützen • sie müssen anschlussfähig an das agile Mindset sein • das Arbeiten an der individuellen (agilen) Haltung ist in der Regel ein andauernder oder zumindest langfristiger Prozess. Deshalb unterstützen die Kommunikationsmethoden idealerweise die (Weiter)Entwicklung (einzelner Aspekte) des agilen Mindsets. Im Beitrag wird exemplarisch eine Methode vorgestellt, die diesen Anforderungen gerecht wird, nämlich LEGO® Serious Play® (LSP). LSP ist eine Moderationsmethode, die in den 1990er Jahren in Kooperation zwischen dem dänischen Spielzeughersteller LEGO® und dem Schweizer International Institute for Management Development Lausanne entwickelt wurde und seit 2010 unter einer Creative Commons-Lizenz nutzbar ist. LSP verbindet aktuelle Erkenntnisse der Managementwissenschaften mit Theorien der Lern- und Entwicklungspsychologie und hat sich im Einsatz im öffentlichen Sektor bewährt. Zu LEGO Serious Play als Methode liegen verschiedene Veröffentlichungen vor, die den Prozessablauf und einzelne Aspekte der Methode detailliert beschreiben. Einen Überblick über die Literaturlage in Europa bietet Frick et al. (2013).

15  Gelungene (agile) Kommunikation mit LEGO® Serious Play®

153

15.2 Die Moderationsmethode LEGO Serious Play Die Grundidee von LEGO Serious Play ist in einem hochstrukturieren Prozess LEGO Modelle als Kommunikationsmedium zu benutzen. Dabei ergeben sich sowohl im Bauprozess als auch bei der Erläuterung und Diskussion der Modelle Mehrwerte, die die Methodik von anderen Moderationsmethoden unterscheidet. Mit dem Einsatz von LSP werden, unabhängig von der spezifischen inhaltlichen Zielsetzung des Einsatzszenarios, drei aufeinander aufbauende Ziele erreicht (vgl. Kristiansen und Rasmussen 2014, S. 15): 1. Breite Beteiligung ermöglichen und Involviertheit der Teilnehmenden steigern: Die LSP Methode garantiert zum einen eine gleichberechtigte Beteiligung aller Teilnehmenden am Arbeitsprozess (z. B. ähnliche Redeanteile und die Möglichkeit für alle, Beiträge zu äußern), zum anderen fördert sie die aktive Mitarbeit aller Teilnehmenden sowie hohes individuelles Engagement. 2. Wissen zugänglich machen: Durch LSP wird das individuelle träge Wissen der Teilnehmenden zugänglich gemacht. Darüber hinaus fördert die Methode das Entwickeln von Verständnis und Interesse für die Perspektiven und Erkenntnisse der anderen Teilnehmenden. 3. Den Teilnehmenden ermöglichen, aus festen (Denk-)Bahnen auszubrechen und neue Ideen zu generieren: Der menschliche Verstand ist darauf trainiert in Mustern zu denken; d. h. nicht nur bekannte Denkmuster anzuwenden, sondern auch neue Denkmuster im Sinne von neuen Ideen, Perspektiven oder Erklärungen zu entwickeln. Schon die Zielebene zeigt, dass die Methode in hohem Maße zu den agilen Prinzipien und dem oben beschriebenen agilen Mindset kompatibel ist. Realisiert werden diese Ziele durch einen seit 1996 in mehreren Iterationen weiterentwickelten strukturierten Arbeitsprozess. Das Vorgehen folgt immer den gleichen vier Schritten (für eine detailliertere Darstellung vgl. Seidl o. D.): 1. Bauauftrag: Zunächst wird den Teilnehmenden eine Frage gestellt, die den Bauauftrag darstellt. 2. Bauen: Die Antwort auf die Frage wird durch das LEGO-Modell gegeben. Dabei bestehen die Modelle zu einem großen Teil aus Metaphern. Dies ermöglicht es, mit einer begrenzten Zahl, Form und Farbe an Bauteilen nahezu unbegrenzt Informationen und Gedanken auszudrücken. Neben dem Mitteilen der eigenen Perspektive werden durch das haptische ‚Erschaffen‘ der Antwort Denkprozesse angeregt und dokumentiert sowie neue Einsichten gewonnen. 3. Teilen: Da das Modell nicht selbsterklärend ist, wird es im nächsten Schritt von der Person, die es gebaut hat, erläutert. Die Teilnehmenden werden angeregt die

154

T. Seidl

‚Geschichte ihres Modells‘ zu erzählen. Dabei findet nicht nur eine Präsentation des Modells für die anderen Teilnehmenden, sondern auch eine vertiefte Auseinandersetzung des Erbauenden mit dem Modell statt. 4. Reflektieren: Alle Teilnehmenden beteiligen sich durch Nachfragen zum Modell bzw. der erzählten Geschichte am Prozess. Dadurch können bislang vernachlässigte Bedeutungen herausgearbeitet und ein geteiltes Verständnis der Perspektive der Person, die das Modell gebaut hat, erreicht werden. Ergebnisse eines Bauprozesses (in sehr einfacher Form) sind beispielhaft in Abb. 15.1 zu sehen. Betrachtet man die Modelle, ist augenscheinlich, dass das Erklären durch die bauende Person ein zwingender Schritt im Arbeitsprozess ist. Die vier exemplarischen Modelle in der Abbildung stellen einzelne Stärken von Teilnehmenden eines LSP-Prozesses dar (verkürzt; von links nach rechts): ‚Die Fähigkeit eine Metaperspektive einzunehmen‘, ‚mich schützend vor andere zu stellen‘, ‚kreativ und vielfältig zu arbeiten‘, ‚vorausschauend zu sein‘ und ‚die Führung zu übernehmen‘. Das strukturierte Vorgehen fördert sowohl das Herausarbeiten der eigenen Perspektive wie das Entwickeln von Akzeptanz für die Perspektive der anderen Beteiligten. Beim Arbeiten mit LSP wird nicht nur die kognitive Ebene angesprochen, sondern auch schwer formulierbare Aspekte (Bauchgefühle, Erfahrungen, Emotionen etc.) in den Arbeitsprozess eingebracht. Damit ein authentisches Handeln der Teilnehmenden möglich ist, werden sie zu Beginn der LSP-Session zunächst durch verschiedene aufeinander aufbauende Übungen geführt, in denen die Anforderungen an die Teilnehmenden (sowohl im Hinblick auf den Umgang mit dem Material als auch mit der Arbeitsweise) langsam gesteigert werden.

Abb. 15.1  Einfache Ergebnisse eines LSP Bauprozesses. (Quelle: Fraunhofer IAO, Benedikt Hilscher)

15  Gelungene (agile) Kommunikation mit LEGO® Serious Play®

155

Der Arbeitsprozess basiert auf verschiedenen theoretischen Konzepten: • Konstruktivismus: Aus konstruktivistischer Sicht ist das bei einem Menschen vorhandene Wissen nicht die objektive Abbildung der Wirklichkeit, sondern das Ergebnis eines individuellen Konstruierens der Wirklichkeit. Die Erfahrungen mit der Methode zeigen, dass bei LSP dieser Konstruktionsprozess nicht nur im Kopf der Teilnehmenden, sondern auch durch das Bauen der Modelle auf dem Tisch stattfindet. Das heißt, die Modelle machen Wissen nicht nur sichtbar, sondern durch das Bauen werden auch neue Erkenntnisse konstruiert. • Storytelling – die Kunst des Erzählens: Das Erzählen von Geschichten ist Kernbestandteil der menschlichen Kultur. Für LSP sind insbesondere zwei Aspekte des Geschichtenerzählens von Bedeutung: 1) Geschichten dienen als Sinngeneratoren menschlichen Handelns (vgl. Loebbert 2003, S. 17). Für den LSP-Kontext bedeutet das, dass im Arbeitsprozess durch Storytelling nicht allein eine Situationsbeschreibung vorgenommen wird, sondern tiefer liegende Bedeutungsebenen bearbeitet werden können. 2) Das Gedächtnis strukturiert Erinnerungen auch in Form von Geschichten (vgl. Echterhoff und Straub 2004, S. 121). Der Storytellingansatz erlaubt so zum einen das effektive Abrufen von vorhandenem Wissen während des LSP-Prozesses, zum anderen zeigen die praktischen Erfahrungen mit der Methode, dass die Arbeitsergebnisse der LSP-Sessions besonders gut von den Teilnehmenden erinnert werden. Zudem ist das Erzählen von Geschichten aus konstruktivistischer Sicht ein wichtiges Vorgehen bei der Konstruktion von Wirklichkeit. Der Soziale Konstruktivismus führt diesen Gedanken noch weiter und vertritt den Standpunkt, dass der Mensch nur in der Interaktion mit anderen Erkenntnisse über sich und die Welt gewinnen kann (vgl. Duss 2016, S. 10). Bei LSP wird gerade diese Interaktion durch den beschriebenen Arbeitsprozess stimuliert und moderiert. • Spiel: Spielen ist ein dem Menschen ureigener Weg neue Fähigkeiten zu erlernen und sich veränderten Bedingungen anzupassen. Typische Eigenschaften des Spiels sind u. a. ein völliges Aufgehen in der Tätigkeit (Flowerleben), das Vorhandensein hoher intrinsischer Motivation sowie die Möglichkeit in geschütztem Rahmen alternative Handlungs-, Interpretations- und Entscheidungsmöglichkeiten ‚durchzuspielen‘ (vgl. Huizinga 1955). Diese Eigenschaften werden bei LSP gezielt genutzt und gefördert, um das Aufgehen im Prozess sowie die Denk- und Reflexionsprozesse der Teilnehmenden zu unterstützen und damit die „transformative Kraft“ (Kristiansen und Rasmussen 2014, S. 134) des Spielens zielorientiert zu nutzen.

156

T. Seidl

15.3 Einsatzszenarien der Methode Wie im ersten Abschnitt beschrieben, spielt agile Kommunikation insbesondere in den Prinzipien 1. Nimm das Ganze in den Blick, 2. bilde cross-funktionale Teams, 3. beziehe die Anspruchsberechtigten ein, 4. verschaffe dir regelmäßiges Feedback von innen und außen, eine wichtige Rolle. Im Folgenden wird anhand von Beispielen aus dem öffentlichen Sektor erläutert, welchen Beitrag LSP hier leisten kann.

15.3.1 Nimm das Ganze in den Blick Eine geteilte Vision sowie ein Verständnis für die Komplexität und die vielfältigen Facetten eines Projektes sind wichtig für die erfolgreiche Durchführung. LSP kann genutzt werden um hier Klarheit zu schaffen. So setzte ich etwa 2015 LSP ein, um die „Identität“ eines neuen Studiengangs an einer Fachhochschule zu erarbeiten. Die Herausforderung des Projektes war, dass Lehrende aus verschiedenen Bereichen der Hochschule in diesen Studiengang involviert waren, die bislang noch nicht zusammengearbeitet hatten und verschiedene fachliche Expertisen und Perspektiven in das Projekt einbrachten. Hinzu kam, dass der neue Studiengang im Hinblick auf Organisation und Struktur für die Hochschule etwas komplett Neues darstellte. Aufgrund der geplanten innovativen Studien- und Betreuungsstruktur müssen die Lehrenden beispielsweise wesentlich enger als in den bislang durchgeführten Programmen zusammenarbeiten (z. B. bei der Bewertung von Studienleistungen). Grundlegende inhaltliche aber auch Wertefragen waren zu diesem Zeitpunkt noch nicht geklärt: Welches Rollenverständnis haben die Lehrenden in diesem Studiengang? Wie werden die Inhalte zwischen einzelnen Veranstaltungen vernetzt? Wie kann die Zusammenarbeit zwischen den Lehrenden sinnvoll gestaltet werden? Welche (akademischen) Werte sollen den Studiengang prägen? Ziel des Methodeneinsatzes war es mit der gemeinsamen Entwicklung einer „Studiengangsidentität“ in diesen ­Fragen Klarheit zu bekommen und nach einer intensiven Diskussion eine gemeinsame Ausrichtung zu diesen (zum Teil sehr abstrakten) Themen zu erreichen. Klassische Methoden erschienen den Beteiligten in diesem Zusammenhang als ineffizient und nicht zielführend deshalb wurde LSP zur Prozessgestaltung eingesetzt. Mit dem im Prozess gemeinsam erarbeiteten LEGO-Modell wurde ein abgestimmtes Verständnis des Masterprogramms entwickelt an dem sich alle Beteiligten nach wie vor orientieren. In den Köpfen und Diskussionen der Lehrenden ist das Modell auch zwei Jahre nach der Erstellung noch nachhaltig verankert und wird in Diskussionen als Referenz- und Identifikationspunkt genutzt. Zudem wird den neuen Erstsemestern des Studiengangs anhand des fotografisch dokumentierten Modells jedes Semester aufs Neue das Konzept des Studiengangs erläutert.

15  Gelungene (agile) Kommunikation mit LEGO® Serious Play®

157

15.3.2 Bilde cross-funktionale Teams Cross-funktionale Teams zeichnen sich dadurch aus, dass sie aus Menschen mit verschiedenen funktionalen Fähigkeiten zusammengesetzt sind. Aus der Forschung zu „guten Teams“ wissen wir, dass geteilte Visionen und Ziele (vgl. auch oben nimm das Ganze in den Blick) sowie ein Verständnis für die Perspektiven, Arbeitsweisen und Bedürfnisse der anderen Teammitglieder zentral für den Teamerfolg sind. LSP kann dazu beitragen diese Aspekte zu fördern. Im Rahmen von Team- und Organisationsentwicklungsmaßnahmen hat sich LSP in dieser Beziehung in ganz unterschiedlichen Kontexten (vom Kindergarten bis zur Klinik) als Augen- und Ohrenöffner bewährt – insbesondere, wenn es um die geteilte Vision und Erwartungen an die gemeinsame Zusammenarbeit geht. Im Rahmen von Teamentwicklungsmaßnahmen (vgl. auch Seidl 2017) habe ich in der Vergangenheit u. a. mehrere Teams in Kindergärten begleitet. Knackpunkte waren hier beispielsweise die unterschiedlichen Herangehensweisen in der Arbeit mit jüngeren und älteren Kindern, die Auseinandersetzung mit neu eingeführten Prozessen und die Definition von Schnittstellen innerhalb der Einrichtung bzw. nach außen. Das Vorgehen bei Teamentwicklungsmaßnahmen kann folgendermaßen aussehen (jeweils dem Ablauf der vier oben beschriebenen Phasen folgend): In einer ersten Baurunde artikulieren die Teilnehmenden zunächst welche Bedingungen sie brauchen, um ihre Kompetenzen erfolgreich in die Zusammenarbeit einbringen zu können. Darauf aufbauend bauen und diskutieren die Teilnehmenden ein Modell ihres optimalen Teams. In einem letzten Schritt konstruieren die Teilnehmenden zusammen, auf der Grundlage der Diskussion um die Einzelmodelle, ein gemeinsames Modell ihres optimalen cross-funktionalen Teams. In der Vergangenheit nutzte ich die Methode auch um ein Prozessoptimierungsprojekt an einer Großklinik zu begleiten. Ziel war es Prozesse, die verschiedene Abteilungen/ Einrichtungen betreffen, sinnvoller zu gestalten. In den gebildeten Arbeitsgruppen waren Vertreter der verschiedensten Bereiche und Statusgruppen vertreten: Vom Chefarzt über den Fahrdienstleiter bis zur Pflegekraft. Ergebnis der Arbeit – neben der Entwicklung der neuen Prozesse – war eine Einsicht in die unterschiedlichen Perspektiven der Teilnehmenden. Der Chefarzt, dem es wichtig war Patienten immer möglich zeitnah zu sehen, verstand plötzlich, was es für den Fahrdienst (der für den Transport der Patienten innerhalb der Klinik verantwortlich ist) für Probleme mit sich bringt, wenn alle Aufträge (unabhängig von der medizinischen Sinnhaftigkeit) mit höchster Priorität angemeldet werden. Über das konkrete Ergebnis der Arbeitsklausur hinaus sind an diesem Tag neue Kommunikationswege entstanden, die noch heute fruchtbar genutzt werden.

15.3.3 Beziehe die Anspruchsberechtigten ein Um Probleme und Herausforderungen langfristig und zufriedenstellend zu lösen, müssen die Bedürfnisse der Nutzer herausgearbeitet und in den Problemlösungsprozess integriert werden. Voraussetzung ist zunächst die Nutzer und Kunden zu identifizieren und

158

T. Seidl

Ihre Wünsche, Vorstellungen und Bedürfnisse als bedeutsam für die eigene Arbeit zu erkennen. Hochschulen stellen sich in den letzten Jahren vermehrt die Frage, wie Studierende bei der (Weiter-)Entwicklung der Lehre beteiligt werden können. Im Hintergrund steht zum einen das Ziel den Studienerfolg der Studierenden positiv zu beeinflussen zum anderen aber auch immer mehr die Überzeugung, dass sich Hochschulen im Wettbewerb um kleiner werdende Studierendengeneration Vorteile verschaffen müssen. Für den Bereich der Curriculumsentwicklung, d. h. den Bereich der Planung der Inhalte und Lehr-Lernformate, gibt es darüber hinaus bereits konkrete Überlegungen, wie agile Werte und Formate genutzt werden können (vgl. Seidl und Vonhof 2017a). Mit dem Ziel hochschulische Qualitätsentwicklungsprozesse sinnvoll durchführen zu können diskutiere ich mit meinen Studierenden regelmäßig ihre Sicht auf „gute Hochschullehre“. Der Prozess sieht dabei folgendermaßen aus: Zunächst beschäftigten sich die Studierenden individuell mit ihrer Vorstellung von und Erwartungen an gute Lehre. Die Ergebnisse werden dann in einem gemeinsamen Modell verdichtet (vgl. Abb. 15.2). Die verschiedenen im Modell repräsentierten Aspekte können dann für die Strategie- und Maßnahmenplanung, etwa im Bereich der Curriculumsentwicklung, genutzt werden.

15.3.4 Verschaffe dir regelmäßiges Feedback von innen und außen Feedback ist für den agilen Arbeitsprozess von großer Bedeutung um frühzeitig Rückmeldung zu Zwischenergebnissen zu bekommen, um diese dann in den weiteren Arbeitsprozess integrieren zu können. Dies ist insbesondere wichtig um Fehler im Produkt/Prozess oder Fehlentwicklungen bei der Lösungssuche/-umsetzung frühzeitig zu erkennen und gegensteuern zu können. In der Vergangenheit wurde LSP von uns schon mehrfach eingesetzt, um die Rückmeldungen von Bürgerinnen und Bürgern in Neu- und Umbauprojekte öffentlicher Bibliotheken einbringen zu können (Seidl und Vonhof 2016, 2017b). Dabei wurden die grundsätzlichen Bedürfnisse der Nutzenden an die Bibliothek bzw. die Bedürfnisse

Abb. 15.2   Die Vorstellung von Studierenden von „Guter Lehre“ als LSP-Modell

15  Gelungene (agile) Kommunikation mit LEGO® Serious Play®

159

spezifischer Zielgruppen (in unserem Fall z. B. Jugendliche) mit LSP herausgearbeitet. Eine ausführliche Beschreibung eines dieser Projekte finden sie in Kap. 17 im vorliegenden Band.

15.4 Fazit Gelungene Kommunikation ist ein zentraler Bestandteil agilen Arbeitens. Der Einsatz von LEGO Serious Play ist eine bewährte Methode den Kommunikationsprozess (nicht nur) im agilen Kontext zu gestalten. Die Resonanz auf den Methodeneinsatz ist unter Führungskräften, Mitarbeitern und Kunden im öffentlichen Sektor äußerst positiv. Besonders wird in den Rückmeldungen die hohe Intensität des Dialogs, die gleichberechtigte Beteiligung im Prozess und die positive Arbeitsatmosphäre hervorgehoben. Sicherlich stellt das Arbeiten mit LEGO zum Teil einen Bruch mit den gängigen Arbeitsmethoden in öffentlichen Einrichtungen dar. Dieses Risiko hat sich aber in den von mir moderierten Prozessen bislang immer ausgezahlt – sowohl im Hinblick auf das Prozessergebnis als auch im Hinblick auf die Prozesszufriedenheit!

Literatur Duss D (2016) Storytelling in Beratung und Führung. Theorie. Praxis. Geschichten. Springer, Wiesbaden Echterhoff G, Straub J (2004) Narrative Psychologie. In: Jüttemann G (Hrsg) Psychologie als Humanwissenschaft. Ein Handbuch. Vandenhoeck & Ruprecht, Göttingen, S 102–133 Forum Agile Verwaltung (2016) Agile Arbeitsmethoden: welcher Nutzen für die öffentliche Verwaltung? https://agile-verwaltung.org/was-bedeutet-agile-verwaltung/was-heisst-agile-verwaltung/ Frick E, Tardini S, Cantoni, L (2013) White Paper on LEGO® SERIOUS PLAY®. A state of the art of its applications in Europe. http://www.s-play.eu/attachments/article/70/splay_White_Paper_ V2_0_1.pdf Hinz O (2017) Segeln auf Sicht. Das Führungshandbuch für ungewisse Zeiten. Springer, Wiesbaden Huizinga J (1955) Homo ludens. A study of the play-element in culture. Beacon, Boston Kristiansen P, Rasmussen R (2014) Building a better business using the Lego serious play method. Wiley, Hoboken Loebbert M (2003) Storymanagement. Der narrative Ansatz für Management und Beratung. KlettCotta, Stuttgart Seidl T (2017) Playful team reflection using LEGO serious play. Int J Game based Learn 7(3):83–86 Seidl T (o. D) LEGO® in higher education. Der Arbeitsprozess. http://legoinhe.de/der-arbeitsprozess/ Seidl T, Vonhof C (2016) Neue Wege der Bürgerbeteiligung in Bibliotheken – Erarbeitung der Stakeholder-Bedürfnisse mit der Methode LEGO Serious Play. Forum Bibl Inf – BuB 8(16):482–487

160

T. Seidl

Seidl T, Vonhof C (2017a) Agile Prinzipien – was kann die Studiengangsentwicklung davon lernen? Fachmagazins Synergie. Digitalisierung in der Lehre 3:22–25 Seidl T, Vonhof C (2017b) Ermittlung von Kundenbedürfnissen durch Gamification. Forum Bibl Inf – BuB 11(17):630–632 The LEGO Group (2010) Open-source Introduction to LEGO(R) Serious Play(R) Wolf H, Bleek W-G (2011) Agile Softwareentwicklung. Werte, Konzepte und Methoden. dpunkt, Heidelberg

Prof. Dr. Tobias Seidl  lehrt und forscht als Professor für Schlüsselund Selbstkompetenzen an der Hochschule der Medien Stuttgart (HdM). Nach Stationen in der hochschuldidaktischen Personal- und Organisationsentwicklung (unter anderem an den Universitäten Mainz und Koblenz-Landau) macht er jetzt Studierende der HdM fit für die Herausforderungen der Zukunft und verantwortet den Bereich Lehrentwicklung der Fakultät Informationen und Kommunikation. Als Coach und Experte unterstützt er Hochschulen, Unternehmen und öffentliche Einrichtungen bei der Generierung und Umsetzung neuer Ideen.

Teil III Praxisbeispiele – Agile Methoden in der Öffentlichen Verwaltung

Agile Arbeitsformen im nicht-agilen Umfeld

16

Von Hürden und Chancen Veronika Lévesque

Zusammenfassung

Die Umstellung eines Betriebs oder einer Verwaltung von einer klassischen Aufbauorganisation zu einer agilen Matrix ist ein riesiges Unterfangen. Schon die schlichte Größe der Aufgabe wirkt oft auf Entscheiderinnen und Entscheider und auch auf Mitarbeitende abschreckend – zumal häufig nur einzelne Beteiligte eine praktische Vorstellung davon haben, was ‚agile Organisation‘ denn in Tat und Wahrheit bedeutet. Oft ist es gerade in der öffentlichen Verwaltung aus rechtlichen und politischen Gründen – zumindest gefühlt – gar nicht möglich. Können wir mit dieser Hürde konstruktiv umgehen und uns nicht abschrecken lassen? Die Idee ist zu erproben, wie agile Arbeitsformen in der nicht-agilen Organisation eingebettet werden könnten. So wird Agilität erlebbar und Erfahrungen können live und in Farbe gemacht werden (Abb. 16.1). Kann es möglich sein, auch in klassisch hierarchisch organisierten Organisationen wie öffentlichen Verwaltungen situativ oder zunehmend mit agilen Grundhaltungen und Methoden zu operieren? Ohne dabei sofort die Hierarchien, Zuständigkeiten und Funktionen allzu brutal infrage zu stellen oder gar zu „gefährden“? Wie könnte das aussehen? ‚Agil‘ ist mehr ein Handlungsrahmen und ein Haltungsraum denn eine Methode oder Strukturform. Es gibt viele Möglichkeiten, agil zu agieren. Und auch, den Strukturen und der Einordnung des Betriebes dabei treu zu bleiben.

V. Lévesque (*)  Forum Agile Verwaltung e. V., Basel, Schweiz E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_16

163

164

V. Lévesque

Abb. 16.1   Agile Teams

16.1 Agile Prinzipien: Nahe an der aktuellen Realität. Praxisnah und anpassungsbereit Agil heißt unter anderem: in kurzen Rhythmen, ausprobieren, anschauen und anpassen, nah an Personen und Situationen auf ein Ziel, das sich nach und nach schärft, handeln und dies jederzeit der tatsächlichen Situation mit allen ihren Veränderungen möglichst nahe und angemessen – deshalb agil eben. These: Die Generationen der heute 40-jährigen und alle Älteren – das heißt, die heute im öffentlichen Leben kulturprägenden Jahrgänge – sind in einer Zeit und von Personen sozialisiert worden, die im Zuge der Nachkriegszeit und in den Jahrzehnten des Wirtschaftswunders die Erfahrung generiert hat, dass Planung, solide standardisierte Prozesse, Stabilität, Nachvollziehbarkeit und bekannte Erfolgsrezepte ein Garant für Erfolg, stetiges Wachstum und Wohlstand sind. Darauf baut in vielen Bereichen das aktuelle Wirtschaftsleben und die auch die öffentliche Verwaltung immer noch auf. Betriebswirtschaftliche Klassiker, d. h. Begriffe wie Funktion, Frist, Planung, Führung, Standards und so weiter, können in agiler Nutzung neue Bedeutung erhalten und angepasst werden. Es nicht zwingend nötig, den bekannten Boden und die Verwurzelung im Bewährten radikal komplett zu entziehen. Es schon hilfreich, diese Begriffe mit Handlungsalternativen zu ergänzen: • • • •

ziel- und situationsbezogene Rollen zusätzlich zu starren Funktionen, nützliche Rhythmen als Alternative zu gesetzten Fristen, Leadership mehr als Führung, organisatorische, situative und personenbezogene Anpassung an momentane Fragestellungen und Ziele gestalten zu können als wichtige Kompetenz neben der üblichen kurz-, mittel- und langfristigen Planung, • in einem Netzwerk, das auch innerhalb der linearen Linie Raum und Bewegungsmöglichkeiten findet, zu agieren.

16  Agile Arbeitsformen im nicht-agilen Umfeld

165

16.2 Erfundene Praxis1: Die „Interessengemeinschaft Qualität“ Immer wieder hat die Leitung sich bemüht, das Thema Qualität einem Bereich hierarchisch anzugliedern oder aber Projekte zu lancieren, die die Qualitätsarbeit klar be- und festschreiben sollten. Im Betrieb sind zahlreiche Fach- und Führungskräfte und auch Stäbe, die in ihrem Führungsbereich Pflichten und Ziele haben, die Qualitätsaufgaben betreffen. Es ist ein Thema, das durchaus allen schon auch „irgendwie echt wichtig“ ist. Gleichzeitig ist es aber schwer zu fassen und wenn man den Faden ‚Qualität‘ aufnimmt, führt er tief in die Prozesse und auch in die historisch gewachsenen Anliegen (und vermuteten Abgründe) des Verwaltungsbetriebs. In die schwer kontrollierbaren Eingeweide: „Schwer absehbar, was genau soll Qualitätsarbeit können, das ist verhängt mit diversen anderen Themenbereichen, es gibt gar unterschiedliche Interessen in den verschiedenen Verwaltungsebenen, das ist gefühlt unplanbar, eventuell eine große Kiste, wohin überall führt das…“. Die Verpuffungseffekte nach jedem neuen Kick-off waren hoch, Projektleitende zu finden war nahezu unmöglich. Der Begriff ‚Qualität‘ fing an, zum Stigma zu werden. Was tun? Ein Gefäß mit dem Fantasietitel ‚Interessensgemeinschaft IG Qualität‘ wurde gebildet. Es war also kein Projekt – bewusst nicht, denn die Qualitätsarbeit war weder neu noch zeitlich begrenzt. Qualitätsmanagement und –sicherung gehörten zu den Regelaufgaben aller Beteiligten. Die IG bestand aus einer koordinierenden Moderation sowie den relevanten Fach- und Führungskadern aus den Ämtern und Stabstellen – 18 Personen. Alle waren für ihre unterschiedlichen Bereiche in Qualitätsfragen entscheidungs- oder fachweisungsbefugt und im Rahmen ihrer Aufgaben verantwortlich für die Umsetzung ihrer Entscheidungen und die Erfüllung von Qualitätspflichten ihrer Organisationseinheiten. Sie wurden aufgrund dieser Aufgaben zur Interessensgemeinschaft eingeladen und behielten im Verlauf der Arbeit ihre Funktionen und ihre Kompetenzen. Die – agilisierende – Idee dabei war, herauszufinden, ob es in so einem Rahmen möglich ist, die Beteiligten moderiert für diese Aufgabenstellung, für die es keinen strukturell vorgegebenen Lead und keine 1:1-Zuständigkeit gab, in adaptive, agile Formen der Zusammenarbeit zu führen, die umsetzungsnah ein zu Beginn kaum greifbares Produkt im Fokus behielten. • Mehr das Ganze und das Gemeinsame in den Blick nehmen als einzelne Organisationseinheiten und Positionen in den Vordergrund zu stellen. • Mehr als cross-funktionales verantwortliches Team (bzw. Interessensgemeinschaft) funktionieren denn als Einzelfunktionstragende, für die das Thema (zu) groß und schwer zu bewältigen erschien.

1„Erfundene

Praxis“ soll heißen: So oder so ähnlich haben tatsächlich Prozesse, die wie hier erzählt durchgeführt wurden, stattgefunden. Sie sind hier aus Gründen der Vertraulichkeit aber verfremdet oder generalisiert. Die Erfahrungen dahinter sind aber realexistierend.

166

V. Lévesque

• Damit auch bereits unterschiedliche Anspruchsgruppen – wenn auch in diesem Beispiel nur interne – dabei zu haben. • Mehr mit Teilergebnissen zu funktionieren, die für sich alleinstehend operabel waren und immer wieder modelliert werden konnten, als ein weiteres Mal „den ein für alle Mal großen Wurf“ zu suchen. Schritt 1: Zunächst wurde ein gemeinsamer Qualitätsbegriff erarbeitet: WAS GENAU meinen WIR für unsere Organisation, wenn wir von Qualitätsaufgaben sprechen? Das erste Teilprodukt: Eine akzeptable bzw. akzeptierte „eigene“ und daher als passend und nicht fremd empfundene Definition.

Schritt 2: Gemeinsam eruierte und formulierte die Interessengemeinschaft dann in der nächsten Etappe fünf Wirkungsfelder im Rahmen der Qualitätsarbeit, die entweder • strategische Grundlagenfragen betrafen, • besonders starke Hebelwirkung vermuten ließen oder • von hoher Dringlichkeit waren. Allein dieser Schritt führte einerseits zu erstmaligen bereichsübergreifenden gemeinsamen Standpunkten und andererseits zu formulierten Unterschieden. Das Arbeitsfeld ‚Qualität‘ wurde sichtbar. Das zweite Teilprodukt: Konkrete Wirkungsfelder mit entsprechenden Anwendungsbereichen – eine erste Idee von Praxisnutzen und Sinn. Diese Wirkungsfelder werden in der Folge nicht mehr nur im Rahmen der Qualitätsarbeit genutzt – dieses Teilprodukt hat sich auch unabhängig von der IG als nutzbar erwiesen.

Schritt 3: Jedes Wirkungsfeld bekam eine koordinierende Co-Leitung innerhalb der Interessengemeinschaft mit je einer Fachperson aus einer Dienststelle und einem Stab. In den monatlichen Sitzungen wurden nun die Arbeiten der verschiedenen Wirkungsfelder vorgestellt, inhaltlich aufeinander abgestimmt und organisatorisch miteinander koordiniert. Gearbeitet wurde zwischen den Koordinationssitzungen innerhalb der herkömmlichen Strukturen, Gefäße, Zuständigkeiten und Kompetenzen. Nächste Teilprodukte: Durch die Co-Leitung der Wirkungsbereiche und die moderierte Plattform der Interessengemeinschaft als koordinierende Taktgeberin entstanden besonders deutlich zwei Effekte: erste Anzeichen einer multiprofessionellen Zusammenarbeit innerhalb der bestehenden Amtsstrukturen stellten sich fast von selbst ein. Gleichzeitig entwickelte sich nach und nach eine gemeinsame multiperspektivische Sicht auf die Arbeitspakete und das Endprodukt: ein praktikables abgestütztes Vorgehen in der Qualitätsarbeit und ihrer Umsetzung in den Ämtern.

16  Agile Arbeitsformen im nicht-agilen Umfeld

167

Die Rückmeldungen sprachen von Fortschritten: Das immer wieder gemeinsame Takten ist echt sinnvoller und praktikabler als Projektpläne. In der Koordinationssitzung der IG sehe ich, wie das gemeinsame Konstrukt wächst, immer wieder angepasst wird – und ich kann dann jeweils sofort damit arbeiten.

Der Begriff ‚agil‘ ist nie gefallen. Stattdessen hat die Interessensgemeinschaft gemeinsam an einem Thema gearbeitet, es sich zu eigen gemacht und an die gegebene Situation adaptiert. Sie hat Produkte entwickelt und umgesetzt. Sie hat sich mit den Spezifitäten ihrer Möglichkeiten und ihres Umfeldes auseinandergesetzt. Es ging nie darum, eine neue agile Struktur oder Methode einzuführen oder den Betrieb an sich infrage zu stellen, sondern eine adäquate Lösung für eine bestehende Herausforderung zu entwickeln.

Veronika Lévesque  ist seit 1998 aktiv als Spezialistin für Organisationsentwicklung mit den Schwerpunkten Kokreation, adaptive Lösungsentwicklung, Change-Prozesse, Visualisierung, Projekt- und Prozessdesign und Koordination multiprofessioneller Teams sowie (Großgruppen-) Moderation und (System-) Beratung. Seit 2003 ist sie in der Öffentlichen Verwaltung, vorher in den Branchen Bildungsmanagement, Spedition und Logistik, Softwareentwicklung und Personalberatung unterwegs. Besondere Interessen: Grenzgänge – zwischen Ländern genauso wie zwischen Aufgabenbereichen und Kontexten.

Bibliotheken und Agilität – Welten begegnen sich?

17

Cornelia Vonhof

Zusammenfassung

Dieses Kapitel blickt auf Bibliotheken als Kultur- und Bildungsinstitution mit der größten Breitenwirkung und deren Ansätze, agile Methoden anzuwenden und vor allem ein agiles Mindset zu entwickeln. Dazu werden nationale und internationale Good Practices vorgestellt und den vom Forum Agile Verwaltung entwickelten Prinzipien zugeordnet.

17.1 Warum Bibliotheken in einem Buch über agile Verwaltung auftauchen (müssen) Rund 8000 Bibliotheken gibt es laut offizieller Deutscher Bibliotheksstatistik in ­Deutschland. 7600 davon, die „Öffentlichen Bibliotheken“, sind in kommunaler oder kirchlicher Trägerschaft. Die rund 400 Wissenschaftlichen Bibliotheken (Universitäts-, Hochschul-, Regional- und Nationalbibliotheken) werden vom Bund oder den Ländern getragen. Bibliotheken sind also zweifelsohne Institutionen, die dem öffentlichen Sektor zuzuordnen sind. Sie sind in aller Regel als Verwaltungsbetriebe in ihre Trägerorganisationen organisatorisch eingegliedert. Private Rechtsformen stellen die Ausnahme dar. Will man also ein breites Feld des Verwaltungshandelns beleuchten, so führt an diesen Institutionen kein Weg vorbei. Auch für die Bürgerinnen und Bürger, die Nutzer und Kundinnen der Bibliotheken, führt an ihnen kein Weg vorbei. Trotz der weitverbreiteten Annahme, im Zeitalter des Internet seien „Büchertempel“ obsolet geworden und ohne-

C. Vonhof (*)  Hochschule der Medien Stuttgart, Stuttgart, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_17

169

170

C. Vonhof

Abb. 17.1   Besuche in Bildungs-, Freizeit und Kultureinrichtungen 2016. (Eigene Darstellung)

hin alles im Netz frei verfügbar, gibt es keine andere Bildungs-, Freizeit- und Kultureinrichtung, die so stark besucht und genutzt wird wie Bibliotheken. Der Vergleich der Besuche in unterschiedlichen Kultur-, Bildungs- und Freizeiteinrichtungen zeigt die herausragende Position von Bibliotheken (Abb. 17.1).

17.2 Ein Blick auf Rahmenbedingungen und Herausforderung für die Bibliotheksarbeit Gleichwohl stimmt es natürlich: Die Rahmenbedingungen, unter denen Bibliotheken heute ihre Services anbieten, haben sich durch die digitale Transformation bereits stark verändert und werden sich weiter verändern. Gerade im Kerngeschäft von Bibliotheken – dem Verfügbarmachen von Information und Wissen – bleibt kein Stein auf dem anderen. Über Jahrtausende hinweg war es eine zentrale Aufgabe von Bibliotheken, gedruckte Texte zu sammeln und zugänglich zu machen. Das genügt nicht mehr, diese Aufgabe entfällt jedoch auch nicht. Hinzu kommt heute die Aufgabe, den Zugang zu digitalen Informationen zu gewährleisten, dies aber zu völlig anderen Bedingungen. Erwartungen an Orts- und Zeitunabhängigkeit sind verbunden mit Erwartungen an Informationen, die personalisiert, kontextspezifisch und nach dem Push-Prinzip geliefert werden. Auch die Wettbewerber haben sich verändert. Bibliotheken konkurrieren nicht mehr nur mit anderen Bibliotheken, Buchhandlungen oder Verlagen, sondern: „Our competition is Apple and YouTube and Amazon – companies creating real-time, dynamic ways to find things to read and watch and know“ (Mofitt 2013). Der Informationsmarkt oszilliert dabei zwischen Informationsflut und „Digital Divide“1. Daraus ergeben sich zusätzliche, neue und in höchstem Maß gesellschaftlich

1Digital Divide oder „digitale Spaltung“ bezeichnet eine Situation, in der Chancenungleichheiten dadurch entstehen, dass nicht jede Bevölkerungsgruppe die gleichen Möglichkeiten hat, an digital verfügbare Informationen zu gelangen, bzw. diese zu nutzen. Dabei geht es zum einen um technische Zugangsmöglichkeiten, aber auch um die Fähigkeiten der Menschen, mit diesen Techniken umzugehen. Ziel ist es, durch geeignete Maßnahmen die digitale Spaltung zu vermeiden bzw. zu überwinden.

17  Bibliotheken und Agilität – Welten begegnen sich?

171

relevante Aufgaben wie zum Beispiel die Vermittlung von „Digital Literacy“, was die Fähigkeit beschreibt, Informationen, die in verschiedenen Formaten von einer Vielzahl verschiedener Quellen auf einer breiten Palette unterschiedlicher digitaler Geräte zur Verfügung stehen, kompetent und kritisch zu handhaben und vor allem zu bewerten. Die Digitalisierung ist aber nur ein Treiber für Veränderungen. Gesellschaftliche Entwicklungen, vom demografischen Wandel, über Migration, die Veränderung von Berufsbiografien, mit der die Notwendigkeit zum Lebenslangen Lernen einhergeht, ein verändertes Freizeitverhalten bis hin zum Verschmelzen von Arbeits- und Privatleben, sind weitere Treiber. Auch aus diesen ergeben sich neue Handlungsfelder, die hier nur exemplarisch angerissen werden. Bibliotheken waren immer schon Orte des Lernens. Ungestörtes Lernen in konzentrationsfördernder Umgebung – am besten in gediegenen Lesesälen – mit Zugriff auf die benötigte Literatur, das sind die Bilder in vielen Köpfen. Doch die Form, wie heute zunehmend gelernt und gelehrt wird2, führt dazu, dass sich der Lernort Bibliothek neu erfindet und die Rolle von Bibliotheken im Bildungsbereich neu zu interpretieren ist. Lernen wird als sozialer Prozess erkannt, den Bibliotheken mit Lernressourcen und Infrastruktur unterstützen. Lernende sind dabei nicht länger bloße Konsumenten, sondern ebenso Produzenten. Sharing-Economy funktioniert nämlich nicht nur bei Autos oder Kinderkleidung, sondern auch bei Lernressourcen. „Open Educational Resources“ sind neue Formate, die peer-to-peer-Lernen3 fördern und die eine verlässliche Infrastruktur benötigen, um Zugänglichkeit sicherzustellen. Das wiederum ist das klassische Kerngeschäft von Bibliotheken. Beim Zugänglichmachen endet der Prozess aber nicht mehr. Die kollaborative Wissensproduktion und das Einbeziehen der Stakeholder (nämlich der Lernenden) in den Prozess der Erstellung dieser Services der Bibliothek, treten als neue Aspekte dazu. Bibliotheken verankern digitale Lerninhalte in der realen Welt. Sie sind aber auch selbst reale, nicht-kommerzielle Orte mit lokaler Verankerung. Der Bedarf einer sich zunehmend digitalisierenden Gesellschaft an solchen „dritten Orten“ (Oldenburg 1989) lässt sich nicht zuletzt an den vorgestellten Besuchszahlen ablesen.

17.3 Ein Blick auf den Betrieb Bibliothek Auch wenn sie nicht zur Kernverwaltung gehören, haben Bibliotheken, allein durch ihre Relevanz für die Bürgerinnen und Bürger, einen berechtigten Platz in einem Buch über die öffentliche Verwaltung. Wenn es nun darum gehen soll, wie Agilität und Bibliothek

2Siehe

das Kap. 23 zu agilen Lernmethoden in diesem Buch. bezeichnet das Lernen, das den wechselseitigen, aktiven Austausch unter Gleichen auf Augenhöhe als sozialen Prozess nutzt, um den Lernerfolg zu steigern und am Bedarf der Beteiligten zu orientieren.

3Peer-to-Peer-Learning

172

C. Vonhof

zusammenpassen, oder anderes gefragt, ob und wie das Konzept Agilität in Bibliotheken bislang angekommen ist und gelebt wird, dann lohnt sich ein Blick auf den Betrieb Bibliothek. Dieser Blick auf eine Bibliothek als Betrieb liegt nahe, weil in den Kapiteln dieses Buches immer wieder deutlich wird, dass agil zu arbeiten zwar in erster Linie eine Haltung, „ein Mindset“ ist, dass aber auch eine Reihe organisatorischer und managerialer Rahmenbedingungen geschaffen werden müssen, damit agil gearbeitet werden kann. Ist also eine Bibliothek ein Betrieb? In der bibliothekswissenschaftlichen Diskussion lässt sich die – durchaus kontrovers geführte – Diskussion über die Bibliothek als Betrieb im betriebswirtschaftlichen Sinn seit den 1970er Jahren nachvollziehen (­Vonhof 2012). Wichtig für unsere Fragestellung ist vor allem die Entwicklungslinie, die sich aus dem Neuen Steuerungsmodell ergibt. Für das Verständnis und die Gestaltung des Betriebs Bibliothek ist kennzeichnend, dass eine Bibliothek nie losgelöst von ihrem Träger, sondern immer als Teil- und Subsystem ihrer Trägerorganisation zu sehen ist. So ist es nicht verwunderlich, dass die intensiven Anstrengungen um eine Modernisierung der Verwaltung nach dem Konzept des New Public Management auch Bibliotheken ergriffen haben. Vor dem Hintergrund einer tief greifenden Finanzierungskrise des öffentlichen Sektors waren Verwaltungen nicht nur in Deutschland einem zunehmenden Reformdruck ausgesetzt. Eine Modernisierungs- und Leistungslücke wurde konstatiert, bei der die herkömmliche Lösungsstrategie eines additiven Ressourcenmanagements, das die Antwort auf neue Anforderungen und neue Dienstleistungen in einer Ausweitung der dafür eingesetzten Ressourcen suchte (vgl. Budäus 1995, S. 11), nicht mehr griff. Im Umgang mit dem Neuen Steuerungsmodell zeigten und zeigen die verschiedenen staatlichen Ebenen der Verwaltung völlig unterschiedliche Herangehensweisen und Entwicklungsstände. In den Kommunen wurden die Gedanken des Neuen Steuerungsmodells am intensivsten verfolgt und die deutlichsten Änderungen vorgenommen. Trotz der insgesamt verhaltenen Bilanz, die sich 20 Jahre nach Beginn des Nachdenkens über neue Steuerungskonzepte ziehen lässt, hat sich die öffentliche Verwaltung bewegt: Der Umgang mit Bürgern als Kunden ist eine nicht mehr wegzudiskutierende Tatsache, Personal wird als wichtige und zu pflegende Ressource wahrgenommen, und der Umgang mit betriebswirtschaftlichen Instrumenten hat den Weg aus der Experimentierphase in den Alltagsbetrieb hinter sich gebracht. Bibliotheken im kommunalen Bereich haben in dieser gesamten Entwicklung eine wichtige Rolle gespielt: Nicht selten waren sie Piloteinrichtungen, die als erste in einer Kommune die Instrumente des Neuen Steuerungsmodells ausprobierten. Aus Sicht der Kommunalspitze sprachen verschiedene Argumente dafür, gerade die Bibliothek auszuwählen: Bei einigen Aspekten der Verwaltungsmodernisierung gehörten Bibliotheken innerhalb der Verwaltungen zu den Vorreitern. Sie setzten bereits selbstverständlich Anforderungen um, die für große Teile der restlichen Verwaltung völlig neu und fremd waren: Dazu zählte das Verständnis als kundenorientierter Dienstleistungseinrichtung mit Öffnungszeiten am Abend und am Samstag – dies schon zu Zeiten, als die meisten Verwaltungsdienststellen freitags spätestens um zwölf Uhr die Pforten schlossen. Dazu

17  Bibliotheken und Agilität – Welten begegnen sich?

173

zählte aber auch die nun geforderte Markt- und Wettbewerbsorientierung: Bibliotheken nutzen seit vielen Jahren Instrumente wie die Deutsche Bibliotheksstatistik (DBS) und betreiben damit Betriebsvergleiche und Benchmarking. Bibliotheken agieren zudem auf einem definierten Markt (für Öffentliche Bibliotheken sind dies prinzipiell die Bürger ihres Einzugsgebietes) mit – im Verständnis des Neuen Steuerungsmodells – einigermaßen klar abgrenzbaren Produkten wie „Bereitstellung von Medien“, „Bereitstellung von Informationsdienstleistungen“ oder „Veranstaltungen für Zielgruppen“. Bibliotheken zählen und zählten andererseits zu den Freiwilligkeitsleistungen einer Kommune und sind zugleich aus Sicht der Verwaltung teure Einrichtungen, die ihre Existenz immer wieder mehr oder weniger explizit rechtfertigen müssen. Ein weiteres Argument kam oft dazu: Reformprojekte sind risikobehaftet. Ein Misslingen in einer Einrichtung der Kernverwaltung hätte für die gesamte Verwaltung weitreichende Folgen gehabt. Eine klar abgegrenzte Einrichtung wie eine Bibliothek hingegen bot ein geeignetes und ungefährliches Experimentierfeld. Sollte das Experiment misslingen, wären die Auswirkungen überschaubar. So war es also zum einen durchaus ein Zeichen der Anerkennung, die Bibliothek als Piloteinrichtung auszuwählen, zum anderen war die Auswahl aber auch ein Beleg dafür, dass weder dem Neuen Steuerungsmodell als Philosophie noch der Bibliothek als Institution in ausreichender Weise Wertschätzung entgegengebracht wurde. Als Piloteinrichtungen haben Bibliotheken an allen Aspekten des Neuen Steuerungsmodells gearbeitet und damit ihre Organisationen verändert und teilweise erhebliche Kompetenzzuwächse im Umgang mit betriebswirtschaftlichen Instrumenten erzielt.

17.4 Einsatz von Managementinstrumenten in Bibliotheken Die Entdeckung von Managementinstrumenten für die Entwicklung und Steuerung der eigenen Organisation war für den Bibliothekssektor als Folge seiner Einbindung in die Entwicklung des Neuen Steuerungsmodells ein wesentlicher Fortschritt. Zwar wurde in vielen Fällen die Frage, welches Managementinstrument in welcher Ausprägung eingesetzt werden soll (Produktplan, Budgetierung, Kosten- und Leistungsrechnung, Zielvereinbarung, Controlling, ….) vom Träger beantwortet und nicht von der Bibliothek selbst. Dennoch konnte in einer repräsentativen Studie ermittelt werden, dass eine breite Mehrheit der befragten Leitungspersonen in Bibliotheken den Einsatz von Managementinstrumenten für sinnvoll hielten (Mundt und Vonhof 2007). Instrumente, die für die Steuerung und Entwicklung von Bibliotheken eine besondere Rolle spielten und spielen, sind • Strategisches Management • Qualitätsmanagement • Prozessmanagement • Instrumente der finanzwirtschaftlichen Steuerung • Partnerschaftsmanagement • Innovationsmanagement

174

C. Vonhof

17.5 Agilität in Bibliotheken – die konsequente Weiterentwicklung Die im Rahmen des Neuen Steuerungsmodells etablierten Managementinstrumente sind – zumindest vordergründig – stark auf die Entwicklung der Institution Bibliothek ausgerichtet. Sie sind geprägt vom Glauben an deren Planbarkeit und Steuerbarkeit aus Managementperspektive. Mithilfe dieser Instrumente findet eine aktive und willentliche Führung des Betriebs statt. Man ist weggekommen vom „Durchwurschteln“. Bibliotheken sind kundenorientierter, flexibler, innovativer und sich selbst als „zu managender Betrieb“ bewusster geworden. Die Kompetenz zum Umgang mit betriebswirtschaftlichen Steuerungsinstrumenten ist stark gestiegen: durch praktisches Handeln und Erfahrungen, aber auch dadurch, dass Management ein Thema in allen bibliotheksbezogenen Ausbildungs- und Studiengängen sowie im professionellen Diskurs geworden ist. Schlägt man nun jedoch den Bogen zurück zu den zu Beginn skizzierten Herausforderungen, denen sich eine Bibliothek in einer VUKA-Welt gegenübersieht, dann wird deutlich, dass die Ansätze der 1990er Jahre nicht mehr genügen. Neue Ansätze sind gefragt. Bei der Suche nach neuen Ansätzen lohnt es sich – wie in anderen Bereichen der Verwaltung auch –, den Blick nicht auf die deutsche Community zu begrenzen, sondern sich international umzusehen. Die publizierten Beispiele zeigen, dass das Thema Agilität in Bibliotheken Fahrt aufnimmt und eine Fülle von Beispielen und „Good Practices“ für diese neuen Ansätze zu finden sind. Um diese guten Praktiken zu systematisieren und zu ermitteln, in welchen Bereichen die Praxis Schwerpunkte setzt, leisten die agilen Prinzipien gute Dienste. Für unseren Zweck müssen jedoch Fokus und Wording der Prinzipien erweitert und angepasst werden. Die Formulierung des Forum Agile Verwaltung (2016) eignen sich dafür: • • • • • •

Nimm das Ganze in den Blick, bilde cross-funktionale Teams, experimentiere mit überschaubaren Änderungen und Teilergebnissen, beziehe die Anspruchsberechtigten ein, verschaffe dir regelmäßiges Feedback von innen und außen, mache so dein System immer angemessener.

17.5.1 Nimm das Ganze in den Blick Agilität bedeutet die Fähigkeit, schnell zu handeln. Sie bedeutet aber nicht Beliebigkeit, Planlosigkeit oder operatives Wurschteln. Vielmehr empfiehlt die agile Herangehensweise, einen längeren Zeitraum in den Blick zu nehmen und für Schlüsselrisiken Vorsorge zu treffen. Hat man klare Vorstellungen von den großen Entwicklungslinien, kann man „auf Sicht steuern“ und dennoch die Richtung beibehalten.

17  Bibliotheken und Agilität – Welten begegnen sich?

175

Damon Jaggar, der neue Direktor der Ohio State University, beschreibt diesen Ansatz als Basis für eine neue beteiligungsorientierte Form der strategischen Planung, die kein Anfang und kein Ende hat, sondern als 12 bis 18-monatiger rollierender Prozess angelegt ist. Ziel ist es, den ressourcenfressenden und starren Strategieprozess klassischer Prägung abzulösen durch die Festlegung weniger strategischer Themen, die durch laufendes Scanning der internen und externen Entwicklungen angepasst und weiterentwickelt werden. Interessant ist auch der Versuch, strategische Kennzahlen zu ersetzen durch „impact narratives“. D. h., soll eine neue Aktivität oder ein Projekt umgesetzt werden, dann sind nicht nur alle (auch die versteckten) Kosten, die Folgewirkungen und Querbezüge darzustellen, sondern es ist eine Wirkungs-Geschichte zu erzählen, die zeigt, inwiefern sich diese Initiative positiv auf die Fähigkeit der Bibliothek auswirkt, ihre strategischen Ziele zu erreichen (Jaggars 2017).

17.5.2 Bilde cross-funktionale Teams Wie in den Verwaltungen, so ist auch in Bibliotheken das Denken in Zuständigkeiten ein zentrales Kulturmuster. Für jede Aufgabe gibt es eine zuständige Abteilung, ein Team oder eine Person. Die Vor- und Nachteile dieser Organisationsformen sind bekannt und ausführlich beschrieben: Zuständigkeitsregeln weisen Verantwortung eindeutig zu, ermöglichen fachliche Spezialisierung und damit ein hohes Maß an operativer Exzellenz und Routine. Das Denken in Silos, das Nicht-Wahrnehmen oder Ignorieren von Kreuzund-Querbezügen ist jedoch der Preis, den eine Organisation dafür zahlt. Nun sind Silo-Denken und Abgrenzung zweifelsohne eine Funktion der Größe einer Organisation. Je größer, desto höher das Maß an Spezialisierung, desto abgeschotteter die Silos. Große Bibliotheken experimentieren daher zunehmend mit unterschiedlichen organisatorischen Ansätzen, um die Silos aufzubrechen. So werden Teams gebildet, die Komplettarbeit für eine bestimmte Zielgruppe leisten (in Stadtbibliotheken können dies zum Beispiel Kinder sein, in Universitätsbibliotheken Forschende). Das jeweilig verantwortliche cross-funktionale Team besteht dann aus Fachleuten für das Medienangebot, die Vermittlungs- und Kontaktarbeit, für Marketing und Social Media, für IT etc. Ihr gemeinsames Ziel: Sie bedienen ihren „Markt“ und ihre Zielgruppe ganzheitlich – von Anfang bis Ende. Andere Bibliotheken versuchen Cross-Funktionalität zu gestalten, indem sie Matrix-Strukturen aufbauen. Hier zeigt sich aber im einen oder anderen Fall auch die Begrenzung, der Bibliotheken als nachgeordnete Verwaltungseinrichtung unterliegen: Wenn die Trägerinstitution eine solche Organisationsform für „Teufelszeug“ hält, nach dem Motto „das haben wir noch nie so gemacht“, dann bleibt der Bibliothek nur, eine informelle Lösung unterhalb der Wahrnehmungsschwelle zu finden. Für Wissenschaftliche Bibliotheken lassen sich darüber hinaus bereits seit einigen Jahren durch die Verschmelzung von Rechenzentren und Bibliotheken Organisationsformen finden, die cross-funktionale Teams aus IT- und Bibliothekskompetenz zur Lösung immer stärker IT-getriebener Services entwickeln.

176

C. Vonhof

17.5.3 Experimentiere mit überschaubaren Änderungen und Teilergebnissen Für Veränderungen in Bibliotheken gilt das Gleiche wie für alle anderen Organisationen: Es ist außerordentlich unwahrscheinlich, dass die anfangs zusammengestellten Anforderungen und Veränderungsziele auch den endgültigen Stand widerspiegeln. Es ist im Gegenteil fast immer so, dass sich die Anforderungen im Laufe eines Veränderungsvorhabens aus den unterschiedlichsten Gründen ändern. Das bedeutet nicht, dass dabei am Ende ein völlig anderes Ergebnis erzielt wird als geplant. Es heißt aber sehr wohl, dass im Projektverlauf neue Ideen entwickelt werden, die entweder alte Ideen ersetzen, ergänzen oder einfach nur verändern. Der Auftraggeber und das Umsetzungsteam lernen gemeinsam. Die bekannteste Methode, um auf diese Herausforderung der Ungewissheit strukturiert zu reagieren, ist „Scrum“.4 Das Framework Scrum kommt aus der Softwareentwicklung, und so ist es nicht weiter verwunderlich, dass auch in der Bibliotheksbranche die IT-nahen Bereiche diese Ideen sehr schnell aufgenommen haben. Als Anwendungsbeispiel einer Bibliothek sei das Kompetenzzentrum für nicht-textuelle Materialien (KNM) an der Technischen Informationsbibliothek Hannover (TIB) genannt. Das cross-funktionale Team arbeitet in Sprints in zuvor vom Team priorisierte Anforderungen ab. Die Dokumentation erfolgt in einem Wiki (Strobel 2015). Ein weiteres Beispiel für den Einsatz von Scrum liefert die schwedische Universitätsbibliothek Chalmers, die Scrum als Projektframework einsetzt, sich aber darüber hinaus als agile Organisation versteht. „Being an agile library organization means we are constantly improving. How? By listening, observing and doing“ (Chalmers Library 2015). Auch die Fallstudie der Universitätsbibliothek San Diego zeigt, wie mit einem agilen Ansatz die Entwicklung einer mobilen Website erfolgreich umgesetzt werden konnte (Critchlow et al. 2010).

17.5.4 Beziehe die Anspruchsberechtigten ein Dieses Prinzip hat für Bibliotheken eine außerordentlich hohe Bedeutung. Hierbei kommt ihr zugute, dass sie keine hoheitlichen Aufgaben erledigt, sondern sich als Dienstleistungsorganisation versteht. Kundenorientierung ist im Selbstverständnis fest verankert. Aus der agilen Perspektive muss aber konstatiert werden, dass in vielen Fällen Kundenorientierung doch eher aus einer spekulativen Innenperspektive erfolgt: Bibliotheken spekulieren darüber, was Kunden wollen und welche Services sie bevorzugen. Sie machen – gestützt auf fachliche Expertise, Erfahrung und durchaus auf Nutzungsdaten – engagiert Angebote und hoffen, damit die Nachfrage ihrer Kunden zu treffen. Keine Frage, dies gelingt oft. Angesichts der dramatischen Änderungen, denen sich Bibliotheken

4Siehe

auch das Kap. 6 „Scrum“ in diesem Buch.

17  Bibliotheken und Agilität – Welten begegnen sich?

177

gegenübersehen und der immer weiter abnehmenden Vorhersehbarkeit von Entwick­ lungen, stellt sich jedoch die Frage, ob diese tradierten Herangehensweisen noch zukunftsfähig sind. Das Nachdenken über Alternativen fällt zusammen mit einer zweiten Diskussion, die derzeit geführt wird, nämlich der, ob Kundenorientierung nicht zu kurz greift und es vielmehr um Bürgerorientierung gehen müsste. Die Diskussion um Kunden- versus Bürgerorientierung ist alt. Schon Ende der 1990er Jahre unterscheidet Bogumil (1999) drei idealtypische Rollen des Bürgers in der Kommune: • der Bürger als politischer Auftraggeber, • der Bürger als Adressat der Leistungserstellung (Kunde, Klient, Untertan) sowie • der Bürger als Mitgestalter des Gemeinwesens, als Koproduzent bei der Leistungserstellung (S. 52). Überträgt man diese Sichtweise auf die heutige Diskussion zur Bürgerbeteiligung, so wird deutlich, dass Bürgerbeteiligung nicht einfach ein neuer Begriff für Kundenorientierung ist, sondern eine wesentliche Rollenerweiterung impliziert. Der Bürger in diesem Verständnis hat nicht mehr die passive Rolle eines Kunden, der „staatliche Leistungen kundenfreundlich verpackt empfängt“ (Mauch 2014, S. 22). Vielmehr übernimmt er idealtypisch eine aktiv gestaltende bzw. mitgestaltende Rolle. Diese bezieht sich konsequenterweise sowohl auf die Problemdefinitionen wie die Entwicklung von Lösungswegen. Der Begriff „participatory library“ wurde von Lankes et al. (2006) geprägt. Die Autoren beschreiben damit, wie Web 2.0-Tools Wege eröffnen, um Bibliothekskunden auch am Kerngeschäft einer Bibliothek zu beteiligen, z. B. indem sie Katalogdaten anreichern oder durch eigene Inhalte zu Repositorien („Community Repositories“) beitragen. Die damit ausgelöste Diskussion fokussierte sich zu Beginn v. a. auf technologische Aspekte, die mit dem aus Web 2.0 abgeleiteten Begriff Library 2.05 umrissen wurden. Casey und Savastinuk setzen jedoch schon früh einen weiteren Rahmen und definieren „Library 2.0“ als a model for library service that encourages constant and purposeful change, inviting user participation in the creation of both the physical and the virtual services they want, supported by consistently evaluating services. It also attempts to reach new users and better serve current ones through improved customer-driven offerings (2006, p. 40).

Wenn Partizipation und Einbeziehung praktisch umgesetzt werden, kann dies in unterschiedlicher Intensität erfolgen. Intensitätsstufen, die sich dafür anbieten, sind „informieren“, „konsultieren“, „kooperieren“ und „ermächtigen“6. Zu jeder Intensitätsstufe lassen

5Die

Bezeichnung „Library 2.0“ wurde im Jahr 2005 von Michael Casey in seinem Blog LibraryCrunch geprägt. 6Diese Systematisierung verwendet ein Stufenmodell der Beteiligungsintensität, das in einem studentischen Projektseminar im Wintersemester 2015 an der Hochschule der Medien in Anlehnung an das Public Participation Spectrum der IAP2 (IAP2 2014) entwickelt wurde.

178

C. Vonhof

sich Ziele der Beteiligung aus Sicht der Bibliothek formulieren (z. B. Stufe „konsultieren“: Einholen von Meinungen, Ideen, Feedback zu (Entscheidungs-)Alternativen). Zu jeder Intensitätsstufe wird darüber hinaus die Rolle bzw. der Nutzen für die Bürger skizziert (z. B. Stufe „konsultieren“: Rolle: Berater; Nutzen: Anerkennung der Anliegen und Erwartungen, Information, wie der Input des Bürgers die Entscheidungen beeinflusst). Ob „Informieren“ bereits eine Form der Beteiligung ist, ist umstritten. Unstrittig ist jedoch, dass Informieren eine Voraussetzung für Beteiligung ist. Dennoch ist nur zu „informieren“ für den Gedanken, den das agile Prinzip mit „Beziehe die Anspruchsberechtigten mit ein“ meint, nicht hinreichend. Konsultative Verfahren haben das Ziel, möglichst vielfältige Anregungen und Vorschläge einzuholen. Dabei sollen sowohl die Problemstellungen geklärt als auch neue Lösungswege, Alternativen und Folgewirkungen identifiziert werden. Die beratende Funktion steht hier im Mittelpunkt. Verbunden damit ist, transparent zu machen, ob und wie Empfehlungen, die von den Bürgern ausgesprochen werden, von den Entscheidungsträgern in ihren Entscheidungsprozess einbezogen werden. Eine Konsultationsfunktion findet sich in vielen Verfahren zur Beteiligung: Zukunftskonferenzen, Beiräte, Befragungen, Fokusgruppen oder Veranstaltungen mit beratendem Charakter. Als Beispiel sei hier die Universitätsbibliothek Rostock genannt, die mit Studierenden einen Design Workshop zur Gestaltung von Lernräumen durchgeführt hat. Ziel war es, mit einfachen handwerklichen Mitteln (z. B. Möbelschablonen aus Pappe und Papier) und in kurzer Zeit von den Benutzern bildlich zu erfahren, welche Raumanforderungen für sie wichtig sind (Ilg 2016). Ebenfalls der Beteiligungsstufe „Konsultieren“ ist die Arbeit mit LEGO Serious Play® zuzuordnen, die zum Beispiel in der Stadtbücherei Tübingen eingesetzt wurde. Noch stärker als beim Design Workshop geht es bei dieser Methode darum, auch unbewusste Ideen und Erwartungen thematisieren zu können. Dies gelingt durch die Einbindung des Spielens in einen zielorientierten Prozess (Seidl und Vonhof 2016)7. Einen sehr umfassenden Konsultationsprozess hat die Cleveland Public Library8 durchlaufen. Gestützt auf einen „Community Engagement Plan“ arbeitet die Bibliothek seit 2014 daran, ihre Benutzer und die Bevölkerung in ihrem Einzugsbereich einzubeziehen und bei der Beantwortung der Frage, wie die Bibliotheken auf Veränderungen in ihrem Umfeld reagieren sollte, zu beteiligen. Mit einem breiten Set an Methoden wird daran gearbeitet, bis 2019, dem 150-jährigen Jubiläum der Bibliothek, das Dienstleistungsportfolio zu überarbeiten. Kooperieren als Beteiligungsstufe strebt eine umfassende Partnerschaft an, bei der Ratschläge und Empfehlungen der Beteiligten so weit als möglich berücksichtigt werden. Ein erfolgreicher Einsatz setzt eine tief greifende Kulturveränderung und ein neues Selbstverständnis der Verantwortlichen und der Mitarbeitenden voraus. Methoden, die

7Siehe

auch das Kap. 15 von Tobias Seidl in diesem Buch. Cleveland Public Library verfügt über eine Zentralbibliothek und 26 Zweigstellen (http://cpl. org/).

8Die

17  Bibliotheken und Agilität – Welten begegnen sich?

179

eine Kooperation mit Bürgern im Verständnis dieser Beteiligungsstufe unterstützen, erfordern eine systematische und konsequente Vorgehensweise: Bürger müssen in den gesamten Prozess der Identifikation und Beschreibung einer Problemlage, in die Entwicklung von Lösungen und letztlich auch in die Implementierung und Evaluation einer Lösung eingebunden werden. Für den Bereich von Bibliotheken sind bisher nur wenige Beispiele für den Einsatz von Design Thinking9 als einer dieser agilen Methoden zu finden. Prominentestes Beispiel für die Arbeit mit Design Thinking ist Dokk1, die neue Zentralbibliothek in Aarhus. Hier wurden im gesamten Planungsprozess für die neue Bibliothek die Nutzer konsequent einbezogen. Der Ansatz von Design Thinking weist sechs Phasen auf, die ein möglichst interdisziplinär besetztes internes Projektteam durchläuft. Die Phasen 1 bis 3 dienen der Formulierung der Herausforderung und Problemlagen und v. a. dem genauen Verständnis der Bedürfnisse der Zielgruppe. Dazu werden verschiedene Methoden der Beobachtung und Befragung der Zielgruppen sowie Kreativmethoden angewandt. In den Phasen 4 bis 6 wird eine Lösung für die Herausforderungen und Problemlagen erarbeitet. Das Besondere und Ungewohnte ist die Arbeit in kurzen Zyklen (Iterationen), in denen Lösungsideen in Prototypen sichtbar und verstehbar gemacht werden. Diese werden der Zielgruppe zum Feedback vorgelegt, verworfen, neu entwickelt oder verbessert. Diese Iterationen in engem Kontakt mit Vertretern der Zielgruppen sollen dazu führen, dass Produkte und Dienstleistungen entwickelt werden, die tatsächlich die Probleme der Zielgruppe lösen. Bürger sind in einem solchen Prozess als Ideengeber, Entscheider und Experten in eigener Sache intensiv eingebunden. Ohne ihren Beitrag ist eine passgenaue Lösung nicht zu erreichen. Dem Beispiel von Aarhus folgen derzeit weitere Bibliotheken wie die Stadtbibliothek Würzburg, die diese Methode zur Planung einer neuen Stadtteilbibliothek einsetzen wird (Bergmann und F ­ licker 2016). In der weitestgehenden Beteiligungsstufe, der Stufe „Ermächtigen“, liegt die endgültige Entscheidung bei den Bürgern. Von ihnen getroffene Entscheidungen werden durch die Bibliothek umgesetzt. Selbstverständlich setzen hier zuvor klar kommunizierte rechtliche oder finanzielle Rahmenbedingungen eine Grenze. Beispiele im Bibliotheksbereich sind nur spärlich zu finden. Anführen ließe sich hier das Modell der Patron-Driven-Acquisition10 oder die Gestaltung von Angeboten und Dienstleistungen in Makerspaces oder Repair-Cafés, die in weitgehend eigener Verantwortung von Bürgern liegen (Giersberg 2014).

9Design

Thinking ist ein Ansatz, der durch einen strukturierteren Prozess zur Entwicklung neuer und vor allem nutzerzentrierter Lösungen führt. Eine Lösung aus Nutzersicht zu entwickeln und dabei die Nutzer im gesamten Entwicklungsprozess aktiv einzubeziehen, ist der Kern des Ansatzes. Aus der Erfahrung der Aarhus Public Library mit Beteiligungsmethoden entstand im Austausch mit der Chicago Public Library und unterstützt durch die Bill und Melinda Gates Foundation das Toolkit „Design Thinking for Libraries“ (IDEO 2014). 10„Kundengesteuerte Erwerbung“, ist ein Erwerbungsmodell für Medien im Bibliothekssektor, bei dem die Kaufentscheidung vom Kunden ausgeht. Bei diesem Erwerbungsmodell wird den Kunden eine Vielzahl von Veröffentlichungen angeboten, die jedoch erst bei tatsächlicher Nutzung durch den Kunden von der Bibliothek gekauft werden (Wikipedia).

180

C. Vonhof

17.5.5 Verschaffe dir regelmäßiges Feedback von innen und außen Agile Teams planen ihre Arbeit adaptiv. Die Teilergebnisse der einzelnen Intervalle sind auf Nutzbarkeit ausgerichtet, auch wenn das „Gesamtprodukt“ noch nicht fertig ist. Diese Teilergebnisse kann man ausprobieren und sich Feedback der Betroffenen holen. Dazu wird die Methode des Prototypings in Bibliotheken eingesetzt. Besonders anschaulich und greifbar lässt sich dies natürlich anhand von räumlichen und haptischen Elementen umsetzen. Die Bibliothek der ETH Zürich hat in ihrem Projekt „Team Working Spaces“ Lernräume für Studierende gemeinsam mit Studierenden entwickelt. Konkret heißt das, dass Studierende Prototypen nach ihren Bedürfnissen gebaut haben. Dabei wurden zwei Formen des Prototyping eingesetzt: Live Prototyping und Rapid Prototyping (Gernacher und Lienhard 2017). Die Stadtbücherei Würzburg, die eine neue Filiale mit Design Thinking entwickelt, bietet ein „Ideenlabor“ an, in dem die Bürgerinnen und Bürger Feedback zu Prototypen einer ganzen Bibliotheksfiliale geben können. Im Transformation Lab der Bibliothek im dänischen Aarhus findet diese Form des Feedback-Einholens schon seit vielen Jahren statt. Feedback muss aber auch von innen kommen. Dazu bietet der agile Methodenkoffer die sogenannten „Standup-Meetings“. Regelmäßig kommt das Team zusammen, um sich kurz über den aktuellen Stand auszutauschen und Hindernisse zu identifizieren, die die weitere Arbeit behindern. Der intensivere Blick auf die Arbeit und vor allem auf die Zusammenarbeit im Team erfolgt in der „Retrospektive“. Das Team einer Stadtbibliothek nutzt die Methode der Retrospektive, um die Arbeit in neuen, cross-funktionalen Teams, die durch eine Reorganisation entstanden sind, zu begleiten (siehe Abb. 17.2). Die Strukturierung durch die Methode „Starfish“ hat sich dabei bewährt. Standup-Meetings und Retrospektiven gehören zu den Methoden, die den Rhythmus der agilen Arbeit bestimmen. Diese rhythmische Abfolge von Planen – Prüfen – Anpassen ermöglicht und fördert einen adaptiven Handlungsmodus. Das ist das Herzstück agiler Arbeit.

17.5.6 Mache so dein System immer angemessener Bibliotheken sind auf dem Weg. Sie experimentieren mit agilen Methoden und vor allem – und das ist die viel größere Herausforderung – mit dem agilen Mindset. Dort wo sich Bibliotheken auf diesen Prozess eingelassen haben, scheinen die Chancen bei weitem die Risiken zu überwiegen11. Die Organisation lernt: Sie lernt, mutig und proaktiv Veränderungen zu begrüßen, sie lernt, dass immer wieder Nachsteuerung und Neupriorisierung nötig ist, egal wie gut der Job ist, den man in der Vergangenheit gemacht hat, sie lernt Wissenssilos zu vermeiden, starke Teams zu bilden, die sich gegenseitig

11Wirkungsanalysen

liegen derzeit noch nicht vor.

17  Bibliotheken und Agilität – Welten begegnen sich?

181

Abb. 17.2   Team bei einer Retrospektive

helfen, mit Unsicherheit umzugehen. Die Welt und ihre Kunden werden Bibliotheken nicht ändern. Sie können aber ihre Haltung zur Welt und zu ihren Kunden ändern: Libraries can continue to bang their heads to a wall as we try to enlighten our users about the benefits of our services or we can learn more about group behavior and design services that fit that behavior. By adapting services to user behavior we might get users to see the value and use our services (Forman und Hansson 2014).

Diese Veränderung wird aber nur dann Erfolg haben, wenn sie nicht als institutionelle Aufgabe und Herausforderung gesehen wird, sondern als individuelle jeder einzelnen Person. Genau diese Position spiegelt das Librarian’s 2.0 Manifesto, das Laura B. Cohen, Web Support Librarian der University at Albany, 2006 verfasst hat. Deshalb sei es hier abschließend in Auszügen zitiert. A Librarian’s 2.0 Manifesto I will recognize that the universe of information culture is changing fast and that libraries need to respond positively to these changes to provide resources and services that users need and want. I will recognize that libraries change slowly, and will work with my colleagues to expedite our responsiveness to change. I will let go of previous practices if there is a better way to do things now, even if these practices once seemed so great.

182

C. Vonhof

I will take an experimental approach to change and be willing to make mistakes. I will not wait until something is perfect before I release it, and I’ll modify it based on user feedback. I will be willing to go where users are, both online and in physical spaces, to practice my profession. I will create open Web sites that allow users to join with librarians to contribute content in order to enhance their learning experience and provide assistance to their peers. I will validate, through my actions, librarians’ vital and relevant professional role in any type of information culture that evolves (Cohen 2007, S. 48).

Literatur Bergmann J, Flicker A (2016) Ein Ort für Kreativität, Mitgestaltung, Inspiration. BuB Forum Bibl Inf 68(9):487–481 Bogumil J (1999) Auf dem Weg zur Bürgerkommune? Der Bürger als Auftraggeber, Mitgestalter und Kunde. In: Kubicek, H (Hrsg) Multimedia @ Verwaltung. Jahrbuch Telekommunikation und Gesellschaft. Hüthig, Heidelberg, S 51–61 Budäus D (1995) Public Management. Konzepte und Verfahren zur Modernisierung öffentlicher Verwaltungen. Edition Sigma, Berlin Casey ME, Savastinuk LC (2006) Library 2.0: service for the next generation library. Libr J 131(14):40–44 Chalmers Library (2015) The way we work. http://stories.lib.chalmers.se/project/waywework/. Zugegriffen: 1. Jan. 2018 Cohen LB (2007) A manifesto for our times. Affirmations to help develop a mindset to respond to the changing information culture. Am Libr 38(7):47–49 Critchlow M, Friedman L, Suchy D (2010) Using an agile-based approach to develop a library mobile website. Code4lib Journal. 12. http://journal.code4lib.org/articles/4642. Zugegriffen: 1. Jan. 2018 Forsman D, Hansson P (2014) Introducing Agile principles and management to a library organization. Proceedings of the IATUL Conferences. Paper 1. http://docs.lib.purdue.edu/iatul/2014/ plenaries/1. Zugegriffen: 1. Jan. 2018 Gernacher R, Lienhard C (2017) Desing Thinking zur Entwicklung von Lernumgebungen: Das Projekt Team Working Spaces an der ETH-Bibliothek. Bibliotheksdienst 51(9):771–785 Giersberg D (2014) Kreativwerkstätten des 21.  Jahrhunderts. https://www.goethe.de/de/kul/ bib/20440837.html. Zugegriffen: 1. Jan. 2018 IAP2 (2014) AP2’s Public participation spectrum. http://c.ymcdn.com/sites/www.iap2.org/ resource/resmgr/Foundations_Course/IAP2_P2_Spectrum.pdf. Zugegriffen: 1. Jan. 2018 IDEO (2014) Design thinking for libraries. A Toolkit for Patron-Centered Design. http://designthinkingforlibraries.com/. Zugegriffen: 1. Jan. 2018 Ilg J (2016) Mehr Spielräume. Methoden der partizipativen Lernraumgestaltung. Bibl Forsch Praxi 40(3):347–360 Jaggars DE (2017) An agile planning and operations framework. Conference Paper. 12th International Conference of Performance Measurement in Libraries. http://programme.exordo.com/ northumbria12/delegates/presentation/28/. Zugegriffen: 1. Jan. 2018 Lankes RD, Silverstein J, Scott N (2006) Participatory networks: the library as conversation. American Library Association, Chicago

17  Bibliotheken und Agilität – Welten begegnen sich?

183

Mauch S (2014) Bürgerbeteiligung. Führen und Steuern von Beteiligungsprozessen. Boorberg, Stuttgart Moffitt J (2013) Library competes thanks to agile development outsourcing. https://www.cio.com/ article/2387131/outsourcing/library-competes-thanks-to-agile-development-outsourcing.html. Zugegriffen: 1. Jan. 2018 Mundt S, Vonhof C (2007) Managementinstrumente in deutschen Bibliotheken. Eine bundesweite Untersuchung zu Einsatz und Verbreitung. Bibl Forsch Praxi 31(3):318–325 Oldenburg R (1989) The great good place: cafes, coffee shops, community centers, beauty parlors, general stores, bars, hangouts, and how they get you through the day. Marlowe, New York Seidl T, Vonhof C (2016) Neue Formen der Bürgerbeteiligung in Bibliotheken. BuB Forum Bibl Inf 68(8–9):482–487 Strobel S (2015) Einsatz von Sprints in der Produktentwicklung der Technischen Informationsbibliothek. Gute Ergänzung für Teamsitzungen beim Projektmanagement – aber kein Ersatz. BuB Forum Bibli Inf 67(11):713–715 Vonhof C (2012) Die Bibliothek als Betrieb. In: Umlauf K, Gradmann S (Hrsg) Handbuch Bibliothek: Geschichte, Aufgaben, Perspektiven. Metzler, Stuttgart, S 266–285

Prof. Cornelia Vonhof  ist Professorin für Public Management an der Hochschule der Medien Stuttgart. Sie ist Bibliothekarin und Betriebswirtin und war als Bibliotheksleiterin und Organisationsberaterin in internationalen Unternehmensberatungen für den öffentlichen Sektor tätig. Sie lehrt im Studiengang Informationswissenschaften und nimmt daher vor allem die Entwicklungen und Veränderungsprozesse von Bibliotheken und Informationseinrichtungen als Organisationen des öffentlichen Sektors und als meistgenutzte, stark kundenorientierte Bildungs- und Kultureinrichtungen in den Blick.

eGovernment: Die digita(gi)le Zukunftsakte

18

Ein Traum von Teamraum: Das Collaboration Management im 21. Jahrhundert Wolf Steinbrecher

Zusammenfassung

In der aktuellen Diskussion um die Anforderungen an eine E-Akte fehlt eine kritische Auseinandersetzung mit dem Ist-Zustand: Wie haben wir unsere Büroprozesse seit Einführung des PC organisiert – insbesondere die wichtigen, die schwach strukturierten Wissensprozesse? Tun wir das Richtige richtig oder verschwenden wir unsere Zeit und unsere Energie, indem wir viele unnötige Dinge umständlich erledigen? Aus einer Beschäftigung mit diesen Fragen ergeben sich erste Ideen für eine digitale Arbeitsweise im 21. Jahrhundert, die die Potenziale des neuen elektronischen Mediums wirklich a­ usschöpft.

18.1 Der Abschied vom Papier – ein langer Weg Seit rund 25 Jahren – etwa ab Anfang der 1990er Jahre – haben sich digitale Arbeitsweisen in der öffentlichen Verwaltung verbreitet. Wie fällt die Bilanz aus? Meine persönliche Antwort lautet: Bestenfalls ernüchternd. Es ist uns bisher nicht gelungen, die spezifischen Stärken des neuen Mediums zur Entfaltung zu bringen. Vielmehr steht unser Denken nach wie vor mit einem Bein fest verankert in der Papierwelt. Dieses Erbe aus der „analogen“ Vergangenheit besteht vor allem aus drei Punkten: • Denken in individuellen „Zuständigkeiten“ statt in Teams. • Denken in Einzeldokumenten statt in Vorgängen. • Ausrichtung unserer Aktenführung auf Objekte statt auf Prozesse. W. Steinbrecher ()  Common Sense Team GmbH, Forum Agile Verwaltung e. V., Karlsruhe, Baden- Württemberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_18

185

186

W. Steinbrecher

Was haben diese Punkte mit dem Papier zu tun? Ein Papierordner weist mit den in ihm geführten Papierdokumenten ein triviales Merkmal auf: Er kann sich zu einem bestimmten Zeitpunkt nur an einem einzigen Ort befinden. Hat Kollege Meyerbeer den Ordner auf seinem Schreibtisch, kann Kollege Müllerschön ihn nicht auch gleichzeitig haben. Er muss warten. Oder er muss sich Kopien machen. Oder Kollege Meyerbeer macht ihm freundlicher Weise die Kopien und schickt sie ihm per Hauspost. Das ist zwar trivial und selbstverständlich, hat aber eine für die heutige Zeit ganz und gar nicht triviale Folge: Teamarbeit (Collaboration) im Sinne von gemeinsamer Arbeit am gleichen Vorgang zur gleichen Zeit ist fast nicht möglich. Daraus hat sich über mehrere Jahrhunderte eine spezifische Arbeitsweise entwickelt, die zuerst in der preußischen Registraturordnung Anfang des 19. Jahrhunderts formalisiert wurde. Thea Miller hat das in ihrer Dissertation „The German Registratur“ in hinreißender Weise dargestellt.1 Das Charakteristikum dieser Art des Arbeitens ist die individuelle Zuständigkeit eines Sachbearbeiters (und seines Vorgesetzten) für einen Vorgang. In einem der ersten Kapitel dieses Buches2 haben wir zwei Varianten dieser papiergebundenen Arbeitsweise geschildert: 1. Bei einfachen Vorgängen gilt die individuelle Zuständigkeit. 2. Komplexere Vorgänge werden – oft gewaltsam – in Teilvorgänge zerschnitten, die wiederum in die Hände einzelner Sachbearbeiter gelegt werden. In jenem Artikel haben wir auch einen alternativen Ansatz einer neuen Arbeitsweise formuliert, nämlich die Bildung cross-funktionaler Teams. Dort waren wir vor allem auf die Unterschiede zwischen traditioneller und agiler „Organisationsphilosophie“ eingegangen. Im vorliegenden Kapitel geht es uns hingegen um den Blick auf die Technik, also um die konkreten Anforderungen an einen „digitalen Teamraum“. Die bisherige Digitalisierung, die vor etwa 25 Jahren mit der Einführung von PCs an den Büroarbeitsplätzen der Verwaltung begann, hat sich darauf beschränkt, im Wesentlichen die traditionellen Papierabläufe der vergangenen Jahrhunderte in das neue Medium zu kopieren. Die neuen PCs3 wurden zuerst nur als komfortablere Schreibmaschine genutzt. Denn es gab noch keine Massenspeicher: Die Dokumente wurden ausgedruckt und auf dem PC wieder gelöscht.

1Vgl.

Miller (1997), insbesondere das Schaubild auf Seite 12. Kap. 3: „Wozu könnte unsere Gesellschaft eine ‚agile Verwaltung‘ brauchen?“ 3Die Zwischenstufe der „Abteilungsrechner“ soll hier übersprungen werden. 2Siehe

18  eGovernment: Die digita(gi)le Zukunftsakte

187

Nach und nach fand ein Ersetzungsprozess statt: a) Das Papierdokument wurde zum elektronischen Dokument. b) Aus Papierordnern wurden elektronische Ordner. (Der Aktenplan fiel dabei weg. Eine formale Ordnerstruktur existiert auf den Servern in mehr als 90 % der Fälle nicht mehr.) c) Die Umläufe wurden zum E-Mail-Versand von Dokumenten. Die Gefahr besteht nun, dass mit der geplanten „Digitalisierung“ der Verwaltung diese Tendenz einfach fortgesetzt und quasi systematisiert wird: ad a.) Alles wird gescannt. Das elektronische Dokument verdrängt das Papier vollständig. ad b.) Der alte gegenstandsorientierte Aktenplan kommt wieder zu Ehren. ad c.) Aus den Umläufen werden „Workflows“ – also standardisierte und korsettierte Umläufe. Gegen den Punkt a.) ist nichts einzuwenden. Die beiden anderen Punkte aber lassen befürchten, dass dem großen Aufwand der E-Akten-Einführung nur ein vergleichsweise geringer Nutzen gegenüberstehen wird.

18.2 Empirische Wüste: Wir wissen nicht, wo wir stehen Die bisherige, spontane und weitgehend unreflektierte „Digitalisierung 1.0“ seit 1990 zeichnete sich durch einen Fortfall vieler Hemmnisse aus, die bei der Papierordnung als lästig empfunden worden waren: • Das Kopieren von Papierdokumenten konnte sehr aufwendig sein, wenn diese viele Seiten umfassten. Bei einer elektronischen Datei spielt die Größe kaum eine Rolle beim Kopieren. – Also wird massenhaft kopiert. Dubletten in großer Zahl mit dem bekannten Versionsproblem sind die Folge. • Leitz- oder Hängeordner waren in ihrer Kapazität beschränkt. In einen 61 mm-­ Leitzordner passten ca. 500 Blatt. War der Ordner voll, musste ein neuer begonnen werden. War das Regal voll, bestand Handlungsbedarf. – Windows-Ordner werden nie voll, sie wachsen ohne Ende. • Das gilt auch für die Schachtelungstiefe. Einen Leitzordner kann man maximal in zwei weitere Ebenen gliedern: man kann ihn mit DIN A4-Einlegeblättern unterteilen und jeden dieser Abschnitte mit Pappzungen. Noch tiefer geht nicht. – Ordnermappen in Hängeregistraturen sind praktisch überhaupt nicht gliederbar. Hier können wir nur ein neues eingehendes Dokument auf die schon vorhandenen drauflegen. • E-Mails können schnell geschrieben und schnell versendet werden. Und vor allem können sie umstandslos per CC multipliziert werden.

188

W. Steinbrecher

Abb. 18.1  Die Anzahl empfangener E-Mails an den Arbeitsplätzen in einem Landratsamt (auf Wunsch des Projektpartners anonymisiert)

Im Endeffekt bezweifeln viele Forscher, dass diese Form der Digitalisierung zu einem Produktivitätsfortschritt geführt hat.4 Die Beschleunigung bei der Erledigung der einzelnen Tätigkeiten wurde demnach mehr als aufgewogen durch die Mengenkomponente, nämlich die Vervielfältigung eben dieser Einzeltätigkeiten. Wer im deutschsprachigen Raum nach repräsentativen Statistiken zu diesem Phänomen sucht, wird nicht gut bedient. Es gibt einige Umfragen zu dem Thema, die aber nur sehr kleine Stichproben aufweisen und nicht nach Art der Arbeitsplätze differenzieren.5 Ich habe in einem DMS-Projekt in einem Landratsamt zusammen mit dem dortigen Projektleiter versucht, nur den Aufwand für den internen Versand von E-Mails zu messen (siehe Abb. 18.1). Dabei wurden alle Büroarbeitsplätze in der Kernverwaltung eines Landkreises in Baden-Württemberg im Jahre 2013 durch eine Abfrage auf den MS Exchange Server ausgewertet. Daraus ergab sich, dass ein durchschnittlicher Mitarbeiter pro Arbeitstag

4Vgl. 5Vgl.

Mankins (2016). dazu beispielsweise bitkom (2014).

18  eGovernment: Die digita(gi)le Zukunftsakte

189

• rund 19 E-Mails von externen Kontakten (Bürger, andere Behörden, Lieferanten) erhielt; • rund 17 interne E-Mails (ohne Termineinladungen); • der Anteil interner an allen E-Mails also ca. 48 % betrug; • dass wiederum der Anteil der E-Mails mit einem Dokumentenanhang bei den internen Mails ca. 58 % betrug; • und dass man den Aufwand für das Versenden und Checken dieser E-Mails und der angehängten Dokumente auf ca. 5,2 % der Arbeitszeit schätzen kann. Dabei ist mit „Checken“ einer E-Mail nur ihre Prüfung und ggf. Abspeicherung oder Löschung gemeint („Betrifft sie mich? Muss ich den Anhang ins Filesystem speichern? Wenn ja: Wohin dort? Muss ich etwas tun? Wenn ja: Wo notiere ich mir diese Aufgabe?“), nicht eine evtl. sich anschließende Weiterverarbeitung. Ob diese Statistik repräsentativ auch für andere Ebenen der Verwaltung ist (­Bundesund Landesbehörden, Städte und kleine Kommunen), kann ich überhaupt nicht beurteilen. Auch ist nichts über den Trend ausgesagt: Nehmen die E-Mails zu oder ab oder stagnieren sie auf hohem Niveau? Auch zur wichtigen Frage der Besprechungen („Meetings“) und der damit einhergehenden Zeitbelastung gibt es kaum belastbare Statistiken. Dabei sind Meetings – ihre Häufigkeit, die Anzahl der Teilnehmenden, ihre Zeitdauer – überhaupt nicht schicksalhaft vorgegeben; sie stellen vielmehr Methoden der Synchronisation in komplexen Arbeitsumgebungen mit verteilten Zuständigkeiten dar – sind also sehr stark mit unserer Siloorganisation verbunden. Wie sollen wir uns verbessern und die Chancen der Digitalisierung aktiv gestalten, wenn wir so wenige Kenntnisse über den Ist-Zustand haben? Solange wir so wenig Bescheid wissen, laufen wir Gefahr, von technischen Änderungen an der Arbeitsoberfläche tief greifende Verbesserungen zu erwarten.6 Wäre deshalb nicht vor der Budgetierung und Ausschreibung großer und langfristig angelegter E-Akten-Projekte ein wenig Ist-Analyse ganz nützlich?

6So wünschen sich laut einer Umfrage der Gesellschaft für Konsumforschung (GfK) knapp 30 % der deutschen Arbeitnehmer an PC-Arbeitsplätzen Zusatzangebote wie firmeninterne Soziale Netzwerke, um die Anzahl der E-Mails zu reduzieren (spielraum 2015). Diese Idee verkennt den Charakter interner E-Mails als Methode, Arbeitsaufträge und Informationen (Dokumente) gezielt zu adressieren.

190

W. Steinbrecher

Abb. 18.2  Ablage nach Organigramm („Siloablage“)

18.3 Silos und erste Teamblumen dazwischen Ein weiteres Relikt aus der Papierwelt prägt unsere Arbeitsumgebung: Die Strukturierung der elektronischen Ablage nach Organigramm (auch „Siloablage“ genannt, weil sie dem Silodenken entspringt und umgekehrt das Silodenken verfestigt). Abb. 18.2 zeigt diese Ablagestruktur schematisch für eine beliebige Kommunalverwaltung: Auf dem Server verfügt jeder Fachbereich (bzw. jedes Amt) über einen spezifischen Dokumentenbereich (hier als Ordner auf einem Laufwerk D: dargestellt). Die Mitarbeiter z. B. des Hauptamtes haben Zugriff auf die Dokumente „ihrer“ Abteilung, aber nicht auf die des Bauordnungsamtes und vice versa. Jeder Funktionsbereich ist abgeschottet in „seinem“ Silo.7 Diese Struktur funktioniert einigermaßen, solange die Prozesse, mit denen ein Fachbereich zu tun hat, ganz in den Grenzen dieses Fachbereichs verlaufen. Mit „einigermaßen“ ist die Einschränkung gemeint: Auch innerhalb dieser Silos herrscht oft keine gute Ordnung; eine irgendwie formalisierte Struktur – sei es der alte „Aktenplan“ oder etwas Moderneres – existiert nicht. Vertretungen sind mühsam, weil man sich in der Ablage des Kollegen nicht auskennt, und auch im „eigenen“ Dokumentenbereich wird oft gesucht.

7Dies

ist die Grundstruktur, die wir in Verwaltungen am Anfang unserer Projekte vorfinden. Und natürlich gibt es Modifikationen dieser Grundstruktur. Teilweise gibt es noch zusätzlich „persönliche“ Ordner oder Laufwerke für jeden Mitarbeiter usw.

18  eGovernment: Die digita(gi)le Zukunftsakte

191

Die Siloablage stößt sofort an Grenzen, wenn die Prozesse fachbereichsübergreifend verlaufen. Abb. 18.3 zeigt, wie derartige Prozesse die Grenzen des Ablagesystems sprengen. Sie führen dann zu der oben geschilderten internen E-Mail-Flut, mit der Dokumente an andere Kollegen versendet werden, die keinen Zugriff auf benötigte Unterlagen der Nachbarabteilungen haben. Zwischen den eingehegten Beeten der Siloablage aber blühen erste Teamblumen. Vor allem bei größeren Projekten, wenn sie eine hohe Komplexität aufweisen und wenn sie länger dauern und die Projektteams über einen längeren Zeitraum zusammenarbeiten, schaffen sich diese oft neue Strukturen. Es werden Projektlaufwerke eingerichtet, auf die alle Projektmitglieder Zugriff erhalten, oder in den letzten Jahren auch oft SharePoint Server. Das zeigt, dass der Bedarf, über die alte Ordnung hinauszugehen, durchaus gespürt wird und auch aktiv neue Mittel und Wege gesucht werden. Wenn diese Bestrebungen aber nicht energisch und fachgerecht unterstützt werden, bilden sich einzelne Inseln, die in sich nicht übersichtlich strukturiert sind und zudem alle Unikate darstellen. Eine Führungskraft in einem meiner Projekte war auf 35 SharePoint-Plattformen zugelassen. Von ihr wurde erwartet, dass sie sich regelmäßig über den aktuellen Stand dieser Projekte auf dem Laufenden hielt. Aber jede Plattform war anders aufgebaut, weil jeder Projektleiter das Rad in „seinem“ Projekt wieder neu erfand. Oft findet man ad-hoc gestaltete Projektablagen vor wie die Bauakte in Abb. 18.4. Dort finden wir Unterordner nach • • • •

Dokumentenart („Fotos“, „Aufträge“, „interne Vermerke“); Projektpartnern („Architektenbüro“, „Handwerker“) Gewerken („Gebäudetechnik“, „Heizung“) Gebäudeteilen („Außenanlagen“, „Grundstück“).

Abb. 18.3  Die Prozesse verlaufen zunehmend quer zu den Silos

192

W. Steinbrecher

Abb. 18.4   Ablagestruktur eines Projektordners für einen Neubau

Der Hauptmangel einer solchen Ordnung besteht in ihrer mangelnden Trennschärfe. Eine E-Mail an einen Handwerker, die sich auf einen die Heizung betreffenden Auftrag bezieht: Wo wird die abgelegt? Unter Handwerker? Unter Aufträge? Unter Heizung? Am besten, man schafft sich einen neuen Ordner „Schriftverkehr“ und ist die Sorgen bei der Ablage los (bloß, dass man in diesem Ordner dann nichts mehr findet). Und sowie man etwas näher hinschaut, stellt man fest: Der Bedarf an einer silo-­ unabhängigen Kollaborationsstruktur ist viel größer als „nur“ bei größeren Projekten. Auch an vielen kleineren Aufgaben sind mehrere Fachbereiche beteiligt: Bei Personaleinstellungen, bei Beschaffungen, bei der Haushaltsplanung, bei Veranstaltungen, in der Öffentlichkeitsarbeit und und und … Es gibt also einen großen Bedarf an Teamlösungen, und dieser Bedarf wartet auf Unterstützung beim Aufbau komplexer Kollaborationsstrukturen. Diese wachsen nicht von selbst, sondern bedürfen der Expertise und der Vernetzung von Erfahrungen. E-Akten-­ Projekte, die sich dieser Herausforderung nicht stellen, werden den Bedürfnissen ihrer künftigen Anwender nicht ausreichend gerecht.

18.4 Dokumente und Aktivitäten nach Vorgängen organisieren Die Idee „Wir ordnen unsere Dokumente, Aktivitäten und Informationen entlang unserer Prozesse“

18  eGovernment: Die digita(gi)le Zukunftsakte

193

Abb. 18.5  Zu jedem Vorgang gehört ein (oft crossfunktionales) Vorgangsteam

ergibt sich logisch aus dem Ansatz, funktionsübergreifende Teams zu bilden. Bei großen Aufgabenstellungen spricht man von Projekten; für kleinere Vorhaben schlagen wir den Begriff des „Vorgangs“ vor.8 Seine Definition lautet: Ein Vorgang ist eine Kette von Tätigkeiten, die ein oder mehrere Menschen verrichten mit dem Ziel, ein nützliches Ergebnis zu erzeugen.9

Zu jedem Vorgang gibt es ein Vorgangsteam – das ist eben das crossfunktionale Team (Abb. 18.5) Es umfasst alle Mitarbeiter der Organisation und eventuell auch externe Beteiligte, die Beiträge zum Abschließen eines Vorgangs – also zur Erreichung seines Ergebnisses – leisten.

8Der

Begriff des Vorgangs stellt einerseits die deutsche Übertragung des englischen Wortes „case“ und des französischen Begriffs des „dossier“ dar. Andererseits ist es bereits in der deutschen Schriftgutverwaltung eingeführt. So empfehlen beinah alle Beihefte zu bundesdeutschen Aktenplänen die „Ablage nach Vorgängen“. Zum Beispiel in den Vorbemerkungen zum Einheitsaktenplan Bayern heißt es: „In einem Vorgang sind ‚alle [Dokumente] zusammengefasst, die einen konkreten, abgrenzbaren Sachverhalt betreffen und für dessen Bearbeitung, Verständlichkeit und Nachvollziehbarkeit bedeutsam sind.“ Vgl. Archive Bayerns (2011, S. 7), Wiedemann und Fritsch (2014). Diese „Definition“ ist einigermaßen unverständlich und nicht ausreichend, um die Arbeitspraktiken in einem Team auf der Basis eines gemeinsamen Verständnisses zu standardisieren. 9Vgl. Steinbrecher und Müll-Schnurr (2014).

194

W. Steinbrecher

Für die Grundstruktur der Ablage bedeutet das: 1. Zu jedem Vorgang wird ein „Ordner“ gebildet.10 2. Auf diesen Ordner haben alle Mitglieder des Vorgangsteams Zugriff.11 In diesem kurzen Satz steckt eine ganze Philosophie: Dies beinhaltet die Absage an das Siloprinzip. Wenn ein Vorgang von Auslöser bis Ergebnis ganz innerhalb einer Funktionseinheit stattfindet, dann kann die Berechtigungsstruktur so bleiben, wie sie ist. Wenn das Vorgangsteam aber aus Mitarbeitern verschiedener Abteilungen besteht, dann werden auch die Berechtigungen „quer“ zu den Abteilungen organisiert. Die Berechtigung folgt dem Prozess, nicht der Prozess passt sich an die Berechtigungsstruktur an. 3. Im Vorgangsordner befinden sich alle Informationen, die zur gemeinsamen Bearbeitung des Vorgangs notwendig sind. Also Dokumente (incl. relevanter E-Mails) und auch Aktivitäten (Arbeitsaufträge, Wiedervorlagen usw.) sowie Statusinformationen zum Stand des Vorgangs. 4. Vorgänge werden abgeschlossen, wenn das Ergebnis erzielt ist (oder es keine Möglichkeit mehr gibt, das angestrebte Ergebnis mit einem vertretbaren Aufwand zu erreichen). Abgeschlossene Vorgänge wandern in eine elektronische Registratur, in der sie bis zum Ablauf der Aufbewahrungsfrist revisionssicher archiviert werden. So bleibt die aktuelle Ablage immer schlank und Trefferlisten von Suchvorgängen überschaubar.

18.5 Adaptive Case Management in Vorgängen 18.5.1 Die Forderung nach Adaptivität des DMS Ein gutes Dokumentenmanagement-System ist immer auch ein Vorgangsbearbeitungssystem. Es unterstützt die Vorgangsteams bei der Strukturierung und Synchronisation ihrer Vorgänge. Wir hatten oben auf die spontan entstehenden Teamräume verwiesen und deren mangelnde Übersichtlichkeit. Wenn ein Mitarbeiter ab und zu einmal in einem einzigen Projekt mitarbeitet, dann kann dieses Projekt „ad hoc“ strukturiert werden. Wenn es aber mehr und mehr Vorgänge werden, in denen wir in Teamform zusammenarbeiten,

10Der

Begriff des „Ordners“ soll hier unabhängig von der technischen Umgebung verstanden werden. Klar ist, dass es sich nicht um Papierordner handelt: In unserem Kontext „E-Akte“ setzen wir die Digitalisierung voraus. Aber ob es sich um einen Windows-Ordner handelt oder einen SharePoint-Raum oder ein entsprechendes Objekt in einer Dokumentenmanagement-Software soll hier nicht festgelegt werden. „Ordner“ ist hier ein Strukturelement, keine Objektklasse in einer Datenbank. 11Auf eine mögliche Differenzierung dieser Rechte nach Lese-, Schreib- und anderen Rechten gehen wir in diesem Kapitel nicht ein. Die Darstellung eines prozessorientierten Berechtigungskonzepts würde seine Grenzen sprengen.

18  eGovernment: Die digita(gi)le Zukunftsakte

195

dann lähmt es unsere Produktivität und bereitet einen erheblichen Basisstress, wenn jeder Vorgang anders aussieht und wir jedes Mal umdenken müssen. Der Mainstream im Dokumentenmanagement preist hier das Konzept des Workflows. Wir Agilisten sind skeptisch.12 Denn: Jeder erfolgreich modellierte Workflow stellt zugleich ein Korsett für den jeweiligen Prozess dar. Im Augenblick seiner Installation beginnt er zu veralten. Das heißt, ein DMS muss nicht nur Workflows managen, sondern muss auch das Workflow-Management managen. Das ist die Forderung nach Adaptivität des DMS, ein Thema, über das in DMS-­ Projekten nur wenig nachgedacht wird und das deshalb in den üblichen Lastenheften für Ausschreibungen ganz selten eine Rolle spielt. Die Kernforderung der Adaptivität lautet: Wenn eine kleinere Änderung in einem Prozess notwendig wird, dann muss die entsprechende Anpassung im DMS innerhalb von einer Arbeitsstunde möglich sein. Am besten ist es, wenn Key-User aus der Fachabteilung selbstständig derartige Änderungen am hinterlegten Workflow schnell und unkompliziert vornehmen können. Denn mittlerweile weisen zwar viele DMS sogenannte „Werkbänke“ auf, bei denen die Verwaltung selbst ihre Workflows modellieren kann. Aber dazu braucht es meistens Fachkenntnisse, die nur in der IT vorhanden sind. Also heißt es für die Fachabteilungen: warten, bis die IT Zeit hat. Und bis dahin arbeitet man mit Workarounds und kehrt oft zu längst überwundenen Arbeitsweisen außerhalb des DMS zurück. Aus diesen Erfahrungen haben wir nach und nach in unseren DMS-Projekten ein anderes Konzept entwickelt, das auf dem sog. Adaptive Case Management beruht und bei Vorgangsteams sehr gut angenommen und erfolgreich verwendet wird.

18.5.2 Standardisierung und Strukturierung durch Meilensteine Für die Strukturierung komplexerer Vorgänge verwenden wir das Konzept des Meilensteins13. Ein Meilenstein ist – technisch betrachtet – ein „Unterordner“ eines Vorgangs, dem Aktivitäten und Dokumente des Vorgangs eindeutig zugeordnet sind. Die Bezeichnung „Meilenstein“ entstammt dem Projektmanagement. Franz Noll hat mich auf die diesbezügliche Definition in Wikipedia aufmerksam gemacht:14 „Ein Meilenstein (englisch milestone …) ist ein Ereignis von besonderer Bedeutung im Projektmanagement. Meilensteine teilen den Projektverlauf in überprüfbare Etappen mit

12Für eine ausführlichere Kritik des Workflow-Konzepts vgl. Steinbrecher und Müll-Schnurr (2014), Kap. 20, sowie Steinbrecher (2014a) und (2014b). 13Das Konzept orientiert sich am Framework des Adaptive Case Management; vgl. Swenson (2010), Fischer et al. (2016), Palmer et al. (2016). 14Siehe Noll (2018).

196

W. Steinbrecher

Abb. 18.6  Meilensteinordner gliedern einen Vorgang Zwischenzielen und erleichtern damit sowohl die Projektplanung als auch die Kontrolle des Projektfortschritts. Solche Ereignisse sind insbesondere: • Das Vorliegen von Liefergegenständen (engl. deliverables) oder Zwischenergebnissen. • Abnahmen, Zwischenabnahmen und Prüfungen (reviews).“

Franz Noll bemerkt dazu anhand des Beispiels in Abb. 18.6: ‚Stellenprofil erstellen‘ ist demnach kein Meilenstein. ‚Stellenprofil fertiggestellt‘ wäre das vielleicht.

Das ist tatsächlich der Unterschied zwischen der Bedeutung „Meilenstein“ im prozessorientierten Vorgangsmanagement und im klassischen Projektmanagement: Dort ist ein Meilenstein ein Ereignis, hier aber verstehen wir darunter eine Teilmenge von Dokumenten und Aktivitäten, verknüpft mit einem Status (der verschiedene Werte annehmen kann) und einem Zeitintervall.15

15Trotz dieser Abweichung von der ursprünglichen Bedeutung des „Meilensteins“ im Projektmanagement wollten wir diesen Begriff verwenden und nicht Worte wie „Phase“ oder „Teilprojekt“. Phase legt den Akzent zu sehr auf eine zeitliche Abfolge, während Meilensteine eben auch nicht nur nacheinander, sondern auch bisweilen parallel aktiv sein können. Den Begriff „Teilprojekt“ wollen wir auf verzahnte Prozesse beschränken.

18  eGovernment: Die digita(gi)le Zukunftsakte

197

Deshalb lautet der Name des Meilensteins „Stellenprofil erstellen“, und dieser kann den Status „erledigt“ annehmen (dann ist das Stellenprofil erstellt). Das Stellenprofil als fertiges Dokument befindet sich in diesem Meilenstein. Es stellt dort quasi das letzte, abschließende Dokument dar im Sinne eines „Liefergegenstands“. Die Suche quer zu Meilensteinen (und im Übrigen auch quer zu den Vorgängen) kann erleichtert werden durch die Festlegung prozessspezifischer Dokumentenarten. Dokumentenarten stehen orthogonal zu den Meilensteinen (Franz Noll). Im Fall des Prozesses „Mitarbeiter einstellen“ gibt es z. B. Dokumentenarten wie • Stellenprofil • Lebenslauf • Zeugnis • Einstellungszusage • Arbeitsvertrag • Usw. Nur häufig gesuchten Dokumenten wird eine solche Dokumentenart zugewiesen. Aber für diese Dokumente – z. B. das Stellenprofil – brauche ich mir nicht den Meilenstein zu merken, in dem sie stehen könnten. Meilensteine sollen automatisch angelegt werden, sowie ein neuer Vorgang angelegt wird.16 Insofern stellen sie eine Standardisierung des Prozesses auf einer sehr grobgranularen Ebene dar. Sie sollen außerdem die Mitarbeiter nicht knebeln; jedes Mitglied in einem Vorgangsteam darf (und soll) bei Bedarf ad-hoc-Meilensteine zum Vorgang hinzufügen. In einem DMS (im Unterschied zu Windows) können einem Meilenstein Metadaten hinterlegt werden; dazu gehören insbesondere die oben schon erwähnten Statusangaben, die über den aktuellen Bearbeitungsstand Auskunft geben. So können sich Mitarbeiter, die nur sporadisch mit einem bestimmten Vorgang zu tun haben – z. B. Führungskräfte oder Kollegen im Vertretungsfall – schnell einen Überblick über den Status eines ganzen Vorgangs verschaffen. Die Statusangabe Die Stelle ist ausgeschrieben und jetzt warten wir gerade auf den Eingang von Bewerbungen.

aufgrund der Meilensteine in Abb. 18.7 ist eine sehr konzentrierte Aussage über einen Vorgang der Personalbeschaffung, den man auf einen Blick gewinnen kann. Sie dienen so der unkomplizierten Synchronisation von Vorgangsteams und ersparen Telefonate und E-Mails mit „Wie steht’s denn so?“-Fragen.

16Die Listen der Muster-Meilensteine von Vorgängen sind also bei den jeweiligen Prozessen zu hinterlegen.

198

W. Steinbrecher

Abb. 18.7  Meilensteine erlauben eine sanfte Standardisierung von Prozessen und geben gleichzeitig schnelle Informationen zum Status eines Vorgangs

In einem Anfangsstadium kann man sich mit drei möglichen Statuswerten begnügen: • Noch nicht begonnen • Aktiv • Erledigt. So haben manche Organisationen dieser Liste den Status „wartend“ hinzugefügt. Und andere sogar prozessspezifische Wertelisten für Meilensteine definiert.

18.5.3 Komplexitätsreduktion Ein Meilenstein in einem Vorgang kann in unserem Konzept ein eigenständiger Vorgang in einem anderen Prozess sein. Auf diese Weise • wird die Komplexität eines Vorgangs reduziert, indem er als Kombination zweier verzahnter, aber eigenständiger Vorgänge dargestellt wird; • wird das Berechtigungskonzept entschlackt – es müssen keine Berechtigungen auf Ebene der Meilensteine vergeben werden (Abb. 18.8).

18  eGovernment: Die digita(gi)le Zukunftsakte

199

Abb. 18.8  Meilensteine erlauben die Darstellung komplexer Projekte als verzahnte Vorgänge

18.6 Vorgänge managen entlang der Prozesse Für die Arbeitsplanung und die Synchronisation der Fachbereiche – der klassischen Funktionseinheiten der Organisation – ist die Vorgangsliste entscheidend. Jeder einzelne Mitarbeiter hat eine Vorgangsliste (egal ob im Kopf oder in einer Kladde oder in der Outlook-Aufgabenverwaltung oder in einer Wiedervorlagemappe: er hat sie, auch wenn er es nicht weiß). Nehmen wir an, jeder Sachbearbeiter habe parallel 10 bis 30 aktive Vorgänge in der Bearbeitung (eine erste grobe Schätzung). Für ein Sachgebiet mit acht Mitarbeitern sind das schon ca. 160 Vorgänge; für einen Fachbereich mit 100 Mitarbeitern rd. 2000 Vorgänge. Eine Vorgangsliste dieser Länge wäre völlig unübersichtlich. Wie kann die Masse der Vorgänge so strukturieren, dass man sie a) leicht finden b) leicht sortieren c) leicht gruppieren d) leicht filtern kann?

200

W. Steinbrecher

Abb. 18.9  Jeder Vorgang gehört zu einem Prozess

Dazu bieten sich drei Ordnungskriterien an: 1. Prozesse 2. Objekte 3. Themen Das soll jetzt in diesem und im folgenden Abschnitt im Einzelnen erklärt werden. Jeder Vorgang gehört zu einem Prozess. Ich wähle Beispiele aus dem Personalbereich, weil jeder von uns entsprechende Vorgänge aus der Mitarbeiterrolle kennt. Beispiele: Der Vorgang „einen Hausmeister für die Anne-Frank-Gesamtschule zum 1. Juni 2018 einstellen“ gehört zum Prozess „Mitarbeiter einstellen“. Der Vorgang „Der Mitarbeiter Frank Herrendorf geht ab 1. August 2018 in Elternzeit“ gehört zum Prozess „Arbeitsverhältnis ändern“.

Diese Zuordnung von Vorgang → Prozess ist eindeutig: Kein Vorgang gehört zu zwei Prozessen, und es gibt keinen Vorgang, der zu keinem Prozess gehört (Abb. 18.9).17 Die Liste der Prozesse einer Organisation bezeichnet man auch als „Prozesslandkarte“ oder „Prozesslandschaft“. In der kommunalen Verwaltung gibt es seit der Entwicklung des „Neuen Steuerungsmodells“ und der (vollzogenen oder noch geplanten) Umstellung vom kameralen Haushalt auf die Doppik einen sogenannten „Produktplan“.

17Das ist letztlich eine Frage der Definition und der Konstruktion der Prozessliste. Vgl. Steinbrecher und Müll-Schnurr (2014).

18  eGovernment: Die digita(gi)le Zukunftsakte

201

Abb. 18.10  Ausschnitt aus der Prozesslandkarte mit Personalprozessen

Der kommt einer Prozesslandkarte sehr nahe: Dem Produkt „Baugenehmigungen“ entspricht der Prozess „Bauanträge bearbeiten“.18 Aus der Gruppierung von Vorgängen nach Prozessen lässt sich ein prozessorientierter Aktenplan entwickeln. Abb. 18.10 zeigt einen Ausschnitt aus einem solchen Aktenplan, den wir in einem Projekt aufgrund des baden-württembergischen Produktplans für eine Stadt entwickelt haben. Die Ordnung der Vorgänge nach Prozessen hat verschiedene Vorteile. Die wichtigsten: • Die Verwaltung von Vorlagen ist besonders einfach. Mehr als 95 % der Vorlagen in einer Verwaltung lassen sich Prozessen zuordnen (z. B. die Vorlage „Absagebrief an einen Bewerber“ gehört eindeutig zum Prozess „Mitarbeiter einstellen“).

18Zu

einer möglichen Verwendung des Produktplans als Aktenplan siehe Steinbrecher (2007). Prinzipielle Einwände gegen die Zulässigkeit einer prozess- bzw. produktorientierten Ablage erhebt Sannwald (2013) aus Sicht eines Archivars.

202

W. Steinbrecher

Abb. 18.11  Vorgänge in einem prozessorientierten Aktenplan

• Die Berechtigungsverwaltung ist relativ einfach. Ein neues Berechtigungskonzept zu entwerfen – und das ist notwendig, wenn man von der Ablage nach Organigramm Abschied nehmen will –, ist für die IT mit Arbeit und Umdenken verbunden. In den meisten Prozessen gibt es relativ stabile (funktionsübergreifende) Vorgangsteams, die jeweils die Vorgänge dieses Prozesses bearbeiten. Steht der Prozess in einer Ordnerhierarchie „über“ den Vorgängen, dann kann man auf dieser grobgranularen Ebene die Berechtigungen setzen. Die Vorgänge bilden dann Ordner in einem „Ordnerbaum“ unterhalb der Prozessebene (Abb. 18.11). Insofern wäre alles ganz klassisch: Wir hätten in unserem DMS eine eindimensionale Baumstruktur wie in einem Windows-Dateisystem – nur eben nicht nach Organigramm, sondern nach Prozessen geordnet. Reicht das aus? Nein. Wir müssen es noch ergänzen, und zwar müssen wir noch die Objektkategorien in die Ordnung integrieren.

18.7 Objektbezogenes Wissen aufbereiten 18.7.1 Definitionen Jede Verwaltung hat mit einer großen Reihe von Objekten zu tun. Über sie den Überblick zu behalten, ist ein großes Anliegen bei einer ganzheitlichen Arbeitsweise.

18  eGovernment: Die digita(gi)le Zukunftsakte

203

Beispiele für Objekte sind: • • • • • • • • •

Frau Daniela Meyerbeer, Grundstückseigentümerin das Grundstück Lohmannstraße 104 die Abteilung 5.12, Wohngeldstelle Herr Kevin Podielski, Hausmeister die Stelle „Hausmeister Verwaltungsgebäude II“ das Gremium „Haushaltsausschuss“ das Projekt „Straßenbahnlinie 4“ das Schulgebäude „Sophie-Scholl-Gymnasium“ die Schule „Sophie-Scholl-Gymnasium“ (als Organisation).19

Objekte sind immer „Einzelelemente“ von Objektkategorien (bzw. eines „Value Set“ im IT-Deutsch): • Frau Meyerbeer ist ein Element der Objektkategorie „Bürger“ oder „Grundstückseigentümer“20 • Lohmannstraße 104 ist Element der Objektkategorie „Flurstücke“ und hat dort die offizielle Bezeichnung 5609/24 • Usw. Typische Herausforderungen bei der Pflege von Objekten sind: • Objekte werden doppelt angelegt, z. B. der gleiche Lieferant unter „Computer Kaersmann GmbH & Co KG“, unter „Computer Kaersmann“ oder einfach unter „Kaersmann“. Wie kann man dies verhindern oder zumindest problemlos korrigieren? • Objekte ändern ihren Namen. Frau Meyerbeer heiratet und erhält den Nachnamen Niederwaldt. Wie will man gewährleisten, dass diese Grundstückeigentümerin künftig auch für abgeschlossene Vorgänge und Dokumente unter “Niederwaldt” gefunden wird? • Objekte haben Merkmale. Frau Meyerbeer hat eine Adresse und eine Telefonnummer. Herr Podielski sitzt auf einer bestimmten Stelle. Dauernd ändern sich diese Merkmale: Durch Umzug, Versetzung usw. – Es würde uns das Leben sehr viel einfacher machen, wenn die Pflege von Objektänderungen nur einmal erfolgen müsste und dann allen anderen Beteiligten (und Berechtigten) zur Verfügung stünden.

19Wenn wir also von Objekten sprechen, so meinen wir dies in einem grammatikalischen Sinn: „In diesem Vorgang bearbeite ich einen Bauantrag von Daniela Meyerbeer zum Flurstück 5609/24.“ Ein Kunde oder Bürger ist deshalb in unserem Sinne auch ein „Objekt“, obwohl Menschen natürlich keine Dinge sind. 20Es gibt (auch nach Bundesländern) unterschiedliche Rechtsauffassungen, ob es zulässig ist, eine Liste „aller Bürger“ zu führen, oder ob diese nach einzelnen Kategorien getrennt werden muss: „Grundstückeigentümer“, „Hundesteuerpflichtige“ usw. Für unser Thema spielt dies eine untergeordnete Rolle.

204

W. Steinbrecher

18.7.2 Integration der Wissenspflege in die operativen Vorgänge Die Objekte sind mit den Vorgängen eng verknüpft. Es bietet sich an, die Lösungen für die genannten Herausforderungen in das Vorgangsmanagement zu integrieren. Dazu passt es gut, dass Vorgänge immer mit Objekten verknüpft sind: • Vorgang 1: Herr Jüngling vom Bauordnungsamt bearbeitet den Antrag von Frau Niederwaldt (=Objekt 1), auf ihrem Grundstück Lohmannstraße 104 (=Objekt 2) einen Carport zu errichten. • Vorgang 2: Der Haushaltsausschuss (=Objekt 1) behandelt einen Antrag, die Grundrenovierung des Sophie-Scholl-Gymnasiums (=Objekt 2) zu beschließen. Wenn also Herr Jüngling merkt, dass Frau Niederwaldt seit ihrem letzten Behördenkontakt geheiratet hat (er merkt das daran, dass beim Grundstück Lohmannstraße 104 noch eine Frau Meyerbeer als Eigentümerin fungiert), dann pflegt er den neuen Namen in die Stammdaten von Frau Meyerbeer-Niederwaldt ein und sofort hat jeder Mitarbeiter der Verwaltung, der mit Frau Niederwaldt zu tun hat, diese Daten zur Verfügung (und auch richtig gefunden, obwohl er noch nach „Daniela Meyerbeer“ gesucht hat). Durch diese Integration der Wissenspflege in die operativen Prozesse und ihre Vorgänge garantieren wir, dass diese Pflege auch wirklich geschieht, dass sie nach einheitlichen Standards geschieht und dieses Wissen zum ganzheitlichen Wissensschatz der Gesamtverwaltung wird (Abb. 18.12).

Abb. 18.12  Vorgänge arbeiten mit oder für Objekte. Deren Pflege kann in das Vorgangsmanagement integriert werden

18  eGovernment: Die digita(gi)le Zukunftsakte

205

Eine solche Integration ist natürlich nicht mehr unter Windows zu gewährleisten, sondern hier bedarf es wirklich eines Dokumentenmanagement-Systems. Und an diesem Punkt werden die Vorteile eines DMS auch wirklich spürbar und bringen einen hohen R. O. I.21

18.7.3 Mehrdimensionale Aktenpläne und die Anliegen der Archivare Windows ist ein eindimensionales System. Man kann nur einen Ordnerbaum pflegen und muss sich für eine eindeutige Struktur auf der obersten Ebene dieses Baumes entscheiden. Und jede Entscheidung hat Nachteile; sie stellt bestenfalls ein „kleineres Übel“ dar. Wenn man einen prozessorientierten Aktenplan in einem Windows-Dateisystem ­verwendet, dann werden die einzelnen Objekte auf verschiedene Vorgangsordner in verschiedenen Prozessen verteilt. Ihr innerer Zusammenhang wird zerrissen. Die Abb. 18.13 zeigt dies exemplarisch an Herrn Burmester: • Im Jahr 2014 wurde Herr Burmester eingestellt (Prozess „Mitarbeiter einstellen“); • In 2016 wurde er in Entgeltgruppe 9 hochgruppiert (Prozess „Eingruppierung ändern“). • Ein Jahr später wurde er wegen Unpünktlichkeit abgemahnt („Mitarbeiter ermahnen und abmahnen“). Offensichtlich hatte er sich auf seinen Lorbeeren ausgeruht. • Nun ist Herr Burmester beleidigt und zieht sich in die Schmollecke zurück. 2018 geht er in Teilzeit (Prozess „Arbeitsverhältnisse ändern“). Diesen interessanten Weg von Herrn Burmester können wir aber nur sehr umständlich verfolgen, durch viel Suchen in verschiedenen Prozessordnern. Die Prozessorientierung der Ablagestruktur führt also zu gravierenden Nachteilen auf der Ebene der Übersicht über die Objekte. Dies stellt im Übrigen auch einen der Haupteinwände aus Sicht von Archivaren dar.22 Hier kann aber ein DMS Abhilfe schaffen (Abb. 18.14). Ohne Aufwand kann man in einem DMS die Vorgänge umgruppieren und ohne Aufwand eine „virtuelle Personalakte Karls Burmester“ erzeugen.

21Durchaus nicht alle Dokumentenmanagementsysteme erfüllen diese Anforderungen. Ihre genaue Beschreibung im Leistungsverzeichnis einer Ausschreibung ist deshalb entscheidend. Leser, die vor einer Ausschreibung stehen, können gerne kostenlos per E-Mail unser „Musterlastenheft DMS“ anfordern. 22Vgl. Sannwald (2013). Die traditionellen, auf der Papierordnung basierenden Aktenpläne sind nämlich vorwiegend objektorientiert, d. h. sie enthalten Aktenplaneinträge für Personalakten, Grundstücksakten, Akten von Führerscheininhabern usw.

206

W. Steinbrecher

Abb. 18.13  In einer Windows-Ablage wird ein Objekt auf verschiedene Prozesse verteilt

Abb. 18.14  Ein DMS kann mehrere Sichten – auch objektorientierte – auf die Vorgänge erzeugen

Die E-Akte hilft uns so, auf der Basis des Prozessdenkens ein schlagkräftiges und einfach zu bedienendes Wissensmanagement zu installieren.

18  eGovernment: Die digita(gi)le Zukunftsakte

207

18.8 Teamarbeit ist die Zukunft Die E-Akte oder genauer: ein prozessorientiertes Dokumenten-, Aktivitäten- und Wissensmanagement auf digitaler (medienbruchfreier) Grundlage ist ein Arbeitswerkzeug. Werkzeuge sind an sich moralisch weder gut noch böse, sondern neutral. Einen Hammer kann man als Türstopper benutzen, man kann mit ihm Menschen attackieren oder auch Nägel einschlagen. Aber auch wenn sich der Hammer als solcher unserem moralischen Urteil entzieht, gibt es doch gute und schlechte Exemplare. Ein Hammer, dessen Kopf sich dauernd vom Stiel löst, wird uns bei all seinen denkbaren Verwendungen nur von eingeschränktem Nutzen sein. In diesem instrumentellen Sinne sind gute Werkzeuge solche, die stabil sind und viele Möglichkeiten eröffnen. Übertragen auf die E-Akte bedeutet das: Wir sehen in verschiedenen Bereichen der Verwaltung eine Tendenz fort vom funktionalen Zuständigkeits- und Silodenken hin zu vernetzter Teamarbeit.23 Wir vermuten, dass sich diese Tendenz in Zukunft fortsetzen wird. Das wäre – wenn unsere Hypothese zutrifft – ein Umbruch in unseren Arbeitsweisen, die tief, sehr tief!, in unser verwaltungskulturelles Stammhirn eingeschrieben sind. Die E-Akte stellt nicht den Kern dieses Umbruchs dar, sondern eher eine begleitende Hintergrundmusik. Aber als solche kann sie harmonisch oder dissonant sein. Wir können und müssen von der neuen Technik verlangen, dass sie die möglichen Änderungsprozesse zumindest nicht behindert. Dass sie nicht die alten, papiergebundenen Arbeitsweisen noch ins 21. Jahrhundert hinüberrettet, sondern dass sie zumindest Möglichkeitsräume eröffnet, die uns in der Gestaltung der Arbeitsweisen der Zukunft freiere Hand lassen als heute. Teamfähigkeit – Unterstützung von Selbstorganisation – individuelle Sichten auf kollektive Vorgänge – Strukturierungsangebote für eine gemeinsame Organisationssprache – Thesauri für unsere Wissensbestände – das sind die Minimalanforderungen, die wir an eine Software stellen dürfen. Und darunter wollen wir es auch nicht tun.

Literatur Archive Bayerns (2011) Bayerischer Gemeindetag, Bayerischer Städtetag, Bayerischer Landkreistag, Generaldirektion der Staatlichen Archive Bayerns Einheitsaktenplan für die bayerischen Gemeinden und Landratsämter mit Verzeichnis der Aufbewahrungsfristen; Reihe: Staatliche Archive Bayerns – Digitale Medien Nr. 3, Stand vom 1. April 2011. Archive Bayerns, München bitkom (Hrsg) (2014) Im Durchschnitt 18 berufliche E-Mails pro Tag, 11. Juli 2014. https://www. bitkom.org/Presse/Presseinformation/Im-Durchschnitt-18-berufliche-E-Mails-pro-Tag.html

23Ein gutes Beispiel dafür sind die „Arenen“ genannten interdisziplinären Teams im schwedischen Ängelholm. Vgl. Kap. 20 dieses Buchs.

208

W. Steinbrecher

Fischer L, Keith D Swenson, Nathaniel Palmer, Bruce Silver et al (Hrsg) (2016) Taming the unpredictable: real world adaptive case management: case studies and practical guidance. Future Strategies Inc, Florida (2011) Mankins M (2016) Is Technology Really Helping Us Get More Done? in: Harvard Business Review, 25. Februar Miller T (1997) The German Registratur, Dissertation, University of Britisch Columbia (Kanada) Noll F (2018) persönliche Mitteilung an den Verfasser zum Thema “Meilensteine in Vorgängen”, 13. April 2018 Palmer N, Swenson KD, Sinur J, Khoshafian S, Chow L et al (2016) Best Practices for Knowledge Workers: Innovation in Adaptive Case Management. Future Strategies Inc, Florida Sannwald W (2013) Akten- oder Produktplan – ein Plädoyer. Produktorientierte Aktenpläne als „Heilmittel“? PUBLICUS, online-Zeitschrift, Richard Boorberg Verlag, Ausgabe 2013/8. https://publicus.boorberg.de/akten-oder-produktplan-ein-plaedoyer/ spielraum (XING-Plattform) (2015) Bürostatistik: So viele E-Mails sind ganz “normal”, 6. April 2015. https://spielraum.xing.com/2015/04/buerostatistik-so-viele-mail-sind-noch-normal/ Steinbrecher (2007) Produktorientierte Ablage: Optimierung des Dokumentenmanagements in der Kommunalverwaltung. Richard Boorberg Verlag, Stuttgart Steinbrecher W (2014a) Mythos “Workflows” – das ewige (unerfüllte) Versprechen, Blog-Post vom 24.03.2016. http://agile-verwaltung.org/2016/03/24/mythos-workflows-das-ewige-unerfuellte-versprechen/ Steinbrecher W (2014b) Statt Workflow-Mythos: Raus aus den Silos!, Blog-Post vom 22.04.2016 http://agile-verwaltung.org/2016/04/22/statt-workflow-mythos-raus-aus-den-silos/ Steinbrecher W, Müll-Schnurr M (2014) Prozessorientierte Ablage: Dokumentenmanagement-Projekte zum Erfolg führen. Praktischer Leitfaden für die Gestaltung einer modernen Ablagestruktur. ­Springer Gabler, Wiesbaden Swenson KD (2010) Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done. Meghan-Kiffer Press, Florida Wiedemann L, Fritsch G (2014) Organisationshandbuch für bayerische Behörden; Kommentierung der Allgemeinen Geschäftsordnung (AGO)/Informations- und Kommunikationstechnik; Grundwerk mit Ergänzungslieferungen. Carl Link, Kronach

Wolf Steinbrecher  ist Volkswirt und Informatiker. Er war lange als Anwendungsentwickler für medizinische Datenbanken und in Systemhäusern tätig. Von 1995 bis 2008 war er Sachgebietsleiter „Organisation und Controlling“ in einer mittelgroßen Landkreisverwaltung (1050 MA). Aus den dortigen Erfahrungen rührt das Interesse an teamzentrierten, agilen Arbeitsweisen. Ein Resultat davon war die Entwicklung des Prozessorientierten Ablagesystems (PAS), das in diversen Büchern dargestellt wird. Seit 2008 selbstständiger Berater. Mitgründer des Forums Agile Verwaltung e. V.

Agile Organisationsentwicklung mit Scrum

19

Gregor Antochin und Silke Keller

Zusammenfassung

Seit fünf Jahren ist in der Bistumsverwaltung der Diözese Fulda ein Projekt zur Einführung von Dokumentenmanagement aktiv. Dieses Projekt wurde seitens der ­ ­Verantwortlichen von Anfang an als eine Herausforderung und eine Chance zu einer grundlegenden Hinterfragung der eigenen Arbeitskultur begriffen. Wie wollen wir künftig zusammenarbeiten? Wie kann eine Dokumentenmanagement-Software uns dabei unterstützen? Und wie wollen wir im Projekt zusammenarbeiten, sodass möglichst viele Anliegen der Mitarbeiter wie auch der obersten Leitung des Bistums sich Raum ­verschaffen können? Unsere ersten Antworten auf diese Fragen möchten wir hier ­vorstellen.

19.1 Die Rahmenbedingungen des Projekts Im Jahre 2013 beschloss das Generalvikariat der Diözese Fulda, die Einführung eines Dokumentenmanagementsystems (DMS). Das Generalvikariat ist die Verwaltung eines Bistums. Im Kern ist das Generalvikariat eine Verwaltungsorganisation zur Beratung und Aufsicht der Kirchengemeinden sowie weiterer kirchlicher Einrichtungen. Wir finanzieren, organisieren und beaufsichtigen

G. Antochin (*) · S. Keller  Bistum Fulda, Fulda, Deutschland E-Mail: [email protected] S. Keller E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_19

209

210

G. Antochin und S. Keller

­auinvestitionen, unterstützen und überwachen die Haushaltsführung, prüfen und B genehmigen Satzungen und Verträge der Kirchengemeinden. In Fulda arbeiten ca. 140 Mitarbeiter/innen im Generalvikariat. Von ihnen werden 2000 Mitarbeitende in der pastoralen Arbeit (Priester, Pastoral- und Gemeindereferenten, Kirchenmusiker, etc.) betreut. Die Organisation gliedert sich in neun Abteilungen und 13 Stabstellen. Die DMS-Einführung ist für uns ein großes Projekt, das für einen sehr langen Zeithorizont unsere Arbeit verändern soll. Mittlerweile – Ende 2017 – ist eine Software beschafft und installiert, und die ersten Abteilungen arbeiten aktiv damit. Nach und nach werden weitere Abteilungen und deren Prozesse ins DMS aufgenommen. Eine DMS-Einführung ist keine technische Angelegenheit wie die Anschaffung eines neuen Druckers oder die Umstellung von einem E-Mail-Programm auf ein anderes. Mit dem DMS werden nicht die bisherigen Abläufe beibehalten und nur schneller erledigt, sondern unsere Arbeitsmethoden grundlegend geändert. Das hat zur Folge, dass auch eine neue – agile – Vorgehensweise im Projekt angezeigt ist. Von beidem – den neuen Arbeitsweisen, die Ziel des DMS sind, wie auch von der Methode ihrer Einführung im Projekt – soll hier die Rede sein.

19.2 Wissen ist Macht – oder? Als Gregor Antochin Anfang 2015 zum DMS-Projektkoordinator eingesetzt wurde, sprach ihn ein Kollege auf dem Gang an: „Na, mit dem Job machst du dich ja jetzt unersetzlich. Damit ist deine Stellung lebenslang gesichert!“ Das hat uns damals nachdenklich gemacht, und wir überlegten uns, wie wir den Zusammenhang von Wissen und Unersetzbarkeit und Macht definieren könnten. Denn die Frage hat direkt etwas mit unserem Projekt zu tun. Wir kamen zu dem Schluss, dass wir genau das Gegenteil anstreben: • Offenheit und Transparenz statt individuelles Abschotten von „Wissensschätzen“; • Vertretbarkeit statt Unersetzlichkeit • Wissen zugänglich machen, sodass jeder es sich künftig selber beschaffen kann. Das DMS stellt ein Mittel dar, dieses Ziel zu erreichen und Alleinstellungspositionen aufzulösen, statt sie zu verfestigen.

19  Agile Organisationsentwicklung mit Scrum

211

19.3 Die Gesellschaft wird schneller … und wir müssen mithalten Das gesellschaftliche Umfeld, in das die Kirche eingebettet ist und mit dem sie in ständiger Wechselwirkung stehen muss und will, entwickelt sich – und dies mit zunehmender Geschwindigkeit. Sowohl die Geschwindigkeit unseres Lebens, Arbeitens, Kommunizierens nimmt zu – als auch die Geschwindigkeit, mit der sich diese Geschwindigkeit ändert. Das macht das oft Schwindelerregende der Änderungsprozesse aus, in denen wir uns und sie uns bewegen. Es gibt viele Beispiele, wie sich unsere Lebens- und Arbeitsgeschwindigkeiten ­verändert haben: wir gehen schneller, wir sprechen schneller, wir führen Theaterstücke schneller auf als die Menschen vor 50 Jahren.1 Mehr noch aber bewegt uns das Ausmaß gesellschaftlicher Veränderung, mit dem wir konfrontiert sind: die demografischen Veränderungen mit dem höheren Anteil älterer Menschen; die Herausbildung neuer soziografischer „Milieus“, die sich teilweise an die Stelle traditioneller Werthaltungen setzen; die Mitgliederentwicklung der Kirche – all dies sind Fragen, mit denen wir uns im Bistum aktiv und zukunftsorientiert auseinandersetzen. Aber wie tun wir das? Wie können wir unsere Energien aus unproduktiven Abläufen freisetzen für die wirklich wichtigen Sinn- und Zukunftsfragen?

19.4 Zu viel Energie fließt in Zuständigkeitsfragen Auch zusammenhängende Arbeiten werden oft noch nicht zusammenhängend bearbeitet, sondern „nach Zuständigkeit“ auf die verschiedenen Abteilungen verteilt und zeitaufwendig der Reihe nach abgearbeitet. Das macht uns unproduktiver als nötig. Sehen wir als Beispiel den Antrag der (fiktiven) Gemeinde St. Elisabeth zur Genehmigung einer Satzung an. Im Bistum seien dafür drei Abteilungen zuständig. Die Gemeinde stellt den Antrag an die Abteilung 19.1. Diese bearbeitet den Antrag, formuliert ihre Stellungnahme und leitet ihn weiter an Abteilung 19.2 (Abb. 19.1). Von dort wandert der Antrag weiter an Abteilung 3, die sich eine Weile damit aufhält. Inzwischen wundert sich der Pfarrer von St. Elisabeth, was wohl aus seinem Antrag geworden sein könnte. Er ruft an – natürlich bei Abteilung 1, denn dort hat er ja sein Dokument hingeschickt. Abteilung 1 weiß nicht, wo der Antrag ist. Klar ist nur – „wir haben ihn nicht mehr.“ Wer könnte ihn haben? Also ruft Abteilung 1 bei Abteilung 2 und dann bei Abteilung 3 an. Dort wird der Antrag aufgefunden, und von dort kann jemand den Pfarrer benachrichtigen: „Es geht alles seinen richtigen Gang“ (Abb. 19.2). 1Viele

Beispiele dazu finden sich in (Rosa 2005). Sehr illustrativ ist auch das Video (YouTube 2014). Darin wird gezeigt, wie ein Boxenstopp in einem Formel 1-Rennen im Jahre 1950 verlief (1:15 min) und einige Jahrzehnte später, 2013 (5 s).

212

G. Antochin und S. Keller

Abb. 19.1  Ein Antrag geht auf die Reise … Abb. 19.2   … und muss gefunden werden

Nun geht es weiter mit der Antragsbearbeitung. Abteilung 19.3 hat ihre Prüfung abgeschlossen und sendet ihn an die Gemeinde. Die Abteilungen 1 und 2 erhalten Kopien zur Kenntnis und heften diese in „ihrer“ Akte ab (Abb. 19.3).

19  Agile Organisationsentwicklung mit Scrum

213

Abb. 19.3   Lange Durchlaufzeiten und mangelnder Gesamtüberblick kennzeichnen den Arbeitsablauf

Was sind die Merkmale dieser Art zu arbeiten? 1. Die Organisation der Arbeit in Form einer Kette führt zu hohen Durchlaufzeiten. 2. Durch die verteilte Dokumentenablage entstehen drei verschiedene Akten in drei ­verschiedenen Abteilungen, mit Doppelablage vieler Dokumente. 3. Niemand hat während des Vorgangs einen zeitnahen Überblick. 4. Die hohen Durchlaufzeiten führen zu unnötigen Störungen: die Betroffenen werden ungeduldig, rufen mit Bitte um Auskunft an – die Beantwortung ist aufwendig und vor allem: komplett vermeidbar. 5. Werden abgeschlossene Vorgänge ans Bistumsarchiv abgegeben, dann bestehen sie oft aus verteilten Akten, deren Zusammenhang kaum ersichtlich und von denen keine vollständig ist. Klar war den Beteiligten: So wollen und können wir nicht weiterarbeiten. Die Verschwendung an Personalkapazitäten ist viel zu hoch, und die Betroffenen in den Kirchengemeinden ­werden nicht gut genug „bedient“. Klar war aber auch: Ein Dokumentenmanagementsystem kann nicht bedeuten, diese Arbeitsweise einfach vom Papier auf elektronische Dokumente umzustellen – sodass es dann drei elektronische Akten gibt statt dreier Papierakten. Sondern die Arbeitsweise selbst musste auf den Prüfstand kommen.

214

G. Antochin und S. Keller

19.5 Zu viel Energie fließt in Koordination Dass E-Mail-Kommunikation in der jetzigen Form auch nicht der Weisheit letzter Schluss ist, zeigt das folgende kleine Schauspiel (Abb. 19.4) mit dem Titel „Eine E-Mail-Flut morgens um 9“. Es ist 9 Uhr am Morgen, Herr Ahrendt hat gerade seinen Rechner hochgefahren und merkt: er braucht dringend die aktuelle Version einer Tabelle. Im Laufwerk seiner Abteilung liegt sie nicht – wer könnte sie haben? Also schreibt er eine E-Mail an zwei Kollegen, die die Datei haben könnten (Abb. 19.5). Die eine Kollegin, Frau Bittmann, antwortet prompt, aber sie muss ihn enttäuschen: sie hat die Tabelle auch nicht. Der andere Kollege antwortet nicht sofort: er ist in einer Besprechung und liest die E-Mail erst um 11 Uhr. Aber er hat die Tabelle und schickt sie Herrn Ahrendt zu und vorsichtshalber auch Frau Bittmann – man weiß ja nie, wer sie noch brauchen könnte (Abb. 19.6). Und beide, Frau Bittmann und Herr Ahrendt, speichern die Tabelle auf ihren jeweiligen Abteilungslaufwerken ab. Resultat der Anfrage: aus einer harmlosen Anfrage wurden 9 E-Mails, 3 Kopien der gesuchten Datei, 2 h Wartezeit für den Anfragenden und mindestens 6 Unterbrechungen des Arbeitsablaufs für die beteiligten Kollegen, bei denen eine E-Mail auftaucht und „ganz schnell“ bearbeitet werden soll. Es sind vor allem diese Unterbrechungen, die uns Stress bereiten und uns am ­produktiven Arbeiten „im Fluss“ hindern.

Abb. 19.4  Um 9 Uhr hat Herr Ahrendt einen Wunsch

19  Agile Organisationsentwicklung mit Scrum

Abb. 19.5  Frau Bittmann antwortet 5 min später

Abb. 19.6  Herr Cramer kann den Wunsch erfüllen – aber erst zwei Stunden später

215

216

G. Antochin und S. Keller

19.6 Unsere Ziele Aus der Analyse der künftigen Herausforderungen wie auch unserer bestehenden ­Verbesserungspotenziale haben sich für uns in den vorbereitenden Diskussionen drei große Zielvorstellungen herausgeschält: 1. Wir wollen besser zusammenarbeiten. Das heißt, wir wollen die unproduktive Energie, die noch in unsere Selbstbeschäftigung fließt, wieder für produktive Zwecke freisetzen. Das heißt letztlich für die Gemeinden und die Gemeindemitglieder. Das Dokumentenmanagementsystem ist dafür ein Mittel, es ist kein Selbstzweck. Es soll uns eine Plattform bieten, auf der wir eine bessere, weniger aufgeblähte, weniger komplizierte Zusammenarbeit organisieren können. Aber um dieses „Besser“ zu erreichen, müssen Menschen lernen, sich anders zu verhalten – das kann uns keine Software abnehmen. 3. Wir wollen aus Fehlern lernen. Den Mitarbeitenden in der Bistumsverwaltung soll das DMS nicht von oben übergestülpt werden. Ein Vorgehen im Projekt, bei dem die Mitarbeiter nach einer kurzen Schulung das DMS anwenden müssten ohne Möglichkeit eigener Einflussnahme – letztlich nach dem Prinzip „friss oder stirb“ – kann hier nicht erfolgreich sein. Vielmehr muss die neue Software Hand in Hand zusammen mit den neuen angestrebten Zusammenarbeitsmethoden eingeführt werden. Abteilung für Abteilung und Prozess für Prozess werden durch die Betroffenen strukturiert (wenn nötig: umstrukturiert) und sofort anschließend im DMS in Betrieb genommen. 5. Wir wollen effektiver werden. In die DMS-Einführung müssen die jeweiligen Anwender einbezogen werden. Andererseits ist das für sie ein Aufwand, den sie neben ihrer Routinearbeit bewältigen müssen. Die neuen agilen Methoden wie Scrum erlauben es, auch dann merkliche Fortschritte im Projekt zu erzielen, wenn die Zeitressourcen knapp sind.

19.7 Kleine Ziele – viele Erfolgserlebnisse mit Scrum Die Ziele, die wir mit dem Dokumentenmanagement verbinden, wollten wir im Projekt selbst auch schon in die Praxis umsetzen. Das heißt, abteilungsübergreifende Zusammenarbeit statt Aufteilung in einzelne Zuständigkeiten. Und das heißt auch: möglichst kurze Durchlaufzeiten im Projekt, sodass die Anwender schnell in den Genuss von ­Verbesserungen kommen. Deshalb entschieden für uns für Scrum. Scrum ist ein Vorgehensmodell des ­Projektund Produktmanagements und ist insbesondere ein Vorgehensmodell zur agilen Softwareentwicklung. Scrum wurde ursprünglich in der Softwaretechnik entwickelt, ­ ist aber davon unabhängig und wird inzwischen in vielen anderen Domänen eingesetzt (Abb. 19.7).

19  Agile Organisationsentwicklung mit Scrum

217

Abb. 19.7  Scrum arbeitet in kurzen Zyklen von 2–3 Wochen, sog. „Sprints“

Die Produktbeschaffung lief dabei ganz klassisch ab – mit Lastenheft, Ausschreibung, Bietervorauswahl, Bieterpräsentationen und Auftragserteilung. Dann aber, in der Einführungsphase (die bis heute nicht abgeschlossen ist), begann Scrum zu greifen. Das Besondere an dieser Methode ist das Arbeiten in „Sprints“. In unserem Projekt haben wir uns auf eine Sprintlänge von drei Wochen geeinigt. Alle drei Wochen findet ein Sprintmeeting statt, in dem die Ergebnisse des vorherigen Sprints begutachtet wird. Dieses Ergebnis soll schon praktisch einsetzbar sein. Das heißt, schon nach den ersten drei Wochen wurde ein Prozess des Seelsorgeamtes „Neustrukturierung von Pfarreien“ in einer ersten Basisversion in die Praxis überführt. Die ersten MitarbeiterInnen wurden im DMS geschult und fingen an, damit zu arbeiten (Abb. 19.8).

19.8 Herausforderungen und Erfolge der neuen Arbeitsmethode Die neue Projektmethode hat für uns in der Bistumsverwaltung einen Experimentierstatus. Scrum ist keine neue verbindliche Regelung, sondern wird selbst ständig auf den Prüfstand gestellt. Immer wieder schauen wir gemeinsam auf diejenigen Abläufe im Projekt, die noch nicht so gut klappen, und bemühen uns um Verbesserungen. Eine Charakteristik von Scrum besteht darin, dass die starren Organisationsstrukturen aufgelockert werden sollen. Das betrifft sowohl die Zusammenarbeit zwischen den Abteilungen als auch zwischen verschiedenen Hierarchieebenen. Das Umsetzungsteam strebt ein „Arbeiten ohne Schulterklappen“ an. Gleichzeitig besteht es aus unterschiedlichen hierarchischen Schichten. Manche Mitarbeiter sind es

218

G. Antochin und S. Keller

Abb. 19.8  In jedem Sprint wird ein weiterer Baustein zum Gesamtprodukt „DMS“ fertiggestellt

nicht gewohnt, eigene Vorschläge selbstbewusst vorzutragen, wenn ein Vorgesetzter oder Vorgesetzter des Vorgesetzten an der Sitzung teilnimmt. Umgekehrt verharren manche Vorgesetzte noch in der Rolle des „besseren Sachbearbeiters“ und meinen, auch jede fachliche Entscheidung am besten selbst treffen zu können. So begegnen sich die Mitglieder des Projektteams in neuen Rollen, die es einzuüben gilt. Vielleicht ist ja dies die wichtigste Neuerung in unserem Projekt: dass wir lernen, dass wir lernen dürfen und das heißt: aus Fehlern lernen dürfen.

Literatur Rosa H (2005) Beschleunigung. Die Veränderung der Zeitstrukturen in der Moderne. Suhrkamp, Berlin YouTube (2014) Formula 1 Pit Stops 1950 Indianapolis 500 & 2013 Melbourne. https://www.youtube.com/watch?v=JOq-5D4gm0U

19  Agile Organisationsentwicklung mit Scrum

219

Gregor Antochin ist Projektkoordinator und SCRUM Product Owner im Bischöflichen Generalvikariat Fulda. Er machte von 2006 bis 2009 eine Ausbildung zum Verwaltungsfachangestellten in dieser Behörde. Von 2009 bis 2015 war er in unterschiedlichen Abteilungen des Generalvikariates eingesetzt. Seit April 2015 ist Gregor Antochin mit der Koordination der Einführung eines Dokumentenmanagementsystems betraut. Er erarbeitete mit einem selbstorganisierendem Team von 6 Personen die Anforderungen für das Dokumentenmanagementsystem und führt mit SCRUM Sprints das System in der ganzen Verwaltung ein.

Silke Keller ist Ltd. Rechtsdirektorin im Bischöflichen Generalvikariat Fulda. Sie ist dort unter anderem als Projektleiterin für die Einführung eines Dokumentenmanagementsystems (DMS) mit der SCRUM-Methode verantwortlich. Silke Keller hat in Marburg/Lahn Rechtswissenschaften studiert. Nach dem Referendariat am Landgericht Gießen war sie von 2000 bis 2011 zunächst in Düsseldorf und dann in Berlin als juristische Referentin bei der Wirtschaftsprüferkammer beschäftigt. Seit 2012 ist sie für das Bistum Fulda tätig.

Agilisierung einer kommunalen Verwaltung – das Beispiel Ängelholm (Schweden)

20

Wolf Steinbrecher

Zusammenfassung

Im April 2017 besuchte eine Delegation des Forums Agile Verwaltung die Stadt Ängelholm. Wir hatten einfach europaweit nach „agiler Verwaltung“ gegoogelt und waren so auf die „Första agile kommun i Sverige“ – die erste agile Kommune Schwedens gestoßen. Was haben wir von unserer Forschungsreise mit zurück nach Deutschland genommen? Die Koffer waren voller Inspiration, der Bestätigung, dass Agilität auch in einer Stadtverwaltung funktionieren kann, dass dies hoch motivierte Mitarbeiter hält und erzeugt, die die unterschiedlichsten Bürgeranliegen als ­lösbare Herausforderungen sehen und gemeinsam angehen. Vielleicht gelingt es mir, in ­meinem Bericht eine Ahnung davon zu vermitteln.

20.1 Ängelholm und seine neue Aufbauorganisation Ängelholm ist eine kleine Stadt am Meer im Südwesten Schwedens. Sie ist eine von 259 schwedischen Gemeinden und hat etwas mehr als 41.000 Einwohner. Die Stadt hat gerade ihr 500-jähriges Bestehen gefeiert und war früher vor allem für handwerkliche Keramik- und Lederprodukte bekannt.

W. Steinbrecher (*)  Common Sense Team GmbH, Forum Agile Verwaltung e. V., Karlsruhe, Baden-Württemberg, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_20

221

222

W. Steinbrecher

Die Stadtverwaltung beschäftigt 3000 Mitarbeiter1. Im Jahre 2013 startete sie ein großes Organisationsentwicklungsprojekt, das darauf ausgerichtet war, demokratische Arbeitsmethoden zu befördern und die Bedürfnisse der Bürger an guten städtischen Dienstleistungen besser zu befriedigen. Jetzt, fünf Jahre später, ist die Verwaltung stolz darauf, sich von einer traditionellen Behörde mit vielen Funktionsbereichen und Silos in eine flexible Organisation „für Entwicklung und Dienstleistung“ transformiert zu haben, für die der Bürger immer im Fokus steht. Seit dem 1. Januar 2015 gilt in Ängelholm eine neue Aufbauorganisation (Abb. 20.1). Als Projektziele waren definiert worden: 1. Klare Ausrichtung auf die Bürger. Auf der Basis von politisch definierten Zielen und Vorgaben, soll ein immer besseres Serviceniveau für die Bürger erreicht werden. 2. Verbesserte Zusammenarbeit und gegenseitige Achtsamkeit. Die vielfältigen Fähigkeiten der Mitarbeiter wurden durch Ermutigung zu kooperativen Verhaltensweisen und zu agilen Arbeitsmethoden besser zur produktiven Anwendung gebracht. 3. Hohe Beteiligung der Mitarbeiter an der Prozessgestaltung. Die Aufbauorganisation wurde entlang der Prozesse völlig neugestaltet. Die Ängelholmer Verwaltung hat drei Arten von Kernprozessen identifiziert, denen jeweils eine in einem zentralen Dezernat2 erbracht wird: • Bildung und Familie • Gesundheit • Gesellschaft und Entwicklung. Der Bereich „Bildung und Familie“ umfasst Leistungsangebote wie Kinderbetreuung, Schulen, Erwachsenenbildung, Unterstützung für Behinderte und andere Bedarfsfälle. Dieses Dezernat beschäftigt mehr als die Hälfte der Angestellten. Das Dezernat „Gesundheit“ versorgt vor allem die Älteren mit Unterstützung und Pflege. „Gesellschaft und Entwicklung“ ist etwas heterogener zusammengesetzt. Das Dezernat ist verantwortlich für den Straßenunterhalt, die ökologische Abfallentsorgung. Und es unterhält zentrale Einrichtungen wie Sportplätze oder Sportwege in den Wäldern. Daneben unterhält es Bibliotheken und Erholungszentren3.

1Viele Dienstleistungen, die in Deutschland von freigemeinnützigen Organisationen erbracht werden, insbesondere im Pflegebereich, sind in Schweden kommunale Aufgaben. Dies erklärt weitgehend den – im Verhältnis zur Einwohnerzahl – großen Anteil der Beschäftigten im Öffentlichen Dienst. Vgl. Wollmann (2008a, b). 2Wir haben das schwedische Wort Huvudsuppdrag mit Dezernat übersetzt. 3Vgl. Ängelholms kommun (2015, 2016).

20  Agilisierung einer kommunalen Verwaltung …

223

Abb. 20.1  Die prozessorientierte Aufbauorganisation

Diese Dezernate mit ihren Kernprozessen sind in den drei Hauptsektoren der G ­ rafik als Kuchenstücke angeordnet. Darum herum stehen als breiter dunkler Rahmen die Unterstützungsprozesse Personal, Finanzen und Kommunikation. Es gibt einen weiteren Unterschied zum klassischen Verwaltungsaufbau, der in der Abb. 20.1 durch eine Reihe von Kreisen dargestellt wird, die wie ein Kranz die Kernverwaltung umgeben: Das sind die vielen Externen – seien es kommunale Eigenbetriebe, Bürger, Unternehmen, andere Behörden, Vereine und Verbände, soziale Gruppen usw. –, die systematisch an der Lösung vieler Aufgaben beteiligt werden. In der Mitte der Führungsauftrag. Eingebettet sind die nach Bedarf gebildeten ­Arenen. Im grauen Kreis „Servicestöd“ = Unterstützungsprozesse.

224

W. Steinbrecher

Abb. 20.2  Die Gestalt einer Arena. (Nach einer Darstellung von S. Glantz und Malin Thorsén)

20.2 Die „Arenen“ – Kernstück der agilen Arbeitsweisen 20.2.1 Definition einer Arena Die „Arenen“ sind das, was als erstes ins Auge sticht und was auch die Ängelholmer als besonders innovativ an ihrem Modell hervorheben. Eine Arena ist eine temporäre Arbeitsgruppe, die ein bestimmtes, konkretes Problem eines Bürgers oder einer Gruppe von Bürgern lösen soll (Abb. 20.2).4 Eine Arena ist ein cross-funktionales Team mit einer konkreten Aufgabe und einer begrenzten Zeitressource. Es setzt sich aus verschiedenen Fachleuten zusammen, die gemeinsam alle nötigen Kompetenzen mitbringen, um Lösungen für die Aufgabe zu ­finden. Das heißt, die Arena hat zwei Arten von Kompetenzen: 1. die fachlichen Kenntnisse, um tragfähige Lösungen zu finden; 2. die Entscheidungskompetenzen, um sich verbindlich auf eine der möglichen ­Lösungen zu verständigen.

4Wo

der Begriff Arena herstammt, konnte uns keiner so genau sagen. Er war auf einmal da.

20  Agilisierung einer kommunalen Verwaltung …

225

20.2.2 Bedingungen für die Bildung einer Arena Eine Arena wird auf Antrag eines Mitarbeiters gebildet. Dafür müssen drei Grundbedingungen erfüllt sein: 1. Bürgerbedürfnis. Arenen werden nicht für interne Organisationsaufgaben gebildet, sondern nur im ­Rahmen der Kernprozesse. Bedingung ist, dass die Organisation ein Problem gemeldet hat („Signal“), das das einzelne Sachgebiet/Abteilung nicht alleine lösen kann. 2. Kooperation Es besteht die Notwendigkeit für eine kooperativere Herangehensweise als üblich, um das Problem im Dienste der Bürger zu lösen. 3. Überschaubarer Zeitraum Das Problem muss voraussichtlich in 3–5 Arena-Treffen lösbar sein. Sind diese Bedingungen erfüllt und ist die Entscheidung zur Einrichtung einer Arena getroffen, so wird das Arena-Team gebildet. Es kann sich aus Mitarbeitern verschiedener Dezernate der Verwaltung, aber bei Bedarf auch aus externen Experten oder den betroffenen Bürgern selbst zusammensetzen. Die herkömmliche Arbeit in Silos und Workflows innerhalb der Verwaltung, aber auch in „innen“ und „außen“ wird in den Arenen überwunden. Jede Arena wird von zwei Prozesssteuerern geleitet. Von diesen gibt es derzeit 15 in der Verwaltung, die diese Tätigkeit neben ihrer normalen, routinemäßigen Sachbearbeitung wahrnehmen. Die Ängelholmer Arenen sind ein schönes Beispiel dafür, wie die aus Scrum bekannte Philosophie der cross-funktionalen Teams in die Verwaltungspraxis übersetzt werden kann.

20.3 Beispiele für Arenen 20.3.1 Ibrahim5 Ibrahim, 18 Jahre, ist vor kurzem als Asylberechtigter in Schweden anerkannt ­worden und lebt in Strövelstorp, einem Gemeindeteil von Ängelholm. Ibrahim will schnell eine Arbeit finden und braucht dringend schwedische Landeskunde, Beratung, soziale ­Vernetzung und Krisenunterstützung.

5Dieses

und die beiden folgenden Beispiele sind dem Bericht Wahl und Skantze (2014), S. 42–44, entnommen.

226

W. Steinbrecher

Um diesen verschiedenen Bedürfnisse Imbrahims nachzukommen, bildet die Verwaltung eine Arena, die unter anderem Fachkräfte aus den folgenden Bereichen abdeckt: • Unternehmen • Vereinsleben • Arbeitsvermittlung • Erwachsenenbildung • Berufs- und Studienberatung • Dolmetscher • Kultur und Freizeit. Und, ganz wichtig: Ibrahim selbst. Der Betroffene ist nicht „der Problemfall“, sondern Teil der Lösung.

20.3.2 Viktor Der 12jährige Viktor hat einen drogenabhängigen Papa. Viktors Eltern sind geschieden, und er wohnt in Ängelholm mit seiner Mutter und seinem kleinen Bruder. Viktor liegt in der Schule weit zurück. Er hat angefangen zu rauchen und Alkohol zu trinken, und hat Schwierigkeiten, bei seinen Schulkameraden Anschluss zu finden. Viktors Mutter ist sehr besorgt um Viktor und hat selbst angefangen, Alkohol zu trinken, um ihre Angst zu dämpfen. Um Viktors verschiedenen Bedürfnissen nachzukommen, bildet die Gemeinde eine agile Arena, die beispielsweise folgende Kompetenzen umfasst: • Schule • Sozialdienst • Kinder- und Jugendpsychiatrie • Freizeit/Kultur • Familienunterstützung (für die Mutter) • Sozialversicherung • Pflegedienst • Arbeitgeber.

20.3.3 Familie Svensson Die Familie Svensson war gerade mit der Hoffnung aus Stockholm nach Ängelholm umgezogen, um dort ein neues Leben beginnen zu können. Die Familie hatte ein Baugrundstück in Hjärnarp gekauft, einem Dorf, das zur Gemeinde Ängelholm gehört. Aber es stellte sich heraus, dass der Bebauungsplan des Bezirks in Überarbeitung ist und dass

20  Agilisierung einer kommunalen Verwaltung …

227

keine Baugenehmigung erteilt werden konnte, solange der Plan nicht verabschiedet ist. Das konnte mehrere Jahre dauern. Dieser Bescheid traf die Familie hart, die nur provisorisch bei der Mutter der Ehefrau, Greta, wohnte. Die Tochter der Familie zeigte wieder Anorexie-Symptome, und der Vater entwickelte eine Spielsucht. Um Antworten auf die verschiedenen Bedürfnisse der Familie Svensson zu finden, richtete die Verwaltung eine Arena ein, mit unter anderem folgenden Funktionen: • Kompetenzen rund um das Baugrundstück – Boden und Erschließung – Grundstücks- und Planungsberatung – Umweltinspektion – Straßenbau – andere Grundstückseigentümer • Kompetenzen rund um die Familie – Sonderpädagoge – Schulschwester – Spezialist für Anorexie und Spielsucht

20.3.4 Verkehrsbelastung vor einer Schule6 Ein weiteres Beispiel für den Einsatz von Arenen war die Aufgabe, Lösungen für die ­Verkehrssituationen vor Schulen zu Unterrichtsbeginn und Unterrichtsende zu finden. Die Verhältnisse am Morgen, wenn die Schüler zur Schule kommen, waren nicht optimal. Eltern bringen ihre Kinder mit dem Auto, andere Schüler steigen aus Schulbussen aus und zur gleichen Zeit kommen Kinder und Jugendliche zu Fuß oder mit dem Fahrrad. Das alles in einem engen Zeitintervall, wenn Fahrzeuge und ungeschützte Kinder sich den gleichen Verkehrsraum teilen müssen, was ein erhöhtes Unfallrisiko bedeutet. In die Arena mussten alle Betroffenen einbezogen werden: Schüler, Eltern, Sicherheitsdienst, die Busgesellschaft und Grundstückseigentümer. Die Prozesssteuerer luden Vertreter aller dieser Gruppen und von den zwei Dezernaten „Gesellschaft“ und „Bildung“ ein. Es fanden vier Arenatreffen statt. Die Schüler, Eltern und die Vertreter der Schulverwaltung diskutierten über Verkehrsverhalten und erarbeiteten praktische Lösungen mit der Busgesellschaft, den Sicherheitsleuten und den Grundstückseigentümern. Zum Schluss präsentierten sie einen gemeinsamen Vorschlag für eine Lösung, die die Sicherheit der Kinder in den Mittelpunkt stellt und gleichzeitig keinen sehr hohen finanziellen Aufwand erfordert.

6Dieses

und das folgende Beispiel entstammen dem Vortrag Glantz und Thorsén (2018).

228

W. Steinbrecher

20.3.5 Bürgerzugang zu Geodaten Es gab die Idee, Bürgern und Unternehmen verbesserten Zugang zu den geografischen Informationen, die von der Stadtverwaltung produziert werden, bereitzustellen. Es wurde eine Arena mit der Zielsetzung ins Leben gerufen, ein Forum zu bilden, in dem ein 3D-Modell der Stadt Ängelholm entwickelt werden sollte, finanziert durch die Stadt und die lokale Geschäftswelt. In diese Arena wurden Grundstückeigentümer in der Stadt, Architekten, ­IT-Unternehmen und Schulen einbezogen. Die Arena verwandelte sich in ein Entwicklungsprojekt. Eine Anzahl von Studenten wurde von einem privaten Architekten eingestellt, um die Arbeit an der 3D-Modellierung Ängelholms voranzubringen. Schließlich wurde daraus ein kontinuierliches Projekt „die Stadt Ängelholm in 3D-Modellen“.

20.4 Verzahnung von traditioneller Sachbearbeitung und agilen Arbeitsweisen 20.4.1 Vorsichtige Agilisierung Die Ziele, die ganz am Anfang des Transformationsprojekts definiert wurden, machten deutlich: Es ging der Ängelholmer Verwaltung nicht darum, „Agilität aus Prinzip“ einzuführen. Sondern im Fokus stand eine bessere Dienstleistungsqualität für die Einwohner der Stadt. Und auf dieses Ziel hin wurde der agile Methodenkoffer durchforstet, welche Ideen und Werkzeuge für eine Stadtverwaltung wie Ängelholm (ca. 3000 Mitarbeiter) angemessen sein könnten (Abb. 20.3). Deshalb stand am Anfang des Projekts auch nicht die Einrichtung von Arenen, sondern der Aufbau eines Servicecenters. Es ist ein Callcenter, bei dem alle Erstkontakte der Bürger aufschlagen (Ängelholm hat nur eine einzige Telefonnummer). Es ist von der Idee her am ehesten einem deutschen „Bürgerbüro“ vergleichbar, stellt aber quantitativ eine ganz andere Dimension dar: im Service-Center arbeiten ca. 60 Mitarbeiter in zwei Staffeln. Die erste Staffel nimmt die Anrufe entgegen und versucht, einfache Anliegen sofort zu erledigen. Etwas komplexere Anfragen werden an die zweite Staffel, das BackOffice, vermittelt, die mit sehr qualifizierten Fachkräften besetzt ist, die Abb. 20.3   Die traditionelle Sachbearbeitung wird nicht aufgehoben, sondern bedarfsweise durch agile Methoden ergänzt

20  Agilisierung einer kommunalen Verwaltung …

229

sich um eine Lösung kümmern. 70 % aller Bürgerkontakte werden vom Service-Center abschließend erledigt. Das Service-Center hält den Sachbearbeitern im „traditionellen“ Bereich den Rücken frei. Sie sind für die normale Antragsbearbeitung zuständig. Die Aufbauorganisation ist prozessorientiert (drei Gruppen von Kernprozessen und eine Gruppe von Unterstützungsprozessen), aber unterscheidet sich – soweit wir es beurteilen konnten – nicht wesentlich von einer deutschen Kommunalverwaltung. Abb. 20.3 stellt diese Aufbauorganisation als Pyramide dar, und in ihr bilden die ­Arenen die relativ kleine Spitze. Das ist der eigentlich agile Teil.

20.4.2 Das Arena-„Signal“ Eine Inflation von Arenen ist nicht gewünscht. Vielmehr soll die Anzahl der Arenen jetzt, in der immer noch andauernden Erprobungsphase der neuen agilen Methoden, gering bleiben, sodass ausreichend Zeit zur kontinuierlichen Erfahrungsauswertung bleibt (Abb. 20.4). Deshalb ist der Prozess der Einrichtung und Durchführung einer Arena strikt ­standardisiert. Eine Arena – wir hatten es oben schon erwähnt – beginnt immer damit, dass ein Sachbearbeiter einen Bedarf anmeldet. Dieses „Signal“ geht bei einer speziellen Stelle ein, die „Signalkoordination“ genannt wird. Diese identifiziert einen betroffenen Funktionsbereich:

Abb. 20.4  Der Ablauf zum Einrichten einer Arena ist genau definiert

230

W. Steinbrecher

• Das ist entweder ein einzelnes Dezernat. In diesem Fall wird die jeweilige Bereichsleitung (Assistenz und Dezernatsleitung) informiert, die inhaltlich beurteilen kann, ob es sich um eine potenzielle „Arenaangelegenheit“ handelt. • Oder es ist von vornherein klar, dass mehrere Dezernate betroffen sind (wie z. B. oben im Fall der „Familie Svensson“, bei dem das Dezernat „Bildung und Familie“ und das Dezernat „Gesellschaft“ einbezogen werden mussten). Dann geht das Signal weiter an den obersten Leitungskreis. Diese fachlich kompetenten Führungskräfte entscheiden dann jeweils, ob eine Arena eingerichtet wird oder nicht. Es werden zwei Prozesssteuerer mit der Moderation ­ ­beauftragt, und die Arena kann starten. Die Lösungsansätze der Arena sowie ihre Ergebnisse nach Umsetzung in die ­Praxis werden in einer Erfahrungsdatenbank gesammelt. Sie soll die Transparenz und das ­Lernen für künftige Fälle gewährleisten. Ihre Struktur befindet sich noch im Aufbau.

20.4.3 Was ist anders? Rein quantitativ ist es vermutlich nur der Bruchteil eines Prozents der Bürgeranliegen, die das Arenaverfahren durchlaufen. Und man kann das Vorgehen der Ängelholmer Stadtverwaltung nur als umsichtig tastend beschreiben. Aber diese kleine Fallzahl hat bei sehr vielen Mitarbeitern einen Umschwung im Denken bewirkt. Eine Besonderheit ist die Qualitätsorientierung und der Fokus auf Leistungsmessung. Das Ziel ist z. B., die Durchlaufzeiten zu minimieren und gleichzeitig die Qualität des persönlichen Umgangs mit den Bürgern zu steigern. Das Servicezentrum beispielsweise ist damit Spezialist für die stark strukturierten Prozesse und arbeitet aktiv in einem ständigen Verbesserungsprozess an der Erarbeitung von Checklisten, Standards und der Wissensausweitung der Mitarbeiter. Herkömmliche Verwaltungsarbeit wird am liebsten als Kette gedacht, bei der Glied für Glied abgearbeitet wird. Wenn mehrere Sachbearbeiter beteiligt sind, arbeiten sie nacheinander – nie gleichzeitig an einem Kettenglied. Zusammenarbeit ist überflüssig, sie gilt als Verschwendung.7 Diese herkömmliche Arbeitsweise in der Sachbearbeitung existiert auch noch in Ängelholm – aber nur dort, wo sie noch sinnvoll ist. Und sie gilt nicht mehr unhinterfragt. Sie stellt nicht mehr das einzig denkbare Modell der Fallbearbeitung dar – es gibt eine Alternative. Auf einmal müssen sich beide Arbeitsweisen – die traditionelle wie die agile – vor der jeweils anderen rechtfertigen: „Wo führe ich zu ordentlichen Resultaten – und wo nicht?“ Und im gleichen Zug wird über die operative Arbeit und das operative

7Siehe im Kap. 3 dieses Buchs den Abschnitt „Die Möglichkeit agiler Verwaltung in schwach strukturierten Prozessen“ und das dort geschilderte Beispiel einer Windpark-Genehmigung.

20  Agilisierung einer kommunalen Verwaltung …

231

Denken eine weitere Ebene eingezogen, ein Oberhaus gewissermaßen. Dort wird über die operative Ebene nachgedacht und entschieden. Die einfache Änderung, dass zum herkömmlichen Arbeitsmodell ein zweites hinzugetreten ist, bringt auf einmal einen Spiegel hervor, in dem ich als Sachbearbeiter meine Arbeit reflektiere. Welche Methode ist für einen konkreten Fall die bessere – traditionell oder Arena? Diese Frage mussten sich die Mitarbeiter vorher nie stellen, weil alles einfach Herkömmliches war. Diese neue Konstellation der Bespiegelung des eigenen Tuns stellt einen sehr wichtigen Teil der Selbstorganisation dar. Und dabei können die Beteiligten eigene Gestaltungskraft erleben. Die Energie, die sie in die Transitionsprojekte stecken, kommt vielfach zurück. Damit können sie auf ein Level kommen, auch von Good Practices anderer lernen zu wollen. Die Professionalität der Projektführer in Ängelholm zeigt sich auch in ihrem Wissen um die eigenen Grenzen. Das ist überhaupt das wichtigste Zeichen von Professionalität – wissen, was man nicht kann. Deshalb gehen die Mitglieder der Steuerungsgruppe auf Konferenzen und lesen Bücher, kooperieren mit Hochschulen – und holen Spezialisten ins Haus.

20.5 Werte und Haltungen 20.5.1 Immer besser werden im Dienste der Bürger Die Mitarbeiter werden kontinuierlich an der Strategieentwicklung beteiligt. Nicht nur 1 % Führungskräfte müssen die Entwicklungen beobachten, die sich in der Kommune tun, sondern 90 oder 100 % der Beschäftigten. Ohne dieses aktive Herauskitzeln der Schwarmintelligenz können komplexe Entwicklungen nicht schnell und vielsichtig genug wahrgenommen werden. In ihrer Keynote vor der Konferenz „Agile Verwaltung 2018“ in Stuttgart im Februar 2018 haben Sofia Glantz und Malin Thorsén – zwei Projektsteuerinnen aus Ängelholm – diese Haltung folgendermaßen gekennzeichnet: We want to be an organization that provides our professional staff with the opportunity to meet the citizen’s needs. We need to have eyes for changes in the outside world and not only for our own organisation. We need to be curious about all the different parts of the society. Our employees should be given the opportunity to think new and try new things. And it is also important that old long experience meet up with new diversity.

Das bedeutet, eine neue Kultur der Aufmerksamkeit und Achtsamkeit – und die hat Ängelholm mit seinen vielen Workshops und Debatten im Projekt angestoßen und entwickelt. Dann tritt an die Stelle des selektiven Tunnelblicks („dafür bin ich nicht zuständig!“) die 360-Grad-Rundum-Neugier.

232

W. Steinbrecher

20.5.2 Vertrauensbasierte Führung Ängelholm orientiert sich eng an den Ergebnissen einer Untersuchung, die die schwedische Regierung über vertrauensbasierte Führung erarbeiten ließ. Dazu gibt es weitere Pilotprojekte und Forschungsstudien in Schweden. Die Effizienz von Organisationen hängt zum immer größeren Ausmaß davon ab, in welchem Maße sie ihren fachlich qualifizierten Mitarbeitern vertrauen, ihre eigene Arbeit gut zu steuern und auszuführen. Die Ängelholmer Verwaltung verfolgt das Ziel, ­wegzukommen von einem eng verstandenen Controlling und Berichtswesen hin zu einer Führungskultur, die die Mitarbeiter als motivierte und fähige Menschen betrachtet, die keines Drucks von außen oder oben bedürfen (Abb. 20.5).

20.5.3 Das Ganze in den Blick nehmen Dazu gehört auch, alle Mitarbeiter ständig zu ermutigen, einen „Blick über den Tellerrand“ zu wagen. Wir lassen noch einmal Sofia Glantz und Malin Thorsén zu Wort kommen: The meaning of a holistic and comprehensive view: Avoid dive pipes, encourage different parts to interact. In order to do that we need common goals, show each other mutual respect, share important information, trust that everyone is doing their best. For that reason we have chosen in Ängelholm to work with the „Agile Arenas.“

Abb. 20.5  Agil.Zusammen.Arbeiten

20  Agilisierung einer kommunalen Verwaltung …

233

Die Arenen sind nicht einfach ein effizientere Meetingmethode, sondern Ausdruck eines agilen „Mindsets“. Und nur dann funktionieren sie auch.

20.6 Und wie haben sie’s geschafft? 20.6.1 Zwei Jahre Workshops Anfangs haben sich die Beteiligten, begleitet durch ein schwedisches Beratungshaus – Advisory Board – sehr auf die Techniken und Methoden sowie auf die zu ändernden Prozesse gestürzt, um schnell festzustellen, dass sie die Menschen nicht vergessen dürfen. Der kulturelle Wandel wurde stark in den Fokus gestellt und in 115 Workshops daran gearbeitet, wie man zusammenarbeiten möchte, um das Bürgeranliegen in den Mittelpunkt der zukünftigen Ausrichtung zu stellen. Eine agile Organisation zu schaffen, erfordert umfassende Kenntnisse darüber, was agile Methoden und Haltungen in der täglichen operativen Arbeit bedeuten. Ängelholm ist es gelungen, mehr als 8 Mio. schwedische Kronen (rd. 780.000 EUR) an ESFMitteln8 einzuwerben, um Führungskräfte und Beschäftigte dahin gehend auszubilden. Allein im Jahre 2016 wurden 115 verschiedene Workshops durchgeführt, an denen über 3000 Mitarbeiter teilnahmen und die 4000 verschiedene Verbesserungsvorschläge generierten. In 2017 wurden alle Führungskräfte und Mitarbeiter in agilen Arbeitsweisen und Haltungen, in Techniken zur Selbstentwicklung und Prinzipien der Zusammenarbeit auf Augenhöhe – z. B. Gleichberechtigung der Geschlechter, Barrierefreiheit, Nichtdiskriminierung sowie ökologisch nachhaltige Entwicklung – geschult. Der Erfolg dieses Vorgehens: nur 10 der 3000 Mitarbeiter haben aufgrund der Neustrukturierung die Organisation verlassen. Dafür erhält Ängelholm in den letzten drei Jahren viele neue Bewerbungen, auch von Bewerbern, die von weit weg herziehen würden, um in Ängelholm arbeiten zu können. Die auch in Schweden bei Personalverantwortlichen bekannte Schwierigkeit, genügend Nachwuchskräfte für den Öffentlichen Dienst zu finden, wurde so nebenbei auch gelöst. Fazit: Ohne die Mitarbeitenden funktioniert eine agile Transformation überhaupt nicht. Die Energien, die die Stadtverwaltung für die Bürger freisetzen wollen, sind die Energien der Beschäftigten. Diese Energien wachsen, wenn Zusammenarbeit gefördert und geübt wird und eine Kultur des Gebens und Nehmens entsteht.

8Der

Europäische Sozialfonds (ESF) ist nach eigener Auskunft Europas wichtigstes Instrument zur Förderung der Beschäftigung und sozialer Integration in Europa.

234

W. Steinbrecher

Literatur Ängelholms kommun (Hrsg) (2015) Ängelholms kommuns nya organisationen, Faltblatt, 8 Seiten Ängelholms kommun (Hrsg) (2016) Medarbetarundersökning 2016. Genomförd av CMA Research AB, 65 Seiten (Oktober) Glantz S, Thorsén M (2018) Why We are Agile with the Arena Method, Vortrag auf der Konferenz „Agile Verwaltung 2018“, Manuskript. http://agile-verwaltung.org/blogthemen-veranstaltungen -konferenz-2018/ Wahl J, Skantze J (2014) Ängelholm. En agil utvecklings- och servicekommun, AdvisoryBoard 2014. http://www.advisoryboard.se/wp-content/uploads_sv/2014/06/agil-utvecklings-servicekommun.pdf Wollmann H (2008a) La réforme de l’administration locale entre changement et continuité. Une perspective comparatiste sur l’ Angleterre, l’ Allemagne, les pays scandinaves, l’Espagne et la Hongrie. In: Marcou G, Wollmann H (Hrsg) Annuaire 2008 des Collectivités Locales, La gazette des communes, Paris, S 165–188 Wollmann H (2008b) Reformen in Kommunalpolitik und -verwaltung: England, Schweden, ­Frankreich und Deutschland im Vergleich. VS Verlag, Wiesbaden (Wüstenrot-Stiftung (Hrsg))

Wolf Steinbrecher  ist Volkswirt und Informatiker. Er war lange als Anwendungsentwickler für medizinische Datenbanken und in Systemhäusern tätig. Von 1995 bis 2008 war er Sachgebietsleiter „Organisation und Controlling“ in einer mittelgroßen Landkreisverwaltung (1050 MA). Aus den dortigen Erfahrungen rührt das Interesse an teamzentrierten, agilen Arbeitsweisen. Ein Resultat davon war die Entwicklung des Prozessorientierten Ablagesystems (PAS), das in diversen Büchern dargestellt wird. Seit 2008 selbstständiger Berater. Mitgründer des Forums Agile Verwaltung e. V.

Agile Pflege bei Buurtzorg

21

Martin Bartonitz

Zusammenfassung

In diesem Kapitel wird über die Erfolgsgeschichte des inzwischen größten ­mobilen Pflegedienstes in Holland berichtet. Buurtzorg ist aufgrund der flachen, agilen Organisation in der Lage, ohne die kostenintensiven Abteilungen wie Marketing ­ und Personalmanagement, aber auch ohne Finanzchef auszukommen. Über 14.000 ­Mitarbeiter, überwiegend Frauen, entscheiden über ihre Arbeitsorganisation selbst. Und das bekommt auch den Patienten sehr gut.

21.1 Einleitung Das folgende Unternehmen, das sich ohne die klassischen Chefs in hoher Selbstorganisation von Teams organisiert, ist zwar keines aus dem öffentlichen Dienst. Dennoch soll es hier gebracht werden, da der Zweck des Unternehmens doch thematisch recht nahe am Gemeinwesen liegt. Buurtzorg wurde 2006 in Holland von Jos de Blok – selbst Pfleger und heutiger Geschäftsführer – und anderen gegründet und hat zum Zeitpunkt der Veröffentlichung dieses Buchs über 14.000 Pfleger, zum großen Teil Frauen, unter Vertrag. Das entspricht einem Marktanteil von 75 %. Das Unternehmen kommt ohne Finanzchef und ohne Personalchef aus. Und da es kein Marketing braucht, gibt es auch keinen Marketing-Chef. Es braucht nur 25 Mitarbeiter in der Verwaltung der Zentrale. Denn die meisten Entscheidungen werden in den 10–15 Personen starken Teams

M. Bartonitz (*)  Produktmanagement, c/o OPTIMAL SYSTEMS GmbH, Berlin, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_21

235

236

M. Bartonitz

getroffen, u. a. auch, welcher Bewerber ins Team kommt, und ganz selten, wer das Team verlassen muss. Buurtzorg wurde mehrfach hintereinander zum besten Arbeitgeber gewählt. Inzwischen versuchen schon andere Länder, u. a. Deutschland und Österreich, das Modell zu übertragen, aber auch asiatische Länder sind sehr interessiert. Das Übertragen der Organisation ist ­allerdings nicht ganz so einfach, da die Gesetzgebungen und Versicherungsmodelle gegenüber Holland in der Regel deutlich anders sind.

21.2 Heutiger Paradigmenwechsel Frederic Laloux geht in seinem Buch ‚Reinventing Organizations: Ein Leitfaden zur Gestaltung sinnstiftender Formen der Zusammenarbeit‘1 besonders auch auf die Erfahrungen von Buurtzorg ein. Er hat aktuell in einer 20-minutige Erklärung vor seiner Heiligkeit, dem Dalai-Lama, kurz und knapp deutlich machen können, welche Transformation, welcher Paradigmenwechsel gerade in unseren Unternehmen vollzogen werden:2 War es vorher noch das Leitbild einer Maschine mit Planung und Kontrolle, so sehen sich Organisationen heute zunehmend als lebendiger Organismus, der einem schnellen Wandel effektiv folgen kann. Dabei sieht Frederic drei wesentliche Dinge, die anders sind: • Anstelle einer hierarchischen Entscheidungsstruktur bildet sich ein Netzwerk aus, in dem die Entscheidungen von den Wirkenden dort getroffen werden, wo das Wissen ist. • Anstelle von Angst, wo Wissen zum eigenen Überleben zurückgehalten wird, tritt eine Kultur des Vertrauens, in der Innovationen sich schnell verbreiten können. • Es geht weniger um das individuelle Geldverdienen als um den Sinn des Wirkens für die Gemeinschaft, besonders auch mit den Kunden. Damit bekommt das Bild des Dienstes für das Gemeinwohl eine angenehme Bedeutung.

1Reinventing

Organizations: Ein Leitfaden zur Gestaltung sinnstiftender Formen der Zusammenarbeit Autor: Frederic Laloux; Verlag: Vahlen; Auflage: 1, ISBN-13: 978-3800649136. 2Seine Heiligkeit, der Dalai-Lama, hat an dem Dialog „Power and Care“ teilgenommen, das von Mind & Life Europe from the Bozar Center for Fine Arts in Brussels, Belgium, organisiert wurde. Der Dialog mit Frederic Laloux ist auf youtube verfügbar: http://youtu.be/JMzhkPMrRA4.

21  Agile Pflege bei Buurtzorg

237

21.3 Motivation zur Gründung von Buurtzorg Nach seinen allgemeinen Ausführungen im Dialog wurde Frederic gefragt, ob er noch ein Beispiel geben könne. Er ging konkrete auf Buurtzorg ein und hat dabei zuerst die vorherige Entwicklung der Pflege in Holland beschrieben. Ich möchte gerne seine Worte hier übersetzt wiedergeben: In Holland gingen die Krankenschwestern als Selbstständige nach Hause zu den Menschen, die sie pflegten. In den 1980er Jahren kam man auf Basis des Maschinen-­Denkens auf die Idee, die Krankenschwestern aus ökonomischen Gründen in Unternehmen zusammenzubringen. Dann kam ma auf die Idee, dass sie persönliche Verbindungen zu den Bedürftigen haben, und es schwierig sein könnte, sie gut auszulasten. Also wurde nun ein Call-Center aufgebaut, das zwischen den vielen Bedürftigen und den Schwestern vermittelte, in dem ihnen auch die Phones genommen wurden. Damit hatten die Bedürftigen nun nicht mehr ihre persönlichen Schwestern, sondern irgendeine, die gerade frei war. Und dann realisierten sie, dass sie den Erfahrenen mehr zahlen mussten, also sollten diese auch nur die komplizierten Dinge tun. Der Rest wurde dann von den ‚billigen‘ Schwestern bedient. Dann bemerkten sie, dass manche Schwester schneller waren als andere. Als führte man Zeiträume ein, z. B. für das Duschen 12 min, für die Gabe einer Spritze 10 min, …. Und oh, da bot es sich nun an, ein Planungsbüro einzurichten. Nun bekamen die Schwestern beim Dienstantritt einen minutiösen, von Google-Map berechneten Reiseplan für den Tag. Und oh, das ist gut, nun konnte man Verbesserungsmaßnahmen einführen. Die Schwestern klebten an den Türrahmen neuer Bedürftiger einen Barcode-Sticker. Sie führten einen Barcode-Leser mit, sodass sie sich beim Ein- und Austreten registrieren konnten. Und so fand man heraus, welche Schwester beim Duschen zu langsam war, und man sie daher speziell trainieren konnte. Aus der Perspektive des Maschinen-Denkens ist all das logisch: Die Prozesse werden billiger und effizienter, und es kann mehr Menschen geholfen werden. Aber am Ende haben das die Schwestern und Bedürftigen gehasst. Das hat die Schwestern in ihrer Integrität sehr verletzt. Sie wussten, dass sie von den Bedürftigen mehr benötigt wurden, hatten aber keine Zeit dafür. Jos de Blok arbeitete in diesem System und war sich sicher, dass er das so nicht mehr mitmachen wollte, und gründete Buurtzorg. Sie waren am Anfang zu viert. Der Zweck sollte sein, den Menschen möglichst schnell zu einem autonomen Leben zu verhelfen. Und so nahm sich nun eine Schwester die Zeit, sich für einen Kaffee hinzusetzen, und dabei darüber zu sprechen, was es braucht, dass der Patient reaktiviert wurde. „Oh, sie haben Kinder, und die unterstützen Sie derzeit nicht. Kann ich dabei helfen, einen Dialog anzustoßen?“. Sie tun so unglaublich tolle Sachen. Sie entwickeln tiefe und fruchtbare Beziehungen zu den Bedürftigen. Und diese werden dabei so viel schneller wieder gesund. Und der finanzielle Effekt dazu: Diese Patienten benötigen nur noch etwa 40 % der Zeit eines Arztes. D. h. das Kaffeetrinken spart den Kassen Hunderte von Millionen Euro im Jahr.

238

M. Bartonitz

Und das Interessante ist: Die Schwestern sind die gleichen. Die Anforderungen der Bedürftigen sind die gleichen. Das Einzige, was sich hier geändert hat, ist, wie wir die Welt sehen.“ Mit diesem Schlusssatz erhielt Frederic Standing Ovations vom Publikum und ein langes Händeschütteln vom Dalai-Lama, der äußerst beeindruckt war.

21.4 Teamarbeit und Autonomie als Leitprinzipien Eingangs haben wir erfahren, dass Buurtzorg ohne einen Personalchef auskommt. Das liegt daran, dass die Teams selbst neue Kräfte einstellen, wenn dies der Bedarf erforderlich macht. Und dabei wird nicht nur geschaut, ob die Erfahrungen passen, sondern besonders auch, ob der Mensch ins Team passt. Werfen wir noch einen Blick auf die Ausbildung. Bei den Pflegekräften handelt es sich zum Großteil um sehr gut qualifizierte Pflegefachkräfte. 70 % sind „registered nurses“, also diplomierte Pflegefachkräfte (darin enthalten 40 % mit Bachelor Ausbildung) – in anderen Pflegeorganisationen sind es durchschnittlich 20 %. Beschäftigte werden e­ ntsprechend ihrer Ausbildung nach Tarifvertrag bezahlt – mit jährlicher Standarderhöhung und Boni je nach Dauer der Beschäftigung. Sie erhalten damit durchschnittlich mehr Lohn als Pflegekräfte von anderen Pflegeanbietern. Der Teamentwicklungsprozess wird von Anfang an durch eine entsprechende Schulung aller Mitarbeiter unterstützt, auch durch ausreichende Zeitressourcen. Dazu wurde die Produktivitätsrate von 75 % auf 60 % gesenkt, und so steht Zeit für Reflexion und Teamarbeit zur Verfügung. Teamkompetenzen können dadurch effektiv genutzt werden und ermöglichen die Übernahme breit gefächerter Pflegeaufgaben. Je nach konkretem lokalem Bedarf wie z. B. mehr Pflegebedürftige mit Demenz oder psychischen Problemen etc. wird im Team entsprechendes Know-how z. B. durch Weiterbildung erworben. Somit ist gut zu verstehen, dass durch diese eigenverantwortliche Gestaltung des Pflegeprozesses in den Teams Buurtzorg völlig ohne mittleres Management in der Gesamtorganisation auskommt. Die damit erzielten Kosteneinsparungen im Verwaltungsbereich sind beachtlich: So hat Buurtzorg lediglich 8 % Verwaltungskosten während diese bei vergleichbaren Anbietern in der mobilen Pflege in den Niederlanden durchschnittlich bei 25 % liegen.

21.5 Transparenz der Entscheidungsfindung Jede Krankenschwester, jeder Pfleger ist mit einem Tablet ausgestattet, über den der Zugang zu allen wissenswerten Daten des Unternehmens möglich ist. Besonders auch zu den Anwendungen, über die Entscheidungen vorbereitet werden. So nutzt besonders Jos de Blok als Geschäftsführer, der in der Regel Entscheidungen größer Tragweite zu treffen hat, einen Blog.

21  Agile Pflege bei Buurtzorg

239

„Je größer die Entscheidung ist, desto weiter ist das Netz, das berücksichtigt werden muss.“ – Frederic Laloux in seinem oben erwähnten Buch. Steht eine wichtige Entscheidung an, verfasst er einen Blogbeitrag und veröffentlicht diesen. Er beschreibt dazu seine Gedanken, mögliche Optionen und äußert sich zu Vor- und Nachteilen. Die Mitarbeitenden haben dann für 24 h die Möglichkeit mittels Kommentarfunktion ihre eigene Meinung kund zu tun. Nach 24 h liest Jos de Blok die Kommentare und versucht, die Stimmungen zu „erspüren“. Hat er den Eindruck, er wisse nun, wie er entscheiden soll, so trifft er die Entscheidung. Hat er das Gefühl, es besteht der Bedarf nach einer tiefer gehenden Auseinandersetzung mit dem Thema, so sorgt er für die Bildung einer Arbeitsgruppe, die das Thema weiterverfolgt. Für Jos de Blok ist diese Vorgehensweise aufwendig und vor allem: Sie verlangt eine unglaubliche Ehrlichkeit von ihm selbst und macht ihn in einer gewissen Weise auch sehr angreifbar. Der Erfolg von Buurtzorg scheint die Effektivität dieses Vorgehens allerdings zu bestätigen.

21.6 Grundzüge der Organisation Frederic Laloux fasst in seinem erwähnten Buch einige Aspekte moderner Arbeitsund Organisationsformen mit Blick auf das Buurtzorg-Modell in Tab. 21.1 etwa so zusammen: Die seit der Industrialisierung bevorzugte taylorisierte Arbeitsteilung3 wird durch eine ganzheitliche Aufgabenerfüllung ersetzt. Die Trennung von Denken und Handeln ist aufgehoben. Da die Teams sehr klein sind, erfolgen Abstimmungen spontan und häufig IT-gestützt, eigene Teambesprechungen werden nur in Sonderfällen anberaumt. Auffällig ist, dass der Informationsfluss sehr transparent und zeitnah gehalten ist und von allen Beschäftigten eingesehen werden kann. Die Zusammenarbeit mit den in den Niederlanden üblichen Primary Health Care Centres ist weitreichend. Nicht verwunderlich, dass auch strategische Entscheidungen, wie etwa die Erweiterung bzw. Bildung neuer Teams durch die bestehenden autonomen Teams selbst getragen werden.

3Als Taylorismus  bezeichnet man das von dem  US-Amerikaner  Frederick Winslow Taylor­­  (1856–1915) begründete Prinzip einer Prozesssteuerung von Arbeitsabläufen, die von einem auf Arbeitsstudien gestützten und arbeitsvorbereitenden Management detailliert vorgeschrieben werden und für die der Begriff Scientific Management geprägt wurde. Der Begriff Taylorismus wird synonym, jedoch in vorwiegend kritischem Kontext verwendet. Meist ist dabei nicht das ­originäre Konzept des Scientific Management gemeint, sondern seine Umsetzung und Wirkung.

240

M. Bartonitz

Tab. 21.1  Aspekte moderner Arbeits- und Organisationsformen Strukturelle Aspekte

Personalmanagement

Arbeitsorganisation und Management

Organisationsstruktur

Autonome Teams, bei Bedarf ­unterstützt durch Coaches

Koordination

Besprechungen nur bei Bedarf, keine Hierarchie

Funktionsbeschreibung

Kein mittleres Management, ­Aufgaben werden gleichberechtigt im Team verteilt

Personalaufnahme

Job-Interviews durch die ­künftigen Teammitglieder, Fokus auf Kompatibilität mit dem Team und den Organisationszielen

Personaleinführung/ Weiterbildung

Fokus auf soziale Kompetenzen, Organisationskultur und ergänzende Weiterbildung, je nach individuellem Bedarf, gemeinsame Workshops

Flexible Arbeitszeit

Individuelle Freiheiten bei Einhaltung der verbindlich vereinbarten Ziele

Beförderungen

Nicht vorgesehen, Rollenflexibilität nach gemeinsamer Vereinbarung im Team, weitreichende Mitspracherechte aller Mitarbeiter, keine Hierarchie im Team

Entlassungen

Nur als letzter Schritt nach ­Konfliktmediation

Arbeitsteilung

Ganzheitliche Erfüllung der ­individuellen Aufgaben im Team

Meetings

Spezielle Meetings nur, um sicher zu stellen, dass alle Meinungen gehört werden

Entscheidungsfindung

Dezentralisiert

Informationsfluss

Sämtliche Informationen in Realzeit verfügbar für alle; Transparenz auch gegenüber Partnerorganisationen

Strategieentwicklung

Basiert organisch auf der Zusammenführung der Beiträge aus den ­autonomen Teams

21  Agile Pflege bei Buurtzorg

241

Dr. Martin Bartonitz ist Produktmanager und SCRUM Product Owner bei OPTIMAL SYSTEMS GmbH, Hersteller eines Enterprise Content Management Systems. Er studierte Experimentelle Physik und wechselte nach seiner Promotion 1992 von der Messprozesssteuerung in die Welt der Geschäftsprozessautomatisierung. In seinen über 25 Jahren befasste er sich im Schwerpunkt mit den fachlichen Anforderungen der Dokumentverwaltung und –steuerung, u.a. auch im öffentlichen Sektor. Seit 12 Jahren arbeitet er mit agilen, sich selbstorganisierenden Teams und schreibt über seine hier gemachten Erfahrungen in Blogartikeln.

Agiles Studieren

22

Detlef Stern

Zusammenfassung

Ein Studium strebt die Vermittlung einer wissenschaftlichen Arbeitsweise an. Ziel ist es, sich weitgehend eigenständig und eigenverantwortlich neue Erkenntnisse zu erarbeiten. Eine Herausforderung, die beim Wechsel von Schule zur Hochschule nicht wenigen Neustudenten schwerfällt und den Ruf nach einer „Verschulung“ der Inhalte laut werden lässt. Diesem Impuls nachzugeben ist jedoch nicht der richtige Weg. Wie das Dilemma auflösen? Eine Lösung könnte die Adaption der agilen Herangehens­ weise sein, die hochgradig empirische Elemente aufweist und damit einer wissen­ schaftlichen Herangehensweise entspricht. Agiles Studieren an der Hochschule Heilbronn adaptiert eben jene Elemente nach dem Vorbild von Scrum und Kanban aus der Softwareentwicklung überträgt diese auf die akademische Wissensvermittlung, kombiniert mit einer frühen Rückkopplung des Lernerfolgs. Das folgende Kapitel gibt einen Einblick in die Entwicklung des Konzepts und die Erfahrungen, die seit der Einführung des agilen Studierens gesammelt wurden.

22.1 Motivation Das Studium einer Wissenschaft unterscheidet sich wesentlich vom Lernen in der Schule. Für die meisten Studienanfänger ist die Umstellung vom bisherigen Lernen in der Schule alles andere als einfach. Gab es bisher einen Lehrplan, der die zu lernenden

D. Stern (*)  Hochschule Heilbronn, Heilbronn, Deutschland E-Mail: [email protected] © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_22

243

244

D. Stern

Inhalte relativ genau und kleinteilig vorschrieb, so ist es nun ein zunächst unübersichtliches Fach, das inhaltlich zu durchdringen ist. Mit dem Übergang an die Hochschule ändern sich Lehr- und Lernformen grundlegend. Ein Lehrer in der Schule kennt seine Schüler und kann fachübergreifend und individuell auf Schwächen und Stärken eingehen. Er nimmt die Schüler gewissermaßen an die Hand. Ein Hochschullehrer konzentriert sich weniger auf individuelle Lernfortschritte, sondern strukturiert ein Thema, präsentiert wesentliche Inhalte und erwartet ein selbstständiges und eigenverantwortliches Einarbeiten in das jeweilige Fachgebiet. Dieser Wechsel der Lehr- und Lernformen ist sinnvoll. Hochschulabsolventen ­sollen (und wollen) später selbstständig und eigenverantwortlich in ihren Berufen arbeiten. Dazu muss der Fokus des Lernens wechseln, von kleinen Lernfortschritten hin zu einem längerfristigen, perspektivbasierten Lernen. Der Blick für das (spezialisierte) Ganze wird wichtiger. Der Wechsel von Schule zur Hochschule überfordert trotz allem viele Studienanfänger. Zum Wechsel der Lehr- und Lernformen gesellt sich ein Wechsel des Umfelds und der Qualitäten. Es gibt keinen stabilen Klassenverband mehr, sondern immer wieder viele, unbekannte Kommilitonen. An Lehrveranstaltungen nehmen 30, 40, 50, 100, 700 Studenten teil. Die Hochschullehrer sind auch Forscher und berichten über nur teilweise gesichertes Wissen. Für ein Referat reicht es nicht mehr irgendeine, irgendwie passende Quelle per Suchmaschine zu finden. Es müssen nun mehrere Quellen einer bestimmten, der jeweiligen Wissenschaft angemessenen Qualität sein. Ziel wird es, Wissen zu schaffen, nicht nur zu konsumieren. Eine weitere Herausforderung sind die Prüfungen, die meist erst am Ende eines Semesters stattfinden. In manchen Fällen muss auch Semester übergreifend gelernt werden. Immer in der Hoffnung, dass man selbst tatsächlich das Angemessene lernt. Individuelle Rückmeldungen auf Lernerfolge vor den Prüfungen gibt es an Hoch­ schulen selten. Nicht ohne Grund ist der Wunsch nach Musterklausuren oder ähnlichem ­vorhanden, auch wenn diese praktisch kaum Unterstützung bieten. Wer eine Wissenschaft studieren möchte, muss also viele Änderungen meistern und sich dabei auf eine neue Umgebung einlassen. Eine (Lern-) Gruppe kann dabei helfen, indem sie eine vertrautere Umgebung schafft und immer wieder Rückmeldungen gibt. Man selbst gibt Rückmeldungen an die anderen Gruppenmitglieder und vertieft dabei Erlerntes. Aus Sicht von Studenten kann das Arbeiten in einer Gruppe viele Vorteile bieten. Es kann aber auch Nachteile bedeuten. Stichworte sind „soziale Hängematte“ oder „Ingroup Bias“ Fachliche Grundlagen lassen sich häufig nicht über Gruppenarbeit erlernen. Aus Sicht eines Hochschullehrers ist eine gute Lehre unter den allgemeinen Bedingungen an der Hochschule nicht immer einfach zu erreichen. Als Hochschullehrer erkenne ich häufig erst zu spät, nämlich bei den Prüfungen, ob und in welchem Umfang meine Lehrveranstaltungen auf Resonanz stießen. Während eine Vorlesung gut geeignet ist, das Lernen von Grundlagenwissen zu initiieren, ist sie weniger geeignet, um

22  Agiles Studieren

245

den Lernfortschritt konstruktiv zu begleiten. Andere Lehrformen, wie Übungsgruppen, ­Seminare, Projektstudien, Laborarbeiten besitzen ihre eigenen Vor- und Nachteile. Eine an die jeweiligen Inhalte angepasste Lehr- und Lernform könnte helfen, viele der Herausforderungen zu erleichtern oder gar zu lösen. Viele dieser Herausforderungen sind gar nicht spezifisch für eine wissenschaftliche Ausbildung. Sie stellen sich auch in der beruflichen, außerwissenschaftlichen Weiterbildung.

22.2 Ziel des Studierens Was soll ein Studium, eine berufliche Ausbildung leisten? Unstrittig ist die Fähigkeit zum selbstständigen, kritischem Denken. Wie wäre es etwas konkreter? Kompetenzen, die zur Planung, Bearbeitung und Auswertung von umfassenden fachlichen Aufgaben- und Problemstellungen sowie zur eigenverantwortlichen Steuerung von Prozessen in Teilbereichen eines wissenschaftlichen Faches oder in einem beruflichen Tätigkeitsfeld benötigt werden. Die Anforderungsstruktur ist durch Komplexität und häufige Veränderungen gekennzeichnet.

Diese Definition stammt nicht von mir. Sie beschreibt vielmehr das Niveau 6 des Deutschen Qualifikationsrahmens, das u. a. die erwarteten Kompetenzen eines Bachelor-Abschlusses bestimmt.1 Auf Master-Ebene (Niveau 7) erweitert sich die Definition um neue, unvorhergesehene und strategieorientierte Elemente:2 Kompetenzen, die zur Bearbeitung von neuen komplexen Aufgaben und Problemstellungen sowie zur eigenverantwortlichen Steuerung von Prozessen in einem wissenschaftlichen Fach oder in einem strategieorientierten beruflichen Tätigkeitsfeld benötigt werden. Die Anforderungsstruktur ist durch häufige und unvorhersehbare Veränderungen gekennzeichnet.

Diese Elemente sind durch eine Hochschulausbildung, durch ein Studium einer Wissenschaft zu bewältigen. Wie wäre es, wenn Studieren wieder das werden würde, was das Wort „studere“ im Lateinischen ursprünglich bedeutet, nämlich sich (selbstständig) um Erkenntnis bemühen? Wie wäre es, wenn das Studieren selbstbestimmt wäre, in einer Gruppe erfolgen könnte und man recht schnell Rückmeldungen über den Lernerfolg bekäme?

1https://www.dqr.de/content/2336.php. 2https://www.dqr.de/content/2337.php.

246

D. Stern

22.3 Lösungsansatz Aus einer bestimmten Sichtweise ähneln sich das Studium einer Wissenschaft und das Realisieren von Software. Beide sollten sowohl individuell als auch in der Gruppe bzw. im Team erfolgen. Die handelnden Personen, Studenten, Hochschullehrer, Softwareentwickler oder Fachverantwortliche, empfinden eine Ungewissheit, ob die eigenen Tätigkeiten tatsächlich zielführend sind. Beide Bereiche benötigen theoretische Grundlagen wie auch praktisches Handeln. In der Softwareentwicklung setzt man dazu agile Methoden ein, die Aspekte wie Wachsamkeit, Änderungswille, Reaktionsvermögen und Optimierung unterstützen, immer in Hinblick auf ein Ziel. Zeitnahe, ggf. individuelle Rückmeldungen sind die ­logische Folge des Zusammenspiels dieser Aspekte. An der Hochschule Heilbronn, Studiengang Wirtschaftsinformatik, bieten wir für unsere Studenten ein praxisnahes Studium an, bei dem theoretische Grundlagen nicht zu kurz kommen. Der praktische Teil besteht, wie auch anderswo üblich, aus einem Praxissemester in einem Unternehmen und einigen Seminaren. Als Besonderheit müssen unsere Studenten eine Vielzahl von Projektstudien leisten. In diesen Projektstudien werden Probleme gemeinsam in Team bearbeitet, häufig in Kooperation mit Unter­ nehmen. In den von mir veranstalteten Projektstudien kommt etwas ähnliches wie Scrum zum Einsatz. Wir sind mit diesem Konzept durchaus erfolgreich. Wie könnte eine agile Lehrveranstaltung aussehen, welche die positiven Elemente der Projektstudien auf die Notwendigkeiten des Erwerbs von Theoriewissen überträgt? Analog zu Scrum setzen wir bei einer agilen Lehrveranstaltung auf ein iterativ, inkrementelles Vorgehen mit definierten, festen Zeitintervallen, den Sprints. Die Länge dieser Intervalle, wir übersetzen diesen Begriff in unserem Kontext mit Studienphase, dauert 2 Wochen. Im Unterschied zu einem Softwareprojekt ist in einer agilen Lehrveranstaltung der Product Backlog, d. h. die zu leistende Arbeit, vorab definiert. Er enthält eine Reihe von Studienthemen, die im Laufe des Semesters zu bearbeiten sind. Zu Beginn einer Studienphase sollten sich die (Studien-) Gruppen überlegen, ­welche Themen sie auf welche Art und Weise bearbeiten sollen. Bei Scrum heißt das „Sprint Planning“. Bei den meisten Themen entscheidet die Gruppe, dass diese nur von einem Gruppenmitglied bearbeitet werden. Die Ergebnisse werden der Gruppe vorgestellt. Andere Themen können entsprechend nur von einigen, z. B. paarweise, bearbeitet ­werden oder gar von allen Gruppenmitgliedern. Beim Planen und späteren Bearbeiten werden die Gruppen durch den Hochschullehrer aktiv betreut. Dabei werden Details zu den Studienthemen gegeben oder auch Bearbeitungsideen diskutiert, ohne eine Lösung vorweg zu nehmen. Ein Studienthema gilt dann als bearbeitet, wenn ein gemeinsamer Lösungsvorschlag dokumentiert ist und eine genügend große Anzahl der Gruppenmitglieder diesem Vorschlag explizit zustimmt. In Scrum heißt dies „Definition of Done“.

22  Agiles Studieren

247

Zum Ende einer Studienphase werden die Lösungsvorschläge vom Hochschullehrer begutachtet, in Scrum auch „Review“ genannt. Während ein Hochschullehrer für eine normale Vorlesung die meiste Zeit in Präsenzterminen und ggf. in Sprechstunden verbringt, ist nun das Bewerten der Lösungsvorschläge zeitlich gesehen der umfangreichste Teil der Veranstaltung. Im Unterschied zu einer Klausurbewertung werden keine expliziten Noten vergeben. Stattdessen unterstützt der Hochschullehrer bei weniger angemessenen Lösungen mit einer inhaltlichen Rückmeldung, inklusive Ideen für Verbesserungen. Diese können während der nächsten Studienphase auch persönlich vertieft werden. Vor Beginn der nächsten Studienphase lesen die Studenten die Rückmeldungen, fragen ggf. nach und überlegen sich, wie sie erfolgreicher werden können (Retrospektive). Dann beginnt der Zyklus von vorn. Pro Semester sind, bei zweiwöchigen Studienphasen, 7–8 Studienphasen möglich. Damit haben die Studenten 7–8 Mal die Möglichkeit ­Feedback zu erhalten. Dieses Vorgehen haben wir Agiles Studieren genannt. Auch wenn das Agile Studieren ursprünglich analog zu Scrum entwickelt wurde, so ist es nicht auf ein Scrum-artiges Vorgehen beschränkt. Es gibt viele alternative agile Methoden, die auch beim Agilen Studieren genutzt werden können. Wenn ein Scrum-ähnliches Vorgehen nicht angemessen erscheint, dann sollten diese anderen Methoden in Betracht gezogen werden (Tab. 22.1). Insgesamt werden durch das Agile Studieren einige Defizite üblicher Veranstaltungsformen ausgeglichen. Die Studenten erhalten spätestens nach zwei Wochen eine inhaltliche Rückmeldung. Die Studenten arbeiten in Gruppen und erhalten durch ihre Gruppenmitglieder zusätzliche Rückmeldungen. Die Studenten bestimmen Studiertempo und -reihenfolge in der Gruppe selbst und müssen nicht dem vom Hochschullehrer geplanten Tempo folgen. Tab. 22.1  Die Begrifflichkeiten gegenübergestellt Scrum (o. ä.)

Agiles Studieren

Definition of Done

Studienthema ist bearbeitet und Team hat ausreichend zugestimmt

Product Backlog

Liste der zu bearbeitenden Studienthemen

Product Owner

(Hochschullehrer)

Retrospective

Retrospektive

Review

Begutachtung der Lösungsvorschläge, inkl. Rückmeldung

Scrum Master

(Hochschullehrer oder Tutoren)

Sprint

Studienphase

Sprint Backlog

Studienthemen, die in nächster Studienphase bearbeitet werden sollen

Sprint Planning

Planung, was in der nächsten Studienphase bearbeitet werden soll

Scrum (o. ä.)

Agiles Studieren

Team

Studiengruppe

248

D. Stern

22.4 Software-Unterstützung An unseren Lehrveranstaltungen nehmen ca. 40 Studenten teil. Bei einer Größe der Studiengruppen von 4–6 Teilnehmern kommt man damit auf etwa 7–10 Studiengruppen. Selbst wenn pro Studiengruppe und -phase nur 10 Themen bearbeitet werden würden, ließe sich dies nicht mit üblichen Mitteln (Mail, Papier) bewältigen. Eine Lösung besteht in der Nutzung einer Software, die auch für die Koordination bei der Entwicklung von Software verwendet wird: einem Issue-Tracking-System3. Damit lassen sich Empfang, Bestätigung, Bearbeitung, Prüfung von Anfragen aller Art bearbeiten. In diesem Fall sind die zu bearbeitenden Themen die Anfragen. Als Hochschullehrer formuliere ich die Studienthemen im Ticketsystem als Anfrage und lasse diese von den Studiengruppen bearbeiten. Damit spare ich viel Koordinationsaufwand. Eine kleine Feinheit gilt es zu beachten: jede Studiengruppe benötigt eine eigene, unabhängig zu bearbeitende Anfrage für ein Studienthema. Deshalb muss die Software das Kopieren von Anfragen unterstützen. So wie Agiles Studieren nicht auf Scrum beschränkt ist, gibt es keine Beschränkungen bei den Hilfsmitteln. Sofern bei allen Beteiligten genügend Disziplin vorhanden ist, ­ können auch Werkzeuge wie Google Docs/Tabellen, Sharepoint, Trello u. v. m ­verwendet werden.

22.5 Erfahrungen Eine häufig gestellte Frage ist die nach den Resultaten des Agilen Studierens, konkret den Klausurergebnissen der Studenten. Sind zum Beispiel die Noten dadurch besser geworden? Diese Frage lässt sich nicht einfach beantworten. Von der Statistik her sind unsere Fallzahlen viel zu gering. Durch das Agile Studieren erhalten die Studenten frühzeitig Rückmeldung, die sie auch verwenden können, um die Entscheidung zu treffen, sich evtl. doch nicht zur Klausur anzumelden und ein Semester länger zu lernen. Es gibt zwar eine Korrelation zwischen der Anzahl erfolgreich bearbeiteter Themen und der Note in der Klausur, aber Korrelation bedeutet nicht Kausalität. Zwar hat sich der Notendurchschnitt leicht verbessert, aber innerhalb einer üblichen Schwankungsbreite. Weitere positive Ergebnisse sind anderweitig sichtbar. Während die Fachkompetenz nicht gelitten hat, können wir eine Verbesserung der persönlichen Kompetenzen (Sozialkompetenz, Selbstständigkeit) feststellen. Selbst- und Fremdbild weichen weniger voneinander ab, das Selbstvertrauen ist gestiegen. Die Studenten sind in der Lage, leistungsschwächere Kommilitonen anzuleiten. Darüber hinaus erfolgt eine zügige Sozialisation an die neue Umgebung.

3Issue-Tracking-System wird auch als Ticketsystem bezeichnet. Vgl. dazu z.  B. https://de.­ wikipedia.org/wiki/Issue-Tracking-System.

22  Agiles Studieren

249

Damit die Ergebnisse einer Themenbearbeitung bewertet werden können, müssen diese nachvollziehbar dokumentiert werden. Das gilt auch für die Zustimmung der anderen Gruppenmitglieder. Dieser Zwang zu einer (eher schriftlichen Dokumentation) der Ergebnisse ist von Vorteil, denn so müssen die Studenten Kompetenzen entwickeln, um komplexe Sachverhalte strukturiert, zielgerichtet und adressatenbezogen darstellen.

22.6 Fachliche Eignung Wir haben Agiles Studieren für unterschiedliche Fachgebiete eingesetzt. Wir haben in Fächern wie Projektmanagement, Programmierung und in einigen betriebswirtschaftlich orientierten Fächern eine gute Passung festgestellt. Studienthemen können die einfache Suche nach Fachdefinitionen sein oder die Bearbeitung von Verständnisaufgaben. Aufgaben, wie sie im späteren Umfeld einer Unternehmensberatung vorkommen, sind genauso möglich wie das nachvollziehbare Berechnen von Kennzahlen oder eine Literaturrecherche. Für manche Veranstaltungen scheint Agiles Studieren nicht so gut geeignet zu sein. Im Fach Statistik hatten Studenten erhebliche Schwierigkeiten mit diesem Vorgehen, in anderen Fächern zeitgleich dagegen nicht. Ein möglicher Grund könnte die relativ starke inhaltliche Abhängigkeit von Studienthemen im Fach Statistik sein. Eine gleichzeitige Bearbeitung von Themen durch mehrere Gruppenmitglieder ist dann kaum möglich. Hier besitzt ein Modell wie Inverted Classroom vermutlich Vorteile. Nicht ohne Grund wird dieses häufig für mathematisch orientierte Fächer eingesetzt.

22.7 Gruppenbildung Extrovertierte Studenten scheinen in Vorlesungen Probleme zu haben, länger still zu sein. Dagegen besitzen klassische Gruppenarbeiten für viele introvertierte Studenten Nachteile. Durch die Flexibilität bei der Gruppenarbeit (im Extremfall: jeder arbeitet alleine und stellt den anderen die Ergebnisse vor) bietet Agiles Studieren beiden Typen Entfaltungsmöglichkeiten. Trotzdem ist nicht alles Gold was glänzt. Zum Beispiel haben wir festgestellt, dass die Gruppeneinteilung kritsch für den Lernerfolg ist. Es gibt Gruppen, deren Mitglieder sich gegenseitig nach vorne pushen. Sobald aber eine Gruppe aus zu vielen wenig motivierten Teilnehmern besteht, manchmal reichen ein oder zwei, dann kann die Gruppe in einen Teufelskreis geraten. Ein anderes Problem kann sich ergeben, wenn die gleichen Gruppen in unterschiedlichsten Lehrveranstaltungen gemeinsam arbeiten. Stabile Gruppe erlauben zwar effizientes, aber nicht immer ein effektives Arbeiten. Sprich: Gruppendenken verhindert sinnvolle Lösungsansätze. Wir beobachten auch, dass die Gruppenarbeit zu den verschiedenen

250

D. Stern

Lehrveranstaltungen nicht getrennt genug beachtet wird, mit dem Effekt von größeren zeitlichen Aufwänden oder zu geringer Produktivität wegen Doppelarbeiten. Zu guter Letzt ist es auch selten der Fall, dass alle Teilnehmer bereits bei der Gruppenbildung feststehen. Manche können zum Termin der Gruppeneinteilung nicht anwesend sein, andere verspäten sich. Einige haben im Laufe ihres bisherigen Studiums noch keinen wirklichen Anschluss gefunden. Für alle stellt sich die Frage: wie finde ich eine passende Gruppe? Umgekehrt sieht manche Gruppe die Aufnahme neuer Mitglieder im Einzelfall als problematisch an. Hierfür muss der Hochschullehrer fallbezogen Lösungen entwickeln.

22.8 Vorgehensmodell Wie schon weiter oben angedeutet, ist ein Scrum-ähnliches Modell nicht immer angemessen. Während in der ersten Zeit dieses Modell wunderbar funktionierte, ist dies in letzter Zeit nicht immer der Fall. Manchen Gruppen liegt die Planung zu Beginn einer Studienphase nicht (Scrum: Sprint Planning). Diese Gruppen arbeiten eher nach einem Kanban-orientierten Modell, bei dem je nach individuell verfügbarer Zeit neue Studienthemen auch innerhalb einer Studienphase zur Bearbeitung ausgewählt werden. In einem Semester fiel den Studenten (und mir) auf, dass sie immer nur in der letzten Woche einer Studienphase an den Themen arbeiteten. Gemeinsam beschlossen wir, auf einwöchige Studienphasen umzusteigen. Damit verstetigte sich die Themenbearbeitung. Auch solche Anpassungen umfasst der Begriff „agil“. Die Mehrheit der Studenten befürwortet eine zeitlich feste Dauer der Studienphasen. Spätestens in Form eines zu erreichenden Meilensteins fühlen sich viele zur Themenbearbeitung motiviert. Viele freuen sich auf das regelmäßige Feedback seitens des ­Hochschullehrers.

22.9 Softwaredienste So sehr eine technische Unterstützung in Form eines Issue-Tracking-Systems helfen mag, so geht es doch mit einer speziell entwickelten Software besser. Im Rahmen eines geförderten Projekts wurde die erste Version einer web-basierten Software für das Agile Studieren fertiggestellt. Diese setzt eine Mischung aus Scrum und Kanban um. Aus Scrum wurden u. a. die definierten Dauern einer Studienphase realisiert. Das Kanban-Modell stand Pate für die

22  Agiles Studieren

251

Aufteilung der Bearbeitung von Studienthemen in einzelne, explizite Arbeitsschritte. Jedes Studienthema befindet sich zu jedem Zeitpunkt in einer der folgenden Zustände, die jedem während der Bearbeitung unmittelbar ersichtlich sind: offen, in Arbeit, abgestimmt, erledigt. Lehrveranstaltungen können leicht eingerichtet werden. Aus dem zugeordneten Studienfach werden ausgewählte Studienthemen übernommen. Studiengruppen ­lassen sich zügig einrichten, Gruppenmitglieder einfach hinzufügen und entfernen. Für alle Beteiligten bleibt transparent, wer wann was getan hat. Dazu gehören auch erste, gruppeninterne Statistiken. Nach einem Semester der Erprobung hat sich diese neue, speziell entwickelte Software bewährt. Die Studenten fühlen sich angemessen strukturell in der zu Beginn unbekannten Lernform des Agilen Studierens angeleitet. Als Hochschullehrer kann ich mich auf das Wichtige konzentrieren, das Feedback an die Gruppen. Im Vergleich zu einer üblichen seminaristischen Vorlesung ist der zeitliche Aufwand des Agilen Studierens bei einer Anzahl von 50 Teilnehmern in etwa gleich geblieben. Aber auch für die Software gibt es Verbesserungsideen. Eine Umfrage unter den ­Teilnehmern hat ergeben, dass diese Gruppen übergreifende Statistiken befürworten. So können die Gruppen sich untereinander besser abgleichen. Gruppenintern reichen externe Chat-Dienste (z. B. WhatsApp) zur Kommunikation vollkommen aus. Allerdings vermissen viele eine ähnlich direkte Kommunikation mit dem H ­ ochschullehrer. Obwohl anders erwartet, wird eine Nutzung der Software über mobile Endgeräte aktuell kaum gewünscht.

22.10 Ausblick Agiles Studieren hat sich seit dem Wintersemester 2013/2014 als valide Alternative zu herkömmlichen Lehrveranstaltungsformen entwickelt. Zusätzlich zu fachlichen Qualifikationen können Studenten ihre persönlichen Kompetenzen weiter entwickeln. Es eignet sich besonders für Fächer, bei denen Lerneinheiten wenig gekoppelt sind. Prinzipiell eignet sich Agiles Studieren auch für die berufliche Weiterbildung. Wie bei einer Vorlesung an einer Hochschule sind Teilnehmer eines Seminars zur Weiterbildung zeitlich, räumlich und inhaltlich an den Dozenten gekoppelt. Agiles Studieren löst diese strikte Kopplung auf und erlaubt arbeitsteiliges, selbstbestimmtes Lernen. Aber Agiles Studieren wäre nicht agil, wenn es von nun an fixiert ist. Informationen über weitere Entwicklungen gibt es unter https://agiles-studieren.de.

252

D. Stern Prof. Dr. Detlef Stern  ist Professor für Projektmanagement, Electronic Business und Softwareentwicklung an der Hochschule ­Heilbronn. Er setzt agile Methoden seit über 15 Jahren erfolgreich in Industrie und Hochschullehre ein.

Faust, Café Z, das Prinzip Kaktus und die Sache mit dem agil lernen und lehren

23

Heinz Bayer

Zusammenfassung

Dieses Buch-Kapitel ist ein Puzzle aus Texten des Fortbildungsskripts „Das pädagogische Schweizermesser“ – das von Heinz Bayer vor 10 Jahren für Schweizer Schuldirektor/innen geschrieben wurde, um ihnen die Denkweise im außerunterrichtlichen Bereich des Faust-Gymnasiums Staufen zu erläutern – und den heutigen Betrachtungen aus der Perspektive des damaligen Schulleiters Günther ­Scheunemann, des damaligen Verbindungslehrers Heinz Bayer und des damaligen Schulsprechers Sebastian Kaempf (Zeitrahmen 1990 bis 2000). Aus heutiger Sicht kann man das frühere Faust-Konzept für Lernende, Lehrende und Schule sehr gut als agiles Prinzip für außerunterrichtliche Projektarbeit ansehen. Deshalb nimmt der Autor ­ das ­Fortbildungsskript auch als Grundlage, um sich dem Thema „agil lernen und lehren“ 2018 praxisorientiert zu nähern. Außerdem versucht er mithilfe des agilen Manifests und den dazugehörenden 12 Prinzipien aus der IT-Branche, praxisbezogen einen Bogen zu einer möglichen Vorstellung von Leitsätzen zum Thema „agil lernen und lehren“ zu spannen. Autor und Interviewpartner sind Gründungsmitglieder des Forums agil lernen und lehren, einem Unterforum des Forums agile Verwaltung.

H. Bayer ()  Forum agil lernen und lehren, Freiburg, Deutschland E-Mail: [email protected] URL: www.aufeigenefaust.com © Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018 M. Bartonitz et al. (Hrsg.), Agile Verwaltung, https://doi.org/10.1007/978-3-662-57699-1_23

253

254

H. Bayer

Agil leiten, lehren und lernen

23.1 Einleitung Zur besseren Zuordnung des Blickwinkels steht im Text: (Schüler), (Lehrer) und (Direktor). (Lehrer) Lange ist es her … so ein Vierteljahrhundert würde ich meinen … als wir, Seb und ich, im Café Z saßen, Taccos mampften und die Zwischenräume von Schule ziemlich agil planten, wenn wir damals auch noch nicht von Agilität sprachen. Eher von „Schülerschule“ oder später dann vom „Prinzip Kaktus“. Und inzwischen bin ich im „Unruhestand“ … (Schüler) und ich, Dr. Sebastian Kaempf, unterrichte Internationale Politik in ­Brisbane. Bei uns an der Hochschule läuft natürlich vieles anders ab als an einer Schule. Angefangen mit der geringeren Stundenanzahl, den erheblich höheren Studentenzahlen im Vorlesungssaal bzw. im Seminarraum bis hin zu der Idee des eigenständigen Lernens der Studierenden ohne vergleichbare pädagogische Wertschätzung seitens der Dozenten – die Unterschiede könnten größer kaum sein. Dennoch habe ich die Prinzipien des ­agilen Lernens, der Schülerschule, die ich damals an meiner Schule so erlebt und ­verinnerlicht habe, ganz einfach in den universitären Alltag und den Umgang mit den Studenten übernommen. ……

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

255

(Schulleiter) und ich, Günther Scheunemann, noch länger im Unruhestand als mein Kollege Heinz Bayer, saß zwar damals nicht mit im Café Z, wusste allerdings von d­ iesen Arbeitstreffen und staune nun etwas darüber, dass Heinz und Sebastian behaupten, dass ich schon damals agiles Leiten im Blut gehabt hätte … aber ja, wenn ich das agile ­Manifest lese, dann muss ich sagen: Gute Grundlage für erfolgreiche Schule, wenn man es richtig ins Pädagogische übersetzt. Zur Erläuterung für unsere Leser/innen: Wir betrachten in diesem Buchkapitel die „Café-Z-Phase“ unseres Lebens aus den drei verschiedenen Perspektiven des damaligen Lehrers, des damaligen Schulsprechers und des damaligen Schulleiters. Das Café Z war unser traditioneller Treffpunkt, an dem wir Vertrauenslehrer und Schulsprecher beim Arbeitsessen (agil: Definition of Fun) unsere weiteren außerunterrichtlichen Projekte planten. Lehrer: Wenn ich versuche, mir diese Entwicklung im außerunterrichtlichen Bereich in Erinnerung zu rufen, dann hatte es für mich sicher 10 Jahre Schulerfahrungen als Verbindungslehrer lang gedauert, bis mir so richtig klar wurde, mit wem man es bei Schüler/ innen zu tun hat. Die Antwort: Mit ganz normalen Menschen. Und unter den ganz normalen Menschen gibt es die Macher, die man machen lassen sollte, weil sie dann was draus machen. Ja ich weiß, das hört sich etwas komisch an. Ist aber nicht komisch. Denn die meisten meiner Lehrerkolleg/innen würden das zwar möglicherweise nach einer längeren Diskussion auch so sehen. Das mit den ganz normalen Menschen, aber sie leben es nicht. That’s the difference. Also .. So etwa vor einem Vierteljahrhundert entsprang die Grund-Idee einem Zufall.

23.2 Zufall Die Erfolgsgeschichte hat am Faust Gymnasium in Staufen damit angefangen, dass im Jahre 1990 nach einer falsch geplanten Spendenaktion für Polen in der SMV Kasse ein Defizit von 1200 DM war. Wir als Vertrauenslehrer wollten nicht sammeln gehen. Ein glücklicher Zufall, wenn man so will. Wir gründeten ein Lehrerkabarett samt Lehrerband, eigens für eine Benefiz-Veranstaltung, und hatten schon nach den Kartenvorverkauf 3000 DM eingenommen. Ein gutes Plakat und das vollkommen Neue: Lehrer auf der Bühne, das funktionierte. Passte in die damalige Struktur. Vor dieser Veranstaltung mussten die Schulfeten am Faust Gymnasium immer mit schulfremden Bands bestritten werden. Nach der Veranstaltung begann in Staufen die große Gründungswelle von Schülerbands. „Was die Lehrer da auf die Beine bringen, können wir schon lange,“ muss wohl der allgemeine Tenor zu dem zugegebenermaßen nicht gerade professionellen Auftritt von uns Paukern gewesen sein. Das Rockcafé entstand. Die Aula als Veranstaltungsraum für Live Auftritte von Rockmusikern der Schule.

256

H. Bayer

23.3 Der Club Nervend für uns betreuenden Lehrer war nur das dauernde Ausleihen der Anlage, denn der Aufwand und die Leihgebühren waren groß und die Einnahmen blieben sehr klein. Aber wie finanziert man eine eigene Anlage, wenn der Schulträger kein Geld hat, zumindest nicht für Rockmusik. Dazu wurde 1991 für ein Jahr ein schuleigener Club gegründet: der Rockcafé-Club. Mit Clubausweis zum Preis von 30 DM, der gleichzeitig Eintrittkarte für 6 versprochene Veranstaltungen war. Also 5 DM für eine Veranstaltung, für Nichtmitglieder das Doppelte. Große Werbeaktion, so kurz vor Weihnachten, Brief an die Eltern – Clubausweis als Weihnachtsgeschenk, das war ein wichtiger Punkt. Und mit 350 Clubkarten und einem kleinen Kredit vom Förderkreis lief das nächste Rockcafé über die eigene Anlage … Nach drei Veranstaltungen konnte der Kredit schon wieder zurückgezahlt werden. Das Rockcafé hatte sich schnell zu einer Kultveranstaltung entwickelt, man musste dabei sein, sodass trotz Clubausweis immer noch genügend ­Einnahmen in die Kasse flossen. Wir, drei Lehrer und eine Handvoll Schüler waren eine kleine Firma in der Schule geworden, hielten einige Male sogar Betriebsversammlungen ab. (Lehrer) Also wenn das nicht agil war. Ausprobieren, experimentieren, anpassen, ­verwerfen, optimieren, reflektieren … und immer in kleinen Schritten. Es gab natürlich keinen Fünfjahresplan Rockcafé … es gab nur immer die nächste Stufe einer langen Treppe namens Rockcafé, deren Ende keiner kannte. (Manifest) „Anforderungsänderungen gehen vor sturer Verfolgung eines Plans“ heißt der vierte Leitsatz im agilen Manifest. Diesen Leitsatz können wir für unsere ­Definition von „Was ist eigentlich agiles Leiten, Lehren und Lernen?“ gleich mal so ähnlich übernehmen. Allerdings hatten wir es damals mit dem agilen Arbeiten natürlich ziemlich leicht. Denn wir hatten ja keinen Plan, wie sowas gehen könnte. Es ging um Innovation, um Neuland, um ein Feld ohne Erfahrungen, auf die man hätte zurückgreifen können. Der Schulleiter gab den Raum für Innovationen, wir betreuenden Lehrer gaben den Raum für Innovationen und die Macher unter den Schüler/innen bretterten los. (Schüler) Als das damals alles losging (1991), war ich in der 9ten Klasse und rutschte deshalb wohl da rein, weil mich der Heinz fragte, ob ich nicht Lust hätte, mich auch an einem Abend mit einer Handvoll Schüler bei einer der Vertrauenslehrerinnen zu treffen. Das war natürlich total aufregend. Nicht nur dabei sein zu dürfen, sondern mich auch richtig einbringen zu können. Wir konnten uns quasi unsere eigene Bühne schaffen, auf der wir uns kreativ, musikalisch, theatralisch und diskutierend austoben konnten. Bezeichnend damals war vor allem das Grundverständnis, dass wir Schüler das alles machten, also wirklich alles, vom Programm, vom Aufbau und Abbau, bis hin zur Bewirtung, etc… und das Grundvertrauen, das uns entgegen gebracht wurde. Vertrauen in unsere Fähigkeiten, die uns gegebenen neuen Freiräume nutzen zu können und das Vertrauen darüber wieder zurückzugeben.

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

257

23.4 Rockcafé Die Bands sprossen aus dem Boden. Showmäßig aufgezogen, mit Showmaster, Rockmusik und Einlagen aller Art (Kabarett, Lesungen, Tanz, Sketche …) wurde das Rockcafé der Ort, an dem aktive Schüler/innen zeigten, was sie auf die Füße stellen konnten. Wir Vertrauenslehrer hatten in der Zwischenzeit den Part der Organisation vollständig an die Schüler abgegeben. (Bitte immer auch Schülerinnen mitlesen) Technik, Auf- und Abbau, Verkauf, Programmgestaltung … alles völlig in Schülerhand. Das war der Beginn des „Konzepts Schülerschule“. Denn die Idee Rockcafé zeigte, dass sich Schüler durch Organisation und Dienstleistung eine eigene finanzielle Basis schaffen können. Unterstützung durch uns Vertrauenslehrer und Rückhalt in der Direktion natürlich eingeschlossen. ­Eigenes Geld erzeugt viel Freiheit im Planen. Unabhängigkeit. Eine Firma in der Schule. Schülerfirma. Kein Schulersatz, sondern bunte lebendige Schulergänzung. Keine Zuschüsse mehr beantragen zu müssen, macht den Kopf frei für neue Ideen, wie z. B. das erste große Open Air am Schuljahresende 1993. Der Wunsch nach einem eigenen Proberaum kam dann ein Jahr später. (Lehrer) „Agilität bedeutet in erster Linie Haltung“ heißt es oft. Ja und genau das war es damals. „Lass die Macher und -innen dran. Und vergiss, dass sie Schüler/innen sind.“ Das war unser Zauberansatz, der viele verblüffte. Weil man es zum Beispiel den ersten beiden Rockcafémoderatoren Gerrit und Christian natürlich nicht ansah, dass der eine später den angesagten Schick- und Schön-Club in Mainz gründen würde und der andere heute Theaterdirektor in Gütersloh ist. Pädagogik auf Augenhöhe. Unsere Faustteams waren Scrum-Teams. Manche Entwicklungen gingen im Wochen-Sprint. ­ Unsere Café-Z-Sitzungen mit den Schulsprechern waren echte Reviews. (Schüler) Die Planungs-/Arbeits-Sessions im Cafe Z, die wir später als Schulsprecher regelmäßig mit den Vertrauenslehrern hatten, zeigten jedes Mal, dass wir die Initiatoren waren, wir unsere Ideen ausleben konnten. Die Vertrauenslehrer fungierten hier quasi im Hintergrund, beratend, manchmal auch bremsend, aber letztlich als wohlwollende Lehrer, die uns einfach machen ließen. Das erzeugte in uns das Gefühl, was schnell zur Gewissheit wurde, dass wir ernst genommen wurden. Was wir aus der metaphorischen Bühne machten, lag an uns. Es war wie ein Feld, das wir bestellen konnten. Und es blieb, wie vielleicht abzusehen war, nicht bei nur einem Feld, sondern daraus entstand ein vielfältiges Netz an Aktivitäten, die als Resultate aus dem Boden schossen. (Manifest) Schauen wir mal wieder in das agile Manifest: „Die Beteiligten und ihre Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge“ steht da an erster Stelle und „Die Zusammenarbeit mit den Kunden ist wichtiger als Vertragsverhandlungen“ an dritter Stelle. (Lehrer) Na klar, Nummer eins übernehmen wir doch gleich so mit. Als Lehrer würde ich im Rückblick sagen: Bei diesem Konzept der Schülerschule waren die aktiven Schüler/innen und wir aktiven Lehrer/innen die Beteiligten und unsere Zusammenarbeit war natürlich die zentrale Grundlage. Die Prozesse und die Werkzeuge zum Beispiel für

258

H. Bayer

dieses konkrete Projekt Rockcafé & Co hatten wir selbst im Ausprobieren entwickelt und optimiert. Nach 25 Jahren Rockcafé können wir behaupten: Es funktioniert genau ­deshalb noch immer, weil die Beteiligten und ihre Zusammenarbeit an erster Stelle stehen. Die Zusammenarbeit mit den Kunden würde ich hier ein wenig vertiefen: Als Lehrer war mir immer klar: Ich bin Dienstleister und ich habe Kunden: Meine Schüler/ innen. Hört sich normal an, ist es aber leider nicht. Statt Vertragsverhandlungen können wir vielleicht Notenverhandlungen setzen. Dieses leidige Thema, das die positive Dienstleistung immer wieder aus der Bahn kippen kann, wenn man nicht zweitrangig damit umgeht. Noten sind nur Wegweiser. Mehr nicht. Meine Kunden müssen vorgehen.

23.5 Faustgefühle Es gab an der Schule einen alten ungenutzten Fahrradkeller und der Schulträger stimmte dem Plan für einen Probenraum zu – nur Geld war leider keines da. Selbstfinanzierung. Diesmal eine Stufe weiter. Die Bedingung von der Baubehörde – eine Fluchttür samt neuer Treppe – wurde mit 25.000 DM veranschlagt. Die damaligen Schülersprecher/ innen überzeugten den Förderkreis, dass ein zinsloser Kredit Aussicht auf Zurückzahlung hätte. Aber: 25.000 DM sind viel Geld. Schul-CD hieß das neue Konzept: Aufwendige Werbung, guter Vorverkauf. Ein Gerümpelkeller als provisorisches Studio. Schüler am Mischpult. 17 schuleigene Bands. 14 Tage Aufnahmen. Juli 95. Das Experiment klappte. ­­ 15.000 DM Gewinn – die Vertrauenslehrer als Betreuer – nicht als Macher. Da-sein, Beraten, Bestärken, Aufschließen, Kaffee kochen. Die Profis waren die Schüler. Der Restkredit eines anonymen Privatsponsors, der sich später als der Direktor selbst entpuppte, wurde durch viele Veranstaltungen abbezahlt. Nachdem der Ausbau eines Probekellers für Schülerbands mit der ersten provisorisch produzierten Schul-CD „faustgefühle“ finanziert werden konnte, kam in der Euphorie die Idee vom eigenen ­Tonstudio inklusive Proberaum. (Schüler) Das war so ziemlich das Verrückteste, was wir vier Schulsprecher damals gemacht hatten: einen Proberaum bauen zu wollen und dafür einen Kredit aufzunehmen über 25.000 DM, für den wir vier persönlich unterzeichneten. Meine Eltern sind beinah ausgerastet. Aber damit noch nicht genug: Wir wollten dieses Geld zurückzahlen, indem wir eine CD mit Schülerbands aufnehmen wollten (so was war damals total neu), um diese CD zu verkaufen, bevor sie überhaupt aufgenommen war. Quasi eine doppelte Verrücktheit. Und auch wenn uns von den Kreditgebern immer wieder gesagt wurde, wir bräuchten das nie zurückzuzahlen, war dies dennoch genau unser Anspruch, weshalb wir das auch persönlich unterschrieben. Nach weniger als einem halben Jahr war das Geld zurückgezahlt. Dazu muss man aber auch symbolisch die Rolle des Schuldirektors herausstreichen: dass er uns 10.000 DM aus eigener Tasche gab (und uns das Versprechen abrang, dass wir niemandem sagen dürfen, dass dies von ihm kam) sagt so ziemlich alles aus: Denn neben den Vertrauenslehrern war es unerlässlich, dass von höchster Stelle auch die Unterstützung und das Vertrauen kam.

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

259

(Direktor) Im Jubiläumsband 2015 „50 Jahre Faust“ schreibt Günther Scheunemann über Leitungsaufgaben: „Du hast die Aufgabe, Freiräume zu schaffen, dafür Kontakte zu knüpfen und Finanzquellen aufzutun, denn ohne Moos nix los. Du bist Teamplayer, denn das Einzige, was du allein tun kannst, ist NEIN-Sagen; für alles andere brauchst du motivierte und engagierte Mitarbeiter auf allen Ebenen.“ (Lehrer) Agile Leitung, wie wir sie verstehen. Unser damaliger Chef tut auch heute noch so, als wäre das ja nix gegen das gewesen, was wir mit den Schüler/innen auf die Beine gestellt haben. Dabei würden Seb und ich natürlich sagen: Es ist die zentrale Grundlage. Ohne agile Leitung kein agiles Lehren, Lernen und Forschen. Warum wir Forschen hier mit im Titel haben? Wenn Schüler sich z. B. selbstständig kundig machen, wie man ein professionelles Tonstudio aufbaut und betreibt, welche Geräte man benötigt und wie die Bausubstanz sein muss, dann ist das Forschen. Forschen ist nicht zu trennen vom Lernen. Das bei uns damals auf allen Ebenen stattfand. Leitung, Lehrende, Lernende. Lebenslang wie man so schön immer sagt. Und es wurde in vielen Teams viel geforscht, viel gelernt und viel weitergegeben. Also auch gelehrt. Schülerschule war nicht nur so ein smarter Begriff. Aber alles natürlich im Schutzraum der agilen Leitung. Denn die agile Schulverwaltung steht noch in den Sternen.

23.6 Fauststudios Staufen Der Ausbau fand in Eigenregie statt. Einnahmen aus Konzerten und Festen, Rockcafés und Open Airs samt Unterstützung einiger begeisterungsfähiger Sponsoren bildeten das finanzielle Fundament. Die „Werbeabteilung“ der fausTeams nutzte gewonnene Wettbewerbe und die Registrierung als dezentrales EXPO2000 Projekt für ihre Zwecke. Mit Fördergeldern von der Schulstiftung Baden-Württemberg und Sponsorengeldern konnten sich die Rockcafé-Aktiven des Faust Gymnasiums ihren Traum erfüllen. Ein ­eigenes digitales Aufnahmestudio. Im Juli 99 kam die Doppel-CD „s’cool regio music“ auf den „Schulmarkt“, die erste Jahresproduktion von Jugendlichen des Faust Gymnasiums ­Staufen im neuen, professionell eingerichteten Studio. 22 Schulbands der Regio sind darauf mit selbstkomponierten Songs verewigt. Das dritte große CD Projekt wurde 2000 abgeschlossen: „FG-DJ-2000“, ein digitales, multimediales Jahrbuch auf CD-ROM, war eine Herausforderung für die Tontechniker, Videospezialisten, Designer, Texter, Musiker, Computerfachleute und Organisatoren unter den Schülerinnen und Schülern der Schule. Das Tonstudio wurde damals mithilfe des Kultusministeriums digital komplettiert. Neben einem Computernetzwerk verfügten die faustaktiven Schülerinnen und Schüler nun auch über eine digitale Videoschnittstelle samt Kamera. Für zwei Jahre konnte sich ein recht erfolgreiches Videoteam behaupten. Auch ein spezielles Netzwerkteam zum Erlernen von Netzwerkadministration wurde von ein paar Schülern im Studio initiiert. Und ein Team hatte sich Programmieren auf die eigenständigen Fahnen geschrieben. Schüler unterrichten Schüler. Schülerschule.

260

H. Bayer

(Manifest) Noch ein bisschen agiles Manifest gefällig? Vier Leitsätze umfasst es. Auf die wesentlichen Aussagen reduziert, die eine Softwareschmiede effektiver und optimaler Software entwickeln lässt. Ein klares Ziel für den umkämpften Markt. Den zweiten Leitsatz hatten wir noch nicht: „Lauffähige Software hat Vorrang vor umfassender Dokumentation“ heißt er. „Ein wenig schade“ fanden wir damals, dass so eine Schule nicht in einer gewissen Konkurrenzsituation steht. Ob sie innovativ arbeitet oder nicht, ob sie viel zusätzliche Energie einsetzt oder nicht … die Deputate bleiben die Deputate … Allerdings, das was sich ändert, ist die Zufriedenheit der Akteure. Und das trägt, wer es einmal richtig geschmeckt hat. Unsere boomende Schülerschule entsprach der entwickelten Software und klar hätten wir damals schon im ersten Jahr dicke Dokumentationspapiere herausbringen können. Wir haben die Zeit lieber für die agilen Aktionen verwendet. Kurzum: Für unser außerunterrichtliches Projekt Schülerschule können wir die vier ­Leitsätze des agilen Manifestes schon einmal gut verwenden. Ob sie am Ende ausreichen, agiles Lehren und Lernen im Ganzen unter ein Dach zu bekommen, wird sich zeigen. So, wir hören an dieser Stelle einmal auf, Geschichten zu erzählen. (Lehrer) 25.000 DM Kredit – von 4 Schüler/innen aufgenommen. „Häää? Wie soll denn sowas gehen?“ werden viele denken. Wenn man agil arbeitet, geht sehr viel. Wenn man die Akteure ernst nimmt, weil es in unserem Falle ja auch gar nicht anders ging, dann funktioniert vieles, das man sonst niemals auf die Beine stellen könnte. Wenn du eine CD produzieren willst, aber als Lehrer keine Ahnung von Tontechnik hast, dann nimmst du doch gerne die Kompetenz von Schülern an, die Ahnung haben. Schon klar: Dieses Konzept Schülerschule ist nicht direkt übertragbar auf den normalen Schulalltag. Weil wir dort mit Scrum-Teams gearbeitet haben, die aus hochaktiven und hochmotivierten Menschen bestanden. Der erste Tontechniker der Faust-Studios hat später bei Paul McCartney studiert. Von dem Kredit hat mein Mitautor ja selbst was erzählt. Ein Vierteljahrhundert danach. Im Fortbildungsskript vor 10 Jahren hat er sich auch schon einmal geäußert.

23.7 Bemerkungen vom anderen Ende der Welt (Schüler) Mannomann, also, meine drei Weisheiten zur Schülerschule. Ist nicht einfach, wenn man in dieser Schule groß geworden ist, nein, das ist falsch, ich bin in ihr erwachsen geworden. Also, das ist jetzt auch nicht ganz richtig. Denn diese Schule war ja gerade erst im Begriff zu entstehen, sie gab’s in dem Sinne noch nicht so richtig. Genauso wenig den Begriff Schülerschule. Ich denke, dass ich großes Glück hatte, genau in der Phase am Faust sein zu dürfen, als alles entstand. Und – und das denke ich ist die Kernaussage – dass ich da mitgestalten durfte. Denn so komisch und ideell das für Außenstehende klingen mag, wir haben unsere eigene Schule gemacht. Nein, nicht den Unterricht, aber alles drum herum. Damit wurden wir groß. Und damit wuchs dann wiederum etwas, was so sicherlich einmalig war in der deutschen Schullandschaft.

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

261

Schüler in voller ­Verantwortung, aber auch in vollem Vertrauen des Direktors und der Ver­ trauenslehrer. Uns wurden kreative Freiräume gegeben, die wir dankend annahmen, sie aber auch einforderten und damit plötzlich neben dem Lehrplan die Chance bekamen, uns als Menschen zu entfalten, Eigenverantwortung zu üben, es lernten, vor großen Gruppen zu reden, zu verkaufen, zu begeistern, zu motivieren, zu delegieren – das alles aber nicht als Einmann/-frau Show sondern als Team. Vier von uns. Wenn ich heute in der Vorlesung stehe und sich alle neugierigen Augen von Undergraduate Studenten auf mich richten, bin ich erstaunlich ruhig. Es ist einfach wie damals, egal ob als Band beim Open Air, oder als wir vor den Elternvertretern und der Gesamtlehrerkonferenz unsere Ideen zu Suchtprävention oder Schul-CD verkauften, Kredite einforderten und dergleichen. Es ist fair zu sagen, dass ich mit und dank der 5 Jahre SMV als Mensch gewachsen bin. Nicht, dass mir dies damals bewusst gewesen wäre. Da zählte nur der Spaß und das Engagement und Ideen nicht nur zu spinnen, sondern auch umzusetzen. Aber ich merke das heute, dass ich damals als Persönlichkeit unglaublich gereift bin, ja eben auch durch und mit der Schülerschule erwachsen geworden bin. Die andere wichtige Erkenntnis ist, dass wir uns nie NIE von leeren Kassen des Schulträgers, Landes, von den gehobenen und warnenden Zeigefingern von Eltern oder anderen Mitschülern davon haben abhalten lassen, unsere Ideen durchzusetzen. Schließlich hielten uns alle für total verrückt, die 15.000 Mark für das Rockcafé aufzunehmen. Niemand traute uns das zu. Ha, denen haben wir’s gezeigt. Und das gab den Optimismus für die persönliche Bürgschaft für die 25.000 Mark für Proberaum und Schul-CD. Es war eine absolute Initialzündung, persönlich zu erfahren, dass vorhandene Hindernisse immer nur dann Hindernisse sind, wenn man vor ihnen verzagt. Es geht auch trotz knapper Kassen und dazu noch in einer Form, die Eigenverantwortung stärkt, und diese in Verbindung mit Ideen zu gelungenen Projekten führen kann, die Schule zur Erlebniswelt machen, die über Unterricht klar hinausgeht. Hier konnten wir uns als Menschen einbringen, sozial, menschlich, organisatorisch, als Teamplayer, als Individuen, als Musiker, Kameramann, Grafiker. Es zeigt ganz klar, dass man Schülern einfach mal was zutrauen sollte, ihnen eine Bühne (also Frei- und Entfaltungsräume) geben muss, denn dann entsteht etwas, das wirklich dem immer mehr eingeforderten Begriff der Schule als Erziehungsort gerecht wird. Das Faust steckt tief in mir drin und es ist einfach wahnsinnig irre zu sehen, dass sich das mittlerweile von Generation zu Generation weitervererbt. Somit war das keine Eintagsfliege, sondern vielmehr Beweis dafür, dass es genau so etwas braucht. Schülerschule als Ort der Persönlichkeitsentwicklung, als Gemeinschaft, die das gemeinsame Einbringen von Ideen und Engagement nicht nur erklärt, sondern als Inbegriff des eigenen Selbstverständnisses fördert und fordert, es schätzt und anerkennt. Wie gesagt, ich durfte dabei sein, aber gleichzeitig durfte ich einer derjenigen sein, die dies aufgebaut haben. Wenn man sich später im Studium oder auch jetzt im Job an der Uni mit Leuten nicht nur aus anderen Gymnasien, Bundesgebieten, Ländern und Kontinenten über ‚back in those days‘ unterhält, dann merke ich immer wieder, wie das Faust in dieser Hinsicht einzigartig war. Ich ging nicht nur an’s Faust, ich ging auch im Faust auf – als Mensch!

262

H. Bayer

(Lehrer) Also klar, Herr Doktor. Da würde ich doch in Sachen Agiles Lernen und Lehren meinen: Exemplarisch. Raum geben. Ziele gemeinsam festlegen. Ausprobieren. Und eben: Haltung untereinander. Gegenseitig ernst nehmen. Klar, mir fiel es nach so langer Zeit als Vertrauenslehrer irgendwann leicht, weil es ja klar war: Schüler/innen, die du nach 10 Jahren beim Abiball wieder triffst, die zeigen dir unentwegt: Die Leute, die du damals als Physiklehrer in Physik ausgebildet hast, die sind alle ganz unabhängig von deiner Physik und der Note in Physik ihren Weg gegangen. Ich habe in der zentralen Phase von Schülerschule einmal mit zwei Schülern einen Netzwerkkurs für Referendare angeboten, obwohl ich als Netzwerkadministrator die Netzwerktechnik nur mithilfe von Schülern beherrschen konnte. Ich habe mich auch gar nicht erst so richtig bemüht, weil ich ja gut schülerteamfähig war. Der Kurs lief so: Ich war der Fortbildungsleiter, habe die jungen Kollegen empfangen, erzählt, vermittelt und dann, wenn es um die technischen Geschichten ging, haben Conny und Tom übernommen. Fließend und souverän. Ja klar, der eine entwickelt inzwischen ja auch souverän Solarmodule für einen chinesischen Konzern („Einer der guten“ meint er immer) und der andere entwickelt Zukunftstechnik bei BMW. Conny hatte übrigens als Schulsprecher den Begriff vom „Prinzip Kaktus“ erfunden. „Der Kaktus ist ein Gewächs, das mit wenig Pflege auf kargem Boden oft erstaunliche Blüten treibt. Der Kaktus geht aber auch bei zu viel Pflege ein. Der Kaktus ist ein Gewächs, bei dem man für viel Fleisch und Substanz eben auch Stacheln in Kauf nehmen muss – sicher keine bequeme Pflanze, aber eine mit ungeheuer effektiver Leistungsbilanz.“ Ja klar, das war die Erfahrung der damaligen Aktiven am Faust: Ihre ernst genommene außerunterrichtliche Arbeit war für so manchen Lehrer schon recht stachelig. Die Aktiven hatten Rechte, die man als Schüler/in eigentlich sonst nicht hat. Bekamen Freiräume, die nicht so leicht steuerbar waren. Erkämpften sich Eigenständigkeiten, die für so manche Lehrperson schwierig zu schlucken war. So würde ich das übrigens auch für agiles Lernen im Unterricht sehen. EduScrum von Willy Wijnands ist eine sehr starke Vorlage für einen hocheffizienten Unterricht mit sehr vielen Freiräumen für Schüler/innen. Aber dass sich dabei die Rolle des Lehrers komplett verändern muss und seine Haltung Schülern gegenüber eine wesentliche Rolle spielt, ohne die das Prinzip Scrum niemals funktionieren wird, das muss klar sein, bevor man sich agilen Methoden beim Unterrichten nähert. (Manifest) Wie wäre es mal wieder mit einem Ausflug zum agilen Manifest. Immerhin treten wir hier gerade an, um den Begriff „Agiles Leiten, Lehren, Lernen und Forschen“ mit Inhalten zu füllen, die nicht nur für unsere frühere kleine „Subkultur am Faust“ gilt, wie sie unser Chef oft liebevoll beschrieb, sondern für möglichst viele Ansätze und pädagogische Ideen, die an vielen Bildungseinrichtungen das Licht der ­pädagogischen Welt erblicken.

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

263

23.8 Auf der Suche nach dem pädagogisch agilen Manifest Die „Agile Alliance“, siebzehn unabhängige ‚leichtgewichtige‘ Software-Methodologen, trafen sich im Februar 2001, um miteinander zu reden und eine gemeinsame Basis zu finden (Siehe auch Kap. 1). Sie einigten sich auf ein Manifest für die Agile Softwareentwicklung. Des Weiteren definierten sie eine Reihe von zwölf Prinzipien hinter dem Manifest, die hier in voller Länge wiedergegeben sind und wir sie für unser Projekt interpretieren: (Original kursiv geschrieben). Den Kunden durch die rechtzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen ist unsere höchste Zielsetzung…. Unsere Schüler/innen mit unseren Freiräumen und Unterstützungen kontinuierlich zufrieden zu stellen, das hatte hohen Stellenwert. Die Entwicklung der Inhalte war in unseren Projekten Kundensache. Wir begrüßen Änderungen der Anforderungen, auch wenn diese spät in der Entwicklung kommen. Agile Prozesse nutzen den Wandel für den Wettbewerbsvorteil des Kunden…. Jeder Jahrgang ist anders, die Hochaktiven kamen und gingen. Die Bedingungen glichen sich nie in den vielen Jahren. Agiles Denken hat es uns ermöglicht, den Wandel als Vorteil zu sehen und zu nutzen. Wir liefern funktionierende Software häufig, alle paar Wochen oder Monate, wobei wir die kürzeren Zeiträume bevorzugen. …. Klar es gab schon auch Jahresplanungen. Aber die waren eher auf dem Papier festgelegt. Wie sie dann als „funktionierende Projektsoftware“ auf den Schulmarkt kamen, hatte immer den Drive des „Auf den letzten Drücker“ – Feelings. Geschäftsleute und Entwickler müssen täglich im Projekt zusammen arbeiten…. Ja klar, es gab das Café Z und es gab die Pausen. Und es gab das Studio mit regelmäßigen Treffen. Aus Lehrersicht würde ich im Rückblick über Jahre meinen: Ja, dieses täglich im Schulalltag Zusammenstehen und Austauschen … kurze Wege … als Lehrer kannte ich immer die Orte, an denen ich die richtigen Leute in den Pausen treffen konnte … Häkchen auch bei diesem Punkt. Setze motivierte Individuen in den Projekten ein. Gib ihnen die Umgebung und Unterstützung, die sie brauchen, und vertraue ihnen den Job bestens zu erledigen. … Na ja, da denke ich, brauchen wir nix zu verändern. Das passt natürlich genau zu unserem damaligen Konzept. Die Konversation von Angesicht zu Angesicht ist die effizienteste und effektivste Art der Informationsweitergabe an und in einem Entwicklungsteam…. Wir hatten damals noch keine digitalen Netzwerke zur Verfügung. Aber ich würde das auch heute noch unterstreichen. Email, Facebook und andere Vernetzungen können gut unterstützen, aber ersetzen niemals die direkte Kommunikation. Menschen sind eben Sozialwesen. Das primäre Maß für Fortschritt ist die funktionierende Software! … Das primäre Maß für gute Projektarbeit ist die Tatsache, dass die Beteiligten in der Sache, für die die Veranstaltung Schule mit hohem finanziellen Einsatz am Laufen gehalten wird, ihren

264

H. Bayer

persönlichen Gewinn erzielen können. Das kann sehr vielfältig sein und hängt in erster Linie nicht mit Noten zusammen. Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten ein gleichbleibendes Tempo ohne Unterbrechung einhalten…. Ja auch das ist in der Erinnerung genau richtig. Das agile Arbeiten in einem Netzwerk mit vielen eigenständigen Teams konnte nachhaltig über viele Jahre auf hohem Niveau stabilisiert werden. Stillstand gab es eigentlich nie, weil es immer wieder neue Hochaktive gab. Technische Exzellenz, gutes Design und deren fortwährende Beachtung verbessern die Agilität. … Auf das Rockcafé übertragen können wir nur nicken. Rockcafé, Club, Open Air, Studio … Wir wurden Jahr für Jahr besser. Einfachheit ist essenziell. … Jawohl. Es gab flache Hierarchien und es gab wenig Kompliziertes. Wir sind auch hier dabei. Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren…. Ach ja, die Fausteams. So nannten wir die vielen verschiedenen Bereiche, die sich mit dem Konzept Schülerschule entwickeln konnten. Genau dafür bekamen wir übrigens den Adelstitel „Anerkanntes dezentrales EXPO2000-Projekt“. Das Team reflektiert in regelmäßigen Intervallen darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an…. Ja klar, ja klar. Wir sagen nur: Café Z … Da wurde genau das gemacht: Reflektiert, angepasst, optimiert, geplant … (Lehrer) Und natürlich muss bei allem eines klar sein: Auch der Chef eines solchen agilen Unternehmens wie z. B. der damaligen Schülerschule muss agil denken und viele Freiräume akzeptieren und deren Kaktuseigenschaften aushalten lernen. Hören wir doch dazu unseren damaligen Direktor. Ebenfalls ein Kommentar aus dem pädagogischen Schweizermesser. Unsere Meinung: Ohne agile Verwaltung kein agiles Lehren und Lernen.

23.9 Zutrauen und Vertrauen (Schulleiter) Das Einzige, was ein Schulleiter (lesen Sie bitte immer auch ‚die Schulleiterin‘!) allein bewirken kann, ist Schulentwicklung zu verhindern. Dies schafft er alleine. Und zwar mehr durch die legale Forderung „ich bin rechtlich verantwortlich, also läuft alles ausschließlich über meine Person“ als durch ein Initiativen blockierendes Nein. Für alles andere, also gerade die Schulentwicklung, das Schulklima, das Image der Schule und der Qualität des Unterrichts benötigt er die Mitarbeit seines Kollegiums, der Elternschaft und besonders die der Schüler. Erziehung und die Erziehungsanstalt Schule lebt von Zutrauen und Vertrauen, Transparenz und einem pädagogisch-grünen Daumen der Verantwortlichen. (Lehrer) Schon die ersten Zeilen unseres Schulleiters von damals zeigen die Grundhaltung für eine agile Schulkultur. Für eine Schulkultur der Auseinandersetzung und ­Entwicklungsfähigkeit. Für Augenhöhe. Für Teamarbeit. Für flache Hierarchien. (Schulleiter) Erste Maxime: Sei präsent.

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

265

Richtig agieren ist nur möglich, wenn der Schulleiter seine Schule und die Schulgemeinde kennt. Dazu muss er in seiner Schule sein, möglichst täglich, und seine Türe offen halten, zuhören mehr als reden, aber auch zügig entscheiden. … … Sein Verwaltungsteam muss mehr sein als der Stab der Berater. Das Team hat auch die Funktion von Multiplikatoren der erarbeiteten Gedanken. Sie sitzen im Lehrerzimmer und diskutieren mit dem Kollegium in kleinen Gruppen, nehmen Impulse, Befürchtungen und Kritik auf und federn ab, leiten sie in die nächste Teamsitzung weiter … Das so vordiskutierte Thema dann in einer Gesamtkonferenz mit allen Lehrern ­zeitökonomisch zu verabschieden, führt auch zu einer besseren Akzeptanz der sonst nicht gerade beliebten Monatskonferenzen…. (Lehrer) Kleine Teams, funktionierende Vernetzung, agile Verwaltung, schnelle Umsetzung, Transparenz (Schüler) Die Idee, dass Kollegen und das Verwaltungsgremium mehr sind als Berater, war genau die Einstellung, die von Direktorenseite uns Schülern entgegengebracht wurde. Wir wurden als Partner behandelt, als auf Augenhöhe Agierende, die ernst genommen wurden und die häufig gezielt auch um Rat gefragt wurden. Teilweise haben wir Dinge vertraulich besprochen, die für das klassische Bild des Verhältnisses Lehrer zu Schüler total ungewöhnlich ist. Aber damit waren wir aktiver Teil unserer Schule. Wir konnten also nicht nur Angebote annehmen, wir waren selber Anbieter. (Schulleiter) Wenn ein Lehrer 35 Jahre, praktisch vom ersten eigenständigen Arbeitstag bis zu seinem Ausscheiden an derselben Schule bleibt, ist dies in Deutschland nicht ungewöhnlich, führt aber auch selten zu Aufbruchsstimmung, zu neuen Wegen, zu Besonderem. Wenn dieser Mensch dann noch die letzten 15 Jahre Schulleiter ist, was sollte aus solch einer Schule auch werden?! Aber so war es am Faust. Ich begann hier, bewegte mich durch alle Bereiche der Schulorganisation, von der Leitung der Chemiesammlung, über die Organisation der Krankenvertretung, des Stundenplans, des Schulhaushalts, der Lehrauftragsverteilung, wurde so „heimlicher Direktor“ und dann wirklich Chef. Die dabei erworbenen Detailkenntnisse haben sich als gute Basis für dieses Amt erwiesen: Ich hatte die Organisation im Griff. Das ist die erste Voraussetzung für pädagogische Arbeit (Organisatorisches Chaos lässt keine Luft für pädagogische Themen). (Lehrer) Die Strukturen müssen stimmen. Agile Verwaltung ist nicht Laissez faire. Aber Organisation im Griff heißt noch nicht agiles Leiten. (Schulleiter) Die zweite Maxime war mein Credo: Jeder Mensch versucht zunächst, positiv zu wirken, will im Erfolg stehen, Anerkennung erreichen. Er wird sich dafür mit großer Intensität selbst motivieren. Gib ihm eine Chance, egal ob Kollege oder Schüler. Wenn sich jemand destruktiv verhält, die Motivation verliert oder ausgebrannt resigniert, waren Türen verschlossen, fehlte die Kommunikation, bauten sich Wände auf oder fehlte die Hilfe oder auch nur das Ohr des Chefs. Schulleitung braucht Mut, denn Erziehung braucht Mut. Mut ist Voraussetzung für Zutrauen gegenüber Kollegen, Mitarbeitern, Schülern. Die Schulleitung braucht aber Mut auch zu Widerspruch nach oben.

266

H. Bayer

(Lehrer): Gute Schule braucht Autonomie in vielen Bereichen. Pädagogische Schulführung bedeutet Raum lassen, Zulassen, Zutrauen, Ertragen von vielen verschiedenen Ansätzen … alles innerhalb der im Kollegium abgesprochenen pädagogischen Zielvorstellung für die Schulentwicklung. (Schüler): Agilität entsteht, indem man jedes Mitglied einer Organisation auch als Mitglied sieht. Nur so wird das Gebilde Schule mit all seinen Hierarchien zu einem lebendigen Organismus. Nur so entsteht Vielfalt, und so werden Räume geschaffen, von Schülern mit ihrer Energie und ihrer Kreativität. Aber dafür braucht es tatsächlich Mut vonseiten der – ich hätte beinahe ‚Verantwortlichen‘ geschrieben – aber das ist nicht ganz richtig, denn verantwortlich waren ja nicht nur die Schulleitung oder die ­Vertrauenslehrer, sondern auch wir Schüler. (Schulleiter) Zutrauen zu Schülern: Sein Problem anhören, sein Projekt vorstellen lassen, die Voraussetzungen klären, auch die versicherungsrechtlichen. Aber das Wichtigste: Zur Durchführung ermuntern. Bei Erfolg ist dies dein/euer Erfolg, wenn es nicht klappt, stehe ich als Schulleiter dafür ein. (Lehrer) Ja klar, das war natürlich unser großer Joker im Ärmel für unser Thema Schülerschule. Unser Chef, der uns den Raum und das Vertrauen gab und wir, die wir dieses Prinzip an unsere aktiven Schüler/innen weiterreichten. Ein Erfolgsrezept. (Schulleiter) Die Jugend ist besser als ihr Ruf. Diese meine Aussage zum Amtsantritt war auch meine Überzeugung. Aber dass die Schüler dies Wort so ernst nahmen, sich ernst genommen fühlten, war wiederum für mich sehr anstrengend. Es lief in den 15 Jahren so erfreulich viel, ich war immer überzeugt, dass ich nicht alles wusste … und habe dies ausgehalten, wurde nie enttäuscht. Schüler arbeiteten, gerade auch an Wochenenden und in den Ferien, bis tief in die Nacht im Studio oder Schulhaus, brauchten einen Hausschlüssel und schliefen dann wohl darauf. Schüler packten ihr Schulhaus à la Christo komplett in rote Folie, eine ganze Jahrgangsstufe stand dazu auf dem Dach. Ein Fehltritt und mir wäre der Prozess gemacht worden. Es war ein unruhiger 12-Stunden-Tag, fast permanent draußen, drunten. Glück des Mutigen, Stolz der ganzen Schule. Jahre später Ähnliches bei einer Schulhausillumination der gesamten Hausfassade zur Winterszeit. „Faust leuchtete“, weithin in die Landschaft. Und war fast 2 Wochen Anziehungspunkt für die Region. Der Schulleiter trug und ertrug die Verantwortung. Kranksein allerdings war bei so viel Betrieb einfach nicht möglich, kalte Füße bleiben da wohl aus. Zutrauen zu Lehrern: „Ich kann Ihnen nicht mehr Gehalt geben, bin bei Ihrer Beförderung nur wenig beteiligt, in Ihrer Arbeitszeit habe ich wenig Spiel … aber ich gebe Ihnen den Freiraum, Ihren Arbeitsplatz Schule für sich selbst zu gestalten.“ Sie haben diesen Freiraum vielfach, auch in weniger spektakulären Projekten, genutzt und viele methodische und kreative Veränderungen zogen so im Faust ein. Kollege Bayer hat geschildert, wie die Schulentwicklung auf Schülerseite lief, chronologisch und mit einer bewundernswerten Eigendynamik. Auch hier in Teams, aber auch in Kleingruppen. Projekte, die in recht kurzer Zeit erfolgreich waren, ebensolche, die über Jahre von verschiedenen Personen weitergeführt wurden…..

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

267

(Lehrer) Ja, das war schon sehr magisch, wie viele Hochaktive im Laufe der Jahre in diesen Modus des Aktivseins rutschten. Immer wieder, Jahrgang um Jahrgang. „Gebt Jugendlichen maximal viele Möglichkeiten, sich zu begeistern, sich zu beweisen, sich einzusetzen, aktiv zu werden, selbst Inhalte zu finden, eigene Fähigkeiten zu entdecken, ernst genommen zu werden – dann verändert sich Schule.“ Das war in den zentralen Zeiten von unserer konzeptionellen Arbeit die Grundaussage und wir konnten sie mit Händen greifen. Wir haben übrigens jahrelang zur Beruhigung der Eltern hochaktiver Schüler/innen den Abiturschnitt der Hochaktiven berechnet. Er war immer besser als der Jahrgangsdurchschnitt. Wenn auch wie gesagt „Prinzip Kaktus“ … stachelig für so manchen älteren Kollegen war und Eltern sich fragten, ob so ein Einsatz nicht vom Lernen abhält. Der Chef dazu: (Schulleiter) Hat mich ungemein viel Kraft und Zeit gekostet, diese alten Herren (meines Alters) wenigstens zum Stillehalten zu bewegen: „Sie müssen ja selbst nicht mitmachen, aber lassen Sie anderes wenigstens zu.“ Irgendein Hardliner hat mir in einer offenen Stunde mal anvertraut „Ich brauche diesen Panzer, diese Sicherheit im ­Althergebrachten, sonst schaff ich das hier nicht mehr“.

23.10 Kontextsteuerung und agiles Leiten Problemstellung: Mit Blick auf das Verhältnis von Innovation und Nachhaltigkeit stellen sich zwei grundlegende Fragen: erstens, inwieweit sind Innovationsprozesse steuerbar, und zweitens, kann die „Trefferquote“ von Innovationen im Sinne eines positiven Nachhaltigkeitsbeitrages im Prozess der Entstehung und Realisierung von Innovationen substanziell beeinflusst werden? Diese Fragen müssen vor dem Hintergrund zunehmender Dynamik und steigender Komplexität von Innovationsprozessen betrachtet werden. … (aus Potenziale eines gesellschaftstheoretischen Steuerungskonzeptes für das Innovationsmanagement 2003 von Klaus Fichter).

(Lehrer) Klar, hier geht es um Prozesse in der Industrie, aber Kontextsteuerung geht auch für Schulen: „Gib den Lehrern Raum, damit sie Schülern Raum geben können, damit sich ganz agil und natürlich Innovationen in den Lebensraum Schule schleichen können“. So etwas würde man die Führungseigenschaften unseres damaligen Schuldirektors beschreiben. Und ja, das ist unsere Meinung: Agiles Lehren, Lernen und Forschen kann nur funktionieren, wenn die Schulleitung auf Kontextsteuerung setzt. Das ist eine zentrale Grundlage. Ohne dass die Möglichkeiten agilen Lehren und Lernens von der Leitung möglich gemacht werden, geht nichts. Direktoren benötigen dafür eigentlich massive Unterstützung von den Bildungsbehörden. Bekommen sie allerdings meist nicht. Schade. (Schulleiter) Und zu allerletzt: Vergessen Sie das Personal nicht. Die Sekretärinnen als Subjekte der Erstkontakte für Eltern und Schüler, die Hausmeister, die bei Dienst nach der Uhr jedes Schulleben ersticken und das Reinigungsteam, das ‚bei guter Führung‘ auch mal am Sonntag nach einer wilden Schulfestnacht zur Reinigung wenigstens

268

H. Bayer

der Toiletten kommt, damit montags der Schulbetrieb wieder laufen kann. Oft reicht, dass diese das Gefühl haben, wahrgenommen zu werden durch ein Wort der Anerkennung, durch einen gemeinsamen Kaffee zur Adventszeit etc. 35 Jahre und 15 Jahre Schulleitung hätten zur Nabelschau, zur Stagnation führen können, wenn alles über meinen Schreibtisch gelaufen wäre und zum Infarkt. Faust ist gut gelaufen und ich bin gesund geblieben nach dem Motto „Zutrauen und Vertrauen“.

23.11 Fazit (Lehrer) Agile Verwaltung ist ein Dauerprozess des offenen Auges. Die Direktion muss teamfähig sein und muss Teamarbeit unterstützen und fördern. Ich denke, nach den Ausführungen unseres damaligen Direktors wird klar, warum wir jungen Kolleg/innen den richtigen Background für agiles Schulentwickeln besaßen. Warum es möglich war, dass wir drei Verbindungslehrer uns ziemlich regelmäßig mit vier Schulsprecher/innen im Café Z treffen konnten, um uns diese vielen wilden und spannenden und zukunftsweisenden Ideen anzuhören und dabei überwiegend zustimmend zu nicken. Manchmal vielleicht auch ein wenig zu bremsen … aber eigentlich – in der Erinnerung – saß ich damals meist da, aß Taccos, staunte, was wir da alles für Aktivitäten losgetreten hatten, weil wir uns als Lehrerband einmal auf die Rockcafébühne getraut hatten und hörte zu, wie sich die Dinge der Schülerschule entwickelten. Heute würde ich in den Worten der Agilen meinen: Wir hatten gescrumt, was das Zeug hergab. Die Café Z Arbeitsessen waren komplette Reviews mit papiernen Scrumboards auf den Tischen. Wir haben mit den Aktivsten der Aktiven zusammen gearbeitet. Unser Chef hat den Raum dafür geöffnet, wir haben den Raum genutzt und unsere Schüler/innen haben den Raum gefüllt. Wenn etwas mal nicht geklappt hatte, dann wurde es eben das nächste Mal anders gemacht. Wir haben damals öfters das Wort von Zukunftswerkstatt im Café Z benutzt. Spinnen, planen, herunter rechnen, ausprobieren. Manchmal habe ich mich gefragt, wie ich eigentlich dazu komme, einfach so viel mehr außerhalb des normalen Unterrichts an Einsatz zu investieren. Und jedes Mal, wenn wir zusammen mit den aktiven Schüler/innen mal wieder Unmögliches möglich gemacht hatten, agil bis zum Anschlag, dann wusste ich immer wieder, dass ich mir damit viel Gutes antue. Um am Ende wie mein damaliger Chef sagen zu können: Faust ist gut gelaufen und ich bin gesund und hochzufrieden geblieben. (Schüler) Agilität/Schülerschule heißt prinzipiell für mich (sowohl an der Schule wie auch an der Hochschule), Schüler und Studenten mit Respekt zu behandeln. Das sagt sich so einfach. Denn gemeint ist nicht einfach nur, sie als Person zu achten, sondern sie als Mensch zu behandeln, der/die tief drinnen irres Entfaltungspotenzial hat, das es gilt, wach zu kitzeln. Ihnen also in diesem Sinne eine Bühne zu bieten, die ihnen diese ­Entfaltungsmöglichkeit gibt. Das bedeutet, sich auf Augenhöhe zu begegnen. Hierarchien sind naturgegeben zwischen Lehrer und Schüler oder Dozent und Student. Aber Hierarchien können eben als steil oder

23  Faust, Café Z, das Prinzip Kaktus und die Sache …

269

flach interpretiert werden. Und es ist nicht verwunderlich, dass die Pädagogik heute in diesem Zusammenhang eher von Lernen anstelle von Lehren spricht. Lehren impliziert die Vermittlung von Wissen von einer Person auf die Breite zu belehrende Masse. Lernen, auf der anderen Seite, impliziert eine flache Hierarchie, in der sich alle Beteiligten auf dem Gebiet des voneinander-Lernens befinden. Der Dozent also genauso wie die Studenten gemeinsam lernen – wobei der Dozent eben ‚nur‘ ein paar Jahre Vorsprung auf diesem Gebiet hat, aber gleichzeitig in dem Wissen handelt, dass Lernen nie aufhört und dass Studenten einen integralen Teil des Lernens ausmachen. Das ist an der Schule wohl schwieriger als an der Uni: Erstere versteht sich herkömmlich als eine Institution, die Wissen vermittelt; letztere erkennt naturgemäß an, dass Wissen und Verstehen sich permanent ändern, wandeln, überwerfen. Da geht es also vordergründig nicht um das Vermitteln von Wissen, sondern eben auch um das Erlernen des Lernens. (Schulleitung, Lehrer, Schüler) Wir stellen alle drei fest: Dass Prinzip, dass eine agile Schulleitung die Möglichkeit für agile Projekte schafft, damit Lehrer/innen mit agilen Ansätzen Schüler/innen eigenverantwortlich viel mehr Entwicklungen zugestehen können ist eine Win-Win-Win Situation für eine Schule. In der Hochphase der „Schülerschule“ spielten wir in der Region für die Aktiven benachbarter Schulen häufig „in einer anderen Liga“. „Was ihr so ganz nebenbei macht, wäre für uns ein Jahresprojekt“ haben wir nicht nur einmal gehört. Und uns Dreien hat es sehr gut getan. Heinz Bayer – November 2017

23.12 Leserbrief von einer eduScrum-Trainerin Lieber Heinz, lieber Günther und lieber Sebastian, wenn ich euer Kapitel zum Thema Agiles Lernen lese, dann geht mir das Herz auf. Ich teile die Meinung von Sebastian: „Agilität/Schülerschule heißt prinzipiell für mich (…), Schüler und Studenten mit Respekt zu behandeln. (…) Gemeint ist nicht einfach nur, sie als Person zu achten, sondern sie als Mensch zu behandeln, der/die tief drinnen irres Entfaltungspotenzial hat, das es gilt, wach zu kitzeln. Ihnen also in diesem Sinne eine Bühne bieten, die ihnen diese Entfaltungsmöglichkeit gibt.“ Als ich begonnen habe, mich mit eduScrum zu beschäftigen, da ging es mir vor allen Dingen darum, trotz vorhandener Lehrpläne und zu erreichender Lernziele Raum für Kreativität und frische Ideen zu erhalten. Ohne dass wir Schule komplett umwerfen müssten, nein, direkt hier, mit den uns gegebenen Möglichkeiten. Wenn ich heute mit Lehrern über eduScrum spreche, höre ich vermehrt: „Wir wollen nicht nur der Durchlauferhitzer für die Wirtschaft sein.“ Das kann ich gut verstehen. Aber was soll das eigentlich genau heißen? Ich denke, wir sollten hier unterscheiden zwischen „Menschen für unschöne Tätigkeiten passig zu machen“ und „Menschen so auf die Zeit nach der Schule vorzubereiten, dass sie sich zurechtfinden, ihre eigenen Wünsche kennen und sie im Miteinander

270

H. Bayer

erfüllen können“. Der gut vorbereitete junge Mensch von gestern ist nicht der gut vorbereitete junge Mensch von heute. In einer komplexer werdenden Welt ist erarbeitetes Wissen wichtig. Es ist aber auch wichtig anzuerkennen, dass wir manche Fragen nicht mit dem ­Wissen von gestern beantworten können. Es zählt, experimentieren zu können, um aktuelles Feedback zu erhalten. Es zählt, den Mut aufzubringen, einen Fehler zu machen und daraus zu lernen. Auch das will gelernt sein. Ich behaupte, junge Menschen brauchen mehr denn je die Fähigkeit, etwas zu wagen, ohne dabei Kopf und Kragen zu riskieren und das gemeinsam und vertrauensvoll mit anderen. Warum erst nach der Schule damit ­beginnen? Warum nicht im geschützten Rahmen Schule damit anfangen? Für mich bedeutet agiles Arbeiten auch mehr Entfaltungsmöglichkeit, Mitspracherecht und Zufriedenheit für den Einzelnen. Den Menschen und den Beitrag, den er leisten möchte, ernst zu nehmen. Gemeinschaft zu fördern. Das gilt nicht nur für das kleine Start-up, mit dem sich Junge und noch Jüngere vielleicht ihren Traum verwirklichen, sondern auch für die Arbeit in der Verwaltung oder im großen Konzern, hier vielleicht „die Wirtschaft“. Es grüßt Alisa Stolze eduScrum-Trainerin und Teammitglied und Gründungsmitglied des Forums agil lernen und lehren. Heinz Bayer  war über 35 Jahre Physik- und Mathematiklehrer am Faust-Gymnasium Staufen. Davon 25 Jahre Vertrauenslehrer und 10 Jahre Studiendirektor für Schulentwicklung und neue Medien. Nach seiner Pensionierung ließ er sich von Professor Beywl an der Pädagogischen Hochschule in Brugg-Windisch zum Luuise-Coach ausbilden und ist dort inzwischen freier Mitarbeiter.