Agil in der ISO 9001 – wie geht das?

Zusammenfassung

Im zweiten Kapitel wird anhand von konkreten Beispielen erläutert, wie sich agile Praktiken in ein Managementsystem nach ISO 9001:2015 integrieren lassen. Dabei werden die Übernahme von Planungs- und Überwachungstätigkeiten durch selbststeuernde agile Teams, die Steuerung agiler Prozesse mithilfe der „BIG FIVE“ und die kreative Dokumentation agiler Praktiken besonders herausgehoben.

2.1 Die Grauzone zwischen Standardprozess und Chaos

Wenn wir herausfinden wollen, wieviel Agilität ein zertifiziertes QM-System nach ISO 9001:2015 verträgt, dann stellt sich zunächst die Frage, ob ISO 9001:2015 die Wahlmöglichkeiten aus Prozess-, Projekt- und agiler Organisation grundsätzlich einschränkt. Ein Blick in die Norm zeigt schnell, dass hinsichtlich der Thematik Projekt keinerlei Vorgaben existieren. Die Nutzung von Projekten ist weder explizit gefordert noch untersagt. Entsprechend verwundert es nicht, dass die Gestaltung von speziellen Vorhaben mit wesentlich einmaligem Charakter auch in QM-Systemen üblicherweise als Projekt erfolgt. Hinsichtlich der verbleibenden Varianten – Prozess- und agile Organisation – gibt es jedoch Forderungen und Hinweise in ISO 9001:2015. Abb. 2.1 zeigt die nachfolgenden Überlegungen graphisch auf.

Abb. 2.1

(Eigene Darstellung)

Grauzonen der Organisationsgestaltung gemäß ISO 9001:2015.

Der sog. „prozessorientierte Ansatz“ gehört zu den Grundsätzen des Qualitätsmanagements gemäß ISO 9000:2015 (Normkapitel 2.3.4). Es wird davon ausgegangen, dass verlässliche Ergebnisse effizienter und wirksamer erzielt werden, wenn die Tätigkeiten als zusammenhängende Prozesse verstanden und diese wiederum als konsistentes System gesteuert werden. Dieser Ansatz wird von ISO 9001:2015 aufgegriffen und insbesondere in Normkapitel 4.4 mit spezifischen Anforderungen ausgestaltet. So muss die Organisation u. a. Eingaben, Ergebnisse, Abfolge und Wechselwirkung ihrer Prozesse bestimmen. Zudem müssen u. a. Prozesseingaben und -ergebnisse bestimmt sowie die Kriterien und Verfahren bestimmt und angewendet werden, mit deren Hilfe die wirksame Durchführung und Steuerung dieser Prozesse sichergestellt werden kann. Bezüglich des Kernprozesses wird in Normkapitel 8.5 festgelegt, dass die Produktion und Dienstleistungserbringung unter beherrschten Bedingungen durchgeführt werden muss. Ergänzend legt Normkapitel 8 diverse Details fest, insbesondere hinsichtlich der Steuerung bestimmter Arten von Prozessen. Daraus ist zu schließen, dass eine (gar) nicht prozessorientierte Organisation mit ISO 9001:2015 nicht vereinbar ist. Das ist aus Sicht der Organisationsgestaltung äußerst sinnvoll. Wenn es z. B. um standardisierte Rechnungslegungsprozesse wie Jahresabschlüsse geht, so ist jeder Verein und jede Kapitalgesellschaft gefordert, diese nachvollziehbar und gesteuert ablaufen zu lassen. Dies ergibt sich schon aus den Forderungen der Kapitalgeber sowie (steuer-)gesetzlichen Regelungen. Wenn die Situation eindeutig bestimmbar ist und Lösungen für sich wiederholende Problemstellungen standardisiert beschrieben werden können, ist eine prozessuale Organisation stets die wirksamste und effizienteste Art, diese Art von Aufgaben zu bewältigen. Wenn z. B. die Produktion von CDs unter genau bestimmten Reinraum-Bedingungen erfolgt, wäre eine agile Reorganisation nicht geboten. Hoch standardisiert prozessorientierte Organisationen entsprechen (hoch) beherrschten Bedingungen. Sie sind mit Sicherheit zertifizierungsfähig und damit „im grünen Bereich“. Die Grauzone entsteht im hybriden Bereich: Es ist zu entscheiden, wie viel Prozessorientierung bzw. welches Minimum an „beherrschten Bedingungen“ ausreichend ist, um eine Zertifizierung zu ermöglichen.

Auf die agile Organisation geht ISO 9001:2015 nicht ein. Jedoch enthält die Norm Konzepte, welche wesentliche Werte und Prinzipien des Agilen Manifests abbilden (The Agile Alliance 2001). So gehören gemäß ISO 9000:2015 Kundenorientierung, Engagement von Personen und die (ständige) Verbesserung zu den unverzichtbaren Grundsätzen jedes effektiven QM-Systems. Entsprechend finden sich in ISO 9001:2015 diverse Anforderungen, welche diese Grundsätze ausgestalten. Zunächst gehört dazu die Kundenorientierung (Normkapitel 5.1.2), welche sich mit höchster Priorität auch als Prinzip im Agilen Manifest wiederfindet. Hinzu kommen die mitarbeiterbezogenen Aspekte der Sicherstellung der Kompetenz (7.2.b), des Bewusstseins des eigenen Beitrags (7.3.c) und die Festlegung der relevanten Kommunikation (7.4). Sie weisen eine hohe Überschneidung mit dem agilen Wert „Individuen und Interaktionen“ auf. Von besonderer Relevanz in ISO 9001:2015 ist die Verbesserung (Normkapitel 10). Sie hat eine hohe Nähe zu dem agilen Wert „Reagieren auf Veränderung“ und dem Prinzip regelmäßiger Reflexion. Die Bestimmung von Chancen und Risiken ist Kernaufgabe des QM und der Leitung in Form des „risikobasierten Denkens“ und ist bei der Bestimmung von Chancen und der Auswahl passender Verbesserungsmaßnahmen gemäß ISO 9001:2015 anzuwenden, um z. B. zukünftigen Erfordernissen und Erwartungen der Kunden Rechnung tragen zu können oder die Leistung zu verbessern. Gehen wir davon aus, dass das Postulat der VUKA-Welt gerechtfertigt ist, ergibt sich daraus, dass eine Organisationsform, die völlig ohne agile Anteile auskommt, nicht zertifizierungsfähig wäre. Unsicherheit besteht darüber, wie viel Agilität und welche Art von agilen Praktiken eine Organisation verträgt, bevor die Agilität mit anderen Anforderungen der ISO 9001 in Konflikt gerät und somit eine Zertifizierung gefährden würde. Hier gilt es, herauszufinden, wo der grüne Bereich verlassen wird und der risikobehaftete Graubereich beginnt.

