Manifest für agiles Qualitätsmanagement Holen Sie Ihren Qualitätsmanager ins agile Boot!
Agilität = Chaos = der Albtraum jedes Qualitätsexperten – so lautet ein weit verbreitetes Vorurteil. Die Deutsche Gesellschaft für Qualität (DGQ) ist vom Gegenteil überzeugt: Qualitätsexperten, die die Prinzipien agilen Arbeitens verstanden haben, werden zu überzeugten und einflussreichen Verbündeten agiler Bereiche. Dr. Benedikt Sommerhoff stellt dazu die sieben Grundsätze eines agilen Qualitätsmanagements vor.
Management Summary
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Manifest für agiles Qualitätsmanagement Holen Sie Ihren Qualitätsmanager ins agile Boot!
Agilität = Chaos = der Albtraum jedes Qualitätsexperten – so lautet ein weit verbreitetes Vorurteil. Die Deutsche Gesellschaft für Qualität (DGQ) ist vom Gegenteil überzeugt: Qualitätsexperten, die die Prinzipien agilen Arbeitens verstanden haben, werden zu überzeugten und einflussreichen Verbündeten agiler Bereiche. Dr. Benedikt Sommerhoff stellt dazu die sieben Grundsätze eines agilen Qualitätsmanagements vor.
Management Summary
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Agilität steht für Chaos und Anarchie! So oder so ähnlich denken leider viele Führungskräfte und auch Mitarbeiter, die noch nicht mit agilen Techniken gearbeitet haben. Dabei erfordert agiles Arbeiten sehr viel Disziplin sowie klare Regeln und Vereinbarungen, damit sich die inkrementell, von mehreren Entwicklern parallel bearbeiteten Arbeitspakete zusammenführen lassen.
Der irrige Eindruck von Anarchie rührt daher, dass im Zuge des Paradigmenwechsels hin zu den Agilen Werten (siehe Kasten) alte Regeln über Bord geworfen wurden. Die Kritiker übersehen jedoch, dass neue Regeln an die Stelle der alte getreten sind; meist, weil sie die neuen Regeln nicht verstehen.
Das klassische Qualitätsmanagement gerät besonders häufig in Konflikt mit Agilität
Da viele Qualitätsmanager sich als Regel(weiter)geber, Regeladministratoren und "Regeldurchsetzer" in der Organisation verstehen, setzen sie sich geradezu zwangsläufig kritisch mit agil arbeitenden Teams und Bereichen auseinander. Die naheliegende Lösung, den Qualitätsmanager nicht einzubinden und darauf zu hoffen, dass er einen "einfach machen lässt", verschiebt die Konfrontation lediglich.
Das führt nicht selten dazu, dass sich agile Teams und Bereiche gegen das Qualitätsmanagement (zukünftig mit QM abgekürzt) wehren und das QM meint, diese Bereiche wieder zurück ins dokumentierte Managementsystem führen zu müssen. Auf diese Weise entsteht ein schwelender Konflikt, in dem beide Seiten ständig intervenieren, um ihre Position zu festigen und jeweils versuchen, Verbündete zu gewinnen.
Der anhaltende Streit zieht Verzögerungen im Projekt und Dysfunktionalitäten im Unternehmen nach sich. Solche Konflikte beobachten wir von der Deutschen Gesellschaft für Qualität (DGQ) immer häufiger – kein Wunder, angesichts der zunehmenden Verbreitung der Agilen Werte.
Diese Konflikte halten wir für unnötig und kontraproduktiv. Als "Agiler" sollten Sie sich die Mühe machen, die Motive für die Ablehnung und Widerstände der Qualitätsmanager zu verstehen. Dann können Sie Wege finden, nicht nur lästige Interventionen abzuwehren, sondern vielmehr deren Unterstützung zu gewinnen.
Warum Qualitätsmanager sich gut als Unterstützer agiler Teams eignen
Zu diesem Zweck haben wir als DGQ ein Manifest für agiles Qualitätsmanagement verfasst. Damit möchten wir Scrum Master, Projektmanager und ihre Teams dazu anregen und motivieren, aktiv bei Qualitätsmanagern um deren Zustimmung und Unterstützung zu werben. Denn wir sind der Überzeugung, dass Qualitätsmanager, die die agilen Prinzipien verstanden haben, gleichzeitig deren ordnungs- und sinnstiftendes Potential begreifen.
Bei mir persönlich speist sich diese Überzeugung u.a. aus einem Gespräch mit einem Qualitätsmanager. Dieser klagte mir sein Leid über seine vergeblichen Versuche, den neuen Entwicklungsleiter ins QM-System einzubinden. Ich hörte heraus, dass dieser offenbar mit agilen Ansätzen arbeitet. Daher erläuterte ich dem Qualitätsmanager kurz die Grundsätze und typischen Regeln des agilen Ansatzes. Der Kollege zeigt sich daraufhin gleich interessiert mehr darüber zu lernen und sich neu und vor allem offen mit der Arbeitsweise seines Entwicklungsleiters zu befassen.
Viele Mitglieder des DGQ haben ähnliches erlebt. Wir schlussfolgern daraus: Die Erkenntnis, dass Agile sehr regelbasiert arbeiten, motiviert Qualitätsmanager dazu, das Managementsystem kompatibel zu den Agilen Werten zu gestalten.
Das Agile Manifest: Beginn des Siegeszugs der agilen Werte
Sofort weiterlesen und testen
Erster Monat kostenlos,
dann 24,95 € pro Monat
-
Know-how von über 1.000 Profis
-
Methoden für alle Aufgaben
-
Websessions mit Top-Expert:innen
Dieter Bertsch
14.06.2017
Besonders gefreut haben mich die Ausführungen zu „Warum wir Agilität brauchen“: Keine oberflächliche Fehldarstellung von wegen schneller und billiger. Danke dafür!
Was m.E. aber zu den am Anfang dargestellten Missverständnissen („irrige Eindruck von Anarchie“) beiträgt, ist das unvollständige Zitieren des Agilen Manifestes. Der fehlende Satz „That is, while there is value in the items on the right, we value the items on the left more.“ zeigt eben auf, dass es sich nicht um Anarchie handelt, sondern um das Setzen anderer Schwerpunkte.
Das mehrfach erwähnte Produktmanagement-Framework Scrum kennt ja nur drei Rollen: Poroduct Owner, ScrumMaster und Development Team. Und ich teile die Meinung von Simon Roberts, dass es natürlich noch weitere Stakeholder außerhalb von Scrum gibt (+1 Rolle; siehe https://scrum4you.wordpress.com/2008/07/18/3-3-rollen-in-scrum-oder-doch-nur-3-1/ und den verlinkten Artikel von Bernd Schiffer).
Da ich kein ausgebildeter Qualitätsmanager bin stellt sich mir die Frage: Wo sollte in Scrum die Rolle des Qualitätsmanagers angesiedelt sein: Im Development Team? Hat der Qualitätsmanager Tasks am Board zur Bearbeitung?
Oder außerhalb des Scrum Teams beim Linienmanager (dessen Notwendigkeit in der Scrum Community inzwischen auch nicht mehr umstritten ist)?
Oder wäre das nach Glogers Rollenmodell 3+3 sogar eine weitere Rolle (3+4)?
Benedikt Sommerhoff
19.06.2017
Klaus Rudolf
23.05.2018