Leadership & Coaching

Kanban

Kanban ist eine Methode des Projektmanagements und der Prozesssteuerung, die ursprünglich in der Produktionssteuerung von Toyota (Ohno, 1988) entwickelt wurde und dann auf Softwareentwicklung übertragen wurde (Anderson, 2010). Das Wort „Kanban“ kommt aus dem Japanischen und bedeutet in etwa „Signal-Karte“. Die Methode zielt darauf ab, den Arbeitsfluss zu visualisieren, Engpässe zu identifizieren und kontinuierliche Verbesserungen zu ermöglichen.

mehr

Ein einfaches Kanban-Board erstellt sich folgendermaßen: Eine Tabelle mit vier Spalten wird erstellt. Die Spalten haben von links nach rechts Namen wie Backlog (Rückstand, Themen Speicher), Doing (In Arbeit), Review (Überprüfung) und Done (Erledigt). Im Backlog werden umsetzbare Ideen und Optionen gesammelt. Dieses dient als Pool an Ideen. In der Spalte Doing oder in Progress befinden sich aktuell in Be- oder Ausarbeitung befindende Aufgaben oder Themen. In Review werden abgeschlossene Aufgaben abgelegt und erhalten eine Kontrollansicht beziehungsweise Feedback. Zuletzt werden abgeschlossene und abgenommene Aufgaben oder Themen in der letzten Spalte Done abgelegt. Einmal erstellt, gilt es, die Tickets (Ideen, Aufgaben, Themen, …) mit ihrem Prozessstand zu verschieben. So entsteht ein Arbeitsfluss von links nach rechts, wobei es nicht ausgeschlossen ist, dass ein Ticket auch mal wieder zurückgeschoben werden kann. Zum Beispiel kann ein Ticket aus dem Review in die Doing-Spalte zurückgeschoben werden, sollte das Thema nicht ausreichend bearbeitet worden sein. Hierbei ist ein sogenanntes Work-in-Progress Limit (WIP-Limit) für die Tickets in der Doing Spalte zu setzen, damit dort kein Engpass die Prozesse verzögert. Hierbei wird ein Zeitpunkt des Abschlusses der Aufgabe festgelegt, um ein effizientes Bearbeiten der Tickets zu gewährleisten. Ein Ticket kann erst dort hinbewegt werden, wenn Platz besteht. Ein niedriges Limit fördert Kooperation (Sieroux et al., 2020).

Je nach Anforderungen kann dieses Board um Spalten erweitert werden, wie eine Unterteilung der vier genannten Spalten oder eine weitere ToDo Spalte zwischen Backlog und Doing. Auch gibt es die Variante einer Fast-Track Zeile für dringliche mit Priorität zu erledigende Aufgaben, sowie viele weitere Bausteine, die ein Kanban-Board auf die eigenen Bedürfnisse anpasst (Sieroux et al., 2020).

weniger

Zwei Beispiele für Kanban Boards sind auf diesem Arbeitsblatt zu finden. 

Scrum

Scrum ist ein agiles Framework für das Projekt- und Produktmanagement, das hauptsächlich in der Softwareentwicklung, aber auch in anderen Bereichen eingesetzt wird. Es wurde von Takeuchi & Nonaka (1986; 1995) entwickelt, um Teams zu helfen, in komplexen Projekten effizient und flexibel zu arbeiten. Die wesentlichen Elemente von Scrum sind: Rollen, Artefakte und Ereignisse.

mehr

1. Rollen:
   1. Product Owner:
      Diese*r ist verantwortlich für die Maximierung des Werts des Produkts, das das Entwicklungsteam erstellt. Der Product Owner verwaltet das sogenannte Product Backlog.
   2. Scrum Master:
      Diese*r ist zuständig dafür, dass das Scrum-Team die Scrum-Praktiken versteht und anwendet. Er hilft, Hindernisse zu beseitigen und den Prozess zu verbessern.
   3. Entwicklungsteam:
      Dieses besteht aus einer Gruppe von Fachleuten, die an dem Produkt arbeiten. Das Team ist selbstorganisiert und funktionsübergreifend, also verfügt es über alle Fähigkeiten und den nötigen Verantwortungsrahmen, die notwendig sind, um das Produkt zu liefern.
   4. Stakeholder:
      Stakeholder können Kunden sein. Als Stakeholder werden die Auftraggeber für ein Produkt bezeichnet. Sie nehmen das Produkt ab und geben dem Entwicklungsteam entsprechendes Feedback
