Veröffentlicht am

Was ist SCRUM nicht?

SCRUM ist kein Selbstläufer. Auch keine Management-Methode, um Micro-Management durchzuführen. Im Nachfolgenden eine Auflistung der Meetings in SCRUM und was nicht deren Bedeutung ist.

Sprint Planning

Das Sprint Planning wird nicht eingesetzt, um dem Team den vorbereiteten Projektplan zu präsentieren oder im Meeting einen Projektplan zu erarbeiten. Auch wird es nicht dafür eingesetzt, dass viele Tickets für die Team-Mitglieder erstellt werden. Der Product Owner weist Tickets Team-Mitgliedern zu, ohne deren Einstimmung zu holen.

Daily

Hier geht es nicht um ein Status-Report gegenüber dem Management oder dem Product Owner. Desweiteren wird es auch nicht nur bei Bedarf ausgeführt oder nicht täglich (sonst hieße es ja auch nicht Daily ;-)).

Estimation Meeting

Hierbei handelt es sich nicht um eine Vorbereitung des nächsten Sprints. Auch werden nicht ausschließlich neue Tickets erstellt.

Und was ist SCRUM nun?

SCRUM ist ein Verfahren für die Produkt- und Projektentwicklung. Es basiert auf einem festen Satz an Regeln und Vorgaben und beinhaltet die drei Rollen Scrum Master, Product Owner und Scrum Developer.

Die SCRUM-Meetings sind hier beschrieben: https://agile-pm.de/2015/07/31/meetings-im-scrum-prozess/

Die Rollen finden Sie hier: https://agile-pm.de/2015/07/31/rollen-in-scrum/

Veröffentlicht am

Agile IT-Führungskraft

Was macht eine gute agile Führungskraft aus? Welche Werte soll sie vermitteln und welchen Mindset besitzen?

Die nachfolgende Auflistung erhebt keinen Anspruch auf Vollständigkeit. Auch sind die Stärken einer agilen IT-Führungskraft nicht wissenschaftlich belegt, sondern beruhen auf einer subjektiven Wahrnehmung.

Eine gute agile IT-Führungskraft…

  • …stellt eine Vision bereit, an der sich die Mitarbeiter orientieren können.
  • …gibt messbare und klare Ziele vor.
  • … begleitet die Mitarbeiter auf deren Weg zur Zielerreichung.
  • …akzeptiert „bessere“ Lösungen und sieht seine Mitarbeiter als die wahren Experten an.
  • …führt nach der „wie-kann-ich-euch-dienen“-Mentalität anstatt „ihr-macht-was-ich-sage“ (Servant Leadership).

Wichtige Eigenschaften einer agilen Führungskraft

  • Hat eine Produkt-/Projekt-Vision.
  • Setzt klare Zielvorgaben und definiert Verantwortlichkeiten.
  • Fällt transparente Entscheidungen.
  • Bindet Mitarbeiter in Entscheidungsprozess mit ein.
  • Führt regelmäßige Retrospektiven durch und überprüft auch sein eigenes Handeln.
  • Fordert und fördert eine offene Feedback-Kultur.
  • Scheut sich nicht davor zurück Lob auszusprechen.
  • Gesteht sich selbst Fehler ein,
  • gesteht auch seinen Mitarbeitern Fehlern zu und
  • nimmt Fehler als Chance zur Optimierung wahr.
  • Verlässt sich auf seine Mitarbeiter und fördert die Selbstorganisation.
  • Hat eine wertschätzende Haltung.

Obligatorische Eigenschaften

  • pünktlich
  • zuverlässig
  • hält sich an eigenes Commitment
  • ehrlich
  • offen
  • hört Mitarbeitern zu

Agile Führungskraft fördert eine agile Arbeitsweise

  • Die Mitarbeiter arbeiten nach dem Pull- und nicht dem Push-Prinzip.
  • Die Aufgabenplanung erfolgt gemeinsam (z.B. in Rahmen von Sprint Plannings).
  • Es werden regelmäßige Retrospektiven durchgeführt, um den kompletten Ablauf zu optimieren.

Weitere Merkmale/Eigenschaften?

Fehlen in der Auflistung noch wichtige Merkmale oder Eigenschaften? Bitte fügt diese über die Kommentarfunktion hinzu.

Veröffentlicht am

Agile Organisationsentwicklung

