Dass die Selbstorganisation nicht vom Himmel fällt sondern erarbeitet werden muss, hatte ich schon geschrieben. Arbeit alleine reicht aber nicht, auch die Einstellung muss stimmen. Der Weg zu selbstorganisierten Teams – egal ob man Scrum oder eine andere teamorientierte Arbeitsweise einführt – gelingt nur mit der passenden Einstellung bzw. einen bestimmten Menschenbild.

In einer Diskussion über Führungsstile sagte eine Führungskraft vor kurzem folgenden Satz zu mir: “Das geht alles auch mit Druck”. In gewisser Weise hat er recht, eine Arbeitsgruppe oder Abteilung lässt sich natürlich mit präzisen Handlungsanweisungen, Druck und Drohungen führen. Ob das in Projekten oder bei Entwicklungsarbeiten in denen es auf Kreativität und neue Lösungen ankommt sinnvoll ist, möchte ich jetzt nicht diskutieren. Wichtiger scheint mir die grundlegende Haltung, das Menschenbild, das zu einem solchen Führungsverständnis führt, zu sein. Provozierend formuliert steckt da folgendes Menschenbild dahinter:

• Mitarbeiter wollen nicht arbeiten und müssen permanent angetrieben werden.
• Mitarbeiter sind dümmer als die Führungskraft. Deshalb muss die Führungskraft mit konkreten Anweisungen den Arbeitsfortschritt absichern.

Nicht minder provozierend formuliert lautet die Antithese:

• Mitarbeiter wissen besser als die Führungskraft wie die Probleme zu lösen sind.
• Mitarbeiter sind grundsätzlich interessiert sich für die Firma und ihre Ziele zu engagieren und wollen lieber sinnvoll arbeiten als faulenzen.

Die Wirklichkeit ist ein wenig komplizierter aber irgendwo zwischen diesen Polen bewegt sich die Einstellung gegenüber den Mitarbeitern. So verlockend Produktivitätssteigerungen durch Selbstorganisation auch klingen mögen, mit einem Menschenbild wie dem zuerst formulierten wird es nie ein echtes selbstorganisiertes Team geben. Nur wer daran glaubt, dass das Team im besten Wissen und Gewissen eine Lösung erarbeitet und dann bereit ist diese Lösung mit zu tragen wird die Früchte der Selbstorganisation ernten können. Dieses Mittragen der Lösung – auch wenn sie im ersten Moment nicht der eigenen Präferenz entspricht – ist die Antwort auf die implizite Vertrauensfrage, die das Team regelmäßig stellt. Wer “Selbstorganisation” nutzen will (z.B. bei einer Einführung von Scrum) muss bereit sein “mitzutragen” auch dann, wenn die Entscheidung des Teams den Eigeninteressen der Führungskraft zuwider läuft. Es gibt nichts Schlimmeres als mit Worten “ja” und mit Taten “nein” zu sagen.

Der Advocatus diaboli fragt nun wie mit politischen Entscheidungen umgegangen werden soll, die ggf. den Entscheidungen des Teams entgegen laufen (könnten). Hier gibt es nur eine Antwort: So früh und so ehrlich wie möglich alle Rahmenbedingungen an das Team kommunizieren. Wenn beispielsweise innerhalb eines Projektes eine Software angeschafft werden muss und auf höherer Ebene hierzu bereits eine Vorentscheidung gefallen ist, muss das Team davon wissen, bevor sie sich selbst mit der Auswahl befassen. Hört sich trivial an ist es aber nicht, ich habe es schon zu oft erlebt, dass wohl überlegte Lösungen mit dem Hinweis auf bereits vorgefasste Entscheidungen wieder gekippt wurden. Kein Team arbeitet gerne für den Mülleimer und eine solche Entscheidung wird von den Mitarbeitern nahezu zwangsläufig als Missachtung Ihrer Arbeit(szeit) betrachtet.

Ohne offene und ehrliche Kommunikation und einer gehörigen Portion Vertrauen in die Mitarbeiter kann Selbstorganisation nicht wachsen.

Ähnliche Beiträge:

