Kitabı oku: «Roadmap durch die VUCA-Welt», sayfa 6

Ein Blick in die agile Praxis: Kanban und ScrumScrum

Das Agile Manifest schreibt nicht vor, wie die Werte und Prinzipien in der Praxis umgesetzt werden sollen. Schon vor der Entstehung des Agilen Manifests gab es eine Reihe von Rahmenwerken (Frameworks), die es erleichtern sollten, entsprechend ähnlicher Prinzipien und Werte den Arbeitsalltag zu gestalten. Diese Rahmenwerke haben den Vorteil, dass sie den Anwendern ziemlich klare Leitplanken und Werkzeuge an die Hand geben, die dafür sorgen, dass sie den Prinzipien entsprechend handeln.

Die bekanntesten beiden Frameworks aus dem agilen Portfolio sind Kanban und Scrum. Von erfahreneren Anwendern werden auch gerne Kombinationen aus unterschiedlichen Rahmenwerken verwendet, wie zum Beispiel Scrum mit Elementen aus Kanban und dem Extreme Programming (xP).7

Um die Grundgedanken und das Zusammenspiel verschiedener Elemente besser zu verstehen, sehen wir uns im Folgenden einmal die beiden populärsten Frameworks genauer an.

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.

Der Scrum Master hat dafür drei große Fokuspunkte, auf die er sich konzentriert. Zum einen unterstützt er den Product Owner. Er hilft ihm, die Anforderungen zu priorisieren und mit dem Entwicklungsteam in kleine, zu bearbeitende Aufgaben zu zerlegen. Zudem hilft er dem PO, sich in der agilen Produktplanung zurechtzufinden.

Als Zweites richtet der Scrum Master seine Aufmerksamkeit auf das Entwicklungsteam. Hier liegt sein Fokus darauf, das Team zu einer Selbstorganisation zu befähigen und die Zusammenarbeit zu verbessern. Dafür muss der Scrum Master ganz auf seine Überzeugungskraft und seine Coaching-Fähigkeiten zurückgreifen, denn in Scrum ist niemand vorgesehen, auch nicht PO oder Scrum Master, der in irgendeiner Form weisungsbefugt wäre.

Und zuletzt ist die Rolle des Scrum Masters auch dazu gedacht, in die Organisation hineinzuwirken. Wenn man mit Scrum beginnt, wird man schnell feststellen, dass gewisse Hindernisse, die eine selbstorganisierte Arbeit verhindern, nicht nur innerhalb der Teamgrenzen zu finden sind. Viele Probleme und Herausforderungen sind teamübergreifend und zum Beispiel in vorhandenen Strukturen oder Prozessen begründet. Es ist unvermeidlich, dass ein Unternehmen, das sich agil aufstellen möchte und dafür Scrum einführt, sich auch organisatorisch deutlich verändern muss.

Exkurs | Rollen und Positionen

Scrum definiert drei Rollen. In vielen klassischen Organisationen besteht eine sehr starke Fokussierung auf Positionen. Auch wenn beide Begriffe oft synonym verwendet werden, besteht hier ein deutlicher Unterschied. Eine Position ist untrennbar mit einer Person verknüpft. Frau Maier oder Herr Müller haben eine Position inne. An diese Position wiederum sind gewisse Rechte und Pflichten geknüpft. Ein Projektleiter trägt die Verantwortung für ein bestimmtes Projekt und hat vielleicht ein Budget zur Verfügung und dann auch eine Weisungsbefugnis für die Projektbeteiligten. Positionen sind in der Regel ein Kästchen in einem Organigramm, in dem ein bestimmter Name steht.

Rollen hingegen definieren erst einmal nur Verantwortlichkeiten, sind aber nicht personenbezogen. Das heißt, die in einer Rolle definierten Verantwortlichkeiten müssen erfüllt werden, aber es ist nicht unbedingt festgelegt, welche Person dies tut. Somit kann eine Rolle auch durch mehr als eine Person ausgefüllt werden, indem man beispielsweise die Verantwortlichkeiten aufteilt.

In sehr vielen Unternehmen wird eine Rolle an eine Position geknüpft. In manchen Fällen ist der Product Owner, der in Scrum als Rolle definiert ist, eine feste Position mit einer zugeordneten Person. Andernorts sind an die Position (das Kästchen im Organigramm) noch zusätzliche (nicht im Scrumguide definierte) Aufgaben, Rechte oder Pflichten geknüpft. Hier findet schnell eine Vermischung von Rolle und Position statt, die am Ende zu einem falschen Verständnis von den eigentlichen Rollen führen kann.

Neben diesen Rollen gibt Scrum auch ziemlich genau vor, welche Bestandteile es gibt und zu welchen Anlässen und wann die Teams zusammenkommen (Scrum Artefakte und Events).

Das Product BacklogProduct Backlog haben Sie ja schon kennengelernt. Es handelt sich dabei um eine Liste, die alle Arbeit enthält, die vom Team zu erledigen ist, um ein Produkt herzustellen. Diese Liste ist geordnet und die wichtigste Aufgabe befindet sich an der Spitze dieser Liste. Der Product Owner ist dafür verantwortlich, das Product Backlog aktuell zu halten und die Reihenfolge der Arbeit festzulegen. Die einzelnen Bestandteile des Backlogs nennt man Product Backlog Items. Diese werden oftmals in Form einer User Story (also aus der Sicht des Benutzers) geschrieben. Product Backlog Item ist alles, was eine Änderung am bestehenden Produkt darstellt, also zum Beispiel neue Anforderungen, Fehlerbehebungen oder die Beseitigung technischer Schulden.

Die Abarbeitung der Product Backlog Items erfolgt in Iterationen, sogenannten SprintsSprint. Ein Sprint ist per Definition maximal vier Wochen lang. Da die Vorausplanung mit zunehmender Länge der Iteration immer ungenauer wird, legt der Scrumguide hier diese Obergrenze fest. Für die meisten Teams hat sich eine Sprintdauer von zwei Wochen in der Praxis als guter Startwert herausgestellt. Es gibt aber auch Scrum Teams, deren Sprints nur einen Tag dauern, oder die sogar mehrere Sprints an ein und demselben Tag durchführen.

In einem gemeinsam Scrum Event (so nennt man bei Scrum die gemeinsamen Termine in Abgrenzung zu den gemeinhin oftmals als unproduktiv angesehenen „Meetings“), dem sogenannten Sprint PlanningSprint Planning, setzt sich das gesamte Scrum Team (Product Owner, Scrum MasterScrum Master und Entwicklungsteam) zusammen und überlegt, was es im nächsten Sprint voraussichtlich liefern kann. Dafür wird erst einmal ein Sprintziel festgelegt und dann Aufgaben aus dem Product Backlog ausgewählt, die zur Erreichung des Ziels notwendig sind.