Die agile Organisationsentwicklung befasst sich nicht ausschließlich auf die Einführung agiler Prozesse in der Produktentwicklung oder einem Projekt. Die agile Organistionsentwicklung geht darüber hinaus und betrachtet das komplette unternehmerische System mit seinen Abhängigkeiten. Die Organisation wird dabei nach agilen Werten hin aufgestellt und eine stetige Optimierung der Prozesse und ein kontinuierliches Lernen wird angestrebt. Im Zuge der Einführung einer agilen Organisationsstruktur werden die Prioritäten auf eine offene Kommunikation, flache Hierarchien und schnellen Feedback-Runden gelegt.

Agile Organisationsentwicklung nach DMAIC-Zyklus

In der agilen Organisationsentwicklung setzen wir auf den DMAIC-Zyklus, um mit dem Kunden zusammen die neue Wunsch-Organisation heraus zu arbeiten. Dabei konzentrieren wir uns auf die im jeweiligen Unternehmen zur Verfügung stehenden Kräften und richten unser Vorgehen an die Bedürfnisse des Unternehmens aus.

Niemand kennt das Unternehmen so gut wie die einzelnen Mitarbeiter. Daher sind sie für uns ein entscheidender Faktor bei der Aufnahme der IST-Zustände und dem Herausarbeiten einer geeigneten Optimierung der Prozesse und der Organisation.

Externer Berater bietet Mehrwert in unterschiedlichen Ebenen

Durch uns als externe Berater bieten wir den Mitarbeitern in den Unternehmen eine neutrale Stelle, um Ideen aber auch Frust einbringen zu können. Die externe Beratung hat zudem den Vorteil, dass bei der agilen Organisationsentwicklung zwar die Bedürfnisse des Unternehmens und die einzelnen Mitarbeiter berücksichtigt werden, doch zugleich Lessons Learned und Best Practices aus anderen Unternehmen und Branchen mit eingebracht werden.

Roadmap agile Organisationsentwicklung

  1. Auftragsklärung (Project Inception)
  2. Datenerhebung (ggf. Interviews, Workshops, Teilnahme an Meetings)
  3. Zusammenfassung von Beobachtungen, Analyse der IST-Struktur, aufstellen von Hypothesen
  4. Ausarbeitung der Ziele und Wunsch-Organisation
  5. ggf. Konzeption von Schulungen und Workshops
  6. Durchführung von Workshops und Begleitung von Änderungsmaßnahmen
  7. Evaluierung der umgesetzten Maßnahmen und erreichten Ziele, Prüfung des Projekts und Auswertung der umgesetzten Maßnahmen
  8. Durchführung von Audits

DMAIC-Zyklus

DEFINE
Auftragsklärung mit Hilfe eines Project Inceptions:

  • In Scope / Out Of Scope
  • Projektbeteiligte
  • Projektziele

MEASURE
Evaluierung des IST-Stands durch:

  • Interviews
  • Workshops
  • Teilnahme an Meetings

ANALYSE
Zusammenfassung von Beobachtungen, Analyse der IST-Struktur und aufstellen von Arbeitshypothesen.

IMPROVE

  • Ausarbeitung der Ziele und der Wunsch-Organisation. Aufstellen eines Projektplans. Konzeption von Workshops zur Umsetzung der Wunsch-Organisation.
  • Konzeption von Workshops zur Umsetzung der Wunsch-Organisation.
  • Begleitende Beratung zur Umsetzung des Projektplans.

CONTROL

  • Evaluierung der umgesetzten Maßnahmen und erreichten Ziele, Prüfung des Projekts und Auswertung der umgesetzten Maßnahmen.
  • Regelmäßige Überprüfung des IST-Standes und Abgleich mit gewünschter Organisation. Evaluierung von Optimierungspotential.

Benötigen Sie Unterstützung zur Einführung von agilen Prozessen? Oder möchten Sie eine Analyse Ihrer aktuellen Struktur durchführen?

Vereinbaren Sie einen Termin zur kostenlosen Beratung!

Kostenlosen Beratungstermin
Veröffentlicht am

Estimation Meeting als Sprint-Vorbereitung

Das Estimation Meeting wird ein- oder zweimal pro Sprint durchgeführt. Bei dem Meeting kommt das Scrum Development Team mit dem Product Owner zusammen, um User Stories zu besprechen. Bei dem Meeting geht es weniger um eine Aufwandsschätzung mit Story Points, als vielmehr eine Grundlage für zukünftige Sprints zu legen.

