führen von grossen, agilen projekten mit verteilten teams - planung bis risiko-management

Manage Agile 2013© 2013 - Dr. Michael Amann - @Michael_Amann - www.pro-mind.com

TITEL

DATUM NAME24.10.2013 DR. MICHAEL AMANN�1

FÜHREN VON GROSSEN, AGILEN PROJEKTEN MIT VERTEILTEN TEAMS - PLANUNG BIS RISIKO-MANAGEMENT

http://www.pro-mind.com


Dr. Michael Amann @ ProMind

Agiler Praktiker: Agilist seit 2007, mehrere Jahre Erfahrung als Scrum Master, Product Owner, Product Marketing Owner und Projekt Manager

Coach: Agile Softwareentwicklung auch für große und verteilte Projekte, Prozessmanagement und Prozessautomatisierung, Qualitätsmanagement

Tool-Coach: Unterstützung bei Auswahl, Programmierung, Anpassung und Weiterentwicklung von Continuous Delivery - im Einklang mit dem Prozess

Lehrbeauftragter: Universität Klagenfurt, Fachhochschule Steyr

Entwickler: Java, JavaEE, Webtechnologien, Testautomatisierung, Modellgetriebene Entwicklung

Trainer: Certified Agile Tester, Geshäftsprozessmanagement,Mobile App Development, Quality Management,Continuous Integration, TDD, BDD

�2


SCRUM IST PERFEKT FÜR KLEINE WEBSEITEN… ABER NICHT FÜR “RICHTIGE” PROJEKTE

�3



“RICHTIGE” PROJEKTE ERFORDERN MEHR PLANUNGKONTROLLE, STRUKTUR, PLANUNG

�4



… DA IST VIEL GELD IM SPIELMILLIONEN ÜBER MEHRERE JAHRE

�5



… UND DAMIT EIN HOHES RISIKOGENAU WISSEN, WAS MAN WANN BEKOMMEN WIRD

�6



… DARUM WILL MAN WISSEN, WAS MAN WANN HATPLANUNG STATT RISIKO

�7



… UND DESHALB MÜSSEN WIR GENAU STEUERNUP-FRONT PLANUNG - DAS PROJEKTMANAGEMENT

�8


Manage Agile 2013© 2013 - Dr. Michael Amann - @Michael_Amann - www.pro-mind.com �9

STELLEN SIE SICH VOR ...BEGLEITEN SIE MICH AUF EINE KLEINE REISE IN EIN REALES PROJEKT



… SIE SIND SOFTWAREHERSTELLERMIT IHRER SOFTWARE WERDEN …

�10



… TAUSENDE NEUE & GEBRAUCHTE AUTOS VERKAUFTVERKAUF VON NEU- UND GEBRAUCHTWAGEN

�11



… UNZÄHLIGE WARTUNGEN ABGEWICKELTSERVICES ABWICKELN

�12



… REPARATUREN KOORDINIERTREPARATUREN DURCHFÜHREN

�13



… ERSATZTEILE VERKAUFT UND VERBAUTERSATZTEILE VERKAUFEN

�14



SIE HABEN DIE PROZESSE IM GRIFFVON DER TERMINVEREINBARUNG BIS ZUM FOLLOW-UP

�15



SIE MÜSSEN EINE ENTSCHEIDUNG TREFFENNEUENTWICKLUNG VS. WEITERENTWICKLUNG



NEUENTWICKLUNG VS. WEITERENTWICKLUNGCHANCEN UND RISIKEN

�21



Weiterentwicklung

Etablierte Applikation

Return-on-Investment

Team ist (noch) vorhanden

Geringes Risiko

Wenig Flexibilität

Hohe Aufwände (Fehler)

Langfristig wird das kaum erfolgreich sein

�22

Neuentwicklung

Moderne Applikation

Flexible Architektur

Team ist nicht vorhanden

Webtechnologie

Moderne Programmiersprache

Hohes Potential



WIE ENTSCHEIDEN SIE?WEITERENTWICKELN VS. NEUENTWICKELN

�23

Quelle: http://www.br.de/fernsehen/bayerisches-fernsehen/sendungen/herzblatt/herzblatt110.html


http://www.br.de/fernsehen/bayerisches-fernsehen/sendungen/herzblatt/herzblatt110.html