In der Gesamtsicht müssen also Leitplanken für die in Abb. 2.1 dargestellten grün-schraffierten und hellgrauen Bereiche gefunden werden, um diese klar von den schwarzen – und damit nicht zertifizierbaren – Bereichen abgrenzen zu können. Im QZ-Artikel von Adam finden sich bereits fünf praktische Tipps für eine ISO 9001-konforme Ausgestaltung agiler Praktiken (Adam 2019, S. 47). In den nachfolgenden Unterkapiteln werden diese ausführlicher ausgestaltet.

Merke

Jede Organisation kann die Organisationsvarianten Prozess, Projekt und agil frei kombinieren. In zertifizierten QM-Systemen ist ein Mindestmaß an Prozessorientierung und an Agilität unverzichtbar. In der konkreten Ausgestaltung sind die risikobehafteten Grauzonen auszuloten.

2.2 Planen, steuern und überwachen

Die Anforderungen der ISO 9001 sind vielfältig. Für den Umgang mit Agilität ist insbesondere relevant, dass eine Organisation sowohl das gesamte QM-System mit seinen Chancen und Risiken sowie den notwendigen Ressourcen als auch die Abläufe in den Kernprozessen („Betrieb“) planen, steuern und überwachen muss. Für die Feststellung, unter welchen Voraussetzungen agile Praktiken mit ISO 9001:2015 vereinbar sind, müssen daher zunächst zwei Fragen beantwortet werden:

• Dürfen agile, selbststeuernde Teams eigentlich Planungs-, Steuerungs- und Überwachungstätigkeiten übernehmen?

• Passen Planungs-, Steuerungs- und Überwachungstätigkeiten zu agilen Vorgehensweisen?

ISO 9001 und agile Teams

In den meisten Organisationen gehören Planungs-, Steuerungs- und Überwachungstätigkeiten zu den Managementaufgaben und werden entweder von den Führungskräften oder von speziellen Abteilungen wahrgenommen. Zu diesen Spezialabteilungen gehören typischerweise das Qualitäts- oder Prozessmanagement. Diese Regelungen gehen jedoch nicht auf spezielle Normforderungen zurück. ISO 9001:2015 macht nämlich keinerlei Angaben darüber, wer diese Aufgaben durchführen soll. So könnte grundsätzlich jede Funktion oder Hierarchiestufe diese Tätigkeiten ausüben, sofern bei den zuständigen Personen die notwendigen Kompetenzen vorhanden sind. Für die Norm gilt stets, dass die Regelung angemessen und funktionsfähig sein muss. Bei einer Prüfung der Angemessenheit sind neben den Kompetenzen der Beteiligten u. a. die Art der betrachteten Tätigkeit, das Prozessziel und das dazugehörige Risikoprofil ausschlaggebend.

Damit ist es nicht grundsätzlich abzulehnen, wenn ein agiles Team im Rahmen seiner Selbststeuerung seine Ziele selbstständig festlegt, die Art des Vorgehens bestimmt, die Aufgaben unter den Teammitgliedern aufteilt und nach Beendigung die Zielerreichung beurteilt sowie ggf. Verbesserungsmaßnahmen entwickelt, priorisiert und einleitet. Seit der Revision von ISO 9001:2015 gilt in vielen Bereichen „Output matters“. Solange also über einen längeren Zeitraum verlässlich die Ziele erreicht werden und die Ergebnisse den Anforderungen der Kunden und Interessenspartner entsprechen, sind auch ungewöhnliche Regelungen zertifizierungsfähig. Letztlich gilt: „Es tut, wenn es tut.“

Entwicklung mit der Scrum-Methode

Das Herz der Scrum-Methodik¹ ist der Sprint – ein festgelegter Zeitraum von maximal 4 Wochen, in welchem ein genau bestimmtes Produkt oder Teilprodukt (Produktinkrement) fertiggestellt wird. In einem solchen Sprint werden die notwendigen Planungs-, Steuerungs- und Überwachungstätigkeiten in Form sog. Scrum-Ereignisse von vorneherein festgelegt. Ziel ist es, besonders an kritischen Stellen eine Überprüfung zu ermöglichen und Transparenz zu schaffen, als konkrete Ausführung des „Inspect & Adapt“-Ansatzes. Zu den Scrum-Ereignissen, die das ganze Scrum-Team gemeinsam durchführt, gehören z. B. das Sprint-Planning. In diesem wird das zu liefernde Produktinkrement festgelegt sowie die dafür erforderlichen, in kleine Einheiten zerlegten Tätigkeiten. In täglichen, 15-minütigen Kurz-Treffen (Daily Scrums) des Entwicklungsteams werden die Fortschritte überprüft und ggf. Anpassungen und Umplanungen vorgenommen. Nach Beendigung des Sprints erfolgt ein Sprint Review, zu dem das Scrum-Team üblicherweise noch weitere Stakeholder einlädt. Hier wird der erreichte Stand des Sprints reflektiert und in Input für die kommenden Sprint Plannings überführt. Budget, geplante Produkteigenschaften sowie Zeitplan für das Produkt-Release werden überprüft und ggf. vollständig umgearbeitet. In einer zusätzlichen Sprint Retrospective vor dem nächsten Sprint Planning wird der vergangene Sprint im Hinblick auf die genutzten Prozesse, Tools und die Zusammenarbeit der beteiligten Personen reflektiert. Ziel ist die Erstellung eines Plans für die Verbesserung der (internen) Arbeitsweise des Scrum-Teams.

