Aus dem Unterricht des CAS Mobile Business mit Ari Byland berichten Nathalie Mollet und Rahel Meier:

Seit der Digitalisierung nimmt die Komplexität der Welt kontinuierlich zu. Die Unternehmen brauchen eine Möglichkeit mit den Veränderungen sehr schnell umgehen zu können. Eine der grössten Herausforderungen dabei ist zu entscheiden, welches Vorgehen am effizientesten ist.

The Cynefin Framework

cynefin_framework

Quelle: Unterrichtsmaterial von Ari Byland

Das Cynefin Framework unterscheidet vier verschiedene Systeme. Je nach System wird ein anderes Vorgehen empfohlen:

Komplexe Systeme

Im komplexen System ist die Ursache-Wirkungsbeziehung nur rückwirkend erkennbar. Eine vorhergehende Analyse ist nicht möglich. Empfohlene Vorgehensweise: „probieren – beobachten – reagieren“.

Komplizierte Systeme

Es bestehen mehrere Ursache-Wirkungsbeziehungen, die zwar klar sind, aber nicht auf Anhieb nachvollzogen werden können. Empfohlene Vorgehensweise: „beobachten – analysieren – reagieren“.

Chaotische Systeme

Es können keine Ursache-Wirkungsbeziehungen identifiziert werden. Das System verändert sich kontinuierlich, was ein gesteuertes Vorgehen unmöglich macht. Empfohlene Vorgehensweise: „handeln – beobachten – reagieren“.

Einfache Systeme

Die Ursache-Wirkungsbeziehung ist sofort klar erkennbar. Empfohlene Vorgehensweise: „beobachten – kategorisieren- reagieren“.

Kann ein Projekt zum komplizierten System zugeordnet werden, empfiehlt sich die klassisch strukturierte Projektplanung. Besteht das Projekt aber aus komplexen Problemen, bei denen der Zusammenhang nicht klar erkennbar ist, gehört es zum komplexen System. Komplexe Probleme können nicht mit Werkzeuge für einfache Probleme gelöst werden. Bei einem komplexen System ist die Lösung nicht planbar. Daher wird ein agiles Vorgehen empfohlen.

Agile Manifest

Vor allem bei IT-Projekten wird das agile Vorgehen immer notwendiger um zeitnah auf die vielen Veränderungen reagieren zu können. Was bedeutet agil?

Das Agile Manifest der SW-Entwicklung:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen
  • Reagieren auf Veränderung mehr als das Verfolgen eines Plans

Prozesse, Werkzeuge, Dokumentationen, Vertragsverhandlungen und Pläne sind nach wie vor relevant und auch vorhanden, werden aber auf das Nötigste reduziert.

Agile Principles:

  • Gemeinschaftliche Zusammenarbeit
  • Minimierung von Verschwendung
  • Veränderung akzeptieren
  • Kunden-Engagement
  • Vertrauen

Scrum Values

Scrum Values

Quelle: Skizze von Ari Byland

Mitte der 90er Jahr wurde der Begriff Scrum erstmals verwendet. Es beschreibt eine Vorgehensweise die es ermöglicht komplexe Probleme zu lösen. Scrum ist weder Technik noch Prozess, sondern ein Framework basierend auf der Theorie der empirischen Prozesssteuerung. Die Grundpfeiler dieser Theorie sind: Transparenz, Überprüfung und Anpassung.

Scrum kann nur funktionieren, wenn innerhalb des Scrum Teams die Scrum Werte gelebt werden:

  • Courage
  • Focus
  • Commitment
  • Respect
  • Openess

Die Sprints

Die Sprints bilden das Herzstück von Scrum. Idealerweise sind alle Sprints gleich lang. Die Maximaldauer beträgt 4 Wochen. Am Anfang jedes Sprints steht die Planung und am Ende die Review/ Retroperspektive. Am Schluss jedes Sprints sollte ein releasefähiges Produkt herauskommen („Done“). Der neue Sprint fängt direkt nach Abschluss des vorherigen Sprints an. Ein Sprint setzt sich aus folgenden Elementen zusammen:

  • Sprint Planning
  • Daily Scrums
  • Entwicklungsarbeit
  • Sprint Review
  • Sprint Retroperspektive

6 Fokusthemen des Scrums

  • Scrum Master
  • Product Owner
  • Team
  • Product Backlog
  • Estimation & Planning
  • Retrospective / Review

Scrum Master

  • ist verantwortlich für agilen Prozess und Einhaltung der Scrum Methodik
  • ist Teamcoach, hat keine Linienfunktion und keinen operativen Einfluss
  • ist Kommunikationsschnittstelle zwischen Team und Product Owner
  • unterstützt den PO in der Wahl der passenden agilen Techniken und Tools
  • erklärt den Stakeholdern den Scrum Prozess und die Scrum Rollen
  • schafft Rahmenbedingungen, bspw. stellt er Ressourcen und Inventar zur Verfügung

Product Owner

  • ist verantwortlich für ein erfolgreiches Produkt/Resultat
  • seine Hauptaufgabe ist das Backlog & die Priorisierung der Inhalte
  • sein Ziel: Business Value des Produktes zu maximieren
  • seine Herausforderung liegt in der Schnittstellenverantwortung zw. Stakeholder und Team
  • seine Skills umfassen: Markt, Produkt & U’kenntnisse wie auch Empathie und Entscheidungskompetenz / Übersetzer zwischen Techniker und Auftraggeber
  • ist kein Teamchef, nimmt keine direkte Aufgabenverteilung vor

Team

  • besteht aus 3 bis 9 Personen
  • ist selbstorganisierend; setzt sich interdisziplinär zusammen
  • wählt seine Teammitglieder über Interviews aus
  • zeichnet sich im Kollektiv verantwortlich
  • gibt Zeit und Ressourcen für die Entwicklung vor
  • bestimmen selbst, wie sie das Ziel erreichen

Product Backlog (Backlog Managment)

  • eine priorisierte Liste
  • die Basis bilden Roadmap, Anforderungen sowie User Story (Auftrag)
  • während des Sprints kann sich das Backlog stets ändern
  • Product Backlog wird folgendermassen erfasst: 1. Benutzer, 2. Ziel, 3. Vorteil

Estimation & Planning

  • Stories in Backlog schätzen
  • Schätzung wird in Story Points vorgenommen, nicht in Zeiteinheit (Thema: Fibonacci)
  • Die Ressourcen und Kosten werden anhand der Schätzung planbar
  • Schätzung und Komplexitätsgrad kommen vom Team, indem die Stories dem Team vorgestellt und anschließend gemeinsam geschätzt werden
  • Die Schätzung geht zurück zum Back log bzw. zum PO der dann die Priorisierung vornimmt

Retrospectives

Quelle: Skizze von Ari Byland

Quelle: Skizze von Ari Byland

  • ein Fazit, bei dem 4 Schlüsselfragen beantwortet werden, mit dem Ziel: Verbesserungen im kommenden Sprint
  • Was war gut?
  • Was haben wir gelernt?
  • Was können wir besser machen?
  • Was ist noch ungelöst?
  • Die Retrospektive aus dem letzten Sprint wird im kommenden mit aufgenommen

Review

  • das Team präsentiert das Resultat
  • Stakeholder können das Produkt ansehen und testen
  • das direkte Feedback aus dem Review fließt ins kommende Backlog durch den PO

Der Scrum Guide: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf

Wer sein Wissen zum Thema Scrum testen möchte, kann ein Assessment mit 30 Fragen durchlaufen: https://www.scrum.org/Assessments/Open-Assessments