RISIKOMINIMIERUNG IST DAS ZIELPROJEKT PLANEN UND UMSETZEN

�24



PROJEKTRISIKENWAS KÖNNTE PASSIEREN?

�25



ITERATION ZERORISIKOREDUKTION VON DER ERSTEN MINUTE AN

�26



Iteration Zero - 3 Monate

Steht am Beginn des Projekts

“Warm-up Sprint”

Timeboxed

Ziele und Rahmenbedingungen für das Projekt werden festgelegt

Risiken werden reduziert ...

�27


DAS RICHTIGE PRODUKT RICHTIG ENTWICKLENVISION UND SCOPE DEFINIEREN



Personas identifizieren

Wer sind die User?

Was machen Sie?

Geschäftsprozesse

Wie arbeiten die Anwender, wenn sie kein IT-System zur Verfügung haben?



Systemfunktionen

Welche Funktionen müssen implementiert werden, um die Prozesse ausführen zu können?

Architektur

Wie werden wir die Applikation betreiben? Wer wird sie administrieren? Wer wird sie erweitern?



Eigentlich ganz einfach. Alles, was das alte System kann. !Da wäre noch, wir brauchen unbedingt ...

“

”



Themen identifizieren - Business Sicht

Epics

Grobe Definition der Features

“Business Value” steht im Vordergrund

“Cost of Delay” Einschätzung

Komplexitätsschätzung

�33

Epic

Topic

Story

Spike

Defect

Debt

Task



WANN WERDEN WIR WAS BEKOMMENFORTSCHRITTSKONTROLLE

�34



Komplexität und Kosten schätzen

Durchschnittliche Geschwindigkeit der Teams abschätzen (auf Epic Ebene)

Automatisierte Datenermittlung nach jeder Iteration

Forecast auf Basis der aktuellen Werte

Berechnung der “Kosten pro Komplexität”

Anpassung des Scopes


Entwicklungsfortschritt



Iteration Zero

“Definition of Done” erstellen

Metriken definieren

Qualitätsziele definieren

Teams- und Themenverantwortungen festlegen

Eskalationsteam definieren

Rollen definieren


PLANUNG TOP-DOWN UND BOTTOM-UPWIE SETZTEN WIR DAS UM

�38



Product Manager Domain 1

Team Lead Domain 1

Product Owner Scrum Team D1

Scrum Master Scrum Team D1

Jakob Nina Alexander Elisabeth

Unser Team in diesem Beispiel



PM Backlog (All) PM - Domain 1

PM - Domain 2

PM - Domain 3

Domain 1

Handover

Scrum team 1 Scrum team 2

Scrum team 3

Sprint Backlog

Planing Meeting

Release 2013

Sprint n

Release Plan Kundenprojekte

Bereichspezifische Backlogs

Scrum Team Backlogs

Scrum Team 3

Planungsmeeting

Scrum Team 2

Scrum Team 1

PM Domain 3

PM Domain 2

PM Domain 1

Übergabe



Product Backlog Team Backlog

….

Product Manager Product Owner

….

Scrum Team

Sprint Backlog

….

~8-10h

Implemented in one sprint (two weeks)

Jazz platform

Customer Requirement

User Story

User Story

Task

Task

Task Customer Requirement

Customer Requirements - User Stories - Tasks

User Story

User Story



Customer Requirement

User Story

Analysis Spike

Design Spike

Analysis Task

Dev. Task

Quality Task

Doc. Task



TEAMS UND NEARSHORINGMOTIVATION UND TEAMS IM NEAR-SHORE BEREICH

�43



Es zählt das Team

�44


Teamstrukturen

Standort

Product Management Team

Product Owner

Mehrere Entwicklungsteams

Near-Shore

Mehrere Entwicklungsteams an unterschiedlichen Standorten

�45


In verteilten Near-Shore Teams ...

“Kunde - Lieferanten” Situation

Product Owner nicht am Standort

Management ist weit weg

Wissen ist verteilt und nicht an allen Standorten(“Knowledge Hubs”)

Kostensituation (1 Scrum Master pro Team)

�46


Rolle des Scrum Masters

Prozessexperte im Team

Moderiert Meetings

Identifiziert und löst Impediments

Koordiniert teamübergreifendeThemen

