Schlagwort-Archive: Scrum

Scrum ist eine agile Projekt-Methode. Durch die Definition bestimmter Rollen (u.a. Scrum Master, Product Owner, Entwicklungsteam) und Meetings (u.a. Sprint Planning Meeting, Daily Scrum, Retrospektive) wird ein iterativer Prozess installiert, der die Arbeit des Projekt bzw. Scrum Teams an dem direkten Feedback des Kunden ausrichtet. Die Methode wird zunehmend auch außerhalb der Software-Entwicklung eingesetzt.

Agile Coach und Festanstellung

Die agile Industrie hat den Beruf des „Agile Coach“ hervorgebracht. Dieser ist normalerweise für ein bis wenige Teams zuständig. Ich selber habe auch mal kurz als Agile Coach für zwei Teams gearbeitet und mir dabei recht schnell die Frage gestellt, ob diese Rolle sinnvoll ist.Coach

Interpretiert man den Agile Coach aus der Scrum Perspektive, d.h. als Scrum Master, dann macht die Rolle als Job-Beschreibung nur bedingt Sinn. Der Scrum Master ist eine Vollzeitbeschäftigung nur während der Setup Phase, danach soll die Rolle bzw. Aufgabe aber aus dem (Entwickler-)Team übernommen werden kann. (Hier zeigt sich deutlich, wie durchdacht Scrum als Geschäftsmodell ist, denn die Scrum Rollen bringen direkt den Bedarf nach Zertifikaten und Beratern mit sich.) Scrum Master in Festanstellung passen also eigentlich nicht ins Konzept.

Aber wir reden ja nicht vom Scrum Master sondern vom Agile Coach. Und der kann nicht nur Scrum, sondern mindestens auch noch KANBAN. Ändert das den Sachverhalt? Nein.

Der Hauptgrund gegen Agile Coaches in Festanstellung, die nur für wenige Teams zuständig sind, ist die Selbstorganisation, die sie fördern sollen. Denn Selbstorganisation erfordert Freiraum. Bei aller guter Absicht, wird dieser Freiraum aber nicht dadurch gefördert, dass ein Agile Coach einen breiten Methodenkoffer auspackt und das Team in seinen eigenen Prozessen damit indirekt lenkt. Wenn ein Agile Coach in Festanstellung sagen wir für drei Teams verantwortlich ist, wird er darauf achten, 1/3 seiner Zeit für jedes Team einzusetzen. Der Coach versteht sich als Teil des Teams und will dieses aktiv entwickeln. Wie soll das Team da lernen selbstorganisiert zu arbeiten?

Bedeutet dies also, dass Agile Coaches an sich keine sinnvolle Rolle sind? Nein. Natürlich ist es sinnvoll auf Erfahrungen zurückgreifen zu können und nicht alle Fehler immer selber machen zu müssen. Es geht aber um die Aktivität bzw. Passivität der Rolle. Ein Agile Coach sollte dann aktiv werden, wenn das Team es anfragt. Die Grundeinstellung ist also passiv.

Buurtzorg als ein Paradebeispiel für ein Unternehmen, das auf Selbstorganisation aufbaut, hat für seine selbstorganisierten Teams „Regional Coaches“ installiert. Ein Coach betreut hier 40-50 Teams. Diese sind somit nie direkt Teil des Teams, sondern treten eher als externe Berater auf. Sie haben keine Weisungsbefugnis, sind nicht an die Performance der Teams gekoppelt. Dies zwingt die Teams zur Selbstorganisation, lässt sie gleichzeitig aber nicht alleine. Unterstützend gibt es ein sehr aktiv genutztes Intranet, über das sich Mitarbeiter schnell und direkt über aufkommende Fragen, Best Practices etc. austauschen können. Dies unterstützt Selbstorganisation im Tagesgeschäft, gänzlich ohne Coaches.

Ein Agile Coach ist dann sinnvoll, wenn er es Teams ermöglicht selbstorganisiert zu arbeiten. Dafür brauchen Teams vor allem Freiraum und nicht 24-7 Unterstützung und Beobachtung.

Bild: Coach Don Lear von Ed Uthman auf flickr, Verwendung unter cc Lizenz

Von der Timebox zur Valuebox