1. Lohnt sich Selbstorganisation Stefan Hagen hatte im Projektmanagement Blog die Frage Selbstorganisation – Chance oder Illusion aufgeworfen. Ich möchte die Frage noch...
2. Was ein Team ausmacht Wir schreiben hier immer wieder über die Bedeutung des Teams. Wir differenzieren zwischen echten Teams und Gruppen, die sich...
3. Scrum oder die Selbstorganisation fällt nicht vom Himmel Das Scrum-Team arbeitet selbstverantwortlich und selbstorganisiert. Selbstorganisation ist eines der wesentlichen Merkmale eines echten Teams – daran besteht kein...

Das Scrum-Team arbeitet selbstverantwortlich und selbstorganisiert. Selbstorganisation ist eines der wesentlichen Merkmale eines echten Teams – daran besteht kein Zweifel. Die Fähigkeit zur Selbstorganisation fällt aber nicht vom Himmel, wenn beschlossen wird “wir machen Scrum” oder die Abteilung in Team umbenannt wird. Diese Fähigkeit muss von der Gruppe hart erarbeitet, geübt und laufend trainiert werden. Ja – es ist wie im Sport. Wenn wir eine Handballmannschaft betrachten ist jedem klar, dass zehn Sportler mit guten individuellen Fähigkeiten noch keine gute Mannschaft ausmachen, die erfolgreich spielt. Es liegt klar auf der Hand, dass der Trainer die harte Aufgabe hat aus den Individualisten eine Mannschaft zu machen, die dann irgendwann auf dem Feld steht und bei kritischen Spielständen selbst dafür sorgen kann, dass sie zum Erfolg kommt. Wie beschränkt der Einfluss des Trainers im laufenden Spiel ist, erkennt man oft daran wie verzweifelt die Trainer auf und ab rennen wenn die Mannschaft nicht das umsetzt was sich der Trainer ausdenkt.

Ein Scrum-Master hat einen ähnlichen Job wie ein Handballtrainer. Er oder sie muss den Haufen von Spezialisten dazu bringen als Team zu agieren und durch laufendes Training dafür sorgen, dass die Leistungsfähigkeit erhalten bleibt. Genau! – es geht um Erhaltung und nicht um Steigerung. Die Leistungsfähigkeit jedes Teams wird von alleine schlechter – es ist genauso wie bei einer Handballmannschaft ohne Trainer, die Spielpraxis kann eine gewisse Zeit die sich verschlechternde Kommunikation und das Einschleifen schlechter Gewohnheiten verlangsamen, langfristig geht es aber nicht ohne Training.

Noch ein paar Wort zur Leistungssteigerung oder gar zum Leistungsdruck: Ein echtes Team arbeitet um Größenordnungen effizienter als eine zusammengewürfelte Gruppe oder ein “zerstrittener Haufen”. Wenn die Teamarbeit ins Laufen kommt entsteht das “Wir-Gefühl”, der Teamgeist, der ein Gefühl der Verpflichtung mitbringt. Dieses Gefühl der Verpflichtung lässt den Einzelnen die persönlichen Bedürfnisse hinten an stellen. Mit dem Erfolg kommt als Belohnung das Gefühl der kollektiven Euphorie. Das ist wichtig und manchmal notwendig. Das Wechselspiel aus Verpflichtung und Euphorie darf aber nicht zum Dauermotor der Arbeit werden sonst besteht die Gefahr des Ausbrennens. Hier steht der Scrum-Master in der Pflicht dieses zu verhindern. Diese Aufgabe ist doppelt schwer, weil ein rennendes Team sich gelegentlich selbst überfordert. Auf der anderen Seite wird gelegentlich von Seiten der Organisation Druck aufgebaut um Hochleistungsteams noch weiter zu treiben und auszubeuten. Der Scrum-Master steht dazwischen. Der / die Scrum-Master ist also nicht nur Hebamme der Selbstorganisation sondern manchmal auch großer Bruder oder große Schwester, die das Team beschützen.

Noch einmal zurück zum Handballsport, den ich als ehemaliger Spieler und Trainer immer noch verfolge. Die deutsche Nationalmannschaft hat in den letzten Jahren große Erfolge gefeiert. Erfolge, die teilweise mit ersatzgeschwächten Mannschaftsaufstellungen erzielt wurden. Der Teamgeist hat hier unglaublich viel kompensiert aber irgendwann kollabiert das Verpflichtungs-Euphorie-System. Die Euphorie kann nicht ewig den Verbrauch der Substanz kompensieren – das enttäuschende Abschneiden bei der letzten Europameisterschaft kann man durchaus als Ausbrennen des Teams deuten.

