Ein Angebot von

Was agile Self-Organized Teams brauchen

| Autor / Redakteur: Alexandra Windisch * / Stephan Augsten

Ein aktiver Schutz vor Störfaktoren hilft selbstorganisierten Agile-Teams dabei, konzentriert zu arbeiten.
Bildergalerie: 1 Bild
Ein aktiver Schutz vor Störfaktoren hilft selbstorganisierten Agile-Teams dabei, konzentriert zu arbeiten. (Bild: adesso)

Agile Teams sind insbesondere in der Software-Entwicklung sehr gefragt, auch große Organisationen wagen sich an die Umstellung. Aber wie wird aus einem – womöglich speziell für ein Projekt zusammengewürfelten – Team ein selbstorganisiertes? Ein Bericht aus der Praxis.

Was heißt „Self-Organized“, also selbstorganisiert? Das Team entscheidet praktisch demokratisch, wer welche Aufgaben übernimmt. Fällt ein Teammitglied aus, werden die Aufgaben unter den verbleibenden Kollegen aufgeteilt – ebenso funktioniert gegenseitige Unterstützung bei technischen Herausforderungen.

Klingt unrealistisch? Mitnichten. Doch was genau braucht ein Team, um selbstorganisiert zu werden? Im Grunde sind das zwei Dinge: Vertrauen und Schutz.

Vertrauen und Zutrauen

Zuerst muss definiert werden, dass jedes Team – ob selbstorganisiert oder nicht – erst einmal zum Team werden muss. Team-Building-Maßnahmen sind also unumgänglich und dienen dem Vertrauensaufbau und Zusammenhalt innerhalb des Teams.

Für ein selbstorganisiertes Team kommt noch das Vertrauen des Product Owners dazu, der dem Kollektiv die Lösung der (technischen) Aufgabe zutraut. Damit wird das Team in seinem Selbstbewusstsein gestärkt. Dies ist notwendig, um Verantwortung für ein Ergebnis übernehmen zu können.

Verantwortung zu delegieren, dem Team zu vertrauen, ist in hierarchischen Organisationen oft eine große Herausforderung – für Manager ebenso wie für die Teammitglieder. Nicht selten scheitert Agilität bereits in diesem Punkt.

Vertrauen auf Augenhöhe: Transparenz

Vertrauen entsteht immer nur in einer respektvollen, offenen Umgebung. Es muss möglich sein, Herausforderungen, aber auch Probleme, Schwierigkeiten oder Fehler offen anzusprechen. Nur mit Transparenz kann sich ein ehrliches Miteinander entwickeln und gegenseitige Verantwortung entstehen.

Transparenz muss übrigens auch vom Product Owner oder Management gelebt werden: Agilität schafft Werte – zum Beispiel für den Product Owner oder den Kunden –, daher muss für das Team auch transparent sein, welche Werte generiert werden sollen.

Auch hier zeigt sich ein mögliches Hindernis für Selbstorganisation: Wenn nicht transparent ist, was mit der Arbeit erreicht werden soll, ist es schwierig, ein Ziel für das Team zu finden. In vielen Organisationen bestehen langjährige Zielkonflikte, die ungelöst ein Hindernis für agiles Arbeiten darstellen. Transparenz wird allen abverlangt, wenn Selbstorganisation gelingen soll.

Aktiver Schutz vor Störungen

Selbstorganisation lässt sich nicht aktiv herbeiführen, sie entsteht, wenn die Umstände dafür günstig sind. Ein wesentlicher Faktor, der ein Team begünstigt, ist aktiv ausgeübter Schutz. Das Team erfährt viele „Attacken“ von außen, dazu zählen zum Beispiel falsche Erwartungshaltungen ebenso wie Störungen durch Stakeholder oder Management.

Als Störung kann auch der Abzug von Ressourcen (ganz oder teilweise) gewertet werden, selbst wenn eine gewisse Fluktuation innerhalb des Teams hingenommen und verwaltet werden muss. Aktiver Schutz vor negativen Einflüssen ist dabei Aufgabe des „Agile Team Lead“, der Störungen abfängt, um ein konzentriertes Arbeiten zu ermöglichen.

