Roadmap durch die VUCA-Welt

Kanban

Am Beispiel von KanbanKanban können Sie sehr schön erkennen, dass die Evolution agiler Frameworks und Methoden nicht erst mit dem Agilen Manifest als Startschuss erfolgt ist. Schon beim Toyota-Produktionssystem fand eine erste Form von Kanban statt. Und blickt man weiter in der Geschichte zurück, kann man sogar noch frühere Wurzeln finden.

Das Wort Kanban stammt aus dem Japanischen und ist eine Zusammensetzung aus den beiden Worten „kan“, was so viel wie Signal bedeutet, und „ban“, was Karte heißt. Somit hieße Kanban wörtlich übersetzt Signalkarte. Laut einer Geschichte, die David Anderson, einer der modernen Vertreter des Kanban, erzählt (Anderson 2011), diente eine Signalkarte schon zu frühen Zeiten zur optimalen Auslastung eines Systems. Ein solches System stellte beispielsweise ein Garten dar, wo man mit Hilfe von Signalkarten sicherstellte, dass nur eine für den Garten passende Menge an Besuchern sich auch in diesem aufhielten. Die Torwächter ließen nur dann einen neuen Gast in den Garten, wenn ein anderer wieder hinausging und seine Signalkarte zurückgab.

Das moderne Kanban hat mit den historischen Ansätzen zwar noch einige Elemente gemein, ist aber stärker angelehnt an das, was wir schon aus dem Lean-Umfeld kennengelernt haben. An dieser Stelle beziehe ich mich daher auf die Regeln und Prinzipien, des modernen Ansatzes, wie ihn Anderson beschreibt und verschiedene andere Praktiker ergänzt und weiterentwickelt haben.

Kanban zeichnet sich dadurch aus, dass man nicht notwendigerweise einen neuen Arbeitsablauf oder neue Rollen einführen muss, um mit Kanban zu starten. Ein Team oder ein Unternehmen, das Kanban anwenden möchte, kann mit dem Arbeitsablauf und den Prozessen starten, die sie gerade praktizieren. Dies senkt die Hürde für den Einstieg.

Zum erfolgreichen Arbeiten mit Kanban gilt es dann, sechs Praktiken in seinen Arbeitsalltag zu integrieren.

1 Visualisierung des Arbeitsflusses: Die erste Praktik besteht darin, den Fluss der Arbeit zu visualisieren. Dies geschieht in aller Regel mit Hilfe eines sogenannten Kanban-Boards. Auf diesem Board kann man in verschiedenen Spalten die einzelnen Schritte der Wertschöpfungskette visualisieren. Einzelne Aufgaben werden auf Papierkarten geschrieben und von einer Spalte in die nächste gezogen, je nachdem in welchem Arbeitsschritt sie sich gerade befinden. Wie Sie sehen, muss hier erst einmal nichts angepasst werden, da lediglich die aktuelle Vorgehensweise abgebildet wird. Hierbei ist es wichtig, die richtige Granularität für die einzelnen Schritte im Wertstrom zu finden, so dass sich eine ausreichende Transparenz ergibt.Abb. 13:Ein exemplarisches Kanban-Board

2 Begrenzung der angefangenen Arbeit im System: Die Arbeit, die sich zu einem bestimmten Zeitpunkt im System befindet, wird als Work-in-Progress (WIP) bezeichnet. Pro Arbeitsschritt, der auf dem Board als Spalte repräsentiert ist, legt man nun eine maximale Menge von Aufgaben fest, die gleichzeitig ausgeführt werden dürfen. Dies macht man mit einer entsprechenden Zahl an der Spalte des Boards sichtbar. Auf diese Weise entsteht ein WIP-Limit, was dazu führt, dass wenn die maximale Anzahl der erlaubten Aufgaben in einer Spalte erreicht ist, keine neue Arbeit in diesem Schritt angefangen werden darf. Hier zeigt sich das daraus entstehende Pull-Prinzip (Ziehen der Aufgaben). Die Aufgaben werden nicht einfach nach Fertigstellung in den nächsten Arbeitsschritt gedrückt (Push), sondern werden nur dann in den nachfolgenden Schritt gezogen, wenn die Kapazität es zulässt. Auf diese Weise sollen Flaschenhälse (englisch: Bottlenecks) aufgespürt werden.

