Vortrag der OOP 2013 von Dr. Thorsten Janning, KEGON AG.

1. KEGON AG
Wie man 100 agile Teams führt –
Herausforderungen an Anforderungs-,
Architektur- und Personalmanagement
OOP 2013
Der Weg ist das Ziel 3
Juli 2000
Fundstücke Holzeisenbahn Motor (10u/min)
KEGON AG 2013

2. Aber es gibt praktische Fragen bei der Einführung….Agilität ist hipp
• Mehrere Teams in einer agilen Organisation
• Koordination von Anforderungen für mehrere Teams
• Gibt es agile Releases?
• Architektur in einer agilen Organisation
• Agile Organisation und mittleres Management
KEGON AG 2013 Seite 2

3. Wie schneide ich Teams?
Variante 1: Feature-Teams
A
B
Team 1 Team 2
E
Team 3
Plattform C D F
KEGON AG 2013 Seite 3

4. Wie schneide ich Teams?
Variante 2: Komponenten-Teams
A
Team 2 Team 3
B E
Plattform C Team 1 D F
KEGON AG 2013 Seite 4

5. Was ist agiles Anforderungsmanagement?
Anforderungsmanagement ist eine Managementaufgabe, um
effektiv und effizient komplexe (IT-)Systeme umzusetzen…
„Der Umfang, die Qualität und somit der Markt- und Mehrwert
des Gesamtsystems werden hierdurch determiniert“
Agilität bietet hierbei den Rahmen mit dem gewissen Unterschied:
Durch ein inkrementelles (schrittweise) und iteratives (sich
wiederholend) Vorgehen…
 …mit transparenten Zielen,
 …in enger Kooperation mit allen Stakeholdern,
 …selbstorganisierend und eigenverantwortlich,
 …mit maximalem Durchsatz (ohne Verzögerung & oft)…
…werden Geschäftswert fähige Anforderungen
in den Entwicklungsprozess geliefert.
KEGON AG 2013 Seite 5

6. Zielsetzung von agilem Anforderungsmanagement
 Effektive Auswahl von Produkten oder Features
 Optimaler Durchfluss durch die Prozesse
 Geschäftsentwicklung
 Vertrieb
 Produktmanagement
 Releaseplanung
 Planbarkeit und Reaktionsschnelligkeit am Markt in Einklang
bringen
KEGON AG 2013 Seite 6

7. versteht den Prozess…..
…in Anlehnung an „Scaled Agile Framework™“
Laufende Priorisierung, Analyse,
Detaillierung und Umsetzung.
KEGON AG 2013 Seite 7

8. Laufende Priorisierung, Analyse,
Detaillierung und Umsetzung.
KEGON AG 2013
Das Richtige tun……..
Seite 8

9. „Exzellente“ Anforderungen liefern……… heißt
Wir unterscheiden Anforderungen in 3 Ebenen in unterschiedlichen
Detaillierungsgraden:
1) Anforderungseingang und –entwicklung durch
Management von Portfolio-Backlogs mit Kanban:
Portfolio-Backlog
KANBAN
Programm-Backlog
 Quality Gates erhöhen die Effektivität (das Richtige)
 WIP-Limits forcieren durch Abstimmung und
Priorisierung die Effizienz (zur richtigen Zeit)
KEGON AG 2013 Seite 9

10. Hauptmotivation: Vermeiden von Verschwendung
Software
Nicht “Fertige” Software/Produkte
Unnötige Features
Wissensverlust
Verzettelung
Multitasking
Verzögerungen
Fehler
Mit Abstand die größte
Verschwendung sind
unnötige Features
KEGON AG 2013 Seite 10

11. „Exzellente“ Releases liefern….. heißt
Portfolio-Backlog
2) Releases generieren als Featurebündel im Programm-
Backlog:
KANBAN
 Features priorisieren und Aufwandsschätzung detaillieren
(maximaler Geschäftswert, ROI, weitere Determinanten)
Programm-Backlog
 Release Planung: Synchronisation aller
RELEASE PLANUNG
Stakeholder und Detaillierung von priorisierten
Features zu User-Stories durch das Umsetzungsteam
zur Konkretisierung des anstehenden Releases.
Team-Backlog
KEGON AG 2013 Seite 11

12. Laufende Priorisierung, Analyse,
Detaillierung und Umsetzung.
KEGON AG 2013
….es richtig tun
Seite 12

