Mein Name Nobody Der Architekt in Scrum

Größe: px

Ab Seite anzeigen:

Download "Mein Name Nobody Der Architekt in Scrum"

Anke Geiger
vor 6 Jahren
Abrufe

1 Mein Name Nobody Der Architekt in Scrum Werner Eberling

2 Kurze Vorstellung 2 Sprecher

3 Ich muss über etwas reden oder: Eine Retrospektive 3 Do more Stop doing Do less Start doing Keep doing

4 Das Projekt - Ein Steckbrief 4 Migrationsprojekt im Bankenumfeld Laufzeit: ca. 4 Jahre Fünf Scrum-Teams mit bis zu acht Team-Mitgliedern Alle Teams arbeiten an einem gemeinsamen Produkt Iterative organisatorische Anpassungen

5 Scrum und das X-funktionale Team 5 Es gibt nur den PO und das Scrum Team Alle benötigten Fähigkeiten sind Teil des Teams Das Entwicklungsteam entscheidet über das WIE

6 Scrum und das X-funktionale Team 6 Es gibt nur den PO und das Scrum Team Alle benötigten Fähigkeiten sind Teil des Teams Das Entwicklungsteam entscheidet über das WIE

7 Nix zu tun für Architekten? 7 Arch. Entwicklungsteam

8 Nix zu tun für Architekten? 8 Was? Arch. Entwicklungsteam

9 Nix zu tun für Architekten? 9 Was? Arch. Wie? Entwicklungsteam

10 Nix zu tun für Architekten? 10 Was???? Arch. Wie? Entwicklungsteam

11 Nix zu tun für Architekten? 11 Was???? XArch. Wie? Entwicklungsteam

12 Hey, mich gibt's ja gar nicht :) 12 Mein Name ist nobody :)

13 Hey, mich gibt's ja gar nicht :) 13 Naja, irgendwie ja scheinbar doch...und das schon seit vier Jahren......aber warum überhaupt? TPO-122

14 Die Sache mit dem Umfeld 14 Projekte stehen nicht für sich alleine Bestimmte Vorgaben sind einzuhalten n n n Technologien Coding Conventions Grundsatzentscheidungen Kann das nicht das Entwicklungsteam erledigen? n n Hängt von der Grösse des Projektes ab n Teams entwickeln n verschiedene Lösungen

15 Die Sache mit dem Ziel 15 Zum Schluss entsteht ein Produkt!!! Entwicklungsteam Entwicklungsteam Entwicklungsteam Entwicklungsteam Entwicklungsteam V1.0

16 Das Problem mit den Silos 16

17 Das Problem mit den Silos 17 Scrum Teams kennen sich in ihrem Aufgabengebiet meist perfekt aus Wenn mehrere Teams an einem Projekt arbeiten bilden sich Wissenssilos Selbst die besten Team-Mitglieder kennen vor allem Ihre Welt Wer behält den Gesamtüberblick?

18 Mögliche Alternative: Sichtwechsel statt Silo 18

19 X-funktional =/= keine Spezialisten 19 == Dev Dev Migr. Test Dev Ops Entwicklungsteam Entwicklungsteam

20 Scrum und das X-funktionale Team 20 Es gibt nur den PO und das Scrum Team Alle benötigten Fähigkeiten sind Teil des Teams Das Entwicklungsteam entscheidet über das WIE

21 Der Architekt als Teil des Scrum Teams 21 Arch. Entwicklungsteam

22 Der Architekt als Teil des Scrum Teams 22 Vorgaben von aussen? John war's!!!!

23 Der Architekt als Teil des Scrum Teams 23 ArchẊ Entwicklungsteam

24 Der Architekt als Teil des Scrum Teams 24!!! Arch. Entwicklungsteam

25 Zusätzlicher (T)PO oder Teil des Entwicklungsteams? 25? oder? Entwicklungsteam Entwicklungsteam

26 Und bei mehreren Teams? 26 oder

27 Scrum und das X-funktionale Team 27 Es gibt nur den PO und das Scrum Team Alle benötigten Fähigkeiten sind Teil des Teams Das Entwicklungsteam entscheidet über das WIE

28 Das WIE Architektur vs. Design 28 <= Querschnittsthema Implementierungsdetail =>

29 Das Problem mit den Vorgaben 29 Vorgaben entbinden von Verantwortung n Der Architekt hat aber gesagt... Nicht leiten, sondern anleiten! Die Teammitgleider abholen und mitnehmen! Anpassungen vornehmen, wenn nötig

30 CoP als Plattform für Querschnittsthemen 30 Der Ausdruck Community of Practice (Abkürzung CoP) bezeichnet eine praxisbezogene Gemeinschaft von Personen, die informell miteinander verbunden sind und ähnlichen Aufgaben gegenüberstehen (Wikipedia) Eine Community of Practice ist eine Gruppe von Personen, die ein gemeinsames Anliegen oder eine Passion für etwas besitzen, das sie tun und lernen wollen, wie sie darin durch regelmäßigen Austausch besser werden. (K. Simons)

31 Zentrale Themen in die CoP 31 Jedes Team entsendet (interessierte) Vertreter Macht Team-Mitglieder zu Beteiligten Nutzt das Know-How der Teams Vertreter tragen die Entscheidung ins Team

32 Und was macht jetzt nochmal der Architekt? 32 Be a Coach (anleiten statt zu leiten!) n n n Pair-Programming Code-Reviews Ansprechpartner für Fragen Diskussionen mit Enterprise Architektur Den Überblick behalten n Auch und besonders über Teamgrenzen hinweg

33 Vorsicht ist geboten Das Ziel im Auge behalten! n Architekten haben einen Affinität zu Elfenbeintürmen,) Vorsicht vor Zeitdieben n Diskussionen mit dem Umfeld arten gerne aus Immer ein Teil des Teams bleiben!

34 Fazit 34 Die Aufgabe des Architekten ist auch in Scrum wichtig n Je nach Projektgrösse Teil eines Scrum Teams oder Querschnittsaufgabe Arbeit mit/in Entwicklungsteams wichtigste Aufgabe n Der Architekt ausserhalb des Teams scheitert! Unterscheidung zwischen Architektur- und Design- Aufgaben! n Nicht überall mitreden wollen! Miteinander statt Kommandostruktur n Kommunikation auf Augenhöhe! Mechanismen des Prozesses zur Selbstreflektion nutzen

35 Vielen Dank!

Ähnliche Dokumente

DevOps. Alexander Pacnik, Head of DevOps Engineering

DevOps. Alexander Pacnik, Head of DevOps Engineering DevOps Alexander Pacnik, Head of DevOps Engineering 29.09.2016 Einführung... Produktfokussierung die Entstehungsgeschichte der Veränderung Umsatz / Features Innovative Phase (technisch orientiert) Deliver