Die Erfahrungen mehrerer Interviewpartner mit diesen Scrum-Ereignissen war durchgängig positiv. Hervorgehoben wurden insbesondere die sehr offenen, kritischen Sprint-Reviews. Durch die enge Zusammenarbeit im Team besteht eher die Bereitschaft, Probleme deutlich anzusprechen und konsequent zu beheben. Während bei Reviewprozessen in klassischen Entwicklungsprojekten eher die Sorge besteht, Kollegen vor anderen Abteilungen oder den für die Reviews verantwortlichen Führungskräften bloßzustellen, herrscht in agilen Scrum-Teams eine sehr aufrichtige Arbeitsatmosphäre. Das führt dazu, dass alle Teammitglieder ehrlich Probleme der Zusammenarbeit benennen und sich auf eine Verbesserung der teaminternen Arbeitsprozesse fokussieren, ohne Übergriffe auf der persönlichen Ebene vorzunehmen. Dazu tragen auch die sachlich orientierten Vorgaben der Scrum-Methodik bei. Damit sind Reviewprozesse agiler Teams oftmals sogar den klassischen Reviewprozessen überlegen.

Planung, Steuerung und Überwachung bei agilen Vorgehensweisen

Es wurde schon festgestellt, dass agiles Arbeiten weit von einem „wir machen mal mit irgendwem irgendetwas irgendwie“ entfernt ist. In den Interviews kam deutlich heraus, dass es bei Agilität um die Lösung von VUKA-Problemen und nicht um die „Große Freiheit Nummer 7“ geht. Wie es einer der Interviewpartner ausdrückte: „Agile Teams sind keine Künstler“. Schließlich gilt es auch hier, ein (unternehmerisches) Ziel zu erreichen. Dies ist für die Nutzung von agilen Praktiken in jedem Organisationskontext eine Grundvoraussetzung.

Damit agiles (Zusammen-)Arbeiten in Organisationen funktioniert, ist auch in einem agilen Team eine Abstimmung unerlässlich. Das bedeutet, dass jeder genau weiß, wofür er zuständig ist. Es müssen also klare Rollen und Verantwortlichkeiten sowie erwartete Arbeitsergebnisse bestimmt werden. In der Softwareentwicklung kann das zum Beispiel heißen: Ein Kollege definiert die Schnittstellen zu den Altsystemen, ein zweiter programmiert die Zugriffsrechte und ein dritter testet. Hinter ihnen hängt dann vielleicht ein Kanban-Board und macht transparent, woran wer gerade arbeitet. Probleme werden täglich in einem morgendlichen Standup-Meeting thematisiert und gemeinsam gelöst. Dabei helfen sich die Mitarbeiter in dem agilen Team gegenseitig aus, sofern sie die notwendigen Kompetenzen für die gerade stockende Aufgabe mitbringen. Die Mitarbeiter entscheiden selbst im Team, ob sie sich nach Beendigung der ersten Aufgabe eine neue Aufgabe suchen oder ob es wichtiger für die gemeinsame Zielerreichung ist, zunächst andere Kollegen zu unterstützen. Eine solche Entscheidung kann nur dann fundiert getroffen werden, wenn Ziel und Arbeitsstand für alle transparent sind.

Die Besonderheit der Ausführung von Planungs-, Steuerungs- und Überwachungsmaßnahmen liegt auch im Detailierungsgrad. Aufgrund des iterativen, schrittweisen Vorgehens und der sehr kurzen (i. d. R. täglichen) Überprüfungszyklen benötigt das agile Team zu Beginn noch keine ausführliche Detailplanung. Stattdessen steigt der Grad der Detaillierung mit dem Fortschritt der Zielerreichung an, sodass eine Aufgabe erst kurz vor oder mit der direkten Übernahme hinsichtlich des Arbeitsprozesses detailliert ausgestaltet wird. In ISO 9001 gibt es keine Vorgaben zum Detaillierungsgrad. Hier gilt ebenfalls wieder „es tut, wenn es tut“. Für VUKA-Probleme ist eine Detailplanung zu Beginn ohnehin Makulatur (siehe Abschn. 1.3).

Merke

Agile Teams sind für ISO 9001 kein Problem! Wichtig ist nur, dass die Funktionsfähigkeit der Planungs-, Steuerungs- und Überwachungstätigkeiten abgesichert ist. Insbesondere bei VUKA-Problemen ist dies durch eine iterative Ausgestaltung gegeben.

2.3 Steuerung von Prozessen – die BIG FIVE

Steuerung von Prozessen bedeutet, dass bestimmte Aktivitäten durchgeführt werden, die dafür sorgen, dass das vorgesehene Prozessergebnis erzeugt wird. Die Definition der Prozesssteuerung aus dem Forschungsprojekt lautet folgendermaßen:

Prozesssteuerung

Die Prozesssteuerung ist ein System, in dem bestimmte Mechanismen in einem Regelkreis auf einen Prozess angewendet werden, um sicherzustellen, dass das Prozessergebnis dem vorgesehenen Ergebnis entspricht.