TimeboxEine der Kernideen von Scrum ist das Arbeiten in Timeboxes. In einer Timebox gibt es einen klar definierten Start- und Endzeitpunkt. Es geht also um Arbeiten nach der Stoppuhr? Das Bild der Stopp- oder Sanduhr trifft nicht wirklich den Kern von Timeboxing im agilen Kontext. Denn über der Timebox steht nach wie vor der Hauptauftrag der Werterzeugung. Eigentlich sollte man die Timebox also besser als Valuebox bezeichnen.

Das Verständnis der Timebox als Valuebox rückt das eigentliche Ziel in den Vordergrund und stellt auch klar, wieviel Organisation in agilen Methoden notwendig ist. Seine Zeit so zu planen, dass am Ende ein vorzeigbares Ergebnis entsteht, ist nicht einfach. Dabei hilft das hohe Engagement und das Commitment des Einzelnen. Wer will schon am Ende eines Sprints nichts zu präsentieren haben! Agile Arbeiter wollen wollen etwas bewegen, sie wollen Wert erzeugen und zwar in sinnvollen Zeiteinheiten.

Wenn die Zeit, die zur Verfügung steht, durch eine Timebox ein klar definiertes Ende hat und am Ende gleichzeitig einen sinnvollen Wert vorzeigbar sein soll, dann muss innerhalb der Timebox ggf. der Wert selber angepasst werden. Aus dem Projektmanagement kennen wir das Dreieck aus Time, Budget und Scope:

  • Die Dimension Zeit ist beim Timeboxing wie schon beschrieben fest. Der einzelne Sprint hat eine klar definierte Länge. Zeit wird damit nur verhandelbar, wenn zusätzliche Sprints geplant werden.
  • Das Budget ist normaler Weise auch klar begrenzt, wenn unter Budget vor allem Manpower gemeint ist. Natürlich kann man das Team kurzfristig erweitern, häufig jedoch ist dies aufgrund der hohen Initialkosten im Sinne der Anlernphase nicht sinnvoll.
  • Damit bleibt nur der Scope, also der geplante Umfang bzw. der abzuliefernde Wert, der innerhalb der Timebox angepasst werden kann. Wenn Komplikationen oder Aufwände sichtbar werden, die in der ersten Schätzung nicht erkennbar waren, dann muss darauf mit Anpassung des Scopes reagiert werden.

Product Owner und Stakeholder müssen dies akzeptieren bzw. fördern. Am Ende ist es für das Produkt und das Unternehmen wichtig, dass möglichst früh ein nutzbarer Wert entsteht, auch wenn dieser zunächst unter den ersten Erwartungen bleibt. Durch agile Methoden wollen wir verhindern, dass einzelne Arbeitspakete über Monate verzögert werden und somit auch über Monate kein Wert am Markt geschaffen wird. Wer schnell Wert produzieren will, der muss akzeptieren, dass dieser Wert in kleinen Einheiten erbracht wird. Ohne dieses Verständnis bleibt die Timebox als leere Methodik zurück. Erst durch das Verständnis der Timebox als Valuebox lassen sich agile Methoden mit Mehrwert praktizieren.

Bild: In Search Of Lost Time von Alexander Boden auf flickr, Verwendung unter cc Lizenz

Sprints sind keine Schleifen sondern eine Kette

Bei den Vorbereitungen zu einigen Seminaren bin ich mal wieder über eine der bildhaften Darstellungen von Scrum gestolpert. Je nach Umfang zeigen diese Bilder alle Aktivitäten, Artefakte, Rollen oder auch alles zusammen. Dabei wird der Sprint eigentlich immer als eine Schleife bzw. geschlossener Kreislauf dargestellt. Nach dem Sprint ist also vor dem Sprint!?

Nein, eben nicht! Denn nach dem Sprint hat sich unser Produkt verändert. Die Welt ist nicht mehr die gleiche wie noch vor 2-4 Wochen. Das ist so ähnlich wie mit der Jahresuhr, die wir schon im Kindergarten erklärt bekommen. Wenn der Winter vorbei ist, dann geht es mit dem Frühling wieder von vorne los. Nur, dass der nächste Frühling eben nicht der gleiche ist wie letztes Jahr. Die Jahresuhr suggeriert, dass sich alles immer wiederholt. Aber das stimmt nicht. Alles verändert sich ständig.

