Artikel in der PMaktuell

Der spannenden Artikel über Fortschrittkontrolle im Projektmanagement von Carsten Czeczine wurde in der Fachzeitschrift der GPM, der PMaktuell veröffentlich.
Den Artikel in der Onlineausgabe der PMaktuell finden Sie hier

Schrödingers Katze im Projektmanagement

… oder, wie geht es eigentlich meinem Projekt?

Wenn wir ein großes Projekt durchführen wollen, dann wissen wir, dass es zu Abweichungen vom Projektplan kommen kann. Und niemand von uns mag es, erst am Ende des Projektes diese Abweichungen zu entdecken oder festzustellen, dass das Projekt ein Fehlschlag war. Deutlich angenehmer ist es, von diesen Abweichungen früher zu erfahren. Denn dann können wir darauf reagieren und das Projekt immer noch zum Erfolg führen. Diese Erkenntnis ist nun nicht neu im Projektmanagement und Generationen von Projektmanagern haben sich schon mit der Fortschrittskontrolle von Projekten beschäftig und entsprechende Instrumente entwickelt. Und doch scheitern immer wieder Projekte scheinbar überraschend in der Schlussphase. Wie kann das sein?

1935 schlug der Physiker Erwin Schrödinger ein faszinierendes Gedankenexperiment vor. In eine undurchsichtige Stahlkammer wird eine Katze zusammen mit einer winzigen Menge einer radioaktiven Substanz, einem Geigerschen Zählrohr und einem Kolben Blausäure eingesperrt. Bei der radioaktiven Substanz besteht eine 50 prozentige Chance, dass innerhalb einer Stunde eines der Atome zerfällt, was von dem Geigerschen Zählrohr gemessen würde und in diesem Falle das Zertrümmern des Kolbens mit der Blausäure durch einen Hammer auslösen würde. Mit dem Ergebnis, dass die Katze stirbt. Dann wird eine Stunde gewartet.
Da nur eine 50 prozentige Chance besteht, dass eines der Atome zerfällt, existiert die Katze in dieser Stunde gleichzeitig in zwei sich wiedersprechenden Zuständen: Sie ist tot und sie ist lebendig (und vermutlich ziemlich verärgert).
Erst wenn wir nach Ablauf der Stunde die Stahlkammer öffnen und nachsehen, wird einer der beiden Zustände real und der andere verliert seine Bedeutung. In der Quantenphysik sagen wir auch, mit der Messung kollabiert das System der überlagernden Zustände.

Was hat das nun mit Projektmanagement zu tun?

Erfolgreiche Projekte basieren auf sinnvollem Projektcontrolling und erfolgreicher Projektsteuerung. Beides lebt davon, den aktuellen Zustand eines Projektes korrekt messen zu können. Und hier fängt nun oft das Problem an.

Die Wurzel unseres Problems liegt in der Art, wie wir Projekte planen. Bevor wir mit der Umsetzung anfangen:

• Sammeln wir alle Anforderungen an das zu erstellende Ergebnis
• Erstellen wir daraus ein detailliertes fachliches Konzept
• Erzeugen wir basierend auf dem fachlichen Konzept ein detailliertes und vollständiges technisches Konzept
• Leiten wir aus dem technischen Konzept alle notwendigen Tätigkeiten ab
• Erstellen wir den Projektplan, der genau festlegt, wer bis wann was tun wird

Das Ergebnis ist quasi die vollständige Beschreibung des Lösungswegs. Die regelmäßige Fortschrittskontrolle findet nun in der Regel als Abgleich zwischen Tätigkeiten, die bis jetzt hätten fertig sein sollen und Tätigkeiten, die bis jetzt tatsächlich geleistet wurden statt. Wir messen den Projektfortschritt also auf der Basis geleisteter Arbeit gegen geplanter Arbeit. Klingt erst mal logisch.

Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und die Umsetzung fehlerfrei ist. Und der Schlussfolgerung, dass damit das Befolgen des Projektplans automatisch zum gewünschten Projektergebnis führt. Herauszufinden, dass dem allerdings oft nicht so ist, das ist nur durch realistisches Testen der Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann dann das Erwachen schmerzhaft sein. Wir finden eventuell erst in der Schlussphase des Projektes heraus, dass das Produkt nicht fertig ist oder nicht funktioniert, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time & Budget zu retten, ist schier unmöglich.

Der Grund für diese späte Erkenntnis ist: Wir messen das Falsche. Wir messen die Menge an geleisteter Arbeit und vergleichen das mit der Menge an Arbeit, von der wir glauben, dass sie notwendig ist. Was wir nicht messen ist das erzielte Ergebnis. Damit verbleibt unser Projekt trotz einer scheinbaren Messung in einem überlagerten Zustand, es ist gleichzeitig ein voller Erfolg und ein totaler Misserfolg. Im Bild von Schrödingers Katze wäre das so, als würden wir den Zustand der Katze rein durch das Verstreichen der Zeit bestimmen wollen, ohne dabei die Tür der Stahlkammer zu öffnen.

Wenn wir ein Projekt bewerten wollen, dann stellt sich zuerst die Frage nach dem erzielten Ergebnis, also was kann das erzeugte Produkt. Dicht gefolgt von der Frage nach den Kosten. Niemand wird uns aufrichtig für unseren unermüdlichen Arbeitseinsatz und die vielen geleisteten Stunden danken, wenn das Ergebnis nicht stimmt. Oder haben Sie schon Lobeshymnen für die vielen Stunden Arbeit gehört, die in den neuen Berliner Flughafen gesteckt wurden? Nein, was unsere Kunden an erster Stelle interessiert ist, ist das Produkt fertig und funktioniert es!