Gemäß den Anforderungen von ISO 9001:2015, Normkapitel 8.1 gehören zu den Aktivitäten der Prozesssteuerung insbesondere die Bestimmung der Anforderungen (a), die Festlegung von Kriterien für die Prozesse (b), die Bestimmung der notwendigen Ressourcen (c), die Steuerung der Prozesse in Übereinstimmung mit den Kriterien (d), die dokumentierten Informationen für die entsprechenden Nachweise (e), die Überwachung geplanter Änderungen und die Beurteilung von Folgen unbeabsichtigter Änderungen. Für die Zertifizierung muss nachgewiesen werden, dass die Steuerung durch die Ausführung dieser und weiterer Tätigkeiten wirklich funktioniert.

In den letzten Jahrzehnten haben sich typische Mechanismen zur Prozesssteuerung in prozessorientierten Managementsystemen etabliert, welche von den Auditoren grundsätzlich als angemessen eingestuft werden. Dazu gehören z. B. die statistische Prozessregelung über Shewart-Regelkarten oder Freigaben von Auszahlungen durch autorisierte Personen im Vier-Augen-Prinzip. In manchen Veröffentlichungen wird die Art, wie agile Teams ihre agilen Vorgehensweisen selbstständig auswählen und umsetzen sowie sich, wenn Not am Mann ist, gegenseitig aushelfen, als eigenständiges Konzept und Gegenmodell zur üblichen prozessualen Steuerung verstanden. Sicher ist, dass z. B. typische statistische Regelungen nur für beherrschte Prozesse sinnvoll sind und damit in VUKA-Umgebungen nicht zum Tragen kommen (können). Unter diesen Prämissen ist kritisch zu fragen, ob und bis zu welchem Grad sich agile Prozesse QM-konform steuern lassen, ohne ihren Charakter zu verlieren.

Im Rahmen des Forschungsprojektes wurde dazu eine Masterarbeit vergeben. T. Japing hat darin untersucht, ob sich hinter der Vielzahl an praktisch genutzten Prozessregelungen vielleicht abstrakte, einheitliche Steuerungsmechanismen verstecken. Mithilfe solcher allgemeinen Prozesssteuerungsmechanismen zur Sicherstellung der Qualität der Prozessergebnisse würde es Qualitätsmanagern und Auditoren leichter fallen, auch ungewöhnliche Vorgehensweisen der Steuerung einzuordnen und als zulässig einzustufen. Untersucht wurden dafür gängige Modelle aus verschiedensten Prozessen und Branchen, z. B. die Statistische Prozesskontrolle (SPC) und die FMEA aus dem Produktionsbereich, die Mechanismen des „Internen Kontrollsystems (IKS)“ aus dem Finanzbereich und die „Three Lines of Defense“ aus dem Risikomanagement. Die Vielzahl an konkreten Beispielen deckte die komplette Bandbreite aller Funktionen eines typischen Unternehmens ab. Diese wurden auf ihre Gemeinsamkeiten durchleuchtet und dann auf einer abstrakten Ebene zusammengeführt. Heraus kamen zunächst acht verschiedene Prozesssteuerungsmechanismen, welche im Anschluss transferiert wurden auf agile Prozesse. Dabei konnte festgestellt werden, dass die erforschten Mechanismen hinsichtlich ihrer Funktion nur marginale Differenzen in der Lenkung klassischer und agiler Prozesse aufweisen.² Konkret bedeutet das: Agile Prozesse können durchaus gesteuert werden, ohne dass die Agilität darunter leidet, und viele Mechanismen zur Gestaltung agiler Arbeitsprozesse können sehr wohl als ISO 9001-konforme Prozesssteuerung begriffen werden.

Im Nachgang zur Arbeit wurden die Erkenntnisse nochmals vertieft und konsolidiert. Schlussendlich lassen sich nun fünf grundlegend verschiedene Prozesssteuerungsmechanismen unterscheiden, welche alle ausnahmslos für klassische und agile Prozesse angewendet werden können. Dies sind die „BIG FIVE“ der Prozesssteuerung (siehe auch Abb. 2.2):

Abb. 2.2

Die BIG FIVE der Prozesssteuerung

Die BIG FIVE der Prozesssteuerung

• 1. Anforderungen/Vorgaben

• 2. Ressourcenbereitstellung

• 3. Regeln

• 4. Koordination

• 5. Review

Anforderungen/Vorgaben

determinieren unbestritten jeden Prozess. Welches Ziel mit den Tätigkeiten verfolgt wird, welches Ergebnis erreicht werden soll, welche Bedingungen der Kunde des Prozesses an eine gute Ausführung stellt – das alles hat einen erheblichen Einfluss auf die Art, wie der Prozess gestaltet und aufgesetzt wird. Nach ISO 9000:2015, 3.6.4 können Anforderungen von interessierten Parteien oder der Organisation selbst stammen und können festgelegt, üblicherweise vorausgesetzt oder verpflichtend sein. Dabei müssen sie nicht zwangsläufig schriftlich als Vertrag, Spezifikation oder anderweitig dokumentiert vorliegen. Sie müssen auch nicht gleich vollständig zu Beginn des Prozesses vorliegen, können also (wie typisch für agile Entwicklungsprozesse) erst nach und nach über Feedbacks zu Entwürfen o. ä. weiter ausgestaltet werden.

Ressourcenbereitstellung