Und so ist es auch mit bzw. durch Scrum. Der Prozessrahmen mag der gleiche bleiben, aber das Team und vor allem das Produkt verändern sich. Scrum ist also nicht die eine Schleife, die immer wieder durchlaufen wird, Scrum ist eine Aneinanderreihung von Schleifen. Und das ist ein erheblicher Unterschied. Denn dies bedeutet, dass es nicht darum geht den Prozess zu wiederholen, sondern das Produkt basierend auf neuen Erkenntnissen zu entwickeln. Ein Backlog kann eigentlich einen Sprint nicht unbeschadet überleben. Wenn die Ergebnisse des letzten Sprints die Planung des nächsten nicht verändern, dann ist arbeiten in Iterationen sinnlos. Scrum soll nicht primär einen Prozess etablieren, Scrum soll Produktentwicklung unterstützen.

Lean Startup ist ein sehr gutes Beispiel für diesen zentralen Sinn von agilem ArbKettengliedereiten. Die Anwendung agiler Methoden wird hier vorausgesetzt. Lean Startup richtet den Fokus auf das Ergebnis und die Anpassbarkeit durch agiles Arbeiten. Und nach dem MVP ist definitiv nicht vor dem MVP. Das eine hat ohne das andere überhaupt keine Bedeutung. Erst die Verkettung von MVPs stellt eine sinnvolle Anwendung der agilen Ideen dar, um so im Sinne von Lean startup am Ende der Kette das für das Marktsegmente passende Produkt gefunden zu haben.

Deshalb ist es so wichtig den vermeintlichen Widerspruch zwischen dem agilen Manifest (Individuen und Interaktion sind wichtiger als Werkzeuge und Prozesse) und einem Framework wie Scrum (Prozess) klar aufzuzeigen. Bleibt man bei der Einführung agiler Prozesse stehen, hat dies absolut nichts mit Agilität zu tun. Erst wenn die Prozesse zur agilen Entwicklung des Produktes genutzt werden, kann man anfangen von agilem Management zu sprechen. Denn agiles Management darf nicht als Methode auf der operativen Ebene verstanden werden, agiles Management betrifft das gesamte Unternehmen, um so die Erkenntnisse und schnellen Ergebnisse auf operativer Ebene für die taktische und strategische Ausrichtung des Unternehmens nutzen zu können.

Bild: Chain Linkage von Max Klingensmith auf flickr, Verwendung unter cc Lizenz

Scrum ist auch nur ein Produkt

Scrum hat als leichtgewichtiges Framework für IT-Projekte eine Erfolgsgeschichte geschrieben, die mittlerweile deutlich über die Software-Branche hinaus geht. Dabei basiert der Ansatz im wesentlichen auf den Prinzipien des agilen Manifest. Dessen erster Leitsatz ist für mich dabei der zentralste:

  • Wir schätzen und Individuen und Interaktionen mehr als Prozesse und Werkzeuge.

Wenn man diesen Leitsatz ernst nimmt, dann schließt dies einen fest vorgegebenen prozessualen Rahmen für agiles Arbeiten aus. Statt sich auf Prozesse und Werkzeuge zu konzentrieren, sollte man auf die Individuen eingehen, die als Team zusammenarbeiten. Besucht man Konferenzen oder Workshops, stellt man aber schnell fest, wie sehr sich die agile Community über Tools und Prozesse unterhält. Es wird über Rollen diskutiert, es wird nach den Top 10 Ratschlägen für einzelne Artefakte und Routinen gesucht, aufgrund der Größe kaum noch druckbare Modelle sollen zeigen, wie man agil skalieren kann. Nur irgendwie fragt niemand nach den Menschen, um die es ja eigentlich gehen soll…

Das Aufwändige an der agilen Idee ist, dass sie zum selbständigen Denken und Handeln zwingt.

  • Das perfekte Board, das jeden Fluss und alle Probleme visualisiert
  • das eine Schema für die Retro, das in jeder Situation funktioniert
  • die 10 Grundregeln für Führung im agilen Kontext

Alles das gibt es nicht! Und deshalb ist es gefährlich Produkte wie Scrum mit Agilität zu verweKaufmannsladenchseln. Ja, Scrum ist ein Produkt! Scrum verkauft Zertifikate. Scrum will über Prozesse sprechen und Tools vermitteln, um Bücher und Beraterstunden an dem Mann zu bringen.