2. Artefakte:
   1. Product Backlog:
      Eine priorisierte Liste von Aufgaben und Anforderungen, die für die Entwicklung des Produkts notwendig sind. Der Product Owner verwaltet das Backlog.
   2. Sprint Backlog:
      Eine Liste der Aufgaben, die das Team in einem Sprint (ein festgelegter Zeitraum, normalerweise 2-4 Wochen) bearbeiten will. Das Entwicklungsteam erstellt und verwaltet dieses Backlog.
   3. Increment:
      Das potenziell auslieferbare Produkt, das am Ende eines jeden Sprints erstellt wird. Es muss den Definitionen von „fertig“ entsprechen und einen Mehrwert für den Gesamtauftrag liefern.
3. Ereignisse:
   1. Sprint:
      Ein festgelegter Zeitraum, normalerweise 2-4 Wochen, in dem ein Inkrement des Produkts erstellt wird.
   2. Sprint Planning:
      Ein Meeting zu Beginn jedes Sprints, bei dem das Team entscheidet, welche Aufgaben aus dem Product Backlog in den Sprint Backlog aufgenommen werden.
   3. Daily Scrum:
      Ein tägliches 15-minütiges Meeting, bei dem das Team den Fortschritt bespricht und den Plan für die nächsten 24 Stunden erstellt.
   4. Sprint Review:
      Ein Meeting am Ende des Sprints, bei dem das Team das fertige Inkrement präsentiert und Feedback der Stakeholder erhält.
   5. Sprint Retrospective:
      Ein Meeting am Ende des Sprints, bei dem das Team seine Arbeitsweise überprüft und Verbesserungen für den nächsten Sprint plant.

Scrum fördert Transparenz, Inspektion und Anpassung, um sicherzustellen, dass Teams kontinuierlich besser werden und einen hohen Wert für ihre Kunden liefern können. Iterativ entwickelt das Team durch die Sprints verbesserte Produktversionen, die nach jedem Sprint funktionsfähig und bereit für Tests und Feedback sind (Sutherland & Schwaber, 2020).

weniger

Kommunikationsprozesse

Als relevante Kommunikationsprozesse in der agilen Führung sind vor allem Moderation, Feedback und Konfliktlösung zu nennen. In agilen Teams, durch die heterogenere Zusammensetzung und die entstehende Eigeninitiative und Selbstständigkeit der Individuen, entstehen Herausforderungen, die Kommunikationskompetenzen essentiell machen.

mehr

Moderation:

Bei Gruppenmeetings empfiehlt sich eine Aufgabenteilung in Moderator*in und die Teilnehmer*innen. Die Rolle der Moderation trägt Verantwortung für den Prozess und die Struktur. Die Teilnehmenden sind durch Beiträge verantwortlich für die entstehenden Inhalte. Wie sehr und wann die einzelnen Teilnehmenden sich einbringen ist dabei eigenverantwortlich zu entscheiden (Oestereich & Schröder, 2017).

Die Moderation sollte klare Sprache wahren und aktiv zuhören. Sie kann zur Förderung der Struktur zusammenfassen, visualisieren und den Leitfaden vorgeben (Oestereich & Schröder, 2017).

Aktives Zuhören:

Das Hauptmerkmal hier ist, mit voller Konzentration zuzuhören und zum Schluss die Kernbotschaft des Erzählten wiederzugeben und bestätigen zu lassen (Rogers & Farson, 1957). Zuhören ist in vier Schritte unterteilbar: Beobachtung, Interpretation, Bewertung und Antwort. So werden Misskommunikation und persönliche Interpretationsunterschiede minimiert. Auch die Trennung von Sachebene und Beziehungsebene gehören zum aktiven Zuhören (Rogers & Farson, 1957). Wir unterscheiden zwischen Beobachtung und Wertung, um die Kommunikation zu vereinfachen.

Feedback:

Damit Feedback richtig ankommt, sollte auch hier aktives Zuhören mitsamt Trennung von Selbstoffenbarungs- und Beziehungsebene genutzt werden. Zur Unterscheidung der unterschiedlichen Ebenen der Kommunikation empfiehlt es sich Schulz von Thuns (2014) “Vier-Seiten-einer-Nachricht”, ein Klassiker der Kommunikationsstruktur, zu beachten. So wird bei negativem Feedback der Auslöser, sowie das Problem deutlich. Auf gegenseitige Wertschätzung und auch positives Feedback ist zu achten. Als erste starke Regel für Wertschätzung gilt, zu erfragen, ob die andere Person mein Feedback in diesem Zeitpunkt hören möchte (Oestereich & Schröder, 2017).

Als Empfänger*in von Feedback ist solches aufzunehmen und wert zu schätzen. Achtung vor einer eigenen Abwehrhaltung und Zeit zum Reflektieren ist geboten (Sieroux et al., 2020).

