Führen von grossen, agilen Projekten mit verteilten Teams - Planung bis Risiko-Management

DATUM NAME24.10.2013 DR. MICHAEL AMANN�1

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

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

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

“RICHTIGE” PROJEKTE ERFORDERN MEHR PLANUNGKONTROLLE, STRUKTUR, PLANUNG

… DA IST VIEL GELD IM SPIELMILLIONEN ÜBER MEHRERE JAHRE

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

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

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

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

… SIE SIND SOFTWAREHERSTELLERMIT IHRER SOFTWARE WERDEN …

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

… UNZÄHLIGE WARTUNGEN ABGEWICKELTSERVICES ABWICKELN

… REPARATUREN KOORDINIERTREPARATUREN DURCHFÜHREN

… ERSATZTEILE VERKAUFT UND VERBAUTERSATZTEILE VERKAUFEN

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

SIE MÜSSEN EINE ENTSCHEIDUNG TREFFENNEUENTWICKLUNG VS. WEITERENTWICKLUNG

NEUENTWICKLUNG VS. WEITERENTWICKLUNGCHANCEN UND RISIKEN

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

Neuentwicklung

Moderne Applikation

Flexible Architektur

Team ist nicht vorhanden

Webtechnologie

Moderne Programmiersprache

Hohes Potential

WIE ENTSCHEIDEN SIE?WEITERENTWICKELN VS. NEUENTWICKELN

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

RISIKOMINIMIERUNG IST DAS ZIELPROJEKT PLANEN UND UMSETZEN

PROJEKTRISIKENWAS KÖNNTE PASSIEREN?

ITERATION ZERORISIKOREDUKTION VON DER ERSTEN MINUTE AN

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 ...

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

Grobe Definition der Features

“Business Value” steht im Vordergrund

“Cost of Delay” Einschätzung

Komplexitätsschätzung

Defect

WANN WERDEN WIR WAS BEKOMMENFORTSCHRITTSKONTROLLE

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

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

Task Customer Requirement

Customer Requirements - User Stories - Tasks

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

Es zählt das Team

Teamstrukturen

Standort

Product Management Team

Product Owner

Mehrere Entwicklungsteams

Near-Shore

Mehrere Entwicklungsteams an unterschiedlichen Standorten

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)

Rolle des Scrum Masters

Prozessexperte im Team

Moderiert Meetings

Identifiziert und löst Impediments

Koordiniert teamübergreifendeThemen

Eskaliert

Beschützt das Team

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

FLEXIBLE TOOLSES MUSS ALLES ZUSAMMENPASSEN

Kommunikationsmittel

Video-Conferencing System ist essenziell

Gemeinsame Sprache etablieren

Informelle Kommunikation ermöglichen (zB: Chat)

Telefon ist sehr unbeliebt

Softwareentwicklungsplattform schaffen

Arbeitsmittel müssen funktionieren

Gemeinsamer Build schaffen

Möglichst viele Schritte automatisieren

Testautomatisierung etablieren

Traceability etablieren

Kollaborationsplattform und ALM

Teamübergreifende Backlogs

Impedimentslisten

Projekt- und Produktdokumentation

Metriken und Kennzahlen

WORAN MESSEN WIR DEN FORTSCHRITT?PERMANENTES FEEDBACK

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)

TIPPS FÜR VERTEILTE AGILE PROJEKTEVERTEILTE TEAMS FUNKTIONIEREN ANDERS

ZEIGEN SIE PRÄSENZETABLIEREN SIE KOMMUNIKATION, KOLLABORATION UND ESKALATIONSSSTRUKTUREN

INVOLVIEREN SIE ALLE TEAMMITGLIEDERVISIONEN, ZIELE, SCHÄTZUNGEN

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

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

ETABLIEREN SIE TEAMÜBERGREIFENDE MEETINGSSCRUM OF SCRUMS

VERLASSEN SIE DIE KOMFORTZONEPRODUKT NACH AUSSEN GEBEN

FLEXIBLE PROZESSE UND TOOLSTOOLS MÜSSEN MIT DEN PROZESSEN MITWACHSEN

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

LASSEN SIE VERÄNDERUNGEN ZUCHANGE PROZESSE ETABLIEREN

SORGEN SIE FÜR QUALITÄTDEFINITION OF DONE

AUTOMATISIEREN SIE MÖGLICHST VIELESDEPLOYMENT MUSS AUF KNOPFDRUCK GEHEN

FEIERN SIE ERFOLGE MIT ALLEN IM TEAMDAS IST DAS ZIEL

ProMind - Process and Software Engineering Dr. Michael Amann

michael.amann@pro-mind.com+43 (699) 100 18 214

@Michael_Amann

Führen von grossen, agilen Projekten mit verteilten Teams - Planung bis Risiko-Management

Technology

Transcript of Führen von grossen, agilen Projekten mit verteilten Teams - Planung bis Risiko-Management

Umsetzung einer verteilten Anwendung mit der dokumentenorientierten Datenbank CouchDB

Efﬁziente Diagnose von verteilten Funktionen automobiler ...

7 Sünden im agilen Umfeld

Ein Framework zur verteilten Produktion von ...

Lastmessung und -verteilung in heterogenen, verteilten ...

Hydrologie - ethz.ch · Diese Methode gewährleistet für Netze mit gleichmässig verteilten Stationen, die kei-ne sehr grossen Höhenunterschiede aufweisen, in den meisten Anwendungsfällen

Ketzerischer Vortrag zur Agilen Entwicklung

Vom agilen Team zur agilen Organisation - in drei Jahren

Modellierung eines verteilten Algorithmus

Herausforderungen für das Qualitätsmanagement im agilen Umfeldaqigmbh.de/...HerausforderungenQMagilesUmfeld.pdf · Herausforderungen für das Qualitätsmanagement im agilen Umfeld

Mit Enterprise Scrum zur agilen Organisation

Kooperativ verteiltes Data Warehouse - MADOC · Abbildung 30: Datenflüsse in einem verteilten Ansatz mit globalem DW.....144 Abbildung 31: Alternativen zum Aufbau eines verteilten

BGM und Agilität - gesundheitbb.de · Systematik des agilen Projektmanagements ..... 1. Agile Methoden geben den agilen Techniken eine Gesamtstruktur 2.

Verifikation eines zertifizierenden verteilten Algorithmus

x Public Sicherheit in verteilten Systemen mit Java und SAML Karlsruher Entwicklertag 2012 Sicherheit in verteilten Systemen mit Java und SAML Jürgen.

Kommunikation und Zusammenarbeit in verteilten Projektteams

Scrum-it! - Adaptierte Methoden für den agilen Projektvertrieb · Scrum-it! - Adaptierte Methoden für den agilen Projektvertrieb ... • Rollen und Rituale im agilen Vertrieb •

UX in der agilen Produktplanung

Das kleine Einmaleins des agilen Produktmanagements

Mit agilen Praktiken SOLIDe Systeme bauen