Bitte nicht falsch verstehen, ich halte Scrum für einen guten Ansatz. Aber wir dürfen nicht den Fehler machen, aus einem Produkt eine Art Religion zu machen. Seminare, Zertifikate und Weiterbildungsangebote sind sinnvoll, solange es um Hilfe zur Selbsthilfe geht. Zu schnell tappen wir aber in die Falle, uns an vorgegebene Fahrpläne zur agilen Transformation, an Prozess-Charts und Best Practices zu klammern. Dies ist natürlich auch entsprechend einfacher und verlockend. Aber solange gilt „Individuen und Interaktionen über Prozesse und Tools“, solange müssen wir uns mehr um die Menschen und die Zusammenarbeit in unserem Unternehmen kümmern, als um vorgegebene Prozesse und Tools.

Man baut agile Organisationen auf, um mit Hilfe von Selbstorganisation die wachsende Komplexität in den Griff zu bekommen. Wer sich selbst organisieren soll, der braucht dafür aber Freiheitsgrade und keine vorgefertigten Produkte. Bis zu einem gewissen Grad ist dieser Freiheitsgrad sogar in das Produkt Scrum selbst eingebaut. So soll sich z.B. der Scrum Master im Laufe der Zeit überflüssig machen. Dort, wo für jedes Team „Agile Coaches“ in Festanstellung gesucht werden, liegt somit der Verdacht nahe, dass die agile Idee nicht wirklich ernst genommen oder verstanden wird. Selbstverständlich ist es sinnvoll, erfahrene Scrum Master o.ä. im Unternehmen zu haben, wenn man eine agile Organisation aufbauen oder werden will. Aber weder ist es sinnvoll einfach alle alten Projektmanagement-Planstellen in agile umzuwandeln, noch ist es sinnvoll, Scrum oder andere Methoden / Produkte aus Prinzip einzufordern. Vielmehr muss es darum gehen, die individuellen Bedarfe der eigenen Organisation zu erkennen und zu bedienen.

Scrum ist nicht nur ein tolles Framework, es ist auch ein sehr erfolgreiches und durchdachtes Produkt. Bitte verwechselt es nicht mit Agilität. Um es mit den Worten von Dave Thomas zu sagen: Agile Is Dead (Long Live Agility)!.

Bild: Kaufmannsladen von Anja Leidel auf flickr, Verwendung unter cc Lizenz

Simply the Best? Agiles Management und Personalauswahl

„If you can only have 10 on the team, they’d better be the very best that you can find.“ Dies ist eine von 14 zenralen Aspekte für agiles Arbeiten, die Bob Warfield in seinem SmoothSpan Blog aufführt. Als ich mein erstes agiles Projekt erfolgreiche beendete, fragten mich viele Kollegen nach dem Erfolgsrezept bzw. den Erfolgskriterien, denn es war auch das erste agile Projekt für unseren Bereich. Scrum, damals die Basis für unser Projektvorgehen, war recht leicht zu erklären. Aber was braucht es, um dieses Vorgehen auch zum Erfolg werden zu lassen? Ich fragte mich das natürlich auch, denn es sollte nicht nur bei einem erfolgreichen agilen Projekt bleiben. Als das wesentlichste Erfolgskriterium kristallisierte sich für mich folgendes heraus: Arbeite mit Profis zusammen! Dies ist eine vielleicht abgeschwächte Form des oben genannten Zitats, meint im Kern aber etwas ähnliches.

Nun könnte man sagen: tolle Erkenntnisse, dass man mit guten Leute gute Ergebnisse erzielen kann! Aber so einfach ist das nicht. Agile Methoden bilden einen Rahmen, in dem Arbeit selbstorganisiert ablaufen soll. Das agile Manifest sagt, dass die Konzentration auf Individuen und Interaktion wichtiger sind als Werkzeuge und Methoden. Dies unterstreicht die Bedeutung der zusammenarbeitenden Menschen. Sich selbst organisieren zu können heißt aber auch, dass man sein Handwerk schon verstehen muss. Zudem arbeiten agile Teams in kleinen Gruppen, so dass kein Raum zum verstecken bleibt. All dies passt also zu der Bedeutung der Qualität agiler Arbeiter und zeigt, warum diese Qualität im agilen Kontext besonders wichtig ist.