Wie können wir dieses Problem der falschen Fortschrittsmessung lösen? Nur indem wir in kurzen Abständen die Tür zur Stahlkammer öffnen und uns vom tatsächlichen Zustand der Katze überzeugen. Wir lassen das System der überlagernden Zustände durch die konkrete Messung kollabieren. Im Projektmanagement bedeutet das, dass wir uns in kurzen Abständen die tatsächlichen Ergebnisse ansehen, die bisher erzielt wurden.

Das Projektmanagementframework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte potentiell auslieferfähige Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt und zwar in finaler Marktqualität. Finale Marktqualität bedeutet in diesem Kontext, dass innerhalb der Iteration alle notwendigen Tätigkeiten durchgeführt werden, um diese Funktionalität ausliefern zu können. Bei den meisten Produkten würde das z.B. das vollständige Testen und Dokumentieren bedeutet. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist, es existieren keine versteckten Restaufwände für diese Funktionalität mehr.

Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die Sie ungeplant zu einem späteren Zeitpunkt durchführen müssen, damit die Funktion wirklich funktioniert. Zum Beispiel, dass Sie in der Test- oder Abnahmephase Ihres Projektes feststellen, dass eine Funktionalität nicht ordnungsgemäß funktioniert und Sie diese nun nachbessern müssen. Das ist Aufwand, den Sie höchsten indirekt durch Puffer eingeplant haben. Wobei Sie aber nicht wissen können, wie viel Puffer Sie tatsächlich brauchen werden. Oft ist es das, was Ihnen am Ende Ihres Projektes die Kopfschmerzen bereitet.

In Scrum bewerten wir am Ende jeder Iteration, welche Funktionalitäten wirklich fertig sind und welche nicht. Wir bekommen damit einen realistischen Überblick über den Zustand unseres Projektes und eine realistische Information darüber, wie schnell wir tatsächlich sind.
Auf diese neue Art der Bewertung umsteigen führt in vielen Projekten erst mal zur Ernüchterung. Plötzlich liegt Schwarz auf Weiß der Nachweis vor, dass die ursprünglichen Erwartungen mehr oder weniger zu optimistisch waren. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst mal dem Mehraufwand durch das direkte Testen zugeschrieben. Und Sie ahnen schon, welche Maßnahme dann gerne als erstes zur Steigerung der Projektperformance gewählt wird. Doch das ist purer Selbstbetrug, diesen Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages.

In erfolgreichen Projekten stellen wir uns den Problemen, sobald sie auftreten und reduzieren damit Projektrisiken so gut wie möglich. Meine Lieblingsfrage, die ich Projekt- und Produktmanagern immer wieder gerne stelle ist: „Wann möchten Sie wissen, dass Sie ein Problem in Ihrem Projekt haben?“ Und die einzige sinnvolle Antwort darauf lautet: „So früh wie möglich!“ Je früher im Projekt Sie wissen, dass Sie ein Problem haben, umso mehr Optionen haben Sie noch, dieses Problem zu lösen und das Projekt so erfolgreich zu Ende zu führen.

„Ja, aber bei uns ist es nicht möglich innerhalb von vier Wochen eine ganze Funktionalität zu realisieren“. Wirklich? In der Tat gibt es vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind. Aber das ist bei weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selber mal darüber nach, könnte es genau diese Sichtweise von zu großen Funktionalitäten sein, die die Entwicklung Ihrer Produkte so komplex und herausfordernd macht?

Ein anderer gerne genommener Einwand ist: „Wir können nicht innerhalb von vier Wochen etwas entwickeln und vollständig testen. Unsere Tests sind dafür viel zu Aufwändig.“ Sind diese Tests zu aufwändig, weil sie so gut und umfassend sind? Oder weil sie nicht effizient genug durchgeführt werden? Auch hier gilt die gleiche Antwort wie zuvor. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. Und auch hier ist das deutlich seltener der Fall, wie es zuerst scheint.

Was wir also sehen ist, dass es für die Umstellung von Projekten auf ein realistischen Bewertungs- und Messverfahren in kurzen Intervallen nicht einfach mit dem Beschluss getan ist, sich alle vier Wochen die Ergebnisse ansehen zu wollen. Tatsächlich ist es dazu notwendig, den gesamten Prozess, wie Produkte und Projekte geplant, entwickelt und getestet werden unter die Lupe zu nehmen und auf das Ziel der stückweisen Abnahme in kleinen Inkrementen umzustellen.
Eine Anstrengung die sich jedoch immer lohnt, denn sie führt zu einem Unternehmen, das in der Zukunft in kürzerer Zeit die bessern Produkte in besserer Qualität entwickeln wird. Überlassen wir also Schrödingers Katze den Physikern und arbeiten lieber mit eindeutigen Zuständen.

In der Quantenphysik dient Schrödingers Katze als Parabel, um den quantenmechanischen Effekt der Zustandsüberlagerung zu veranschaulichen und führt dort zu neuen Erklärungsversuchen unserer Welt oder so faszinierenden Ideen wie der Theorie unendlich vieler paralleler Universen.
Im Projektmanagement dahingegen führt Schrödingers Katze zu Kopfschmerzen und zu manchmal scheinbar unendlicher Frustration. Hier lässt sich Schrödingers Katze übrigens auch gut mit einer alten Weisheit der Dakota-Indianer kombinieren: Wenn dein Pferd tot ist, steig ab!
Diese Weisheit wird gerne im Kontext des Projektmanagements zitiert, um klar zu machen, dass gescheiterte Projekte losgelassen werden sollen. Aber wie wir oben schon gesehen haben, scheitern viele an der Frage, ob das Pferd denn wirklich schon tot ist.