3 Messung und Steuerung des Flusses: Die nächste Praktik besteht darin, den Fluss zu messen und gezielt zu steuern. Dazu werden bestimmte Metriken erhoben, die es erlauben, Aussagen über die Leistungsfähigkeit des Gesamtsystems zu treffen.Eine dieser Größen ist die Cycle-Time. Darunter versteht man die Zeit, die gemessen wird von dem Moment an, wo die erste Arbeit an einer Anforderung durchgeführt wird, bis zum Abschluss dieser Aufgabe. In der Regel wird der Start der Arbeit durch einen Commitment-Punkt auf dem Kanban-Board bestimmt, der die Akzeptanz der Anforderung ausdrückt und eine Verpflichtung zur Umsetzung darstellt. Der Abschluss der Arbeit eines Teams wird durch einen Delivery-Punkt bestimmt, also dem letzten Arbeitsschritt, den ein Team selbst durchführt. Eventuell ist das noch nicht der finale Schritt, da noch andere Teams später im Prozess beteiligt sein könnten.MetrikBeschreibungMessungLead-TimeVorlaufzeit. Die Zeit, die eine Aufgabe von der Erstellung (Eintritt ins System) bis zur Erledigung (beispielsweise Lieferung an den Kunden) benötigt.Zeitpunkt der Fertigstellung – Zeitpunkt der AnforderungCycle-TimeZykluszeit. Die Zeit, die eine Aufgabe innerhalb eines bestimmten Arbeitsschrittes (oder eine Kombination von Arbeitsschritten) benötigt.Zeitpunkt der Fertigstellung des Arbeitsschritts – Zeitpunkt des Starts des ArbeitsschrittsDurchsatzAnzahl der Aufgaben pro Zeiteinheit (zum Beispiel abgeschlossene Aufgaben pro Tag)geschlossene Aufgaben pro Zeiteinheit (kann mit Lead- und Cycle-Time kombiniert werden)Work in Progress (WIP)Aufgaben in Bearbeitung.Anzahl der parallellaufenden Arbeiten in bestimmten Arbeitsschritten.Tab. 4:Wichtige Metriken in einem Kanban SystemEine weitere Metrik ist die sogenannte Lead-Time. Die Lead-Time misst die Zeit von dem Moment an, wenn die Anforderung im System erstellt wird bis zur Auslieferung. Die Lead-Time ist also das, was ein Kunde von außen sehen würde, von dem Moment, in dem er einen Wunsch geäußert hat, bis dass er ein Resultat zurückgeliefert bekommt.Auch der Durchsatz spielt eine wichtige Rolle. Der Durchsatz wird in der Regel errechnet als Quotient aus durchschnittlicher WIP und mittlere Cycle-Time (Little’s Law). Kennt man diese Kennzahlen, dann kann man im Folgenden anfangen Parameter zu variieren und so das Gesamtsystem zu optimieren.Wenn Sie sich die Metriken anschauen und den Zusammenhang mit dem Gesetz von Little vergegenwärtigen, dann lassen sich daraus einige interessante Schlussfolgerungen ziehen. In der Abbildung ist der Wertstrom als ein Kanal dargestellt. Sicher stimmen Sie zu, dass es ein sinnvolles Ziel ist, den Durchsatz zu erhöhen. Die mathematischen Zusammenhänge lassen nun zwei offensichtliche Optionen zu:Option eins besteht darin, einfach mehr Arbeit in den Kanal zu drücken. Damit würde bei gleichbleibender Durchlaufzeit der Durchsatz nach oben gehen. Sie werden aber zurecht sagen, dass das sicher keine gute Idee ist, da dies schnell zu Überlastung und in letzter Konsequenz zum Zusammenbruch führen wird.Die zweite Option besteht darin, die Durchlaufzeit zu reduzieren. In unserer Bild würde das erreicht, indem wir den Kanal verkürzen. Nun ist auch weniger Platz für Work in Progress. Die Reduzierung von Arbeit führt also automatisch zu kürzeren Durchlaufzeiten und somit zu einem höheren Durchsatz. Das ist der Grund, warum die WIP-Limits für Kanban so essenziell wichtig sind.Abb. 14:Littles GesetzLittles Gesetz