Trotzdem würde ich heute das Erfolgskriterium anders formulieren: Bring den best möglichen Mix aus Menschen als ein Team zusammen. Ich will damit verdeutlichen, dass es nicht reicht, die zehn besten Individuen auszuwählen, für die dann, wie Bob Warfield schreibt, „pay what it takes“ gilt. Keine Frage, Qualität hat ihren Preis. Entscheidend ist aber das entstehende Team, das Gesamtgefüge. Neben der beruflichen Qualifikation muss dabei auch die Persönlichkeit betrachtet werden. Ein Team funktioniert dann, wenn sich sowohl die fachlichen als auch die persönlichen Merkmale der Teilnehmer gegenseitig so unterstützen, dass das Team mehr wird als die Summe seiner Einzelteile.

Bob Garfield gibt zusätzlich noch folgende Tipps, um das Team best möglich zu unterstützen, bzw. die besten Leute optimal ans Teams / Unternehmen zu binden:

  • Make engineering a first class part of the company.
  • Give them a high performance environment to work in.
  • Parallel Career Tracks for Pure Techies and Management.

All dies kann ich unterschreiben, wobei man den ersten und dritten Punkt verallgemeinern muss, denn man kann und sollte auch außerhalb des IT-Bereichs agil arbeiten. Eine der wichtigsten Aufgaben für agiles Management im Bereich Personalauswahl ist aus meiner Sicht aber die Zusammensetzung des Teams optimal zu unterstützen. Die Personalauswahl muss auf das entstehende Team abgestimmt werden und darf nicht nur isoliert betrachtete Superstars auswählen. Hilfreich ist es z.B. potenzielle Kandidaten auch mit dem Team reden zu lassen. Ich verlasse dafür mit dem HR-Manager den Raum und lasse den potenziellen Kollegen und Teile des Teams sich einfach mal beschnuppern. Dabei soll kein Team entstehen, wo sich alle auf anhieb perfekt verstehen. Ein gutes Team braucht auch Spannungspunkte. Diese zu erahnen ist Aufgabe von HR und Manager. Aber ein unverfängliches Kennenlernen gibt beiden Seite eine gute Chance, in die neue neue Konstellation hineinzufühlen.

Die zweite zentrale Aufgabe für agiles Management ist es dann, für dieses Team passende und gleichzeitig den Wert des Unternehmens steigernde Aufgaben auszuwählen. Das Team so gut verstehen lernen, dass man zu der Teamkompetenz passende Aufgaben auswählen kann, ist dafür die Voraussetzung. Natürlich muss dabei immer auch der Mehrwert für das Unternehmen betrachtet werden. Im Zweifel würde ich aber eine bestimmte Aufgabe runter priorisieren, wenn ich dadurch den Output des jeweils aktiven Teams optimieren kann. Dann können auch Personalwechsel nicht mehr nur als Gefahr gesehen werden, sondern auch als Chance mit einer neuen Teamkonstellation ganz neue Teamkompetenzen zu erreichen und andere Themenschwerpunkte setzen zu können, ohne dabei an Fahrt zu verlieren. Hat man mehrere Teams zur Verfügung, lohnt sich je nach aktuellen Themen also auch die Frage, ob die bestehenden Teams verändert bzw. durchmischt werden sollten. Starre Abteilungsgrenzen sind dabei wenig hilfreich. Agilität muss somit auch in der Organisation der Organisation ankommen.

Der Product Owner als Prediger

Manchmal gibt es diese Momente, in denen man die Welt nicht mehr versteht. Die Fakten liegen auf dem Tisch, die Vor- und Nachteile auf der Hand und trotzdem wird eine Entscheidung getroffen, die all dies scheinbar unberücksichtigt lässt. Gerade für agile Teams, die ein hohes Maß an Gestaltungswillen und Eigeninitiative aufweisen sollten, sind solche Momente kritisch. All zu schnell kann hier eine Situation entstehen, bei der sich das Team vom Unternehmen bzw. den Entscheidungsträgern entfernt. Die eigentliche Kraft des Teams geht verloren. Was können wir dagegen tun? Meine These dazu: Das P in PO steht für Prediger.

Ein mögliche Erklärung für scheinbar nicht nachvollziehbare Entscheidungen gegen alle Fakten liefert die klassische Analyse des Wissens. Sie besagt, dass drei Bedingungen erfüllt sein müssen, damit ein Individuum (I) Wissen über P erlangen kann:

  1. P muss wahr sein
  2. I muss an P glauben
  3. I muss Gründe haben an P zu glauben