13. Systematisches Refactoring nach Wertbeitrag
Der Wertbeitrag der Komponenten ist wesentlicher Parameter bei der
qualitativen und quantitativen Bewertung von Refactoring-Maßnahmen. Den
Wertbeitrag kann man aus einer Kaskade von Architekturzielen ableiten.
Standardisierung von Komponenten (z.B.
Standardisierung
Plattformen, Middleware, ...); im Idealfall
Verwendung von Commodity
Wiederverwendbarkeit Möglichkeit der Nutzung von Services in
unterschied-lichen System-Kontexten (Fokus auf
Service)
Durchdringung der Anwendungs-Landschaft durch
Reichweite einen Service (Fokus auf Service-Landschaft)
Effizienz der Nutzung und Wiederverwendung von
Wirtschaftlichkeit Services (Fokus Service-Landschaft und IT-Org./-
Prozesse)
Monetärer Nutzen durch Wiederverwendung von
Wertschöpfung Services (Fokus IT-Org./-Prozesse)
Geschäftliche bzw. betriebswirtschaftliche
Business Value Bedeutung der Services
(Fachlichkeit/Wirtschaftlichkeit)
KEGON AG 2013 Seite 13

14. Realisierung in vielen Teams
Iterationen durchführen als Summe von User Stories im
Epics
Team- Backlog:
 Priorisierung von User Stories wie bei den Features.
 Schätzung von User Stories in Story Points.
 Sprint Planung: Identifizierung des Iterations-
umfangs und durch Detaillierung von User Stories in
Tasks (kleinste Arbeitseinheit).
 Die Team-Velocity bestimmen: Durchschnittliche Story
Points, die ein Team in Sprints liefert.
 User Stories können beliebig weiter detailliert werden,
hierdurch erhält man Tasks auf Stundenebene.
KEGON AG 2013 Seite 14

15. Testaktivitäten in die Spezifikationsphase ziehen
Neben der fachlichen Beschreibung der User
Geschäftsprozesse
Features
Stories in Geschäftsprozessen das Testszenario
als Spezifikation etablieren (vgl. hierzu TDD).
Geschäftseinheiten
Das Livesystem besteht aus User Stories,
welche Features (Funktionalitäten) formen,
die wiederum die Geschäftseinheiten abbilden.
Durch Formulierung von Testszenarios als
Spezifikation wird die Detailspezifikation vereinfacht.
Per Definition kann eine User Story nur dann erfolgreich
abgenommen und integriert werden,
wenn die System-, Akzeptanz- und
Unittests erfolgreich waren.
KEGON AG 2013 Seite 15

16. Realistische Planung und bessere Prozesskontrolle
Standardisierter Rahmen für die Planung und
Fortschrittskontrolle:
• Durch iterative Koordination ständig aktuelle
Informationen auf allen Ebenen verfügbar.
• Standardisierte Metriken geben jederzeit
Aufschluss über den aktuellen Stand einzelner
Anforderungen, Projekte, Releases und Budgets.
• Zuordnungen von Mitarbeitern und Aufgaben
geschieht auf Basis der Erfahrungen in den
Teams und Hochrechnungen aus den Messungen
der Vergangenheit.
 Verringerung von zukünftigen Risiken auf allen Ebenen
durch ständigen Lern- und Verbesserungsprozess.
 Jederzeit (auch nach der Entwicklung) Nachvollziehbarkeit
auf Anforderungsebene durch den zentralen
Dokumentationsprozess (z.B. Wiki).
KEGON AG 2032 Seite 16

17. Zusammenfassung agile Prozesse
 Alle Aktivitäten orientieren sich an strategischen
Themen und forcieren die daraus abgeleiteten
Kommunikation der Stakeholder
Anforderungen (auch auf Teamebene wie Bugs, Spikes,
Laufender Input durch iterative
Refactors, etc…)
 Transparentes Arbeiten am Agilen Board (oder
Online Tools wie Gira/Grasshopper, etc…). Jederzeit
klare und schnelle Antworten darüber, warum und an
was weiterbearbeitet wird und wann geliefert wird.
 Rollen sind je nach zu definierender Zielstruktur
skalierbar.
 Systemparameter sind individuell einstellbar:
Release und Iterationszyklen und Zeitrahmen für die
Planungen.
 Steigerung der Reaktionszeit und Realisierung von