Unklarheiten beseitigen

Der Product Owner wird in diesem Meeting User Stories präsentieren, die mit dem Scrum Development Team zusammen diskutiert werden. Das Team fragt Fragen und der Product Owner wird die User Story verbessern, in dem er alle Fragen beantwortet und die Ergebnisse in der User Story notiert. Ggf. wird das Team feststellen, dass eine User Story zu komplex für einen Sprint ist. In dem Fall wird es zusammen mit dem Product Owner die User Story in mehrere kleinere User Stories herunter brechen.

Schätzungen anpassen

Von Zeit zu Zeit wird der Product Owner nicht nur neue User Stories mit dem Team besprechen, sondern bereits bekannte User Stories erneut diskutieren. Gründe hierfür können neue Erkenntnisse mit Auswirkungen auf die Aufwandsschätzung sein, oder auch der Aufbau von Erfahrungen im Team. Durch das wiederholte Betrachten der User Stories werden die Schätzungen im Product Backlog kontinuierlich optimiert, was zu einer besseren Vorhersagbarkeit bei der Roadmap-Gestaltung führt.

Vorbereitung auf das Sprint Planning

In der Anfangsphase eines neuen Projekts wird der Fokus auf der Planung des nächsten Sprint Plannings liegen. Product Owner und Team besprechen dann bereits bekannte User Stories, bei denen die Rückfragen bereits geklärt sind. Dadurch kann die benötigte Zeit im Sprint Planning 1 reduziert werden. Das Sprint Planning wiederum kann sich dann darauf konzentrieren zu ermitteln, welche User Stories im nächsten Sprint umgesetzt werden können, anstatt zusätzlich noch die Inhalte zu diskutieren.

Voraussetzung für eine Roadmap

Im weiteren Projektverlauf wird der Product Owner auch User Stories diskutieren, die erst in der Zukunft relevant sein werden; vielleicht im übernächsten Sprint, nächsten Monat oder auch in drei Monaten. Wenn zusätzlich die User Stories auch geschätzt werden (z.B. mit Hilfe von Story Points) und die Velocity bekannt ist, dann hat der Product Owner alles zur Hand, um daraus eine Roadmap zu generieren.

Veröffentlicht am

Defintion of Ready und Definition of Done

Die Defition of Done (DoD), oder auch Level of Done (LoD) genannt, bestimmt wann eine User Story als done bezeichnet werden darf. Die Definition of Ready (DoR) bestimmt, ob ein Product Backlog Item ausreichend beschrieben ist, um es in ein Sprint Backlog aufzunehmen. Beide Definitionen haben zum Ziel die Story-Qualität zu erhöhen um damit ein besseres Produkt-Ergebnis zu erzielen.

Interne und externe Anforderungen


Die Definition of Done beinhaltet dabei sowohl Punkte aus der Organisation heraus als auch teamspezifische Anforderungen.

Aus der Organisation kann zum Beispiel die Anforderung entstehen, dass Code Reviews zwingend erforderlich sind. Als Anforderung aus dem Team könnte zum Beispiel der Push in den Master Git-Branch als Anforderung definiert werden.

Diese Anforderungen gelten global für alle Product Backlog Items des Teams.

DoD: ein Team-Angelegenheit

Im Verlauf des Sprints werden die einzelnen Punkte des DoD abgehakt, bis alle berücksichtigt worden sind. Das Scrum Development Team ist zuständig für die Einhaltung des DoD.

Hat das Team die Story verstanden?

Anders als das DoD beinhaltet die Definition of Ready Kriterien an Product Backlog Items. Erst wenn diese Kriterien erfüllt sind, kann eine User Story in den aktuellen Sprint des Teams übernommen werden.

Die DoR stellt dabei allerdings keine Einlasskontrolle für das Sprint Planning 1 dar, sondern auch im Rahmen des SP1 kann die DoR erfüllt werden.

Product Owner füllt DoR aus

Der Product Owner ist zuständig für die Erfüllung des DoR und sorgt somit für die Qualität der Product Backlog Items. Inhalte eines DoR können zum Beispiel sein:

  • Die User Story ist formal beschrieben
  • Acceptance Criteria wurden definiert
  • Der Umfang der User Story ist klein genug, so dass sie in einem Sprint umgesetzt werden kann
  • Die User Story wurde geschätzt