Stellen wir uns vor, wir sitzen bei „Wer wird Millionär“ und haben es mit der 500.000-€-Frage zu tun. Wenn wir die Antwort wissen, dann können wir sie beruhigt einchecken lassen. Aber wann können wir sicher sein, die Antwort zu wissen? Gemäß der oben aufgeführten Bedingungen, sollten wir an unsere Antwort glauben (2). Wir müssen also von unserer Antwort überzeugt sein, plattes raten wäre dafür also keine Option. Zusätzlich sollten wir noch unterstützende Gründe (3) haben, an unsere Antwort zu glauben. Gründe, die wir nach außen erklären können, z.B. also, dass wir etwas über das abgefragte Thema gelesen haben. Damit hätten wir die Bedingungen (2)+(3) erfüllt, fehlt also nur noch die erste Bedingung (1). Und diese zeigt an dem Beispiel auch gleich das ganze Dilemma vor dem wir stehen. Denn ob unsere Antwort wirklich stimmt bzw. wahr ist, dass weiß am Ende nur Günther Jauch. Vielleicht haben wir ja leider den Artikel, den wir gelesen haben, falsch verstanden. Wir glauben dann an unsere Antwort, haben auch Gründe daran zu glauben, nur bleibt unsere Antwort dabei leider falsch.

In der Realität sind wir ständig mit tlw. sehr komplexen Fragen konfrontiert. Leider gibt es dabei keinen Günther Jauch, der die richtigen Antworten kennt. Es gibt keinen Spielführer, der uns heimlich Tipps gibt, und keine eindeutige Definition für die richtige Antwort. Deshalb versuchen wir Data Driven zu arbeiten, um die Wahrheit quasi zu messen. Aber ab einem bestimmten Grad an Komplexität helfen uns allein Daten nicht weiter. Wir müssen diese analysieren und Ableitungen treffen und haben auch dann keine Gewissheit über die Richtigkeit der gewonnenen Erkenntnisse. Und dann kommt der Glauben (2) ins Spiel, weil er die Bedingung ist, die wohl fast immer erfüllt werden kann. Die Gründe für den eigenen Glauben (3) sind schnell gefunden, im Zweifel im reichen Erfahrungsschatz, den jeder mit sich rum schleppt. Und wenn hart gemessene Daten, z.B. die Ergebnisse eines A/B-Tests, mal nicht so recht zum eigenen Glauben passen, dann sind diese eben falsch. Wer kann schon garantieren, dass es keinen Fehler in der Testanlage gab? Deshalb gewinnen in der Realität häufig die persönlichen „Glaubenssätze“ über die vermeintlich objektiven Daten.

Dieser Blick auf Wissen und damit auch auf die persönliche Wahrheit und die Grundlage für Entscheidungen zeigt, wie subjektiv wir alle agieren (müssen). Die klassische Analyse des Wissens weckt Verständnis dafür, wie Entscheidungen zustande kommen. Vor allem auch deshalb, weil es hier nicht um ein isoliertes Problem von Entscheidungsträgern geht, sondern weil wir alle vor der gleichen Herausforderung stehen. Darüber hinaus bekommen wir mit der klassischen Analyse des Wissens aber auch ein Mittel an die Hand, Wahrheit und Entscheidungen im Unternehmen zu beeinflussen. Nicht die reine Weitergabe von Fakten und Daten sind relevant, sondern den Entscheidungsträger an etwas glauben zu lassen. Ein Product Owner hat somit auch die Rolle eines Predigers, wenn er das Team und Produkt gut im Unternehmen platzieren will.

Geht Selbstorganisation von selbst?

Die agile Idee basiert wesentlich auf der Idee der Selbstorganisation. Warum aber ist die Auseinandersetzung mit entsprechenden Methoden und Vorgehen überhaupt nötig, wenn sich die Organisation doch von selbst organisieren soll? In vielen Unternehmen und Institutionen wird so aktiv gegen Selbstorganisation organisiert, so dass wir sie als Prinzip erst wieder möglich machen müssen. Um sowohl dem Rätsel als auch der Lösung für Selbstorganisation auf die Spur zu kommen, sollten wir uns zunächst anschauen, was Selbstorganisation bzw. selbstorganisierte Systeme auszeichnet. Es gibt vier Bedingungen für Selbstorganisation: Komplexität, Selbstreferenz, Redundanz und Autonomie.