4 Explizite Regeln für den Prozess: Kanban macht den Prozess explizit. Normalerweise geschieht dies auf dem Kanban-Board selbst, so dass alle Beteiligten genau wissen, welche Regeln gelten und wo sie zu finden sind. Wichtig ist dabei, eine genaue Definition zu haben, wann eine Aufgabe fertig ist und in die nächste Spalte gezogen werden kann. Auch die Bedeutung der einzelnen Spalten sollte möglichst eindeutig und klar beschrieben sein. Zudem muss geklärt sein, wer etwas ziehen darf, wann etwas gezogen wird und in welcher Reihenfolge die nächsten verfügbaren Tickets gezogen werden. Und natürlich muss auch das WIP-Limit klar ersichtlich sein und von allen eingehalten werden.

5 Förderung von Leadership auf allen Ebenen: Wie Sie sich leicht vorstellen können, führen die bisher vorgestellten Praktiken dazu, dass Sie sehr schnell die Schwachstellen in den bisherigen Abläufen finden können, wie zum Beispiel Flaschenhälse. Um diese zu beheben kommt es auf das Engagement aller Beteiligten an. Nicht nur eine bestimmte Abteilung, sondern alle an der Wertschöpfung beteiligten Personen, egal in welcher Hierarchieebene, sind dazu aufgerufen, sich an der kontinuierlichen Verbesserung zu beteiligen. Zudem müssen auch alle Ebenen die vereinbarten Regeln einhalten (insbesondere das WIP-Limit).

6 Verwendung von Modellen zur Erkennung von Chancen für Verbesserungen: Zur kontinuierlichen Verbesserung soll auch die Praktik führen, Modelle zu verwenden, um Chancen für kollaborative Verbesserungen zu erkennen. Dabei stellen die Modelle vereinfachte Darstellungen des Prozesses dar. Hier gibt es eine ganze Reihe von bekannten Ansätzen, die oft Verwendung finden. So zum Beispiel der Deming-Cycle (PDCA, Plan-Do-Check-Act) oder die Theory-of-Constraints, die Goldratt vorstellte (Goldratt/Cox 2013).

Exkurs | EngpasstheorieEngpasstheorie (Theory of Constraints, TOC)

Die Engpasstheorie besagt, dass der Durchsatz eines Systems einzig durch seinen Engpass bestimmt ist. Sie wurde von Eliyahu GoldrattGoldratt, Eliyahu entwickelt und veröffentlicht.

Gemäß der Engpasstheorie existiert zu jedem Zeitpunkt genau ein Schritt in der Wertschöpfungskette, der einen Engpass darstellt und somit den Durchsatz begrenzt. Dieser Engpass ist oftmals das Glied in der Kette, welches die geringste Kapazität besitzt. Daher sollte das erste Bestreben sein, diesen Engpass zu finden und voll auszulasten. Dazu stellt man sicher, dass der Engpass zum einen möglichst wenig Leerlauf hat und zum anderen nur für die wichtigsten Aufgaben genutzt wird. Alles, was nicht unbedingt vom Engpass bearbeitet werden muss, sollte man auslagern. Fortan wird dann der Engpass den Takt für das Gesamtsystem vorgeben, also nur noch so viel Arbeit im System sein, wie die Kapazität des Engpasses zulässt. Alle Optimierungsversuche sollten sich dann auch auf den Engpass konzentrieren, da jede Optimierung an einer anderen Stelle nicht den Gesamtdurchsatz steigern würde und im Gegenteil nur zu Wartezeiten und Überproduktion führen würde. Folgt man diesen Empfehlungen und erhöht die Kapazität des Engpasses, dann wird man höchstwahrscheinlich in der Folge auf einen neuen Engpass stoßen, bei dem man genauso verfahren sollte.