So gesehen leiden viele Projekte sogar an Schrödingers Pferd!

Imagebroschüre binaris informatik GmbH

Unsere Imagebroschüre ist jetzt auch online verfügbar!

http://binaris-informatik.de/ueber-uns/image-brochuere/

Unser Artikel über Test Driven Development auf informatik aktuell

Die informatik aktuell hat heute unseren Artikel über Unit-Tests und Test Driven Development veröffentlich. Und das macht uns schon ein bisschen Stolz.

Den ganzen Artikel findet ihr hier:
http://www.informatik-aktuell.de/entwicklung/methoden/gute-unit-tests-und-testgetriebene-entwicklung-tdd.html

Warum sich Gedränge so sehr lohnt

Im ersten Moment klingt Gedränge für die meisten von uns eher unangenehm, nach etwas, dass man nicht unbedingt haben möchte. Doch als Ken Schwaber und Jeff Sutherland 1995 nach einem Namen für ihr Projektmanagementframework suchten, da verbanden sie eine andere Vorstellung mit Gedränge. Sie suchten nach einem passenden Begriff, der ausdrückt wie ein Team gemeinsam und kurzentschlossen auf sich ändernde Umstände reagiert, um dennoch das gewählte Ziel zu erreichen. Das Scrum, wie das Gedränge im Rugbysport genannt wird, drückt dieses fast perfekt aus.

In verschiedenen Varianten des Rugbysports ist das Scrum die Standardsituation, durch die nach einer Spielunterbrechung der Ball wieder ins Spiel gebracht wird. Dabei stehen sich beide Mannschaften in einer kompakten Formation gegenüber und versuchen, nachdem der Ball in das Gedränge eingeworfen wird, diesen in Besitz zu nehmen.

Die Herausforderung in dieser Analogie zum Projektteam gestaltet sich wie folgt: Jede der beiden Mannschaften hat im Vorfeld eine Strategie vereinbart, wie sie das gemeinsame Ziel, den Ballbesitz, erreichen möchte.
Da allerdings schon klar ist, dass nicht alle Einflussfaktoren bekannt sind (z.B. die Strategie der gegnerischen Mannschaft) oder bestimmt werden können (das Verhalten der gegnerischen Spieler), wird die Strategie auch nur entsprechend grob geplant.

Nach dem Einwurf des Balls versuchen beide Mannschaften jetzt ihre Strategie umzusetzen. Dabei werden sich jedoch schon innerhalb von Sekunden mindestens eine und evtl. sogar beide Mannschaften mit sich völlig anderen Umständen konfrontiert sehen. Und hier, mitten im Gedränge gibt es jetzt keine Möglichkeit sich erst mal in Ruhe zurückzuziehen und eine neue Strategie zu besprechen oder sich von einem Trainer die nächsten Schritte vorgeben zu lassen. Nein, das Team muss nun autonom in der Hitze des Gefechts sein Verhalten anpassen um doch noch das Ziel zu erreichen.

Und genauso wünschen sich Ken und Jeff, wie moderne Projektteams mit den sich immer wieder verändernden Umständen in gängigen Softwareprojekten umgehen sollen.
Auch in Scrum (wir reden nun über das Projektmanagementframework) planen wir. Da wir uns aber darüber bewusst sind, dass wir vorab nicht alle Einflussfaktoren kennen und berücksichtigen können, planen wir bewusst anders. Wir planen weniger im Voraus und weniger im Detail. Angelehnt an die Just-in-time Idee aus dem Lean Management erfolgt Planung immer nur in dem zu aktuellen Moment richtigen Ausmaß bzw. erst zu dem Moment, wo sie wirklich notwendig ist. Das ist einer der großen Paradigmenwechsel, die Scrum mitgebracht hat.

Und um wieder auf das Gedränge zurückzukommen, setzen wir in Scrum nicht auf die konzeptionelle und planerische Kompetenz einer Einzelperson, wie z.B. den Projektleiter, sondern auf die Fähigkeiten und Erfahrungen unseres ganzen Projektteams. Wie beim Forschungsgebiet der Schwarmintelligenz glauben wir daran, dass eine zentrale Führung eines Projektteams nicht notwendig und oft sogar weniger leistungsfähig ist. Oder mal anders formuliert, wir formieren eine ganze Gruppe von gut ausgebildeten Fachleuten, die meistens auch nicht ganz kostengünstig sind. Und wollen dann nur einen Teil ihrer Hirnkapazität nutzen, weil wir ihnen nicht zutrauen, sich organisieren zu können? Wer an dieser Idee festhält, der hat immer noch zu viel Projektbudget übrig.

Doch eines dürfen wir natürlich zugeben, diese Form der Selbstorganisation von Teams muss oft erst noch erlernt werden. Auch Rugbyspieler und Rugbymannschaften sind nicht mit dem Wissen geboren worden, wie sie sich im Gedränge verhalten sollen. Sie haben das trainiert. Und damit auch Projektteams das lernen können, bietet Scrum einen einfachen aber effektiven Feedbackmechanismus, der durch inspect-and-adapt in kurzen Zyklen aus Projektteams hocheffiziente Mannschaften formt.

Da hört sich der Begriff Gedränge doch auf einmal ganz anders an.

Seminar Test Driven Development mit Java

Unter dem Schulungslabel binaris education bieten wir nun eine Schulung über Test Driven Development mit Java an. Am Beispiel der Programmierung eines LEGO Mindstorms Roboters zeigen wir die verschieden Phasen bei der Entwicklung von Software mit TDD.

Weitere Informationen und Termine zu diesem Seminar finden Sie hier.

Vortrag auf dem PM-Tag 2011