In Kürze noch einmal die wichtigsten Punkte als Zusammenfassung. Diese Punkte gelten nicht nur für Scrum sondern für alle Organisationsformen, die auf selbstorganisierte Teams setzen:

• Selbstorganisation muss erarbeitet, geübt und erhalten werden.
• Selbstorgansierte Teams brauchen Trainer.
• Trainer benötigen eine andere Ausbildung als Teammember

Ähnliche Beiträge:

1. Teamphasen, Projektmanagement und Teamuhrwerk Im agilen Manifest steht an erster Stelle der Satz „Individuals and interactions over processes and tools“. Die Menschen im...
2. Wann ist ein Team (k)ein Team Teamarbeit ist wichtig. Für Projekte braucht man Teams. Das sind zwei unbestrittene Aussagen, die in vielen Variationen in Literatur...
3. Selbstorganisation und Menschenbild Dass die Selbstorganisation nicht vom Himmel fällt sondern erarbeitet werden muss, hatte ich schon geschrieben. Arbeit alleine reicht aber...

Für erfahrene Scrum Anwender oder agile Software-Entwickler ist klar was ein Stand-Up-Meeting ist. Da diese Methode auch unter anderen Rahmenbedingungen von großem Nutzen sein kann, möchte ich zuerst noch einmal kurz zusammenfassen, was ein Stand-UP-Meeting ist. Es ist ein sehr häufiges, regelmäßiges (tägliches) Treffen des Projektteams. Das Treffen ist bewusst kurz gehalten (Richtwert 15 min) und wird im Stehen abgehalten. In der Regel steht das Team im Kreis um das gemeinsame Taskboard. Der Ablauf ist standardisiert, es werden von jedem Anwesenden kurz und knapp die folgenden Fragen beantwortet:

• Bin ich mit der Aufgabe fertig geworden, die ich mir bis heute vorgenommen hatte?
• Welche Aufgaben nehme ich mir bis zum nächsten Treffen vor?
• Gibt es ein Problem, das mich gehindert hat meine Aufgabe(n) abzuschließen?

Ausgehend von einer sinnvollen Teamgröße von 4 bis 8 Personen, hat jede(r) Anwesende nur ca. 2 min Zeit seine Fragen zu beantworten. Damit wird schon offensichtlich wie knapp die Zeit ist. Der Grund, dass diese Meetings sich oft verlängern liegt aber weniger an der knappen Zeit, sondern an den folgenden Gründen:

• Unpräzise Moderation
• Abhängigkeit von Aufgaben und resultierende Konflikte
• Allgemeines Kommunikationsdefizit des Teams

Unpräzise Moderation

So unerfreulich es für den Moderator (Scrum Master) auch sein mag – das 15-minütige Meeting erfordert eine präzise Moderation. Begründung und Analyse von Problemen gehören nicht in das Stand-Up-Meeting sondern müssen ggf. in separaten Terminen mit klarer Agenda besprochen werden. Es ist Aufgabe der Moderation die angesprochenen Probleme festzuhalten um danach Lösungen herbeizuführen zu können. Wenn das Problem in irgendeiner Form erfasst ist (Liste, Merkkärtchen, Taskboard, …) wird im Stand-Up-Meeting nicht weiter über dieses Problem gesprochen. Um diese Vorgehensweise besser einhalten zu können ist es z.B. hilfreich wenn alle Anwesenden, die ein Problem mitbringen, dieses schon vorab auf einem roten Kärtchen notieren. Diese Kärtchen werden dann im Meeting gesammelt und sichtbar aufgehängt. Über jedes Kärtchen darf dann nur so viel gesprochen werden, dass klar ist worum es geht.

Abhängigkeit von Aufgaben und resultierende Konflikte