hat erkennbar direkten Einfluss auf die Qualität der Abläufe und des erzielten Prozessergebnisses. Ob agil oder klassisch: Alle notwendigen Ressourcen müssen verfügbar sein. Das gilt für personelle Ressourcen sowohl in der passenden Qualität, also Kompetenzausstattung und Arbeitshaltung, als auch in der passenden Quantität, z. B. in Form von nutzbaren Arbeitsstunden. Ebenso gehört dazu z. B. die Bereitstellung von Finanzmitteln oder Budgets, Infrastruktur und Arbeitsumgebung und die Managementunterstützung. Alle notwendigen Ressourcen müssen gemäß ISO 9001, 7.1 bestimmt und bereitgestellt werden. Dazu ist insbesondere die oberste Leitung verpflichtet (Normkapitel 5.1). Der optimale Mix kann in Abhängigkeit von den Anforderungen/Vorgaben sehr unterschiedlich aussehen. So können z. B. Rechnungslegungsprozesse durch IT-Workflows erheblich gestützt und damit häufig schneller und fehlerfreier durchgeführt werden als ohne eine solche technische Investition. Agile Prozesse haben stets eine hohe Abhängigkeit von personellen Ressourcen.

Eine Besonderheit ist der Umgang mit der Ressource „Zeit“. In klassischen Prozessumgebungen ist die prozessuale Steuerung über Zeitvorgaben häufig darauf ausgerichtet, die zentrale Kundenforderung der rechtzeitigen oder schnellen Bearbeitung zu erfüllen. Entsprechend wird versucht, eine zeitliche Optimierung über die Steuerung der Einzelaktivitäten zu erreichen, sodass der Prozessablauf insgesamt beschleunigt oder verstetigt wird. Wenn die Zeitbudgets zu knapp bemessen sind, werden jedoch leicht die festgelegten Prozessziele verfehlt und manchmal auch die Mitarbeiter überlastet. In agilen Prozessen, insbesondere in den agilen Prozessen mit hohen kreativen Arbeitsanteilen, werden agile Vorgehensweisen in besonders eng getakteten Zeitabschnitten geführt, das sog. „Timeboxing“. Damit soll die Konzentration und Fokussierung auf die vorliegende Aufgabe ermöglicht werden. Vorrangiges Ziel ist es dabei nicht, den Prozess insgesamt zu beschleunigen, sondern durch die höhere Konzentration aller Beteiligten das Ergebnis zu verbessern. Ausgangspunkt dafür ist die Erkenntnis, dass mehr Zeit nicht immer zu besseren Ergebnissen führt. Das Prinzip des Timeboxing wird z. B. bei Sprint-Ereignissen verwendet oder in Design Thinking-Phasen.

Timeboxing im Sprint

Alle Sprint-Ereignisse sind zeitlich befristet über Time Boxes. Der Daily Scrum z. B. ist auf maximal 15 min jeden Tag festgelegt, sodass immer das Sprint-Ziel im Fokus steht. Das Entwicklungsteam sorgt selbst für eine passende Struktur. Ziel ist es, andere Meetings überflüssig zu machen, Hindernisse zu identifizieren und zu beseitigen, schnelle Entscheidungen zu fördern und alle wesentlichen Informationen auszutauschen. Es ist durchaus üblich, dass sich einzelne Mitglieder oder das Team im Anschluss länger treffen, um notwendige Umplanungen oder Anpassungen vorzunehmen oder besondere Themen im Detail zu diskutieren (Schwaber und Sutherland 2017, S. 12–13).

In „normalen“ Besprechungen gibt es häufiger Ärgernisse, welche die Effizienz des Meetings massiv beeinträchtigen und Teilnehmer frustrieren. So kommen regelmäßig Personen zu spät und andere müssen warten. Manche Teilnehmer checken zwischendurch ihre E-Mails oder reden mit dem Nachbarn, weil sie den Eindruck haben, dass das aktuelle Thema sie nichts angeht oder sie nichts dazu beitragen können. Im Daily Scrum sorgt die strikte Time Box dafür, dass solche „Leerzeiten“ eliminiert werden.

Regeln

bestimmen, welche Aktivitäten in Prozessen ausgeführt werden müssen und wie die einzelnen Tätigkeiten auszuführen sind. Häufig werden diese dokumentiert und manifestieren sich z. B. in Richtlinien, Handlungsanweisungen, Policies, Guidelines, Verfahrensanweisungen oder SOPs (Standard Operating Procedures). Regeln können sehr unterschiedliche Stufen der Verbindlichkeit haben. Reicht für manche Prozesse die mündliche Festlegung, dass Praktikanten sich bei Rückfragen immer an ihren Praktikumsbetreuer wenden sollen, so gibt es für die Bedienung eines SAP-Systems umfangreiche Handbücher mit detaillierten Anweisungen, welche Kennzeichen in welchen Fällen wo zu setzen sind. Selbstverständlich gelten diese Handbücher auch dann, wenn Mitglieder agiler Teams solche Systeme nutzen. Ein agiler Software-Programmierer nutzt schließlich die gleiche Programmiersprache wie sein klassisch arbeitender Kollege. Die Mitarbeiter im Rettungsdienst stellen zwar vor Ort ihre Erstdiagnose agil, die Behandlung selbst wird allerdings (z. B. in Schleswig-Holstein) mit Checklisten oder standardisierten Arbeitsanweisungen geregelt, welche im Kleinformat für die Hosentasche vorliegen. In anderen Fällen sind detaillierte Handlungsanweisungen für agile Praktiken unpassend, da ja ihr Zweck gerade darin besteht, für ungewöhnliche VUKA-Situationen selbstgesteuert innovative Lösungen zu generieren. Dennoch kann es auch hierfür durchaus sinnvoll sein, allgemeine Regeln aufzustellen. So kann z. B. festgelegt werden, dass Sonderaufträge im Controlling immer von demjenigen zu verantworten sind, bei dem die Anfrage eingegangen ist. Das agile Team ist in diesen Fällen aus Mitarbeitern aller betroffenen Abteilungen zusammenzustellen, wobei mindestens ein Teammitglied Erfahrungen mit der Moderation agiler Teams besitzen muss. Die zu nutzenden agilen Vorgehensweisen und Tools sind jedoch individuell von dem agilen Team im Arbeitsprozess abzustimmen.