Am 16. September 2011 hält Carsten Czeczine auf dem PM-Tag 2011: Agiles Projektmanagement trifft Realität der GPM in Düsseldorf einen Vortrag zu selbstorganisierenden Teams. Der Tag verspricht mit einer Reihe weiterer interessanter Vorträge recht interessant zu werden.

Weitere Informationen gibt es hier.

Kanban Vortrag bei der RheinJUG im Februar 2011

Am 3. Februar 2011 hält Carsten Czeczine einen Grundlagenvortrag über Kanban bei der RheinJUG in Düsseldorf. Alle Informationen zu diesem Termin gibt es hier.

Update: Der Vortrag ist mittlerweile gehalten und er hat ganz eindeutig nicht nur Carsten Czeczine viel Spass gemacht. Die Resonanz war sehr gut. Hier finden Sie die Nachlese zum Vortrag vom Veranstalter.
Und hier die Präsentationsunterlagen als PDF.

Was sind selbstorganisierende Teams?

Zusammen mit den Begriffen der agilen Softwareentwicklung beziehungsweise dem agilen Projektmanagement wird auch immer öfters von selbstorganisierenden Teams gesprochen und oft betont, dass diese selbstorganisierenden Teams ein wichtiger Bestandteil der agilen Welt ist. Aber was genau bedeutet das denn, wenn ein Team selbstorganisierend ist?

„Das ist doch ganz einfach“, wird uns oft entgegnet, „das sind Teams, die ihre Arbeit selber organisieren“. Das ist doch schon mal ein Ansatz: Die Arbeit wird anders, „selber“ organisiert. Und was genau damit gemeint sein kann, ob es wirklich nur bei der Selbstorganisation der Arbeit bleibt und welche Konsequenzen das hat, genau damit wollen wir uns in diesem Artikel beschäftigen.

Fangen wir im ersten Schritt mal mit der Definition eines Teils der Fragestellung an, was verstehen wir denn unter einem Team?
Als Team verstehen wir im Folgenden eine Gruppe von Personen, die innerhalb eines Unternehmens gemeinsam eine bestimmte Aufgabe zu erfüllen haben. Dabei kann es sich grundsätzlich sowohl um interdisziplinäre Projektteams handeln, die bestimmte Projektziele erreichen sollen wie auch um Funktionsgruppen, wie beispielsweise die Systembetreuung eines Unternehmens, die bestimmte Maintenanceaufgaben wahrnehmen. All diesen Teams ist gemeinsam, dass das Team als solches eine bestimmte Aufgabe hat und die Teammitglieder zur Erreichung dieser Aufgabe miteinander interagieren.
Da derzeit meistens noch im Zusammenhang mit agiler Softwareentwicklung von selbstorganisierenden Teams gesprochen wird, werden wir uns in diesem Artikel manchmal auf softwareentwickelnde Projektteams beziehen. Die meisten der besprochenen Aspekte gelten jedoch auch für alle anderen Arten von Teams.

Wenn wir von selbstorganisierende Teams sprechen, was ist denn dann eigentlich ein nichtselbstorganisierendes Team, von dem wir uns ja jetzt scheinbar abgrenzen möchten?
Für diese Definition bietet sich die klassische Art der Teamorganisation an, die wir heute noch in den meisten Organisationen beobachten können. Eine Gruppe von Personen, die von einem Teamleiter geführt wird und in der jedes Teammitglied die Aufgaben durchführt, die ihm von seinem Teamleiter zugeordnet werden. Und dabei werden sowohl der Zeitpunkt wie auch die Art der Durchführung vom Teamleiter oder anderen organisatorischen Vorgaben vorgegeben. Der Großteil der Verantwortung und das Wissens über die Zusammenhänge liegen dabei beim Teamleiter, wofür er ja oft auch besser bezahlt wird. Diese Form der Teamorganisation zu diskreditieren, wollen wir uns an dieser Stelle ersparen. Welche Folgen sie haben kann (und ich möchte hier betonen, dass wir hier von können und nicht von müssen sprechen), ist Ihnen als Leser dieses Artikels selber schon bekannt.

Kommen wir also endlich zu dem, was uns wirklich interessiert, was bedeutet das Selbstorganisieren bei selbstorganisierenden Teams? Vorweg die Anmerkung, dass es dafür keine DIN Norm gibt und auch keine andere verbindliche Vorschrift, wann ein Team als selbstorganisierend gilt und wann nicht. Wir werden gleich eine Reihe von Aspekten besprechen, die Teil der Selbstorganisation eines Teams sein können. Welche davon dann für ein spezielles Team wirklich Sinn machen, hängt immer von den Umständen ab, unter denen dieses Team arbeiten muss und ist mit gesundem Menschenverstand zu entscheiden. Bedenken sie dabei, die Selbstorganisation ist kein Selbstzweck und es gibt auch keinen Orden dafür. Das warum des Ganzen wollen wir uns später ansehen.