Komplexität kann über die Anzahl möglicher Zustände eines Systems beschrieben werden, wobei die Komplexität zunimmt, je mehr Zustände das System annehmen kann. Die praktische Übersetzung können interdisziplinäre Teams sein, die aufgrund der Mischung an Kompetenzen mehr Lösungsansätze erdenken können als monothematisch aufgestellte Teams.

Selbstreferenz ist nicht etwa ein Widerspruch zur Offenheit eines Systems, sondern vielmehr die Fähigkeit eines Systems innerhalb der eigenen Grenzen Reaktionen auszulösen. Retrospektiven als Teil der agilen Methodik sind ein gutes Beispiel für Selbstreferenz. Das Team diskutiert intern die eigenen Abläufe und Prozesse und beschließt dabei direkt auch das Vorgehen gegen ungewollte bzw. die Verstärkung gewollter Praktiken.

Redundanz bedeutet für ein selbstorganisiertes Team, dass es keine klare Gewaltenteilung wie z.B. in hierarchischen, industriellen Organisationen gibt, bei denen eindeutig zwischen Organisierenden und Ausführenden getrennt wird. In einem selbstorganisierten Team kann jeder verschiedene Funktionen einnehmen.

Autonomie ist die Fähigkeit eines Systems, seine internen Abläufe frei zu gestalten. Dies soll aber nicht heißen, dass es keinerlei Abhängigkeit bzw. Austausch mit der Außenwelt gibt. So erhalten die Entwickler in einem klassischen Scrum Team zwar von außen ein Ziel, wie dieses aber erreicht wird, kann das Entwickler-Team autonom entscheiden.

Insbesondere die Begriffe Redundanz und Autonomie zeigen recht deutlich, dass Selbstorganisation aktiv etabliert werden muss, da sie zum Teil im Widerspruch mit den klassischen Organisationslehren stehen. Wenn wir Selbstorganisation wollen, dann müssen wir zulassen bzw. ermöglichen, dass sich komplexe Teams mit hoher Autonomie zusammenfinden dürfen, deren Mitglieder in verschiedene Rollen schlüpfen können und die die Organisation aus eigener Kraft weiterentwickeln wollen. Welcher der Aspekte ist aus Eurer Erfahrung die größte Herausforderung?

Scrum ohne commitment? Ohne mich!

Bis 2011 war in dem Scrum Guide noch die Rede vom commit(ment) bzgl. der Sprint-Ziele, heute ist die Rede von forecast. Ist dies nur ein Austausch von Wörtern oder eine Änderung in der dahinter liegenden Philosophie? Um dieser Fragestellung auf den Grund zu gehen, wollen wir uns im zweiten Teil der Serie Sarte goes agile mit dem Begriff Verantwortung beschäftigen. Sartre schreibt zum Thema Verantwortung in ‚Der Existentialismus ist ein Humanismus‘:

Wenn jedoch die Existenz wirklich dem Wesen vorausgeht, ist der Mensch für das, was er ist, verantwortlich.“

Wenn es keinen vorgegebenen Rahmen für den Mensch gibt, sondern sich der Mensch allein durch seine Handlungen definiert, dann sind wir auch verantwortlich für das, was wir tun. Wir sind frei, weil wir uns für unser Handeln entscheiden, weil wir immer die Wahl haben. Damit tragen wir aber auch die volle Verantwortung. Diese Verantwortung haben wir laut Sartre aber nicht nur für uns selbst:

So bin ich für mich selbst und für alle verantwortlich, und ich schaffe ein bestimmtes Bild vom Menschen, den ich wähle; mich wählend wähle ich den Menschen.“

Wir sind also nicht nur für uns selbst, sondern für alle verantwortlich. Diese allgemeine Verantwortung resultiert aus dem Gedanken, dass wir frei handeln und nur das wählen (können), was wir als gut einstufen. In diesem Sinne wählen wir dann mit allem was wir tun gleichzeitig auch das Menschen-Bild, das wir befürworten.