Wie selbstverständlich auch agiles Arbeiten mit Regeln funktioniert ist insbesondere an häufig genutzten agilen Methoden zu erkennen. Diese sind gerade deswegen so beliebt, weil sie detaillierte Anwendungsregeln enthalten. Der deutschsprachige Scrum-Guide z. B. hat 22 Seiten (Schwaber und Sutherland 2017). Wie es ein interviewter Entwickler ausdrückte: „Durch die Nutzung von Scrum sind wir viel geregelter und transparenter als der Entwicklungsprozess vorher“.

Koordination

sorgt dafür, dass die durchzuführenden Aktivitäten im Prozess so aufeinander abgestimmt sind, dass der gesamte Prozessdurchlauf optimiert wird. Es geht also um die Abstimmung und (Nach-)Steuerung der Schnittstellen zwischen den (Teil-)Prozessen und Aktivitäten. Solche Koordinationsfunktionen werden typischerweise durch bestimmte organisatorische Rollen übernommen oder mithilfe technischer Unterstützung (z. B. IT-basierte Workflow-Systeme) sichergestellt. Koordinative Rollen können sehr unterschiedlich ausgestaltet sein. Die gängigste Form der Koordination ist die Verteilung von Aufgaben durch die jeweilige Führungskraft. In Projekten werden die Arbeitspakete entsprechend über die (Teil-)Projektleitung koordiniert. Die Gesamtkoordination mehrerer Teilprojekte erfolgt über die Gesamtprojektleitung und den Lenkungsausschuss in seinen regelmäßigen Sitzungen. In agilen Entwicklungsprojekten ist z. B. die Rolle des Scrum Masters eine koordinative Rolle, indem er dafür sorgt, dass die Zusammenarbeit optimiert wird und sicherstellt, dass Ziele und Produktdomänen von allem im Scrum-Team verstanden werden. Die Entscheidungen über die konkrete Arbeitsaufteilung trifft jedoch das Entwicklungsteam im Rahmen seiner Selbststeuerung.

Die Ausgestaltung der Koordinationsfunktion gehört zu den wesentlichen Unterschieden zwischen agilen und klassisch arbeitenden Teams. In verschiedenen Branchen werden zur Sicherstellung reibungsloser Abläufe und optimaler Ressourceneinsätze Disponenten eingesetzt, z. B. bei der Routenplanung in Speditionen und Kurierunternehmen, in der Einsatzplanung für Zeitarbeitnehmer bei Personaldienstleistungen und für die Optimierung der Maschinenlaufzeiten im Produktionsbereich. Wie bereits in Abschn. 1.3 am Beispiel erläutert, zeichnen sich agile Teams gerade bei der Koordination sehr komplexer Prozesse (VUKA-Probleme) aus, da so alle notwendigen Informationen und Kompetenzen für eine sinnvolle Abstimmung direkt eingebunden werden können. Viele agile Praktiken können in diesem Verständnis als eine Sonderform der Disposition angesehen werden, welche auf Teamebene (ungewöhnlich) hohe Freiheitsgrade ermöglicht.

Reviews

finden nach dem Durchlauf des Prozesses oder auch der einzelnen Teilprozesse statt und dienen der strukturierten Überprüfung des realen Prozessablaufs und der erzielten Prozessergebnisse. Sie finden meistens als Review-Meeting statt und können auch eine formale Abnahme des Ergebnisses beinhalten. Als wesentlicher Input für die ständige Prozessverbesserung ermöglichen sie es, Fehler, Mängel oder Inkonsistenzen des Ablaufs geordnet zu erfassen und Optimierungen für den nächsten Durchlauf anzustoßen.

Reviews kommt in agilen Praktiken – und insbesondere bei der Nutzung agiler Methoden – eine besondere Bedeutung zu. Wie bereits in Abschn. 2.2 erläutert, ist im Scrum die Durchführung von Sprint Review und Sprint Retrospective verpflichtend. Im Design Thinking bilden Reviews einzelner Prozessschritte in Form von Evaluations-, Verbesserungs- und Reflexionsphasen einen integralen Bestandteil des methodischen Arbeitsablaufs (Blatt und Sauvonnet 2017, S. 93). Gerade bei kreativen Entwicklungsprozessen ist es heutzutage State of the Art, eine strenge Trennung zwischen zwei Arten von Denkzuständen zu machen: Der möglichst breiten und kreativen Ideenentwicklung (Divergieren) und der Bewertung in Form einer Fokussierung auf bestimmte Funktionalitäten oder die Auswahl von potenziell besten Lösungen (Konvergieren). Ein ständiger Wechsel zwischen beiden Phasen im Rahmen des Design Thinking ermöglicht eine schrittweise, kontinuierliche Optimierung der Lösungsansätze durch das jeweilige Entwicklungsteam.³ Der gesamte Entwicklungsprozess auf Basis von Design Thinking spannt in einem Makrozyklus einen Bogen von den ersten Ideen über die kritischen Funktionalitäten und Funky Prototypen bis hin zum finalen Prototypen. In jeder dieser Phasen durchläuft das Team iterativ einen Mikrozyklus von der kundenzentrierten Beobachtung über die Ideenfindung bis zum Test der jeweiligen Prototypen (Lewrick et al. 2017, S. 30–37). In den Tests werden die Prototypen je nach Auswahl der Tools auf verschiedenste Weise überprüft – oder im ISO-Jargon den verschiedensten Arten von Verifizierungs- und Validierungstätigkeiten unterzogen. Solche ständigen Überprüfungen und Bewertungen, ob die (Zwischen-)Ergebnisse den Kundenanforderungen entsprechen, stehen im direkten Einklang mit den Entwicklungsanforderungen von ISO 9001:2015, 8.3.4. Eine ausführliche Übersicht typischer Prozesssteuerungsmechanismen von Entwicklungsprozessen – jeweils in agiler und klassischer Ausführung – sind dem QZ-Artikel von Japing & Adam zu entnehmen (Japing und Adam 2019, S. 46).