Wir hatten es bereits am Anfang, ein wichtiger Punkt bei der Selbstorganisation ist die Organisation der Arbeit. Oder auch: Wer macht Was Wann! Beim wer macht was geht es erst mal darum, wer überhaupt was machen kann. Es gibt gerade bei Projektteams zwei extreme Ausprägungen für die Verteilung der notwendigen Fähigkeiten im Team: Spezialisten oder Generalisten.
Im ersten Fall kann jede notwendige Tätigkeit oft nur von einer, wenn das Team Glück hat von zwei Teammitgliedern ausgeführt werden. Damit beantwortet sich die Frage nach dem wer macht was quasi automatisch. Im zweiten Fall kann jeder im Team alles, das bedeutet, jede notwendige Tätigkeit kann von jedem Teammitglied in einer verantwortbaren Qualität durchgeführt werden. Ein hoher, aber nicht unmöglicher Anspruch, vor allem wenn man ihn dadurch etwas abmildert, das alle notwendigen Tätigkeiten nur von mindestens zwei oder besser drei Teammitgliedern ohne Qualitätsverlust durchführbar sein müssen.
Die Form der Selbstorganisation liegt darin, dass das Team selber entscheidet, welche Ausprägung der Wissensverteilung es wählen möchte, eher die Spezialisierungen oder doch die Generalisierung. Und das Team ermittelt auch selber welche Tätigkeiten für die erfolgreiche Erfüllung aller Teamaufgaben notwendig sind und welche Skills dafür im Team zur Verfügung stehen müssen. Wird externes Knowhow benötigt, ist es Aufgabe des Teams zu beschreiben, was genau benötigt wird, der eigentlichen Einkauf wird in der Regel dann jedoch durch andere Stellen im Unternehmen erfolgen. Geht es dabei jedoch um die Einstellung neuer Mitarbeiter für das Team, dann sollte das Team ein Mitspracherecht bei der Entscheidung haben. Denn das Team kann am besten beurteilen, ob ein neuer Mitarbeiter sowohl vom fachlichen wie auch sozialen Skill ins Team passt.
Entscheidet sich das Team eher für die Variante der generalisierten Wissensverteilung, dann liegt es auch in der Verantwortung des Teams für die notwendige Verteilung des Wissens zu sorgen. Das kann durch schriftliche Dokumentation erfolgen oder durch regelmäßige Vorträge im Team oder durch konsequente Zusammenarbeit von immer zwei Kollegen bei der Durchführung von Aufgaben (in der Softwareentwicklung auch als Pair Programming bezeichnet). Wichtig ist hierbei, dass Wissen, dass noch verteilt werden muss konsequent identifiziert wird. In einem mir bekannten Team führen wir hierfür regelmäßig eine sogenannte Truck-Faktor-Analyse durch. Das bedeutet wir analysieren für jedes Teammitglied, welche Auswirkungen hätte es für das Team wenn der Mitarbeiter morgen von einem LKW (Truck) überfahren würde und damit von heute auf morgen dem Team unwiderruflich nicht mehr zur Verfügung stände. Natürlich können Sie das bei sich auch weniger brachial formulieren, z.B. der Kollege ist wegen Steuerschulden über Nacht aus dem Land geflohen und nun nicht mehr auffindbar oder ähnliches. Sie verstehen schon, worauf es ankommt. Und dann überlegen Sie, ob ohne diesen Kollegen notwendige Tätigkeiten im Team nicht oder nur mit Schwierigkeiten durchführbar wären. Und wenn ja, beschließen Sie, wie Sie das vermeiden können.

Damit ist schon mal die Frage geklärt, wer KANN was. Jetzt kommen wir zur Frage zurück, wer MACHT was. Von außen werden Anforderungen an das Team gestellt. Ein selbstorganisierendes Team bricht die Anforderung in tatsächlich durchzuführende Tätigkeiten (auch als Tasks bezeichnet) runter, gibt sofern gefordert Aufwandsschätzungen ab und verteilt die dadurch entstehende Arbeit innerhalb des Teams. Diese Verteilung der Arbeit kann dadurch geschehen, dass das Team sich regelmäßig oder bei Bedarf trifft und im Gespräch die Aufgaben verteilt oder aber auch durch bestimmte Mechanismen, die allerdings ebenfalls vom Team bestimmt werden. So ein Mechanismus ist zum Beispiel einen Teamwand wie bei Scrum oder Kanban, auf der die anstehenden Tasks aufgeführt sind und die Teammitglieder je nach Verfügbarkeit sich die Aufgaben selber nehmen.

Dann haben wir gerade gesehen, dass eventuell geforderte Aufwandsschätzung vom Team selber erstellt werden und nicht von jemand außerhalb. Das ist sofort einsichtig, da nur der, der die Aufgabe durchführen soll auch wirklich sagen kann, wie lange er dafür brauchen wird. Wenn wir das jetzt noch damit kombinieren, dass das Team selber organisiert, wer was macht, dann ist natürlich sofort klar, dass das Team auch bei der eigentlichen Projektplanung eine wesentliche Rolle spielt. In Scrum ist das beispielsweise durch das Sprint Planningmeeting gelöst. Der Product Owner, ein Produktmanager, Anforderungsmanager oder wie auch sonst die Rolle bezeichnet wird, die dafür verantwortlich zeichnet fachliche Anforderungen anzunehmen, zu bewerten und zu priorisieren stellt dem Team vor, welche fachlichen Anforderungen/Aufgaben in welcher Priorität zu erfüllen sind. Und das Team bestimmt anschließend, welche Tätigkeiten und Aufwände sich daraus ergeben und bis wann diese durchführbar sind, bzw. welche Aufgaben innerhalb eines bestimmten Zeitraums erfüllt werden können.
Klingt verwirrend und aufwändig? Wenn ich unbedingt für die nächsten 24 Monate planen möchte bestimmt. Dann doch besser als einzelkämpfender Projektleiter alleine die Planung machen? Wenn Sie damit bessere, realistischere Projektpläne bekommen, lassen Sie mich es bitte wissen 🙂 Doch das ist eine andere Diskussion.