Goldratt bietet als Beispiel für Prozesssteuerung das sogenannte Drum-Buffer-Rope-Verfahren an. Dabei verwendet er als Bild eine Gruppe von Pfadfindern, die hintereinander im Gänsemarsch laufen, und als Gruppe ein gemeinsames Etappenziel erreichen sollen. Somit stellt der Pfadfinder, der das langsamste Tempo geht, den Engpass im System dar. Unser langsamer Pfadfinder bekommt bildlich gesprochen eine Trommel in die Hand (Drum), und bestimmt auf diese Weise den Takt des Gesamtsystems. Es kann auch jederzeit zu Störungen vor dem Engpass kommen. In unserem Bild beispielsweise ein stolpernder Pfadfinder, der den langsamsten in der Kette dadurch aufhält. Das würde bedeuten, dass der Engpass nicht optimal ausgelastet werden kann, da er abbremsen oder sogar anhalten müsste. Also sollte ein vernünftiger Puffer vor dem Engpass eingerichtet werden, so dass kleinere Ausfälle (Stolpern) den Engpass nicht verlangsamen (Buffer). Zuletzt sollte nun durch das Tempo des Engpasses und die Größe des Puffers gesteuert neue Arbeit in das System gezogen werden. Im Beispiel unserer Pfadfindergruppe würde ein Seil zwischen dem vordersten Pfadfinder in der Gruppe und dem Engpass gezogen, das die Zwischenräume steuert, so dass ein bestimmter Puffer vorhanden ist.

Hält man die vorgeschlagenen Praktiken ein, dann stellt Kanban ein Werkzeug für die evolutionäre Veränderung in Unternehmen dar. Durch das Aufdecken von Engpässen im System und der Konzentration auf eine kontinuierliche Verbesserung wird nach und nach das Gesamtsystem immer leistungsfähiger.

Beim Einsatz von Kanban spielt das Einhalten von WIP-Limits eine sehr große Rolle. Gerade Teams, die noch unerfahren mit dieser Vorgehensweise sind, tendieren dazu, die Begrenzungen zu ignorieren. Dies kann zum einen daran liegen, dass sie noch nicht ganz verstanden haben, welch große Bedeutung die Limitierung der Arbeit für den evolutionären Veränderungsprozess in Kanban besitzt. Zum anderen ist es aber auch häufig so, dass viele traditionelle Unternehmen großen Wert darauflegen, alle zur Verfügung stehenden „Ressourcen“ optimal auszulasten. Daher fühlen sich die Mitglieder eines Arbeitsteams verpflichtet, lieber eine neue Aufgabe zu beginnen, anstatt untätig herumzusitzen. Wie die Engpasstheorie jedoch verdeutlicht, führt das dazu, dass sich die Arbeit vor dem Engpass auftürmt und somit mehr Probleme entstehen, als es Mehrwert bringt. Umso wichtiger ist es, die Arbeit entsprechend zu visualisieren. Denn es geht darum, die Arbeit zu managen und sich die Menschen darum herum selbst organisieren zu lassen. Wenn die Arbeit allerdings nicht sichtbar ist, dann könnte leicht die Tendenz entstehen, das zu managen, was die Manager sehen können: die Menschen.

Der Fokus sollte erst einmal darauf liegen, den Engpass zu entlasten und dafür zu sorgen, dass wieder Kapazitäten frei werden. Wenn hier keine Möglichkeit der Unterstützung besteht, dann kann man die entstandene Zeit für die Verbesserung des Prozesses und des Gesamtsystems zu nutzen, mit dem Ziel, den Engpass langfristig zu beheben. Diese freigewordene Zeit wird oftmals auch als Slack bezeichnet und spielt in so gut wie allen agilen Rahmenwerken eine wichtige Rolle. Slack ist wichtig und notwendig, um die Leistungsfähigkeit des Gesamtsystems kontinuierlich zu steigern.