2.4 Dokumentation von agilen Praktiken

Bestimmte dokumentierte Informationen werden von ISO 9001:2015 explizit gefordert, z. B. eine Qualitätspolitik, Qualitätsziele oder Entwicklungseingaben. Selbstverständlich müssen diese auch von agilen Teams dem Auditor vorgelegt werden können. Das ist ohnehin nur die Spitze des Dokumentationseisbergs. Schließlich gibt es ergänzend noch vielfältige gesetzliche Nachweis- und Aufbewahrungspflichten für verschiedene Funktionsbereiche von Organisationen und auch noch Dokumente, welche von Kunden oder von anderen internen Einheiten benötigt werden.

Freiheit für die Software-Entwickler

Gerade in der Software-Entwicklung greift die Begeisterung für agile Vorgehensweisen um sich. Unlängst hat ein Team von Software-Entwicklern ihrem Projektleiter erklärt, dass sie nun ein agiles Entwicklungs-Team wären und Scrum nutzen würden. Damit würde natürlich ein völlig anderes Arbeiten gelten. Deshalb würden sie auch die festgelegten Quality-Gates nicht mehr einhalten und bräuchten sich auch um die bisherigen Dokumentationsvorgaben nicht mehr zu kümmern.

So einfach geht das nicht!

Wenngleich eine agile Zusammenarbeit mit z. B. täglichen Standup-Meetings manche der üblichen Dokumentationsanforderungen in arbeitsteiligen Prozessen obsolet werden lässt, gibt es doch externe Vorgaben, die strikt einzuhalten sind. Ein exemplarischer Blick auf das Bankwesen und die Pharmaindustrie verdeutlicht schnell, dass die Einhaltung der jeweiligen aufsichtsrechtlichen Vorgaben und Nachweispflichten Grundvoraussetzungen der Geschäftstätigkeit sind. Dazu gehören in beiden Fällen auch umfangreiche Dokumentations- und Nachweispflichten im Software-Bereich – für klassische und agile Entwicklungsteams. Oder, wie es ein Interviewpartner ausdrückte „agil bedeutet nicht die völlige Freiheit von Richtlinien oder Dokumentation“.

Die Einführung von Agilität kann also nicht als Begründung dafür herhalten, zukünftig auf alle Arten von dokumentierten Informationen zu verzichten. Andererseits ist eine Kultur der ständigen ausführlichen Verschriftlichung sämtlicher Überlegungen und Aktivitäten ebenfalls nicht mit agilen Arbeitsformen zu vereinbaren. Wie bereits in Abschn. 2.2 erwähnt, finden sich in ISO 9001 keine allgemeinen Vorgaben zum erwarteten Detaillierungsgrad dokumentierter Informationen. Getreu des Prinzips „es tut, wenn es tut“ ist lediglich sicherzustellen, dass die Informationen so dokumentiert werden, dass sie von allen betroffenen Personen auch nachvollzogen werden können. Hinzu kommt, dass dokumentierte Informationen schon per Definition gemäß ISO 9000:2015, 3.8.6 die verschiedensten Formate annehmen und auf diversen denkbaren Trägermedien verewigt werden können. Dank moderner Medien gibt es hier eine Fülle an Möglichkeiten, die im Sinne des Informationsempfängers kreativ genutzt werden können und trotzdem ISO 9001-konform sind.

Aufzeichnungen und Regelungen

Aufzeichnung eines Stand-up Meetings

Es ist unmittelbar einsichtig, dass es nicht sinnvoll sein kann, jedes 15-minütige Stand-up Meeting anhand eines ausführlichen Verlaufs-Protokolls zu dokumentieren, mit dessen Erstellung ein Teammitglied 30 min beschäftigt ist. Manchmal müssen jedoch wesentliche Entscheidungen aus dem Meeting aufbewahrt oder an zu dem Termin verhinderte Teammitglieder, Kunden oder parallel arbeitende Teams weitergegeben werden. Je nach Situation bieten sich zur Dokumentation z. B. die folgenden Varianten an:

Boards: Diskutierte Arbeitspakete, anstehende Themen oder wesentliche Aspekte einer Entscheidung werden vom Moderator während des Meetings direkt aufs Whiteboard geschrieben oder auf Post-its festgehalten, welche dann an Pinnwand oder Flipchart befestigt werden. Solche Arbeits-Boards in den Teamräumen werden laufend gepflegt und sind eine ständige Referenz für alle Mitglieder. Abwesende Teammitglieder oder externe Parteien können durch Fotos über Zwischenstände informiert werden, welche auf dem Teamlaufwerk abgespeichert oder per E-Mail versandt werden. Damit diese das Board auch verstehen, empfiehlt es sich, hierfür eine standardisierte Struktur festzulegen (z. B. die eines Kanban-Boards).

Entscheidungs-Foto: Wenn alle Teammitglieder dabei sind, kann der Wortlaut einer getroffenen Entscheidung kurz auf einem Flipchart festgehalten werden. Dann stellen sich alle Teammitglieder um das Flipchart herum und halten den Daumen hoch (oder parallel oder herunter). Davon ein schnelles Handy-Foto gemacht – fertig. Das Foto kann gespeichert, per WhatsApp geteilt oder per E-Mail versandt werden. Das Bild hat einen eindeutigen Zeitstempel, und es ist auch auf einen Blick klar, wer bei der Entscheidung anwesend war und votiert hat.