Schwieriger wird es wenn einzelne Aufgaben voneinander abhängen, wenn z.B. eine(r) auf die Ergebnisse eines anderen warten muss. Das Problem des einen wird damit indirekt zum Problem des anderen. Hier ist zudem ein erhebliches Konfliktpotential verborgen. Niemand gibt in der Runde gerne zu, wenn er seine Aufgabe nicht abgeschlossen hat – umso besser wenn die vermeintliche Schuld bei einem anderen liegt. Trotz der Brisanz der abhängigen Aufgaben und Probleme gilt auch hier: Diskussion und Analyse gehört nicht in das Stand-Up-Meeting. Hier gilt es für den Moderator die Beteiligten zu identifizieren und ggf. sofort einen Ausweichtermin zu vereinbaren, in dem das Problem nur mit den wirklich Beteiligten zu diskutieren. Derartige Abhängigkeitssituationen lassen sich an spontanen Wortwechseln der Beteiligten erkennen. Diese Wortwechsel können sich leicht in die Länge ziehen und sich über einen Schlagabtausch zu einem Streit entwickeln. Umso wichtiger ist es sie schnell zu beenden und in einem anderen, geeigneteren Rahmen zu besprechen.

Allgemeines Kommunikationsdefizit des Teams

Auch wenn man Schreibtisch an Schreibtisch oder Tür an Tür arbeitet wird der notwendige Gesprächsbedarf nicht automatisch gedeckt. Gesprächsbedarf entsteht einerseits aufgrund des notwendigen Informationsaustauschs andererseits aus dem Bedürfnis nach sozialer Interaktion. Beide Anliegen sind sehr wichtig und brauchen den notwendigen Raum. Dieser Raum ist allerdings nicht das Stand-Up-Meeting. Dementsprechend gilt es auch hier das Bedürfnis nach Kommunikation in einen anderen Rahmen zu befriedigen. Dies kann ein Workshop zum Informationsaustausch, eine offene Gesprächsrunde oder ein gemeinsames Bier am Abend sein. Ein Kommunikationsdefizit lässt sich oft an einer Vielzahl von Wortmeldungen und Redebeiträgen erkennen.

Fazit

Die Moderation muss mit Argus-Augen darüber wachen, dass nur Fragen beantwortet und Probleme genannt werden. Alles andere muss in separate Termine verschoben werden, die im besten Fall schon während des Stand-Up-Meetings oder sofort danach vereinbart werden. Wichtig ist in jedem Falle, dass beim notwendigen “Abbrechen” eines Redebeitrages in Aussicht gestellt ist, dass das Thema ausführlich zur Sprache kommt. Die richtige Form des Ausweichtermins und der Teilnehmerkreis hängen dabei von den jeweiligen oben genannten Ursachen des Redebedarfes ab.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 6, siehe Mindmap zu Inhalt und Struktur.

Keine ähnlichen Beiträge.

Und heute gleich der zweite Literaturtipp hinterher. Wer sich für agile Softwareentwicklung und hier insbesondere für Scrum interessiert findet in dem Buch von Roman Pichler eine sehr gut geschriebene Einführung. In wenigen Stunden lässt sich das Buch durcharbeiten um einen guten Einblick in Scrum zu erhalten. Es lohnt sich aber auch ein zweites oder drittes Lesen, da viele Abschnitte mit Informationen vollgepackt sind. Informationen die zum weiter nachdenken und zum Reflektieren der gemachten Erfahrungen anregen. Die Absätze im Buch sind meistens sehr kurz gehalten und bringen die wichtigen Sachverhalt, in kurzen klaren Sätzen auf den Punkt.

Scrum – Agiles Projektmanagement erfolgreich einsetzen

Ähnliche Beiträge:

1. Lesetipps zum Wochenende Es gibt Wochen, da kommt man mit dem Lesen interessanter Blog-Artikel kaum nach. Auch die Blogroll erhält so den...
2. Drei kurze Lesetipps zum Wochenende Zuerst ein guter Beitrag über Scrum Rollen. Uwe Friedrichsen bringt kurz und klar auf den Punkt wo sich die...
3. aktualisierte Blogroll In der Blogroll sind 3 neue Blogs hinzugekommen: Zuerst möchte ich Guerilla Projektmanagment nennen. Hier geht es um den...