Was ist, wenn absehbar ist, dass das Team die aktuelle Planung nicht einhalten kann? Traditionell greift nun ein Projektleiter/Teamleiter ein und verordnet Maßnahmen. Nicht bei selbstorganisierenden Teams. Wir kommen später noch zu dem Punkt der Übernahme von Verantwortung durch Team und Teamitglieder. Auch hier ist das Team gefordert zu entscheiden, welche Maßnahmen sinnvoll erscheinen um entweder die Planung doch noch erfüllen zu können oder die Auswirkungen durch die Nichterfüllung zu minimieren. Das kann selbstverordnete Mehrarbeit sein, die Reduzierung der technischen Ansprüche an die Lösung (halt im ersten Schritt nicht das superneue supercoole Framework von XY einsetzen sondern erstmal was bewährtes) oder die Konzentration auf die wichtigsten fachlichen Features.

Was fällt noch unter die Selbstorganisation? Da fällt zum Beispiel auch die Art, wie gearbeitet wird drunter. Bei Softwareentwicklern sind das zum Beispiel Programmiervorgaben, welche Tools verwendet werden, Dokumentation im Code, welche Tests sind zu schreiben bzw. durchzuführen, welche weiteren Maßnahmen sind zur Erhöhung der Arbeitsqualität einzuhalten wie beispielsweise Pair Reviews oder Test Driven Development, Continous Integration oder die Wahl der Iterationslänge.

Was das Team möglicherweise auch selber regeln kann ist die Anwesenheit. Ja, es gibt Situationen und Umstände, in denen die unternehmens- oder bereichsweite Vorgabe von Kernarbeitszeiten Sinn macht. Und in vielen Fällen sind diese Vorgaben leider nur einer formalistischen Denkweise geschuldet. Wenn ein Team in einer bestimmten Phase keine Schnittstellen zu anderen Mitspielern hat oder diese nicht zeitnah benötigt werden, was spricht dann dagegen, dass das Team nachts arbeitet wenn dieses dem Team entgegen käme. Oder die Teammitglieder zeitversetzt arbeiten, solange diese ihre Arbeit untereinander ohne Verlust von Qualität und Zeit koordiniert bekommen? Wenn die Verantwortlichen dem Team unterstellen, dass es im Sinne des Unternehmens denkt, dann können sie dem Team die Entscheidung über die Arbeitszeiten ruhig selber überlassen. Und das schließt auch die Entscheidungen darüber ein, wer wann in Urlaub gehen kann.

Als letztes wollen wir noch die Selbstorganisation der Kommunikation im Team betrachten. Ein selbstorganisierendes Team bestimmt selber darüber, wie es innerhalb des Teams kommuniziert. Damit ist zum Beispiel gemeint, dass das Team festlegt ob es Teammeetings braucht und falls ja wie oft und lang diese sein müssen. Oder wie mit Problemen im Team umgegangen wird, seien es technische oder zwischenmenschliche. Hat ein Teammitglied beispielsweise ein technisches oder fachliches Problem, dann kann es eine Teamvereinbarung sein, dass er formlos eine Quick Design Session einberufen kann Auf der könnte er die anderen Teammitglieder zum Rat oder ihre Meinung bitten. Und es gehört auch zur Teamvereinbarung, ob die Teilnahme an solchen Quick Design Sessions Pflicht ist oder eben nicht.

Wir haben jetzt eine ganze Reihe von möglichen Aspekten der Selbstorganisation eines Teams gesehen. Und allen gemeinsam ist, dass mit Ihnen nicht nur die Freiheit der Entscheidung einhergeht sondern auch die Übernahme von Verantwortung. Befragt man die Entscheider in Unternehmen, ob sie selbstorganisierende Teams einführen möchten, so bekommt man oft zögerliche oder sogar direkt ablehnende Antworten. Der zumeist unausgesprochene Grund dafür ist meist die Annahme, dass die Teams die Freiheit der Entscheidung zum Nachteil des Unternehmens ausnutzen würden. Die Motivation oder Kompetenz zugetraut im Sinn des Unternehmens zu agieren wird oft erst den Team- oder Projektleitern zugetraut.

Die Einführung selbstorganisierender Teams bedingt also den Paradigmenwechsel, dass alle Mitarbeiter des Unternehmens motiviert und befähigt sind, eigenverantwortlich im Sinne des Unternehmens zu agieren. Und dazu gehört auch, dass das Team selber die Verantwortung für die erfolgreiche Bewältigung der Aufgaben übernimmt. Und hier ist mit Team nicht irgendein abstraktes Gebilde gemeint, sondern jedes einzelne Teammitglied muss sich diese Verantwortung zu Eigen machen. Das kann bei Teams, in denen die einzelnen Mitglieder unterschiedliche Ansichten bezüglich der Übernahme von Verantwortung und damit dann auch dem Einsatz zum Erreichen der gemeinsamen Ziele haben, schnell zu interessanten Spannungen führen. Hier setzt ein gruppendynamischer Effekt ein, in dem sich rasch herauskristallisiert, wer „mitzieht“ und wer nicht. In den meisten Fällen wird das Team das intern regeln können und sollte dazu auch die Chance bekommen. „Regeln“ bedeutet dabei oft, dass sich in den gruppeninternen Diskussionen klärt, warum der eine oder andere nicht motiviert genug ist, den notwendigen Einsatz zu zeigen. Und es zeigt sich, ob durch Anpassung der internen Organisation nicht doch alle zufrieden gestellt werden können, oder eben auch nicht. Gruppenzwang ist dabei ein hässliches Wort und meistens auch ein bisschen überzogen. Aber manchmal wirkt er auch Wunder.