Arbeitet das Team Co-Located in einem eigenen Raum, so verstärkt dieser den Schutzgedanken auch räumlich. Natürlich darf es immer Dinge geben, die den Raum des Teams nicht verlassen, sei es nun real oder virtuell.

Der Teamleiter: Servant Leader

Agile Methoden schreiben keinen Teamleiter, oft auch keinen Projektleiter mehr vor – und auch der Scrum Master oder Kanban Master hat laut Lehrbuch nur die agile Methode zu coachen beziehungsweise zu ermöglichen. Ihr Aufgabenbereich ist darauf beschränkt, Hindernisse zu beseitigen, damit die Methode gelebt werden kann.

Die Praxis zeigt hier wesentlich bessere Ergebnisse, wenn jemand auch als Agile Team Lead fungiert. Dies ist meist der Scrum oder Kanban Master, aber ebenso kann es einen Projektleiter oder Lead Developer geben, der sich um das Team kümmert.

Wie bereits erwähnt, ist die Rolle des Agile Team Leads eher passiv innerhalb des Teams, aber aktiv im Ermöglichen der günstigen Umstände, die das Team zur ungestörten Arbeit braucht. Als „Servant Leader“, also Diener des Teams, erkennt er die Bedürfnisse des Teams, nimmt sie ernst und beseitigt bestehende oder aufkommende Hindernisse. Manchmal kann das so weit gehen, dass er mithilft, wenn es Engpässe gibt.

Macht/Kraft als Kollektiv

Ein Agile Team Lead ist Teil des Teams, ist also auf Augenhöhe und kann gleichzeitig die Kraft des Kollektivs spüren, die ein agiles Team hat. Denn zum Beispiel Sprint-Planung oder Terminzusagen finden im Kollektiv statt, ebenso die Aufteilung oder Reihenfolge von Aufgaben. Jeden Eingriff von außen würde das Team als Störung empfinden.

Zusätzlich ist höchste Transparenz gefragt, was Informationen zu Abhängigkeiten oder Wertgenerierung betrifft. Wenn das Team versteht, dass ein bestimmter Termin oder ein bestimmtes Feature einen besonderen Wert haben, wird das Kollektiv diesen Wert generieren wollen. Beispielsweise kann die Aussage „Wenn wir das Feature X zum nächsten Ersten haben können, bedeutet dies einen echten Wettbewerbsvorteil“ ungeahnte Kräfte innerhalb eines Teams mobilisieren.

Der Product Owner kann auch die innovative Kraft des Kollektivs nutzen: Die Programmierer entwickeln Features direkt aus der Aufgabenstellung des Benutzers, die zum Beispiel in der Satzschablone der User Stories zu finden sind. Innovation würde nicht entstehen bei detaillierten Vorgaben zum Solution Design oder gar Pseudo-Code.

Fehlerkultur – aber richtig

Trägt ein Team gemeinsam die Verantwortung für die Lösung der Aufgabe, dann ist das Team auch gemeinsam verantwortlich, wenn Fehler passieren. Fehler sind die effektivste Möglichkeit, zu lernen und als solche sollten sie auch gesehen werden.

Im Fehlerfall sorgt der Agile Team Lead daher für eine gemeinschaftliche Analyse und Behebung. Außerdem gibt es auch eine gemeinsame Kommunikation nach außen. Agile Mechanismen wie beispielsweise regelmäßige Retrospektiven sorgen ihrerseits für die Aufarbeitung von Schwierigkeiten und Maßnahmen zur Qualitätsverbesserung innerhalb des Teams.

Der Umgang mit Fehlern: So fühlt es sich nicht gut an.
Der Umgang mit Fehlern: So fühlt es sich nicht gut an. (Bild: adesso)

Der Umgang mit Fehlern ist ein wesentlicher Faktor für die Selbstorganisation eines Teams. Verantwortlich agieren kann nur jemand, der keine Angst hat. Wenn Fehler passieren, werden sie behoben und analysiert, um daraus zu lernen. Die Suche (und am Ende gar Verantwortung) von Schuldigen ist reine Zeitverschwendung und wird schnell zur Vertuschung, also Intransparenz führen.