Wie schon im vorangegangenen Artikel erwähnt betrachte ich Agilität eher als Geisteshaltung denn als rein methodischen Ansatz. Am ersten Punkt des agilen Manifests

Individuals and interactions over processes and tools
 

möchte ich dies verdeutlichen. Mit “individuals” sind die Menschen gemeint. Die “interactions” sind wechselseitige Kommunikation und die daraus entstehenden Beziehungen der Menschen. Die Kommunikation, der Erfahrungs- und Wissens-Austausch und die gemeinsamen Erfahrungen lassen ein Netzwerk von Beziehungen entstehen. Dieses Netzwerk ermmöglicht eine kooperative Zusammenarbeit und lässt etwas entstehen das mehr ist als die Summe der Einzelnen. Deshalb gehören die Menschen, die Kommunikation zwischen ihnen und ihre Beziehungen zusammen. Das ist die Bedeutung von “individuals and interactions”. Und das soll im Zweifelsfalle wichtiger sein als Prozesse und Werkzeuge? Ja! Und wiederum gilt es einem Vorurteil entgegen zu treten: Prozesse und Werkzeuge werden nicht negiert sondern lediglich im Zweifelsfalle zurückgestellt bzw. nach Prüfung modifiziert um sie passender zu machen. Es wird das Prinzip “inspect and adapt” angewendet.

Diese Priorität macht den Unterschied aus. Lasse ich einem Projektteam in einem konkreten Projekt die Freiheit etwas anders zu machen, als es sonst in der Firma üblich ist oder setze ich durch, dass sich das Team an alle “Regeln” hält. Ganz plakativ ins Bild gebracht sieht der Unterschied folgendermaßen aus:

Ein drastisches Bild, das den prinzipiellen Unterschied aber deutlich macht. Die Menschen gestalten ihre Gruppe und ihren Prozess, oder die Menschen ordnen sich dem Prozess unter. Die Wahl der agilen Variante setzt voraus, dass ein Grundvertrauen vorhanden ist, dass die meisten MitarbeiterInnen aus eigenem Antrieb im Sinne des Projektes arbeiten wollen. Die (überspitzt formulierte) Antithese zu diesem Grundvertrauen ist die Annahme, dass alle MitarbeiterInnen zur Arbeit gezwungen werden müssen. Das sind nicht nur zwei paar Stiefel, der Unterschied ist so groß wie der zwischen Stiefel und Sandale. Das bedeutet, dass sich “Agiles Projektmanagement” nicht so einfach einführen lässt wie ein neues Werkzeug. Das Grundvertrauen in die Fähigkeiten der Menschen muss vorhanden sein. Der Versuch Vorgehensweisen wie SCRUM ähnlich wie einen neuen Prozess einzuführen wird scheitern. Wenn die ersten Schritte bereits getan sind muss in größeren Organsiationen dafür gesorgt werden, dass die die zu Beginn entstehenden agilen Inseln geschützt werden.

Und es gibt noch einen weiteren Punkt zu bedenken. Obwohl ich selbst ein Anhänger agiler Vorgehensweisen bin, erhebe ich doch warnend den Finger. Nicht jeder Prozess lässt sich beliebig umgestalten, es gibt auch Prozesse, die sich nicht für Agilität eignen. Das heißt es kann richtig Sinn machen mit agilen Inseln im klassischen Meer zu arbeiten. Über diese agilen Inseln werde ich in einem der nächsten Beiträge noch etwas schreiben.

Ähnliche Beiträge:

1. Agiles und klassisches Projektmanagement I – Planung Agilität ist mehr als ein neuer Ansatz oder eine neue Methode Projekte zu managen. Es ist eine Arbeitsweise bzw....
2. Virtuelle oder verteilte Teams Ich gestehe der Begriff des “virtuellen Teams” steht nur in der Überschrift um Futter für die Suchmaschinen zu liefern....
3. Teamphasen, Projektmanagement und Teamuhrwerk Im agilen Manifest steht an erster Stelle der Satz „Individuals and interactions over processes and tools“. Die Menschen im...

