Agiles

Projektmanagement zwischen

Verlag und Dienstleister

Buchreport-Webinar, 30.1.2015 / @mkraetke / martin.kraetke@le-tex.de

le-tex

  • Verlagsdienstleister, Standort Leipzig

  • 150 Mitarbeiter (Head Count), 100 (vollzeitäquivalent)

  • agile Entwicklung mit Ruby On Rails, XSLT/XProc

Scrum wurde für Produkte mit internen Teams entwickelt.

Wie überträgt man Scrum auf Verlag und Dienstleister?

Scrum-Rollen

Scrum-Rollen

  • Product Owner

  • Scrum Master

  • Team

Problem

Product Owner und Team können unterschiedliche Interessen und Informationen haben.

Scrum Master

  • moderiert Sprint-Prozess mit Verlag und Dienstleister

  • kann vom Verlag, Dienstleister oder
    auch extern gestellt werden

  • muss seine Rolle möglichst neutral ausüben

Pilot User (Verlag)

  • formal: „Team“ des Product Owners

  • repräsentiert Nutzer des Produktes

  • unterstützt Product Owner z. B. bei User Stories, Backlog Refinement etc.

Manager (Dienstleister)

  • formal: „Product Owner“ des Dienstleisters

  • vermittelt zwischen Product Owner und Team

  • organisiert interne Team Meetings und nimmt
    an Sprint Planning, Review und Retrospektive teil

Verlage haben im Gegensatz zu einem Softwarehersteller typischerweise viele, unterschiedliche Projekte.

Wie lassen sich agile Methoden auf unterschiedlich große Projekte skalieren?

Scrum-Aktivitäten

Kriterien

  • Budget

  • Zeitressourcen

  • Laufzeit

  • Erfahrung mit agilen Projekten

Verlag und Dienstleister müssen eine passende Konfiguration für die Sprints finden.

Beispiel: kleines Projekt

  • Sprintdauer: 2 Wochen

  • kein Daily Call

  • Weekly Call (Sprint Review,
    Retrospektive und Planning)

Beispiel: mittleres Projekt

  • Sprintdauer: 1 Woche

  • Daily Scrum à 5-10 min jeweils mit Verlag und Team

  • Weekly Call (Sprint Planning)

  • Videokonferenz zu Sprint Review und Retrospektive

Wie lässt sich die Kommunikation zwischen Verlag und Dienstleister organisieren?

Scrum-Artefakte

Scrum-Artefakte

  • Product backlog

  • Sprint backlog

  • Product Increment

Product/Sprint backlog

  • es muss alles dokumentiert sein, was Bestandteil eines Sprints werden könnte, also jedes Feature, Erweiterung, Bugfix, Anforderung

  • Aufwände für Umsetzung müssen immer abgeschätzt werden

  • User-Stories sollten allgemein verständlich und ausführlich die Features beschreiben

  • Visualisierung mit Task Board

Product Increment

  • nicht mehr und nicht weniger als die
    fertigen Product-Backlog-Einträge

  • Definition of Done für jedes Feature vereinbaren

Kommunikation

  • so wenig Mail wie möglich, so viel wie nötig

  • Zugriff für alle jederzeit möglich

  • Ticket-Software mit Scrum Plugin (agileMantis, Redmine Agile) oder eigenständige agile PM-Tools (Jira)

  • Wiki, Dokumentation, Versionsverwaltung