Eskaliert

Beschützt das Team

�47


Motivation in verteilten Teams

Daily Standup Meeting

Umfeld schaffen

Leute involvieren durch Estimation Meetings

Kommunizieren

Visionen vermitteln

Erfolge hochhalten

Impediments lösen

Fortschritt zeigen

Incentives starten

Teamtreffen an den Standorten

�48


FLEXIBLE TOOLSES MUSS ALLES ZUSAMMENPASSEN

�49



Kommunikationsmittel

Video-Conferencing System ist essenziell

Gemeinsame Sprache etablieren

Informelle Kommunikation ermöglichen (zB: Chat)

Telefon ist sehr unbeliebt

�50


Softwareentwicklungsplattform schaffen

Arbeitsmittel müssen funktionieren

Gemeinsamer Build schaffen

Möglichst viele Schritte automatisieren

Testautomatisierung etablieren

Traceability etablieren

�51


Kollaborationsplattform und ALM

Teamübergreifende Backlogs

Impedimentslisten

Projekt- und Produktdokumentation

Metriken und Kennzahlen

�52


WORAN MESSEN WIR DEN FORTSCHRITT?PERMANENTES FEEDBACK

�53



Das Ziel ist es, zum festgelegten Releasetermin das gewünschte Produkt in der geforderten Güte und zu den geplanten Kosten zur Verfügung zu stellen.

“

”



Output statt Stunden schätzen

Stunden beschreiben, was wir bezahlen

Output (Value) zeigt, was wir bekommen

Teams brauchen unterschiedlich lange

Urlaube, Krankenstände etc. wirken auf Stunden, nicht zwingend auf Output

Verhältnis zwischen Stunden und Komplexität wird sich über die Zeit verändern


Customer Requirements by state

Release 1.0



Entwicklungsfortschritt



Teamperformance messen und vergleichen

Vergleichen von relativen Werten und Entwicklungen

Committment Qualität

Veränderung der Team Geschwindigkeit

Veränderung der Defects

Veränderung der “Debt”


Risiko Frühindikatoren

Offene Impediments

Neue Defects

Neue Debt Services

Weitergeschobene Stories pro Sprint (Overcommitment)

�60


TIPPS FÜR VERTEILTE AGILE PROJEKTEVERTEILTE TEAMS FUNKTIONIEREN ANDERS

�61



ZEIGEN SIE PRÄSENZETABLIEREN SIE KOMMUNIKATION, KOLLABORATION UND ESKALATIONSSSTRUKTUREN

�62



INVOLVIEREN SIE ALLE TEAMMITGLIEDERVISIONEN, ZIELE, SCHÄTZUNGEN

�63



KOMMUNIZIEREN SIE LIEBER ZU VIELFORTSCHRITTE, TÄTIGKEITEN, ENTSCHEIDUNGEN DOKUMENTIEREN

�64



REAGIEREN SIE SOFORTGEFÜHL DER VERNACHLÄSSIGUNG VON NEAR-SHORE TEAMS VERMEIDEN

�65



ETABLIEREN SIE TEAMÜBERGREIFENDE MEETINGSSCRUM OF SCRUMS

�66



VERLASSEN SIE DIE KOMFORTZONEPRODUKT NACH AUSSEN GEBEN

�67



FLEXIBLE PROZESSE UND TOOLSTOOLS MÜSSEN MIT DEN PROZESSEN MITWACHSEN

�68



ÜBERBRÜCKEN SIE DISTANZEN MIT TECHNIKVIDEOKONFERENZ, CHAT, TELEFON, ...

�69



LASSEN SIE VERÄNDERUNGEN ZUCHANGE PROZESSE ETABLIEREN

�70



SORGEN SIE FÜR QUALITÄTDEFINITION OF DONE

�71



AUTOMATISIEREN SIE MÖGLICHST VIELESDEPLOYMENT MUSS AUF KNOPFDRUCK GEHEN

�72



FEIERN SIE ERFOLGE MIT ALLEN IM TEAMDAS IST DAS ZIEL

�73



ProMind - Process and Software Engineering Dr. Michael Amann

[email protected]+43 (699) 100 18 214

@Michael_Amann


mailto:[email protected]

führen von grossen, agilen projekten mit verteilten teams - planung bis risiko-management

Technology