Folglich ist falsche Fehlerkultur ein weit verbreitetes Hindernis für Organisationen, agil zu werden. Angst vor Fehlern lähmt, dies gilt ganz besonders für eine offene Teamkultur, die in diesem Klima niemals entstehen kann.

Hindernis Hierarchie, Micro-Management

Ein anderes Hindernis für selbstorganisierte Teams ist Hierarchie. Hierarchie beschränkt die Eigenverantwortung und begünstigt Kontrolle in Form von Micro-Management. Auf diesem Nährboden kann sich kein selbstorganisiertes Team entwickeln, da die Teammitglieder Eigenverantwortung oder Umgang auf Augenhöhe gar nicht kennen. Aber auch für hierarchische Team- oder Projektleiter ist es unvorstellbar, ihre Verantwortung „an das Team“ abzugeben.

Mögliche Auswege bei Umstellungsschwierigkeiten

Am effektivsten ist es, bestehende Hindernisse zu entfernen, um die Einführung agiler Methoden zu unterstützen. In alten, gewachsenen Organisationen ist dies oft schwer möglich oder dauert Jahre. Oft sind schon Versuche mit einem agilen Pilotteam gescheitert.

Eine letzte Möglichkeit ist in solchen Fällen, ein ganzes Team zuzukaufen, das bereits mit agilen Methoden vertraut ist und außer Haus (beim Provider) arbeitet. Selbst widrige organisatorische Gegebenheiten wirken sich dann nur sehr mäßig aus, da Störungen aufgrund der räumlichen Trennung gut abgefangen werden können.

Eine gute „Brücke“ zur Organisation (zum Product Owner) beziehungsweise Unterstützung des Product Owner vor Ort sind wichtige Faktoren, die ein Remote Team beispielhaft agil performen lassen. In einem nächsten Schritt können dann einzelne Teammitglieder in das Remote Team integriert werden oder das Team arbeitet im Haus und dient als „lebendes Anschauungsobjekt“.

Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen

ESE Kongress Keynote 2018

Wie sich Menschen organisieren, wenn ihnen keiner sagt, was sie tun sollen

22.01.19 - Arbeiten Sie noch – oder beschäftigen Sie sich nur? Auf dem ESE Kongress 2018 forderte Dr. Lars Vollmer die Zuhörer auf, mehr Verantwortung zu übernehmen und mehr Initiative zu ergreifen. Die Top-Keynote ist nun als Video-Aufzeichnung kostenlos verfügbar. lesen

Tipps und Tricks für zeitgemäßes Projektmanagement

Tipps und Tricks für zeitgemäßes Projektmanagement

09.07.18 - Es ist noch kein Meister vom Himmel gefallen und nicht jeder hat ein angeborenes Organisationstalent. Probieren Sie deswegen folgende Tipps, um Ihr nächstes Projekt zum Erfolg zu führen. lesen

Agile Projekte mit Scrum effizient und einfach starten

Agile Projekte mit Scrum effizient und einfach starten

25.06.18 - Will man ein Software-Projekt beginnen, sind die Anforderungen in der Praxis so unterschiedlich wie die Unternehmen, Mitarbeiter und Projekte selbst. Dieser Beitrag zeigt ausgewählte Ansätze auf, wie Sie Ihrem agilen Projekt einen optimalen Start verleihen, indem Sie vorausschauend Potenziale nutzen und Fehler vermeiden. lesen

* Alexandra Windisch ist Senior Consultant bei adesso und hat mehr als 20 Jahre Erfahrung im IT-Projektgeschäft. In dieser Zeit hat sie alle projektrelevanten Rollen ausgeübt vom Requirements Engineer, Business Analyst, Architekt, Programmierer und Tester bis hin zu Projektmanagement und Teamleitung von virtuellen Teams. Sie hält Zertifikate für Projektmanagement (PMP), ITIL, IREB, CPUX, Datenschutz, Scrum Master und Scrum Product Owner. Sie arbeitet seit mehr als 15 Jahren agil, seit acht Jahren auch als Scrum Master und TeamLead nationaler und internationaler Teams, seit zwei Jahren für adesso.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45735304 / Agilität)