Und was mache ich, wenn ich doch einen unverbesserlichen Querschläger im Team habe, der durch seine Verweigerung den Erfolg des Teams und die Gemeinschaft an sich gefährdet? Was machen Sie denn in einem traditionellen Team mit so jemand? Wenn Sie ausreichend taff sind, dann entfernen Sie ihn aus dem Team, in den meisten Fällen wird er jedoch einfach als Ballast geduldet und mitgeschleppt. Ist das wirtschaftlich und hilft es dem Unternehmen? Steigert es die Motivation und Zufriedenheit der restlichen Mitarbeiter? Nein, definitiv nicht! In einem selbstorganisierenden Team wird es aufgrund der verstärkten Gruppeneffekte schwierig, so jemand zu dulden. Bleibt also nur, das Problem endgültig zu lösen. Klingt hart? Ist es auch, jedoch nur für den Verweigerer. Der Rest profitiert.
Nur damit wir uns richtig verstehen, dass ist nicht der Aufruf zu „wer nicht richtig funktioniert, der fliegt“. Die Selbstorganisation in Teams räumt allen Beteiligten wesentlich mehr Möglichkeiten ein, genau die Form des Einsatzes zu zeigen, die ihm jeweils am besten liegt. Und führt damit fast automatisch zu einer wesentlich höheren Motivation. Und auch individuelle Defizite wie fehlende Skills oder das jemanden bestimmte Tätigkeiten „einfach nicht richtig liegen“ können in einem solchen Team wesentlich besser aufgefangen werden. Das Team als Gemeinschaft findet selber raus, wie die individuellen Fähigkeiten jedes Einzelnen am besten genutzt werden können und wie das Team davon am besten profitiert. Und auch wie jeder sich im Team konstant verbessern und damit auch seinen eigenen Marktwert steigern kann. Und das sollte doch Anreiz genug sein. Noch sozialer geht es wohl kaum.

So, nachdem wir jetzt gesehen haben, welche Rechte zur Selbstbestimmung ein selbstorganisierendes Team haben sollte, welche Ansprüche darf umgekehrt der Projektleiter, Teamleiter, Produktmanager, Abteilungsleiter, etc. an das Team haben?
Nun als erstes Transparenz. Wir haben gerade noch davon gesprochen, dass für selbstorganisierende Teams Vertrauen durch die Verantwortlichen ins Team bzw. die Teammitglieder notwendig ist. Dieses Vertrauen ist wesentlich leichter aufzubringen und aufrechtzuerhalten, wenn für die Außenstehenden die Prozesse im Team und die Regeln, nach denen das Team agiert nachvollziehbar sind. Wenn ich als Vorgesetzter wissen möchte, wie das Team intern die Arbeit verteilt, dann ist die Antwort „Machen Sie sich keine Sorgen, wir regeln das schon irgendwie“ nicht besonders vertrauenerweckend. Am besten veröffentlicht das Team seine Regeln pro aktiv, z.B. in einem firmeninternen Wiki. Spätestens aber auf Anfrage sollten die aktuellen Regeln verständlich und vollständig kommuniziert werden.

Ein weiterer Punkt ist, wer die Aufgaben des Teams festlegt. Teams, und auch selbstorganisierende Teams, sind kein Selbstzweck, sondern haben ihre Daseinsberechtigung immer in den Aufgaben, die sie erfüllen sollen. Und die Aufgabe wird dort festgelegt, wo das Geld herkommt. In Köln sagen wir dazu: „Wer die Musik bestellt, der bestimmt auch was sie spielt“. Wenn sich die Aufgaben für das Team ändern oder weitere Aufgaben hinzukommen und das Team das Gefühl hat, für diese neuen Aufgaben eigentlich nicht richtig zu sein, dann kann es natürlich die Verantwortlichen darauf hinweisen. Ein grundsätzliches Verweigerungsrecht besteht aber zumindest in meinem Modell von Welt nicht. Das ist nicht anders, als bei traditioneller Teamorganisation.
Das wird besonders deutlich bei Projektteams, die während der Projektphasen laufend mit neuen Anforderungen konfrontiert werden. Die Auswahl, welche Anforderungen umzusetzen sind und in welcher Priorität, bestimmt der verantwortliche Projektleiter oder Produktverantwortliche. Das Team bestimmt dann darüber, wie die Umsetzung geschieht und wie lange es dauern wird.

Da wo es Sinn macht, gelten natürlich auch unternehmensweite Vorgaben bzgl. der Systemlandschaft, der Architektur, der zu verwendenden Tools und Dokumentations- und Qualitätsvorschriften. Die Betonung liegt jedoch tatsächlich auf „da wo es Sinn macht“. Prüfen Sie in Ihrem Unternehmen mal kritisch, welche der bestehenden Vorschriften tatsächlich unternehmensweit Sinn machen. Die zu verwendenden Tools aus Lizenzgründen einzuschränken kann Sinn machen. Auch die Systemlandschaft zentral reguliert übersichtlich zu halten macht Sinn. Einheitliche Qualitätsstandards finde ich sogar besonders gut. Wobei allerdings hier schnell die Frage aufkommen kann, wie sich dieses Qualitätsstandards einheitlich für ein größeres Unternehmen definieren lassen. Und zwar so, dass wirklich Qualität erzeugt wird und nicht nur unnötige Arbeit in den Teams. Und bei einheitlichen Dokumentationsrichtlinien fangen die meisten Unternehmen schon an mit Kanonen auf Spatzen zu schießen (meist durch wichtige Unternehmensberater dazu aufgestachelt). Und unternehmensweite Programmierrichtlinien sind fast immer mehr schädlich als nützlich. Ich verstehe die gute Absicht hinter all diesen Vorgaben. Aber das Gegenteil von Gut ist oft nicht Böse sondern gutgemeint.