minimalen Kosten bei Veränderungen/
unvorgesehenen Situationen.
KEGON AG 2013 Seite 17

18. Mittelfristig notwendig: Die agile Organisation
• Grundlage: Verlassen der klassischen Linienorganisation
• Stärken der Entscheidungskompetenz der Teams
• Führung durch persönliche oder fachliche Autorität
• Klärung von Personalentwicklung
• Definition von Karrierepfaden und Bezahlmodellen auf
Basis von Fach- und Sozialkompetenzen
KEGON AG 2013 Seite 18

19. Querschnittsfunktionen in einer agilen Organisation
Architektur-Board
Team 1
Qualitäts-Board
Release-Board
Produkt-Board
Team 2
………..
Jetzt beginnt die
Agile
Team n
Wirklichkeit
• Querschnittsfunktionen werden matrix-artig zu der Teamstruktur
aufgesetzt
• Den Architekten bestimmt das Team, nicht das Management
• Die passenden Qualitätsmaßnahmen schlägt das Board vor,
bestimmt aber das Team
• ….
KEGON AG 2013 Seite 19

20. Veränderung von Führungsverständnis?
Nach Günther Dueck:
Neurotic Leadership
Die Realität gerade im mittleren Management steht einer agilen
Organisation in der Regel im Weg!
Schafft man es, Neurotiker zu konstruktiven Team-Mitgliedern zu
machen oder sind sie anderenfalls nur hinderlich?
Wenn man die harte Tour wählt, darf man nicht auf halber Strecke
Halt machen!
KEGON AG 2013 Seite 20

21. Management-Theorie: Duale Prozess-Betrachtung
Überraschung, Prinzip
Person,
dynamisch Entscheidung, Verantwortung
Wiederholung, Regel
strukturiert Skillprofil
Automatisierung Quelle:
Dr. Gerhard Wohland
Matthias Wiemeyer
Denkwerkzeuge
Problem für dynamische
(z.B. Kunden- Märkte
Anforderung) Verlagshaus Monsenstein und
Vannerdat OHG Münster
www.mv-wissenschaft.com
Jeder Arbeitsprozess wird durch ein Problem angestoßen und durch
seine Lösung beendet.
Bei trägen Problemen wird der Prozess fast ausschließlich durch
Ereignisse getriggert, die sich wiederholen. Der Anteil
überraschender Probleme ist gering.
Die Prozessbeschreibung kann sich auf die Struktur beschränken.
KEGON AG 2013 Seite 21

22. Software-Entwicklung als dynamisches Problem
Überraschung
Prinzip
Person Dynamischer Teil
Entscheidung
Verantwortung
Wiederholung
1 2 3 4 Regel
Strukturierter Teil
Skillprofil
Automatisierung
Bei dynamischen Problemen wird der Prozess vor allem durch
überraschende Ereignisse getriggert.
Die Behandlung einer Überraschung erfordert Ideen auf der Basis
von Prinzipien.
Nur motivierte und qualifizierte Menschen können mit
Überraschungen sinnvoll umgehen.
KEGON AG 2013 Seite 22

23. Agile Steuerung der Organisation durch Marktelemente
Beispielhaftes Problem:
Erweiterungen und Pflege von Frameworks gefährden die
Wirtschaftlichkeit von Systemen
Schwergewichtige Architekturentscheidungen im Laufe des Projekts
erhöhen die Kosten „unberechenbar“
Indizien:
Kostenexplosion bei Basiskomponenten betroffener Produkte
Maßnahmen:
Agile Organisation von kleinen eigenständigen Produkteinheiten
Möglicher Nutzen:
Wirtschaftliche Verwendung von Basiskomponenten
Agile und Markt-getriebene Steuerung von Architekturentscheidungen
KEGON AG 2013 Seite 23

24. Die Zukunft: Unternehmer im Unternehmen……
IT-Gesamtverantwortlicher
Fördert Standardisierung
Fordert Wirtschaftlichkeit
Beauftragt Anwendung
Kunde (Fachbereich) Setzt
Basiskomponente
ein
Business Komponente
Verantwortlicher
Basiskomponente
KEGON AG 2013 Seite 24

25. Kontakt
Noch Fragen offen?
Schauen Sie doch mal ins Web unter www.kegon.de
Oder fragen Sie einfach bei mir nach:
thorsten.janning@kegon.de
KEGON AG 2013 Seite 25