In agilen Teams ist es wichtiger als in konventionellen Teams, sich als Teammitgliedern Feedback zu geben. Durch hohe Selbstständigkeit und Kooperation entsteht ein höherer Bedarf an horizontalem Feedback.

Konfliktlösung:

Dies ist vorwiegend zwischen den Konfliktparteien zu erledigen und nicht unbedingt Aufgabe der agilen Führungskraft. Doch alle Teammitglieder müssen wissen, wie zu handeln ist.

Konflikte: “Unvereinbar erlebte Spannungsfelder, die hohe oder auch wiederkehrende belastende emotionale Reaktionen bei den Beteiligten auslösen und deren Aufmerksamkeit binden” (Oestereich & Schröder, 2017, p. 259).

Wenn ein Konflikt festgestellt wird, sollten sich die Konfliktparteien zusammensetzen und gemeinsam zunächst die Sach- und Beziehungsebenen schildern. Wahrnehmung und Respekt sind vorausgesetzt. Hieraus kann ein Wunsch zum Vorgehen zur Behebung des Konflikts geäußert werden, der anzunehmen oder abzulehnen ist. Falls dies scheitert, sollte eine neutrale Mediation stattfinden (Oestereich & Schröder, 2017). Eine Mediation ist ein strukturierter Prozess, der durch eine*n Mediator*in begleitet wird. Diese Person ist unabhängig, nicht am Konflikt beteiligt, unparteiisch und allen Parteien wohlwollend.

Hier gibt es Arbeitsblätter zum Feedback und zum aktiven Zuhören. 

weniger

DevOps-Prinzip

Das DevOps-Prinzip basiert auf der agilen Softwareentwicklung und hat den Zweck, den Zyklus der Systementwicklung zu beschleunigen und zu optimieren (Courtemanche, Mell & Gills, 2024). Dieses Ziel soll durch verschiedene Methoden erreicht werden. Herkömmlich ist Entwicklung und Betrieb in Softwareunternehmen getrennt angesiedelt. Der Betrieb, also die Administration der Systeme und Kundenbetreuung, und die Entwicklung, also die Weiter- oder Neugestaltung der bestehenden Systeme, leiden unter schlechter Kommunikation und unterschiedlichen Interessen. Daher ist das Hauptmerkmal des DevOps (wie der Name verrät) die Zusammenlegung von Entwicklungs- (Development) und Betriebsabteilungen (Operations).

mehr

Die Rollen der Mitarbeitenden sollen sich dabei nicht vermischen, doch für jedes System sollen die Zuständigen von höherem Austausch und leichterer Absprache kunden- und nutzenorientierte Ergebnisse liefern können. Die jeweiligen Interessen werden besser wahrgenommen, integriert und getestet. So arbeiten alle zuständigen Personen parallel und kollaborativ. Durch ständige Integration werden die kleinen Versionen schnell getestet und eingearbeitet. Dabei wird eine Automatisierung namens CI/CD-Pipelines genutzt. Diese stehen für Continuous Integration und Delivery. Diese IT-Tools unterstützen automatisiert bei dem Bauen und Testen der neuen Softwarebausteine, als auch beim Testen der Integration und der Nutzerakzeptanz (Courtemanche, Mell & Gills, 2024).

Schwächen, die dabei jedoch aufkommen sind entgegenzuwirken: Der Wissensaustausch zwischen den jeweiligen Fachleuten nimmt ab. Außerdem drohen die Produkte von einer gemeinsamen technischen Bauweise auseinander zu gehen (Oestereich & Schröder, 2017).

Empfehlung zu weiterführender Literatur ist hier das Buch “Phoenix Project” von Kim, Behr und Spafford (2013).

Wie ist das auch auf die agile Organisation anwendbar? In Teilen ist es eindeutig: Die Zusammensetzung der Teams ist, wie oben schon genannt, nicht nach Fachwissen, sondern nach Projekt oder Produkt zu bestimmen. Bei Vertrieb, Entwicklung, Produktion und Kundendienst ergibt dies sicherlich Sinn, bei der Buchhaltung, Rechtsabteilung und Personal ist die Aufspaltung auf Projekte oder Produkte allerdings zu überdenken. Eine interdisziplinäre anstatt monodisziplinärer Struktur von DevOps zu übernehmen ist allgemein ein guter Weg zu mehr Agilität.

weniger

Zur Vertiefung dieses Themas empfehlen wir die Literatur der angegebenen Quellen. Ausführliche Quellenangaben finden sich auf der Seite „Materialien und Literatur“.

zurück zur Übersicht


weiter mit Kritik