Kommen wir mal zu einer anderen interessanten Frage: Braucht ein selbstorganisierendes Team eigentlich noch einen Teamleiter? Teamintern hat er ja eigentlich keine Aufgaben mehr: Er verteilt nicht die Arbeit, er muss den Urlaub nicht regeln, keine Zeitpläne oder Arbeitsergebnisse kontrollieren. Also unnötig, oder? Nun, nicht so ganz. Der Großteil der Unternehmen ist immer noch streng hierarchisch und meist recht unflexibel organisiert. Und in diesem Umfeld müssen sich dann auch die selbstorganisierenden Teams bewegen. Das bedeutet, dass sie klar definierte Ansprechpartner für die Welt außerhalb des Teams haben müssen. Der Teamleiter ist also kein Vorgesetzter mit Weisungsbefugnis mehr sondern eher ein Dienstleister, der als Schnittstelle und Koordinator für das Team fungiert.

Und wie verhält sich das mit der disziplinarischen Führung bei selbstorganisierenden Teams? Die disziplinarischen Führung beinhaltet in Unternehmen in der Regel die Entscheidungen darüber, wer in eine Organisationseinheit (z.B. das Team) kommt und wer nicht, bzw. diese Einheit verlassen muss, die Beurteilung von Mitarbeitern und das Gehalt derselben.
Bezüglich der Zusammensetzung des Teams, also Einstellung und Entlassung von Teammitgliedern, hatten wir schon gesehen, dass das Team hier ein Mitspracherecht haben sollte. Beim Gehalt gelten die gleichen Regeln wie sonst auch mit einer Ausnahme: Bei variablen Gehaltsanteilen die mit der Erreichung von individuellen Zielen gekoppelt sind, ist darauf zu achten, dass diese individuellen Ziele nicht im Widerspruch zu den aktuellen Teamregeln stehen oder die schon besprochenen Möglichkeiten des Teams zur Selbstorganisation einschränken. Wenn ein Teammitglied als individuelle Vorgabe die Spezialisierung auf ein bestimmtes Thema bekommen hat, das Team aber bei der Wissensverteilung auf Generalisten setzt, dann besteht hier ein Widerspruch der entweder die Teamvereinbarung gefährdet oder aber den variablen Gehaltsanteil des Mitarbeiters. Besser ist es die variablen Gehaltsanteile an Teamziele zu koppeln, Ziele die das Team als ganzen erreichen kann und deren Erreichen damit auch positive Effekte für alle Teammitglieder haben.

Zum Schluss die Königsfrage: Warum sollten Teams selbstorganisierend sein und macht das wirklich bei allen Teams Sinn?
Einen Teil der Vorteile von selbstorganisierenden Teams können wir schon den Argumentationen weiter oben entnehmen. Die stärkere Übernahme von Verantwortung durch das Team selber und die einzelnen Teammitglieder. Die damit verbundene bessere Motivation und die gruppendynamischen Effekte, die in der Regel zu höherer Effektivität führen. Die Selbstregulierungskräfte eines solchen Teams, das fast automatisch die Fähigkeiten der einzelnen Mitglieder optimal einsetzen und die Defizite ausgleichen wird.

In klassischen Teams mit zentraler Führung ist der Teamleiter schnell ein Flaschenhals, wenn es an ihm liegt die Arbeit im Team zu verteilen und zu kontrollieren. Selbstorganisierende Teams neigen dazu, auftretende Flaschenhälse schnell zu identifizieren und zu beseitigen. Dazu ist es übrigens von Vorteil in selbstorganisierenden Teams die agile Denkweise des „inspect and adapt“ zu verankern. In der klassischen Organisationslehre neigen wir dazu Regeln immer als für die Ewigkeit zu betrachten und den Umstand, dass Regeln geändert werden müssen als Versagen anzusehen. Deshalb ist das Erstellen von Regeln oft so komplizierter Akt, weil ja nicht falsch gemacht werden darf und führt so oft zu umfangreichen komplexen Regelwerken, die möglichst jede Eventualität berücksichtigen sollen. Nicht so in der agilen Denkweise. Einfache Regeln erstellen, die Regeln anwenden, beurteilen ob die Regeln zu den gewünschten Ergebnissen führen, wenn notwendig die Regeln anpassen, usw.
Durch dieses Vorgehen entsteht im Team automatisch ein kontinuierlicher Verbesserungsprozess, durch den das Team auch bei sich ändernden Rahmenbedingungen die maximale Leistungsfähigkeit behält.

Ein kleiner Nachteil der selbstorganisierenden Teams ist, dass sie in der Anlaufphase etwas langsamer sind. Wird so ein Team neu aufgebaut, dann muss die Gruppe erst mal anfangen einen ersten Wurf von Regeln zu definieren und auszutesten, welche Regeln die besten Ergebnisse erzielen. Und dass wird anfangs von vielen ausufernden Diskussionen im Team begleitet sein. Vor allem wenn sich die Teammitglieder vorher noch nicht kannten wird das einen recht intensiven Prozess des sich gegenseitig kennenlernen beinhalten. Und dann wird das Team nach und nach Fahrt aufnehmen. Das bedeutet aber im Gegenzug, dass die Selbstorganisation eher ungünstig für Teams mit hoher personeller Fluktuation ist oder zeitlich nur stark begrenzter Lebensdauer.

Um abschließend auf die erste Formulierung zurückzukommen: Ja, selbstorganisierende Teams sind Teams, die ihre Arbeit selber organisieren. Und eben auch noch mehr!

Vortrag ‚Practical Scrum‘ in Venlo

Am 2. Juni 2010 wird Carsten Czeczine vor den Studenten der Fontys University of Applied Sciences in Venlo den Vortrag ‚Practical Scrum‘ halten. Das ist ein Grundlagenvortrag über Scrum für das Frühjahrssemester. Weitere Informationen gibt es hier.

Nächste Seite »