Video- oder Tonmitschnitt: Die bisherige Vorgehensweise wird auf den Prüfstand gestellt und ausführlich diskutiert. Damit im Falle späterer Rückfragen klar ist, warum der eingeschlagene Weg nicht weitergeführt wurde, wird entweder die gesamte Diskussion (z. B. für verhinderte Teammitglieder) oder das vom Moderator zusammengefasste Ergebnis (z. B. für Kunden oder andere Teams) als Video- oder Tonmitschnitt aufgezeichnet. Aufgrund der Dateigröße ist dies allerdings besser über ein gemeinsames Laufwerk bzw. via Dropbox oder We-Transfer zu teilen als über E-Mail.

Analog zu den im Beispiel genannten Alternativen zu klassischen Aufzeichnungsformaten kann die Dokumentation von Regeln für die Durchführung von einzelnen Aktivitäten oder Prozessen ebenfalls nicht nur über die üblichen Guidelines oder Arbeitsanweisungen erfolgen. Video-Tutorials, die Aufzeichnung von virtuellen Seminaren für den späteren Abruf oder Podcasts finden sich zunehmend bereits in klassischen Prozessen. Dabei gibt es auch in agilen Praktiken durchaus die Notwendigkeit von klaren Regelungen – nicht umsonst enthält der Scrum-Guide 18 Seiten mit Richtlinien für diese agile Methode (Schwaber und Sutherland 2017). Wenn es aber darum geht, festzuhalten, dass z. B. in der Entwicklung einwöchige Sprints unter Nutzung verschiedener agiler Methoden erfolgen sollen, würde es sinnvoll sein, hier nur sehr allgemeine Eckpunkte festzuhalten. Da agile Praktiken ihren Einsatz bei echten VUKA-Problemen finden, ist es nur natürlich, dass vorher nicht im Detail festgelegt werden kann, welche Methode Erfolg versprechend einzusetzen ist. Gerade das muss von dem Team und seinem Moderator im Bearbeitungsverlauf selbstständig festgelegt und ausgestaltet werden können. Relevant für die Qualität des Prozesses ist damit vor allem die richtige Teamzusammensetzung und der kompetente Umgang mit der eigenständigen Arbeitsorganisation und der situationsbezogenen Toolauswahl. Die Regelung dafür, wie diese Aspekte sichergestellt werden, könnte sich bei Bedarf in einem entsprechend Regelungsdokument wiederfinden.

Ein etwas kreativerer und mutigerer Umgang mit sinnvollen Dokumentationsformen ermöglicht es problemlos, ISO 9001 und Agilität mit einander zu vereinen.

Modellierung von (agilen) Prozessen

In den letzten Jahren haben viele Organisationen erhebliche Anstrengungen darauf verwendet, die Auswüchse individuell aufgenommener und äußerst detailreicher Prozessmodellierungen zu begrenzen. Für ein mittelständisches Unternehmen produzieren 200 umfangreich modellierte Prozesse der dritten Ebene allein durch die Notwendigkeit der Aktualisierung Zusatzaufwand, der häufig in keinem Verhältnis zum Vorteil der dokumentierten Detailsteuerung steht. Es gibt inzwischen verschiedene Ideen und Tools, wie sich die individuellen Vorgehensweisen agiler Teams ebenfalls in Prozessmodellierungen abbilden lassen. Beispielhaft genannt seien hier die prozeduralen Modellierungsansätze wie BPMNEasy bzw. die subjektorientierte Modellierung oder regelbasierte Modellierungssprachen wie z. B. Case Management Model and Notation CMMN, das Declare Rahmenwerk oder Dynamic Condition Response-Graphen. Einige dieser Ansätze versuchen, die realen Vorgehensweisen in den iterativen Zyklen im Detail nachvollziehbar zu machen. Die subjektorientiert Modellierung z. B. ermöglicht, dass jeder Prozessbeteiligte individuell sein Prozesshandeln in Form von Subjektverhaltensdiagrammen modellieren und anhand dessen überprüfen und verbessern kann (Fleischmann et al. 2011). So schön es ist, dass so etwas nun technisch möglich ist, so wenig erschließt sich der Sinn aus Managementperspektive. Individuelle Lösungen, die von speziell für eine Thematik ausgewählten Teams für die VUKA-Welt gefunden werden, sind ohnehin nicht auf andere Probleme übertragbar. Deswegen wird ja ein agiles Vorgehen genutzt. Dies nun auch noch im Detail zu modellieren schafft keinen Mehrwert.

Im anderen Extrem sind agile Vorgehensweisen in der Prozessmodellierung gar nicht erkennbar. In den Geschäftsprozessen der ersten und häufig auch der zweiten Ebene sind die dargestellten Teilprozesse naturgemäß so grob, dass darin enthaltene agile Praktiken nicht gesondert herausgehoben werden. In manchen Fällen geschieht das bewusst, um so einen eventuell kritischen Auditor nicht auf die Nutzung agiler Vorgehensweisen aufmerksam zu machen. Aus Steuerungssicht ist dies jedoch dort ungeschickt, wo agile Praktiken nicht isoliert, sondern in enger Verzahnung mit klassischen Prozessen vorkommen. Den im folgenden Kap. 3 genannten Stolpersteinen lässt sich effektiver begegnen, wenn die entstehenden Reibungen zwischen agilen und klassischen Komponenten aktiv gemanagt werden. Dafür muss man sich jedoch dieser Problematik bewusst sein. Deshalb ist es empfehlenswert das Vorkommen solcher agilen Bestandteile zu signalisieren. Für IKS-Risiken werden üblicherweise an den Prozessschritten Notationen wie rote Flaggen, rote Dreiecke oder Blitze verwendet. In Analogie dazu könnten für agile Praktiken z. B. orange Flaggen etabliert werden (siehe Abb. 2.3).

Abb. 2.3

(Eigene Darstellung)

Modellierung agiler Prozesse.