Veröffentlicht am

DoR mittels INVEST

In diesem Artikel https://agile-pm.de/2019/02/20/defintion-of-ready-und-definition-of-done/ wurde die Defintion of Ready vorgestellt. Die Defintion of Ready (DoR) stellt eine Art Einlasskontrolle für Product Backlog Items dar. Erst wenn die Kriterien erfüllt sind, kann ein Product Backlog Item für das Sprint Backlog verwendet werden. Mit Hilfe des Akronyms INVEST lassen sich die Kriterien an eine User Story in Kategorien erfassen.

Independent

Der Vorteil unabhängiger User Stories ist, dass User Stories frei priorisiert und im Zweifel sogar aus dem Product Backlog heraus genommen werden können, ohne das übrige Product Backlog groß zu beeinflussen.

Negotiable

User Stories sollten aussagekräftig mit den notwendigen Details beschrieben werden. Allerdings sollten User Stories keine Lösungen vorgeben und noch Raum für Diskussionen zwischen Scrum Developer und Kunde lassen.

Valuable

Eine User User stellt für sich einen Wert dar. Wird die User User Story umgesetzt, so wird eine Wertsteigerung im zu entwickelnden Produkt erzielt.

Estimatable

Nur wenn eine User Story durch das Scrum Developer Team geschätzt worden ist, kann es in das Spirnt Backlog aufgenommen werden.

Sized appropiately

Eine User Story sollte genau so groß sein, dass sie im Rahmen eines Sprints umgesetzt werden kann.

Testable

Jede User User Story sollte für sich testbar sein. Dazu werden Acceptence Criteria / Akzeptanzkriterien definiert, die durch die Scrum Developer und dem Product Owner auf ihre Einhaltung hin überprüft werden.

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.