Wie geht ein Team mit Methoden um? Muss ein Team eine Methode vollständig umsetzen? Darf es eine Methode verändern, etwas weglassen oder hinzufügen? Mit einem Vergleich kann ein Team diese Frage selbst schnell beantworten.
Als Organisationsberater führen wir Methoden ein. Ich bin der Überzeugung, dass sich viele Konflikte in Teams entschärfen, wenn es bestimmte Methoden anwendet. Rollen und Regeln sind besser geklärt.
Häufig werden wir gefragt, ob man diesen oder jenen Punkt weglassen kann. Oder ob man erst mal mit einem Teil startet oder ob man etwas verändern kann?
Bei Scrum beispielsweise haben die Teams viele Freiheiten. Den Scrum-Vätern ist es wichtig, dass die Teams sich bewusst für ihre Arbeitsweise entscheiden und sie dürfen auch von den Scrum-Regeln abweichen. Nur sollten sie es dann nicht mehr Scrum nennen. Das finde ich in Ordnung.
Beim Nachdenken über Methoden im Allgemeinen bin ich auf den folgenden Vergleich gestoßen: Methoden sind wie Spiele (z. B. Schach oder Dame; /1/).
Bei Brettspielen haben sich die Regeln über die Zeit entwickelt und sind in sich schlüssig. Jede Veränderung beeinflusst den Spielreiz. Würfeln bei Schach wäre zwar zunächst interessant aber wahrscheinlich schnell langweilig. Wenn wir bei Dame nur mit 4 statt mit 12 Steinen spielen, wäre das Spiel bestimmt schnell zu Ende.
Wenn man die Regeln mit Bedacht ändert, ändert sich der Reiz nicht. Beispielsweise spielt man mit Schachanfängern zunächst Bauernschach. Statt mit 16 Figuren spielt jeder nur mit 8 Bauern und König. Wer zuerst mit einem Bauern die Grundlinie des anderen Spielers erreicht, ist der Gewinner. Wenn ein Anfänger das verstanden hat, fügt man eine weitere Figur hinzu. Irgendwann sind dann alle Figuren dabei.
Auch wenn ein Anfänger schon gut mit allen Figuren Schach spielen kann, braucht er sich nicht sofort mit der Rochade oder en passant zu befassen, um ein schönes Spielerlebnis zu haben.
Beim Go-Spiel ist es ähnlich. Statt mit einem 19x19er Brett lernt ein Anfänger erst mal auf einer Fläche von 9x9 Kreuzungspunkten.
Trotz aller Spielvereinfachungen bleibt es das Ziel, irgendwann das Spiel nach allen Regeln zu spielen.
So ist es auch mit Methoden. Eine stückweise Einführung ist gut, wenn man sinnvolle Zwischenschritte wählt. Das temporäre Weglassen dient dazu, schneller zu lernen. Aber das Ziel ist immer, die Methode komplett zu "spielen".
Sie können einen erfahrenen Trainer fragen, was er in anderen Teams erlebt und gesehen hat. Erfahrene Berater schreiben gerne Bücher über die Einführung von Methoden. (Das hebt den Expertenstatus.) Lassen Sie sich von der Dicke des Buches oder der Themenfülle nicht verwirren. Achten Sie eher auch die Probleme und wichtigen Begriffe. Versuchen Sie herauszufinden, was dem Autor wichtig ist. Das lässt sich meist in kurzen Sätzen zusammenfassen.
Das Definieren von Zwischenschritten ist auch das Ziel von sogenannten Reifegradmodellen wie z. B. CMMI. Nicht, dass Sie jetzt solche Reifegrade 1:1 übernehmen (/2/). Aber Sie können sich ansehen, welche Schritte oder Prozesse auf welcher Stufe wichtig sind.
Am Anfang geht es meist darum, überhaupt Prozesse grob zu definieren und das Einhalten der einfachen Prozesse sicherzustellen. Wenn sich alle daran gewöhnt haben, werden die Rollen und Prozesse verfeinert. Je besser man wird, desto mehr will wann wissen, wie gut man tatsächlich ist. Auf den höheren Stufen fängt man dann an, Daten über Prozesse zu sammeln und auszuwerten.
Sie können eine Methode auch in Handlungs- oder Problembereiche zerlegen und diese stückweise einführen. Das passiert oft mit ITIL. Da nimmt man nicht gleich alle Disziplinen sondern fängt mit Incident- oder Change-Management an (/3/).
Allgemein gesprochen geht es beim Einführen von Methoden auch um das Ändern von Gewohnheiten. Versuchen Sie herauszufinden, welche Gewohnheiten der neuen Methode im Wege stehen. Vielleicht können Sie dort ansetzen.
Jede Methode hat so etwas wie einen Kern oder eine Essenz. Suchen Sie danach.
Teams dürfen Methoden ändern und anpassen. Es ist ihre Arbeitsweise. Wenn sie Methoden stark ändern, müssen sie ihr einen anderen Namen geben. Zudem sollten sie sich bewusst sein, dass die Änderungen die Qualität ihrer Arbeit beeinflussen. Versuchen Sie für die Änderungswünsche einen Vergleich zu finden: Was lassen wir gerade weg? Ist es nur eine Spielfigur weniger? Ändern wie die Spielfeldgröße? Führen wir ganz andere Spielregeln ein? Diskutieren Sie dies im Team. So entwickeln Sie ein gutes Gefühl für die Methode.
Als Organisationsberater führen wir Methoden ein. Ich bin der Überzeugung, dass sich viele Konflikte in Teams entschärfen, wenn es bestimmte Methoden anwendet. Rollen und Regeln sind besser geklärt.
Häufig werden wir gefragt, ob man diesen oder jenen Punkt weglassen kann. Oder ob man erst mal mit einem Teil startet oder ob man etwas verändern kann?
Bei Scrum beispielsweise haben die Teams viele Freiheiten. Den Scrum-Vätern ist es wichtig, dass die Teams sich bewusst für ihre Arbeitsweise entscheiden und sie dürfen auch von den Scrum-Regeln abweichen. Nur sollten sie es dann nicht mehr Scrum nennen. Das finde ich in Ordnung.
Beim Nachdenken über Methoden im Allgemeinen bin ich auf den folgenden Vergleich gestoßen: Methoden sind wie Spiele (z. B. Schach oder Dame; /1/).
Bei Brettspielen haben sich die Regeln über die Zeit entwickelt und sind in sich schlüssig. Jede Veränderung beeinflusst den Spielreiz. Würfeln bei Schach wäre zwar zunächst interessant aber wahrscheinlich schnell langweilig. Wenn wir bei Dame nur mit 4 statt mit 12 Steinen spielen, wäre das Spiel bestimmt schnell zu Ende.
Wenn man die Regeln mit Bedacht ändert, ändert sich der Reiz nicht. Beispielsweise spielt man mit Schachanfängern zunächst Bauernschach. Statt mit 16 Figuren spielt jeder nur mit 8 Bauern und König. Wer zuerst mit einem Bauern die Grundlinie des anderen Spielers erreicht, ist der Gewinner. Wenn ein Anfänger das verstanden hat, fügt man eine weitere Figur hinzu. Irgendwann sind dann alle Figuren dabei.
Auch wenn ein Anfänger schon gut mit allen Figuren Schach spielen kann, braucht er sich nicht sofort mit der Rochade oder en passant zu befassen, um ein schönes Spielerlebnis zu haben.
Beim Go-Spiel ist es ähnlich. Statt mit einem 19x19er Brett lernt ein Anfänger erst mal auf einer Fläche von 9x9 Kreuzungspunkten.
Trotz aller Spielvereinfachungen bleibt es das Ziel, irgendwann das Spiel nach allen Regeln zu spielen.
So ist es auch mit Methoden. Eine stückweise Einführung ist gut, wenn man sinnvolle Zwischenschritte wählt. Das temporäre Weglassen dient dazu, schneller zu lernen. Aber das Ziel ist immer, die Methode komplett zu "spielen".
Woher weiß ich denn, welche Zwischenschritte sinnvoll sind?
Nun, diese Frage ist nicht ganz so einfach. Aber Sie können selbst die Lösung finden.Sie können einen erfahrenen Trainer fragen, was er in anderen Teams erlebt und gesehen hat. Erfahrene Berater schreiben gerne Bücher über die Einführung von Methoden. (Das hebt den Expertenstatus.) Lassen Sie sich von der Dicke des Buches oder der Themenfülle nicht verwirren. Achten Sie eher auch die Probleme und wichtigen Begriffe. Versuchen Sie herauszufinden, was dem Autor wichtig ist. Das lässt sich meist in kurzen Sätzen zusammenfassen.
Das Definieren von Zwischenschritten ist auch das Ziel von sogenannten Reifegradmodellen wie z. B. CMMI. Nicht, dass Sie jetzt solche Reifegrade 1:1 übernehmen (/2/). Aber Sie können sich ansehen, welche Schritte oder Prozesse auf welcher Stufe wichtig sind.
Am Anfang geht es meist darum, überhaupt Prozesse grob zu definieren und das Einhalten der einfachen Prozesse sicherzustellen. Wenn sich alle daran gewöhnt haben, werden die Rollen und Prozesse verfeinert. Je besser man wird, desto mehr will wann wissen, wie gut man tatsächlich ist. Auf den höheren Stufen fängt man dann an, Daten über Prozesse zu sammeln und auszuwerten.
Sie können eine Methode auch in Handlungs- oder Problembereiche zerlegen und diese stückweise einführen. Das passiert oft mit ITIL. Da nimmt man nicht gleich alle Disziplinen sondern fängt mit Incident- oder Change-Management an (/3/).
Allgemein gesprochen geht es beim Einführen von Methoden auch um das Ändern von Gewohnheiten. Versuchen Sie herauszufinden, welche Gewohnheiten der neuen Methode im Wege stehen. Vielleicht können Sie dort ansetzen.
Jede Methode hat so etwas wie einen Kern oder eine Essenz. Suchen Sie danach.
Teams dürfen Methoden ändern und anpassen. Es ist ihre Arbeitsweise. Wenn sie Methoden stark ändern, müssen sie ihr einen anderen Namen geben. Zudem sollten sie sich bewusst sein, dass die Änderungen die Qualität ihrer Arbeit beeinflussen. Versuchen Sie für die Änderungswünsche einen Vergleich zu finden: Was lassen wir gerade weg? Ist es nur eine Spielfigur weniger? Ändern wie die Spielfeldgröße? Führen wir ganz andere Spielregeln ein? Diskutieren Sie dies im Team. So entwickeln Sie ein gutes Gefühl für die Methode.
Anmerkungen
- /1/ Ganz neu ist der Vergleich nicht. Die Scrum-Väter vergleichen die Scrum-Regeln ebenfalls mit Schachregeln: http://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/
- /2/ Das Einführen von Reifegraden entspricht ebenfalls dem Einführen einer Methode.
- /3/ Über das schrittweise Einführen von Change-Management habe ich bei itil.de geschrieben: http://www.itil.de/2013/06/24/wie-itil-die-leistungen-von-scrum-teams-verbessert/
Genau hier liegt für mich der Denkfehler:
AntwortenLöschen""
Beim Nachdenken über Methoden im Allgemeinen bin ich auf den folgenden Vergleich gestoßen: Methoden sind wie Spiele (z. B. Schach oder Dame)
""
Wir sprechen hier ja über Methoden, mit welchen in spezifischen (und immer unterschiedlichen) Firmen Ergebnisse konzipiert, realisiert und vertrieben werden.
Die Erfahrungen der Organisationsentwicklung lehren uns, dass keine für alle Firmen geeigeneten "Standardmethoden" gibt, bzw. Standard nur in eng begrenzten Bereichen sinnvoll eingesetzt werden können.
Ein Grund dafür ist, dass diese Methoden ja dazu dienen müssen, Produkte zu erhalten, die der Firma eine USP sichern. Das heisst: Nur bei "Nebenprozessen", nicht aber im "Kernprozess" sind Standardmethoden sinnvoll.
Beim Kernprozeess geht es also darum, "immer wieder ein neues Spiel zu spielen".
Lieber Hans Peter,
AntwortenLöschenDu sprichst mehrere Punkte an.
1. Meine Erfahrung ist auch, dass es nicht möglich und sinnvoll ist Firmen, Standardmethoden aufzudrücken. Jede Methode wurde aus einer spezifischen Situation heraus in einer Firma entwickelt und danach weitergetragen. Theoretisch kann damit keine Methode in einer anderen Firma funktionieren, weil die Situation, die Stakeholder, das Umfeld und die Erfahrungen ganz anders sind. Wie Du sagst, muss dann der Bereich eng eingegrenzt werden, damit eine Methode in dem Bereich die Chance hat wirken zu können.
2. Die Unterscheidung in Kern- und Nebenprozessen finde ich gut. In den Kernprozessen muss jede Organisation ihre Eigenheiten bewahren. Wir müssen beim Einsatz von Methoden also unterscheiden, ob es ein Kern- oder Nebenprozess ist. In den Nebenprozessen sollten Standards gelten.
3. Eine interessante Frage ist, ob z. B. Projektmanagement und ob Produktentwicklung bei einer Firma zu den Kern- oder den Nebenprozessen gehört. Produktentwicklung gehört für mich zu den Kernprozessen, weil sie das langfristige Überleben der Firma sichert. Je nach Situtation ist Projektmanagement Kern- oder Nebenprozess.
4. Kommen wir nochmal zu meinem Denkfehler zurück: Ich habe nach einem Vergleich gesucht, mit dem ich die Gestalt einer Methode besser verstehe. Beim Vergleichen mit einem Spiel habe ich besser verstanden, nach welchen Regeln ich Methoden ändern kann. Meine Annahme war, dass eine Methode in sich konsistent ist bzw. einen stabilen Kern hat. Allerdings gibt es viele Methoden, die "nur" ein Sammelsorium von besten Praktiken sind und deshalb auch nicht in sich konsistent sind.
Welcher Vergleich wäre für Dich passender? Gibt es für Dich einen Vergleich?
LG, Jan
Zu deiner letzten Frage zuerst:
AntwortenLöschenDa möchte ich zunächst mal fragen, was unter "Methode" verstanden wird. Im Allgemeinen meinen wir damit eine systematisierte Vorgehensweise zur Gewinnung von Erkenntnissen (etwa in der Wissenschaft) oder zur Herstellung von Konnzepten, Produkten oder Ergebnissen im allgemeinen.
Vor diesem Hintergrund sind nicht die Regeln eines Spiels eine "Methode" sondern jene Vorgehensweisen, mit welchen ein neues Spiel konzipiert und marktfähig realisiert wird.
Oder bei meinem gerne benutzten Beispiel des (inkrmentell-adaptiven) Komponierens eines Musikstücks (als Analogie zum Programmieren), das auf einem bereits vorhandenen Klavier (als Analogie zur bestehenden ICT-HW und Basis-SW) gespielt wird ist die "Methode" die für den Komponisten typische Vorgehensweise beim Komponieren.
Und diese ist je nach Komponist unterschiedlich. Wäre sie es nicht, dann gäbe es als Musik bloss einen "Einheitsbrei".
Natürlich werden Musikwissenschaftler quer über alle diese unterschiedlichen Vorgehensweisen - vielleicht auch nur für bestimmte Gruppen von Komponisten - ein paar gemeinsame "Vorgehensmuster" erkennen. Und für Musikstudierende kann der Gebrauch dieser Muster nützlich sein, um erste Kompositionen zu erstellen um dann daraus eine eigene Vorgehensweise (=Methode) zu entwickeln.
Trotz dieser individuellen Eigenheiten des Komponisten wird er sich einerseits an Standards halten (z.B. daran, was ein bestimmtes Instrument und ein üblicher Profimusiker und nicht nur ein Ausnahmetalent leisten können) und er wird in einigen Bereichen genau so vorgehen wir viele andere Komponisten auch, etwa bei der Nutzung der diversen Formen des "Kontrapunkt".
Wobei die einzelnen Formen des Kontrapunkts "Techniken" darstellen, die "methodisch" (also planmässig und überlegt) genutzt werden.
Sowohl den "Methoden" als auch den "Techniken" liegen "Prinzipen" zugrunde. Das sind generelle, verallgemeinerte Grundsätze. In der Musik z.B. die Harmonielehre.
Prinzipien des Software-Entwurfs sind z.B. die schrittweise Verfeinerung (Abstraktionsstufen), das Geheimnisprinzip und die Programm-Modularisierung.
Auch die "12 Prinzipien des Agilen Manifests" sind solche.
Nun zur Frage, ob das Projektmanagement (PM) ein Kern- oder Nebenprozess ist, also seine Methode klar firmenspzifisch oder "ab Stange" gestaltet ist.
Für mich weder noch. Denn das PM stellt eine Methode dar, mit der "etwas" (im Bereich der Haupt- oder Nebenprozesse) auf Basis einer Vorstellung vom zu Erreichenden innerhalb eines definierten Zeitraums und mit definierten Kosten erreicht werden soll, und zwar i.a. in Kooperation mit diversen Personen. Und zudem handelt es sich bei einem Projekt immer um etwas Neuartiges und daher Risikobehaftenem. Die spezifische Ausgestaltung der PM-Methode hängt also immer vom zum Erreichenden, dem Zeitraum, dem Kostenrahmen, den Beteiligten und dem Kontext innerhalb dessen dieses Projekt abgewickelt wird ab.
Ein "Standardvorgehen" ist also nur dann denkbar, wenn alle diese Merkmale (Ergebnis, Zeitdauer,Kosten, Beteiligte, Kontext) "wie schon mal gehabt" sind, es also nichts Neuartiges darstellt. Dann aber ist es kein Projekt sondern z.B. eine Auftragsabwicklung "nach Schema F".
Also: PM ist immer ein spezifisches und einmaliges Vorgehen. Dabei werden jedoch bekannte "Vorgehensmuster" - angepasst - genutzt und bestimmte projektübergreifende Techniken eingesetzt. Und es werden bestimmte allgemeine Prinzipien des PM verfolgt.
PRINCE2 etwa ist ein / besteht aus solchen "Vorgehesnmustern", die jedoch je nach Situation spezifisch "zurechzuschneidern" sind. Auch für dieses "tailoring" beschreibt PRINCE2 übrigens "Vorgehensmuster".
Hui. So viele Begriffe, die ich erst mal durchsortieren muss: Methode, Vorgehensweise, Vorgehensmuster, Standardvorgehen, Techniken, Prinzipien ...
AntwortenLöschen(Da habe ich noch genug Stoff für unser Blog oder für die Diskussionen bei Xing.)
Der allgemeinen Definition der Methode stimme ich zu. Wenn ich darüber nachdenke, ist Lean Startup eher Methode als PRINCE2. Denn bei Lean Startup geht es ja darum, etwas über die Kunden zu lernen.
Bei den Spielregeln bin ich mir noch nicht ganz sicher: Wenn ich ein Spiel spiele, um zum Beispiel strategisches Denken zu üben, wäre das eine Methode. Wenn ich nur spiele, um mir die Zeit zu vertreiben, also an keine Erkenntnis interessiert bin, dann wäre es keine Methode.
Wenn der Zweck des Erkennens nicht im Vordergrund steht, dann wäre es ein Verfahren oder eine Vorgehensweise.
Wäre dann die Spielmetapher passend für ein Verfahren?
Danke für diesen Artikel für die Variabilität in agilen Prozessen. Da dies auch ein Blick in die neuen Arbeitsprozesse mit sebstbestimmten, bei der Arbeit mehr Freude verspürenden Menschen ist, würde ich mich freuen, wenn Sie den Artikel auf dem Blog der Initiative Wirtschaftsdemokratie nochmals veröffentlichen würden.
AntwortenLöschenViele Grüße
Martin Bartonitz