Zurück zum Scrum Guide: mit commitment ist eine sehr hohe Verantwortung verbunden, zu Deutsch eine Verpflichtung, die Ziele zu erreichen – also die volle Verantwortung für das Handeln innerhalb des Sprints. Der Begriff forecast ist diesbezüglich deutlich schwächer. Dies ist insofern in Linie mit Sartre, als dass ein Scrum Team nicht die volle Freiheit hat. Es existiert innerhalb eines vorgegebenen Rahmens. Je freier dieser Rahmen gestaltet ist, desto mehr Verantwortung kann dem Team auch übertragen werden. Ein Team aber, das durch Organigramm, Rollenverteilung und vorgegebene Ziele definiert ist, kann kaum noch zur Verantwortung gezogen werden. Je agiler jedoch eine Organisation aufgestellt ist, desto mehr Freiheit und damit auch Verantwortung ergibt sich für den Einzelnen. In der extremsten Form hat jedes Team-Mitglied die Verantwortung für die gesamte Organisation, muss im Gegenzug aber auch in voller Freiheit agieren dürfen. So gibt es bereits Organisationen, die alle hierarchischen Strukturen auflösen und es jedem selbst überlassen, sich Aufgaben und Projekte zu suchen. Aber dies ist sicherlich (noch) eine Ausnahme.

Die oben beschriebene Anpassung des Scrum Guides kann man also als Abkehr einer idealistischen Sicht der agilen Idee betrachten: weg von grundlegender Agilität hin zur agilen Methode in der betrieblichen Realität. Ich für meinen Teil hätte gern das commit zurück, damit ich im Gegenzug auch meine Freiheit einfordern kann. Das eine geht nicht ohne das andere.

Sartre goes agile – Teil I: erst das Team, dann das Organigramm

Der Existentialismus bietet einige sehr spannende Ansätze, die sich auf die Idee agiler Organisationen übertragen lassen. Deshalb möchte ich in einer kleinen Serie an Blog-Posts einige dieser Ideen diskutieren. Dabei geht es nicht um eine tiefe Auseinandersetzung mit der Philosophie des Existenzialismus sondern sehr bewusst um die freie Interpretation einzelner Aussagen im Kontext des agilen Arbeiten. Ich werde mich dabei insbesondere auf Aussagen von Sartre beziehen.

Im diesem ersten Teil der Serie ‚Sartre goes agile‘ wollen wir eine der zentralen Kernaussagen des Existentialismus beleuchten: die Existenz geht der Essenz (bzw. dem Wesen) voraus. Sartre selbst schreibt dazu in seiner Klarstellung zum Existenzialismus:

In philosophischen Begriffen gesprochen, hat jeder Gegenstand ein Wesen und eine Existenz. Ein Wesen, das heißt eine konstante Gesamtheit von Eigenschaften; eine Existenz, das heißt eine gewisse effektive Anwesenheit in der Welt. (…) Mit einem Wort, der Mensch muß sich sein eigenes Wesen schaffen;“ 

Übertragen wir diese Idee nun auf ein agiles Team, z.B. ein SCRUM Team. Fei nach Sartre schafft dieses Team seine Eigenschaften, sein Wesen selbst – abgesehen davon, dass jedes Teammitglied sein eigenes Wesen in des Team einbringt. Es gibt also keine Eigenschaften, die dieses Team vor seiner Gründung bzw. vor dem ersten Sprint hat. Erst durch das gemeinsame Handeln der Menschen, die sich in diesem Team zusammenschließen, entsteht das Wesen des Teams. Wir kennen dies in agilen Methoden z.B. dort, wo wir i.R. der Retrospektiv-Ergebnisse eigene Team-Regeln aufstellen. Diese Regeln existieren nicht losgelöst von dem Team, sondern befassen sich mit den konkreten Bedürfnissen, die sich aus dem Schaffen des Teams ergeben. Die Idee des Existenzialismus lässt sich hier aber noch deutlich tiefer interpretieren. Nämlich dergestalt, dass auch die Rolle des Teams innerhalb der Organisation erst mit dem Team und seinen Ergebnissen und Aktivitäten entsteht. Dies ist damit ein Gegenentwurf zu dem klassischen Ansatz, bei dem Teams, Aufgaben und Rollen durch ein Organigramm bzw. das Management a priori definiert werden.

In der Praxis brauchen wir natürlich einen gewissen Rahmen, in den ein Team eingebettet ist. Wir brauchen zumindest eine Vision, aus der wir unseren Backlog füllen und priorisieren können. Wenn dies gegeben ist, dann können wir mit einer Organisation, die die Existenz vor die Essenz stellt, die volle Kraft unserer Teams nutzen. Denn dann können sich die Teams so aufstellen und definieren, dass sie das Beste aus ihrer spezifischen Konstellation an Persönlichkeiten und Fähigkeiten heraus holen.