Scrum for Management Praxis versus Theorie oder Praxis ... · Scrum ist Projektmanagement? •...

31
Scrum for Management Praxis versus Theorie oder Praxis dank Theorie ALM Day 26.Oktober 2011 Urs Böhm

Transcript of Scrum for Management Praxis versus Theorie oder Praxis ... · Scrum ist Projektmanagement? •...

Scrum for Management

Praxis versus Theorie oder Praxis dank Theorie

ALM Day 26.Oktober 2011

Urs Böhm

Übersicht

• Kurze Situationsübersicht

• Diskussion Prozesse

• Challenges in der SW-Entwicklung

• Wie geht Scrum mit diesen Challenges um?

• Alternativen?

• Diskussion

• Video „Scrum in under 10 Minutes“ (falls Zeit)

Urs Böhm, Oktober 2011

Scrum ist Projektmanagement?

• Erreichen eines Ziels

Beschränkte Ressourcen

On Time

On Budget

• Projektmanagement ist nicht Ressourcenmanagement

Urs Böhm, Oktober 2011

Produktion und Entwicklung

Urs Böhm, Oktober 2011

Do the right things

Speed

Do the things right

Entwicklungsprozesse

Urs Böhm, Oktober 2011

Vergleich

Urs Böhm, Oktober 2011

Wasser-

fall

Death

March

V-Modell Code &

Fix

Scrum

Flexibilität -- -- - ++ ++

Change -- -- - + ++

Planbarkeit ++ --- ++ -- +

Abbruchs-

möglichkeiten

-- - - + ++

Quick and Dirty -- ++ -- ++ --

Umgang mit

formalen

Anforderungen

++ - ++ -- -

Skalierbarkeit ++ -- ++ - Mindestgrösse

Big Design Up Front vs. Agile

Urs Böhm, Oktober 2011

Fehlervermeidung in frühen

Phasen ist günstiger

Starkes Requirement

Engineering

Passende SW-Architektur

und SW-Design

Planbarkeit

Challenges beim Umgang

mit Veränderungen

Analysis Paralysis

Späte Sichtbarkeit

des Ergebnisses

Wann ist eine Software

fertig?

Challenges in der SW-Entwicklung

• Was soll überhaupt entwickelt werden?

• Umgang mit Veränderungen

• Kommunikation und Transparenz

• Schätzungsungenauigkeit

• Entwicklerproduktivität

• Anwachsende Codebasen

• Teamkultur (Team oder Working Group)

Urs Böhm, Oktober 2011

Vertrauen in

Entwicklungsteam Führung von

Knowledge Workern

Innovation

SCRUM Prozess

Urs Böhm, Oktober 2011

Sprint Review Sprint Retrospektive

Burndown Chart

Burndown Chart

Produkt

Backlog

Sprint

Backlog

Potentiell

Lieferbares

Produkt-Inkrement

Scrum Kommunikation

Daily Scrum

Sprint Planning Meeting

Sprint Review Meeting

Sprint Retrospective

Besprechungen sind:

• Klar strukturiert

• Inhaltlich festgelegt

• Timeboxed

• Ergebnis

Scrum basiert auf Rollen

Urs Böhm, Oktober 2011

Produkt Owner

Scrum Master

Entwicklungs-

Team Management

Kunden

User

Entwicklungs-Team:

• Implementiert User Stories

• Garantiert die vereinbarte Qualität

• Entscheidet wie viel im Sprint

entwickelt wird Produkt Owner:

• Auslieferungszeitpunkt

• Funktionalität

• Kosten

• Backlog Verantwortung

• Priorisierte User Stories

Verantwortlichkeiten

Urs Böhm, Oktober 2011

Scrum Master:

• Prozessverantwortung

• Eliminiert Störungen

• Impediments „Probleme“

Projektziel & Kommunikation

Urs Böhm, Oktober 2011

Kommunikation

Transparenz

Reviews

Schätzungen verfeinern sich im Projektablauf

Urs Böhm, Oktober 2011

Iterative

Anpassungen

Planning Poker

Retrospektive

Entwicklerproduktivität

Urs Böhm, Oktober 2011

Entwicklerproduktivität Statistik

Urs Böhm, Oktober 2011

Teamarbeit

Verantwortung

gegenüber Team

Retrospektiven

9:1

3:1

Fokusierung auf Ziel

Urs Böhm, Oktober 2011

Sprints (Iterationen)

Klares Ziel für Team

Moving Target für

Product Owner

Unscharfe Verantwortlichkeiten & Aufgaben

Urs Böhm, Oktober 2011

Klare

Verantwortlichkeiten

Transparenz

Impediment Backlog

Manifest für Agile Softwareentwicklung

Wir erschließen bessere Wege, Software zu entwickeln,

indem wir es selbst tun und anderen dabei helfen.

Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden,

schätzen wir die Werte auf der linken Seite höher ein.

Urs Böhm, Oktober 2011

„Transforming the world of work“

Urs Böhm, Oktober 2011

Agile Alternativen zu Scrum

• Scrum bedingt Änderungen in der Organisation.

Neue Jobbezeichnungen

Neue Verantworlichkeiten

Neue Hierarchien

Transparenz

Neue Stellenbeschreibungen

Iteratives Vorgehen bei Planung & Entwicklung

• Scrum einzuführen bedeutet eine Revolution

Urs Böhm, Oktober 2011

Scrum muss von

„Oben“ eingeführt

werden!

Kanban startet mit dem bestehenden

Prozess. Es vermeidet zu viel Change in der

sozialen Hierarchie.

Kanban ermöglicht einen „Stealth“ Ansatz.

Kanban ist ein evolutionärer Ansatz.

Scrum ist ein revolutionärer Ansatz

Was sagen andere zu Scrum?

Urs Böhm, Oktober 2011

Links

• „Scrum in under 10 minutes“ (Youtube)

• http://www.scrumalliance.org/http://www.scrum.org/

• „State of Agile Development“ survey

• http://www.dasscrumteam.com

• Wikipedia

• http://www.noser.com

Urs Böhm, Oktober 2011

NOSER ENGINEERING AG

Talackerstrasse 99

CH-8404 Winterthur

+41 52 234 56 48 direct

+41 52 234 56 11 phone

[email protected]

www.noser.com

Software

Craftmanship

Urs Böhm, Oktober 2011

Inkrementelles Vorgehen

Urs Böhm, Oktober 2011

Plan Do

Check Act

Zu

entwickelnde

Software

Iteratives Vorgehen „Divide Et Impera“

Urs Böhm, Oktober 2011

Iteration 2

Iteration 1

Iteration 3

Iteration 4

Iteration 2

Iteration 1

Iteration 3

Iteration 4

Klassische Projekt Überwachung

Urs Böhm, Oktober 2011

Kanban Board

Urs Böhm, Oktober 2011

Brücken Analogie

Urs Böhm, Oktober 2011

Das Problem?

Billiger

Termingerechter

Budgetierter

Besser

Und gleichzeitig offen für Veränderungen sein