Bisher haben wir gesehen, wie Kanban funktioniert, wenn ein Team eine Anforderung von der Aufnahme bis zur Umsetzung komplett bearbeitet. In der Praxis wird es aber in einem großen Unternehmen mehrere Teams geben, die in irgendeiner Form zusammenarbeiten müssen, um eine Aufgabe wirklich abzuschließen. Hier ergeben sich schnell Abhängigkeiten und es ist zum einen oft unübersichtlich, zum anderen kaum möglich, ein einziges Kanban-Board zu haben, das alle Arbeitsschritte in der gewünschten Granularität visualisieren kann. Viele einzelne Kanban-Teams machen daher noch nicht automatisch ein agiles Unternehmen aus. Ein anschauliches Beispiel, wie man zu echter „Business-Agilität“ gelangt liefert Klaus Leopold, der zur Orientierung verschiedene Flight-Level (Flughöhen) vorschlägt (Leopold/Kaltenecker 2018).

Auf dem obersten Flight-Level schaut man auf die Wertschöpfungsketten, die in einem Unternehmen vorhanden sind. Die meisten Unternehmen haben mehr als ein Produkt oder teilen ihre Arbeit in unterschiedliche Projekte auf. Diese stellen sehr häufig auch eigene Wertschöpfungsketten mit gewissen Besonderheiten dar. Auf der oberen Ebene interessiert man sich genau für diese unterschiedlichen Initiativen und nutzt die Kanban-Praktiken, um auf dieser Granularität den Gesamtwert für das Unternehmen zu optimieren.

Das Flight-Level darunter konzentriert sich auf eine dieser Wertschöpfungsketten und stellt die Arbeitsschritte und die Aufgaben in einer Granularität dar, die eine Koordination der verschiedenen beteiligten Teams ermöglicht. Es ist die Ebene der Koordination.

Geht man noch ein Level tiefer, so ist man auf der Team-Ebene, wo die Arbeit, die von einem Team erledigt wird, visualisiert und optimiert wird. Wenn hier Arbeiten abgeschlossen werden, wird diese Aktualisierung auf das darüberliegende Level übertragen. Würde man Kanban nur auf das Teamlevel beschränken, dann würde es eventuell zu lokalen Optimierungen kommen, die – wie wir gesehen haben – das Gesamtsystem eventuell sogar verschlechtern. Durch die unterschiedlichen Flughöhen hat man aber auf unterschiedlichen Ebenen die Engpässe und auch mögliche Verbesserungen im Blick, so dass man die gesamte Wertschöpfungskette und auch das gesamte Unternehmen verbessern kann.

Im Zusammenhang mit Kanban fällt oft der Begriff Kaizen, was sich aus den japanischen Begriffen kai (Wandel) und zen (zum Besseren) ableitet. Kaizen beschreibt den kontinuierlichen Verbesserungsprozess, der sich bei Einhaltung der Kanban-Praktiken von allein einstellen sollte. Darüber hinaus gibt es aber eine Reihe von Praktiken, die von den meisten Teams geteilt werden, auch wenn es keine Regeln gibt, die sie vorschreiben. So zum Beispiel regelmäßige Statusmeetings, Reviews oder auch Retrospektiven.

Eine weitere, gern genutzte Praktik bei der Verwendung von Kanban, ist die Einführung von Service Level Agreements (SLA). Die Aufgaben werden dann bestimmten Klassen zugeordnet. So ist es möglich, bestimmte Aufgaben einem Service Level zuzuweisen, der bevorzugt behandelt wird. Sobald dann an einer Station Kapazitäten frei werden, wird eine solche Aufgabe als erstes bearbeitet. Dies führt auch zu unterschiedlichen Cycle- und Lead-Times für die verschiedenen Service Level, die auch zum Kunden kommuniziert werden können.

Scrum

„Mit 85 % ist ScrumScrum die meistgenutzte agile Methode. Danach folgen Kanban, Lean und DevOps.“ Zu diesem Schluss kommt die Studie Status Quo Agile,1 die von der Hochschule Koblenz 2016/17 durchgeführt wurde.2 Scrum erfreut sich damit viele Jahre nach seiner ersten Erwähnung im „New new product development game“ sehr großer Beliebtheit.