Agilität ist mehr als ein neuer Ansatz oder eine neue Methode Projekte zu managen. Es ist eine Arbeitsweise bzw. eine Wertevorstellung. Die Punkte des agilen Manifests zeigen es auf:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Entgegen landläufigen Vorurteilen handelt es sich nicht um Aussagen, die etwas negieren. Es wird nicht gesagt, es müsse keinen Plan oder keine Dokumentation geben. Es sind Werte und Prioritäten. Es wird mehr Wert auf die Lauffähigkeit der Software – oder allgemeiner die Funktionstüchtigkeits des Projekt-Ziel-Artefakts – gelegt, als auf eine ausführliche Dokumentation. Es wird in Bezug auf den Kunden mehr Wert auf Zusammenarbeit als Vertragsverhandlung gelegt. Auch im ersten und im letzten Punkt sind Prioritäten formuliert. Diese lohnen aber eine genauere Betrachtung, da hier große Differenzen zum klassischen Projektmanagement sichtbar werden. Trotz der Differenzen steckt in den Punkten “Individuals und Interactions” bzw “Responding to change” auch der Schlüssel zur Kombination agiler und klassischer Vorgehensweisen.

Responding to change over following a plan

In agilen Projekten wird nicht geplant – so lautet eines der Vorurteile. In agilen Projekten gibt es sehr wohl einen Plan, er hat lediglich eine geringere Reichweite und wird sehr häufig überarbeitet und schrittweise verfeinert. Im Falle von Scrum wird täglich geplant und täglich geprüft ob der Plan eingehalten wurde. Jede(r) formuliert täglich die nächsten Aufgaben, die er oder sie in Angriff nimmt. Beim nächsten Meeting wird über die Erledigung oder Nicht-Erledigung gesprochen. Die Aufgaben wurden zuvor bei der Planung des jeweiligen Sprints gemeinsam ermittelt. Die Aufgaben selbst leiten sich aus den Anforderungen, die in diesem Sprint umgesetzt werden sollen, ab. Die Anforderungen wiederum entstammen dem priorisierten Produkt-Backlog. Es handelt sich also um eine verschachtelte Struktur von Plänen, die iterativ verfeinert werden. In einem “Wasserfall”-Projekt wird zu Beginn ein Gesamtplan erstellt, der so gut wie möglich eingehalten wird. Die Grafik zeigt den Unterschied:

Die real zu erledigenden Aufgaben (graue Balken) werden klassisch so früh und so vollständig wie möglich ermittelt und geplant. Im agilen Projekt werden zu Beginn die Eckpfeiler des Projektes (Vision und Endtermin) und der Plan für den ersten Sprint festgelegt. Die weitere Spezifikations- und Planungsarbeit wird über das Projekt verteilt. Die Planungsarbeit liegt klassisch überwiegend beim Projektleiter. In agilen Projekten beteiligt sich das Team wesentlich stärker an der Planung. Der Unterschied der Planung liegt also überwiegend darin “Wann und von wem der Plan gemacht wird”. Eine mögliche Synthese von klassischer und agiler Vorgehensweise ist in der nächsten Grafik angedeutet:

Ein grob ausgeführter Wasserfall liefert den Input für den Start der agilen Implementierung, die agile Implementierung liefert das Produkt zurück. Der klassische Grobplan ist der Rahmen in dem die agile Detail-Planung ablaufen kann. Am Thema Planung wird einerseits die Differenz der Ansätze aber auch ein möglicher Synthese-Punkt sichtbar.

Und hier geht es zum zweiten wichtigen Unterschied zwischem agilen und klassischer Vorgehensweise.

Ähnliche Beiträge:

1. Agiles und klassisches Projektmanagement: Menschen, Prozesse und Führungsphilosophie Wie schon im vorangegangenen Artikel erwähnt betrachte ich Agilität eher als Geisteshaltung denn als rein methodischen Ansatz. Am ersten...
2. Zusammenfassung Projektmanagement – Checklisten Zum Wochenende möchte ich die vorangegangenen Beiträge zu den Projektmanagement-Checklisten zusammenfassen. Hinter den 7 Checklisten steckt natürlich ein gedanklicher...
3. Politik, Teamgeist und Projektarbeit Politiker fordert mehr Teamgeist in der Regierung. Dieser Satz ist einer Schlagzeile meiner Tageszeitung entnommen. Eine Regierung, die gemeinsam...