Eine tragende Rolle bei der systematischen Umsetzung der von Takeuchi und Nonaka beschriebenen Praktiken nahmen Ken Schwaber und Jeff Sutherland ein. Jeff Sutherland griff die beschriebene Idee auf und nutzte die Erkenntnisse in ersten Projekten. Ken Schwaber veröffentlichte bereits 1995 auf der OOPSLA-Konferenz einen ersten Beitrag über Scrum. Beide Pioniere gehörten auch zu den Unterzeichnern des Agilen Manifests im Jahr 2001. Im gleichen Jahr veröffentliche Ken Schwaber auch das erste Buch zum Thema Scrum, gemeinsam mit Mike Beedle (Schwaber/Beedle 2002).

Schwaber und Sutherland taten sich zusammen und gestalteten gemeinsam den Scrumguide,Scrumguide der die Spielregeln von Scrum definiert, auf die sich alle Anwender des Frameworks berufen.3 Der Scrumguide wurde in viele Sprachen übersetzt und wird regelmäßig aktualisiert. Auch wenn Scrum sehr populär in der IT ist, wird im Scrumguide explizit darauf hingewiesen, dass Scrum in allen erdenklichen Bereichen verwendet werden kann. Von einer großen Liste strahlender Beispiele berichtet Jeff Sutherland in seinem Buch „Die Scrum Revolution“ (Sutherland 2015). Der Scrumguide beschreibt drei wichtige Rollen, die zur Ausführung von Scrum benötigt werden.

Der Product Owner (Eigentümer des Produkts) hat die Verantwortung für das Produkt. Dafür muss er sicherstellen, dass die Aufgaben erledigt werden, die am meisten Wert generieren. Dies gelingt ihm, indem er alle Arbeiten, die zu erledigen sind, um das Produkt herzustellen, in das Product Backlog einträgt und dort in eine eindeutige Reihenfolge bringt.

In der Regel gibt es eine Reihe von Leuten, die ein Interesse an dem Produkt haben. Dies können zum einen (potenzielle) Kunden sein, zum anderen aber die eigene Unternehmensführung oder auch andere Abteilungen im eigenen Unternehmen. Die Aufgabe des Product Owners besteht nun darin, die Interessen dieser Stakeholder einzusammeln und gegeneinander zu gewichten. Dafür muss er in engem Kontakt mit den Stakeholdern stehen.

Im Gegensatz zum Wasserfallmodell, wo das Produktmanagement und die Entwicklung zwei getrennte Abteilungen bilden, ist der Product Owner Teil eines Scrum Teams und daher auch mitverantwortlich für die gelungene Umsetzung der Anforderungen. Der Product Owner ist dafür verantwortlich, was getan wird. In Scrum ist es wichtig, dass es genau einen Product Owner für ein Produkt gibt. Dies soll verhindern, dass sich zum Beispiel ein Komitee nicht einigen kann und somit Entscheidungen sehr träge getroffen werden können. Zwar können verschiedene Personen sich die Aufgaben des PO aufteilen, am Ende muss es aber genau eine Person geben, deren Entscheidung im Zweifelsfall von allen akzeptiert wird.

Das Entwicklungsteam besteht aus den Experten, die das Produkt herstellen. Das Team zeichnet sich durch seine interdisziplinäre Aufstellung aus. Im Scrum-Umfeld wird diese Eigenschaft als „Crossfunktionalität“ (X-funktional abgekürzt) bezeichnet. Es sind Experten aus den unterschiedlichsten Bereichen der Wertschöpfungskette in einem Team vorzufinden, die dann gemeinsam als Team eine Gesamtverantwortung für ein Produkt oder eines Produktbestandteils übernehmen. Dabei bemüht man sich um die Ausprägung eines T-Profils bei den Teammitgliedern (siehe Exkurs).

Exkurs | T-ProfilT-Profil

In klassischen Arbeitsgruppen, die aus Experten der gleichen Fachrichtung bestehen, hat man es in aller Regel mit Spezialisten zu tun. Diese haben eine tiefgehende Expertise in einem bestimmten Fachgebiet. Damit ihre Expertise möglichst effizient genutzt werden kann, ist ihr Arbeitsumfeld so gestaltet, dass sie sich ausschließlich auf diesen Fachbereich konzentrieren können. Auch Mitarbeiterentwicklung findet in diese Spezialrichtung statt. Dies wird oft als I-Profil bezeichnet, weil es eine einzelne, sehr spezialisierte Fähigkeit repräsentiert.

Demgegenüber strebt man in interdisziplinären Teams das sogenannte T-Profil (T-Shape) an. Dies bedeutet, dass das Teammitglied immer noch ein Experte in einem bestimmten Fachgebiet ist, was den Stängel des T repräsentiert. Gleichzeitig bemüht sich das Teammitglied aber auch, Aufgaben aus angrenzenden Fachgebieten zu lernen und bei Bedarf zu übernehmen. Wenn man ein wenig rechts und links seiner eigenen Spezialfähigkeit schaut, dann ergibt sich so der Querbalken des T-Profils.

Erinnern wir uns zurück an die Engpasstheorie, dann sehen wir, dass dieses angestrebte T-Profil kein Selbstzweck ist, sondern sehr wichtig, um die Leistungsfähigkeit eines Teams zu erhöhen. Ein Teammitglied mit I-Profil könnte, wenn ein Engpass gefunden wird, der in einem angrenzenden Arbeitsschritt liegt, nicht unterstützen, da ihm entsprechende Fähigkeiten fehlen. In klassischen Organisationen, die auf Effizienz und Auslastung optimiert sind, würde ein solches Teammitglied sich weiter mit den eigenen Aufgaben beschäftigen. Dies wäre aber eine lokale Optimierung, die dazu führen würde, dass sich vor dem Engpass ein Berg von Arbeit anhäuft. Besitzt das Teammitglied aber ein T-Profil, kann es den Engpass entlasten und somit zur Gesamtleistung des Teams beitragen, selbst wenn einzelne Glieder der Wertschöpfungskette nicht optimal ausgelastet sind.

Oftmals wird das T-Profil so missverstanden, dass jeder im Team in der Lage sein sollte, jede Aufgabe zu übernehmen, die anfallen könnte. Wie Sie oben gesehen haben, ist dies nicht das Ziel (und auch sehr utopisch). Das T-Profil soll vielmehr sicherstellen, dass eventuelle Engpässe entlastet werden können und im Falle des Ausfalls eines oder mehrerer Teammitglieder die Arbeit nicht komplett eingestellt werden muss, nur weil der eine „wissende“ Fachexperte nicht greifbar ist.

Das Entwicklungsteam organisiert sich selbst, so wie es meint, die gesetzten Ziele erreichen zu können. Das Team trägt die Verantwortung, wie etwas getan wird.

In Scrum gibt es keine speziellen Rollen innerhalb des Teams. Es gibt also keine weitere Unterteilung zwischen Entwicklern, Testern, Analysten, Ingenieuren, Layoutern oder welche Spezialgebiete auch immer zur Erstellung eines Produkts benötigt werden. Dadurch soll zum einen die Entwicklung in Richtung T-Profil unterstützt werden, zum anderen aber auch ein Gefühl für die gemeinsam getragene Verantwortung für das Ergebnis gestärkt werden.

Als dritte und letzte Rolle beschreibt der Scrumguide den Scrum MasterScrum Master. Für die meisten Unternehmen, die Scrum einführen, ist diese Rolle ein absolutes Novum, denn in den allerseltensten Fällen gab es zuvor eine Rolle, die eine vergleichbare Aufgabe hatte. Auf der einen Seite soll der Scrum Master das Scrum Rahmenwerk fördern und unterstützen. Er hilft also dem Team zu verstehen, wie genau Scrum funktioniert, und wie ein Rädchen in das andere greift. Zudem besteht sein Hauptfokus aber darauf, die Zusammenarbeit des Teams zu optimieren.