In letzter Zeit treffen immer mehr – auch sehr grosse – Organisationen die Entscheidung, die Entwicklungsabteilung auf agile Vorgehensweisen umzustellen.
Die Einführung von z.B. Scrum in der Entwicklung hat jedoch weitreichende Auswirkungen auf die gesamte Organisation, die häufig unterschätzt werden. Oft ist im Management noch gar nicht klar, was das für das Unternehmen als Ganzes heisst. Es kommt zu einer Revolution von unten, die vielleicht gar nicht in dem Ausmaß beabsichtigt oder absehbar war. Das führt zu viel Unsicherheit auf allen Seiten bis zu handfesten Krisen und Konflikten.
Gewürzt mit Erlebnissen und Erfahrungen aus unseren Beratungsprojekten machen wir uns auf die Suche nach Zusammenarbeitsmodelle für grössere Unternehmen und mehrere Teams. Wir stellen dar, wo wir auf Diskrepanzen zwischen Kontrolle und Vertrauen stoßen und geben Denkanstöße für den Umgang mit Anforderungen und Planungsaspekten auf Unternehmensebene. Abschliessend betrachten wir die Freiheitsgrade, die agile Entwicklung in Bezug auf Requirements Engineering und Projektplanung braucht und welche Leitplanken vom Management dafür gesetzt werden müssen.
9. Ein Produkt
Product Owner C
Produkt C
Team C
Manage Agile
Oktober 2012
10. Ein Produkt – mehrere Projekte
Product Owner C
Produkt C
Projekt 3
Team C
Projekt 3 Projektleiter
Projekt 3
Projekt 2 Projektleiter Projekt 2
Projekt 2
Projekt 1 Projektleiter Projekt 1
Projekt 1
Manage Agile
Oktober 2012
12. Mehrere Produkte - Ein Projekt
Product Owner A
Product Owner B
Produkt B
Produkt A
Projekt 3
Projekt 3 Projektleiter
Projekt 3
Team A
Team B
Manage Agile
Oktober 2012
13. Product Owner
Ein Produkt, viele Module, viele Teams, viele Projekte Produkt/ System
Projektleiter
Projekt 3 Team C
Projekt 3
Product Owner
Modul D
Product Owner
Modul A
Team D
Projektleiter
Projekt 2
Team A
Projekt 2
Product Owner Team B Product Owner
Modul B Modul C Manage Agile
Oktober 2012
14. Product Owner
Ein Produkt, viele Module, viele Teams, viele Projekte Produkt/ System
Projektleiter
Projekt 3 Team C
Projekt 3
Product Owner
Modul D
Product Owner
Modul A
Team D
Projektleiter
Projekt 2
Team A
Ressourcenplanung:
1 Mitarbeiter in mehreren Teams Projekt 2
Product Owner Team B Product Owner
Modul B Modul C Manage Agile
Oktober 2012
22. Zusammenspiel der Ebenen
Strategie
Top
Management
Mittleres
Management
Architektur-
vision
Produkt-
vision
Operative
Ebene
Selbstorganisierend
Manage Agile
Oktober 2012
23. Zusammenspiel der Ebenen
Strategie
Top
Management
Mittleres
Management
Architektur-
System-
vision
vision
Produkt-
vision
Operative Service
Ebene
Betrieb
Chief
Integration Product Owner
Architektur
Selbstorganisierend
Release
Manage Agile
Oktober 2012
24. Zusammenspiel der Ebenen
Strategie
Top
Management
Mittleres
Management
Architektur-
System-
vision
vision
Produkt-
vision
Operative Service Nur nicht festlegen
Ebene
Betrieb
Chief
Integration Product Owner
Architektur
Selbstorganisierend
Release
Manage Agile
Oktober 2012
26. Zusammenspiel der Ebenen
Top
Management
Mittleres
Management
Man hilft den Menschen nicht, wenn man für sie tut,
was sie selbst tun können
Abraham Lincoln
Operative Service
Ebene
Betrieb
Chief
Integration Product Owner
Architektur
Selbstorganisierend
Release
Manage Agile
Oktober 2012
27. Zusammenspiel der Ebenen
Top
Management
Mittleres Agile Mindset Leitplanken
Management
Selbstorganisierend Problemlöser
Transition Team Linienmanager
Operative Service
Ebene
Betrieb
Chief
Integration Product Owner
Architektur
Selbstorganisierend
Release
Manage Agile
Oktober 2012
29. Zusammenspiel der Ebenen
Top
Management
Mittleres Agile Mindset
Management
Selbstorganisierend Problemlöser
Transition Team
Operative
Ebene
Chief
Aufmarsch der Product Owner
Product Owner
Selbstorganisierend
Manage Agile
Oktober 2012
30. Zusammenspiel der Ebenen
Top
Management
Mittleres Agile Mindset
Management
Selbstorganisierend Problemlöser
Transition Team
Operative
Ebene
Chief
Product Owner
Selbstorganisierend
Manage Agile
Oktober 2012
31. Zusammenspiel der Ebenen
Zitat eines Scrum Masters:
„[...] Missverständnis bezüglich der Bedeutung der Rollen
Top in der Scrum-Methodology gibt und zwar die Illusion, daß die "Rolle"
Management gleichbedeutend mit Macht, Einfluss und Recht wäre,
wobei sie aus meiner Sicht eher Pflicht, Verantwortung, Fleiß und
Disziplin bedeutet... [...]„
Mittleres
Management
Linienmanager
Operative Besetzung der Rollen
Ebene
Chief
Product Owner
Selbstorganisierend
Manage Agile
Oktober 2012
32. Zusammenspiel der Ebenen
„[...] Missverständnis bezüglich der Bedeutung der Rollen
Top in der Scrum-Methodology gibt und zwar die Illusion, daß die "Rolle"
Management gleichbedeutend mit Macht, Einfluss und Recht bedeutet würde,
wobei sie aus der meiner Sicht eher Pflicht, Verantwortung, Fleiß
bedeutet... [...]„F
Mittleres
Management
Linienmanager
Operative Barrieren werden verstärkt
Ebene
Chief
Product Owner
Selbstorganisierend
Manage Agile
Oktober 2012
Teams sehen es oft als Paradigmenwechsel zumindest hoffen Sie esManagement sieht es oft als eine weitere Vorgehensweise – sonst ändert sich nixWas sich tatsächlich ändern kann und was auf eine Organisation zukommt, werden wir im Vortrag ansprechen.Kontext hierbei ist das Anforderungsmanagement und das Projektmanagement/ Planung. Wir werden nicht über generelle Transitions und Change Management sprechen.Weiterhin werde ich sicherlich mehr Fragen aufwerfen, als Antworten geben können. Aber ich hoffe, ich kann Ideen aufwerfen.
Lösen Sie sich von dem Gedanken, einzelne Mitarbeiter zu 50% an Projekt A, zu 50% an Projekt b und zu 50% an Projekt C einzuplanen. Das funktioniert nicht.Versuchen Sie, feste Teams zu bilden und ein Produktteam zusammenzulassen und die Projektanforderungen im Team zu bearbeiten. Holen Sie ggf. Experten hinzu und versuchen Sie, für diese ein Arbeitsumfeld zu gestalten, dass sie flexibel in Teams unterstützen können.
sum
sum
Wenn sie viele Menschen haben, die sich selbst organisieren, müssen sie trotzdem die Richtung vorgeben. Das scheint manchmal schwierig
Nehmen wir an, die Testumgebung steht seit längerem und immer wieder nicht für die Teams zur Verfügung.Erwarten Sie als Transition Team jetzt ein Ticket oder eine Mail vom Scrum Master? Dann seien sie nicht überrascht, wenn das nicht geschieht, sondern ein Scrum Master beim Daily mit diesem Problem auftaucht. Und erschrecken Sie nicht, wenn plötzlich 13 Product Owner auf der Matte stehen. Dann müssen Sie handeln und sich die probleme anhören.
Bestehende Abteilungen fürchten einen Identitätsverlust oder auch Machtverlust.Testabteilung: Plötzlich testet das Scrum Teams selbst. Was heisst das für die Testabteilung? Braucht man uns nicht mehr? Die Rolle und Aufgabe ändert sich. Sie werden eher eine Serviceeinheit im Sinne von zur Verfügung stellen von Infrastruktur, Know How und Testmethodik. Sie untersüttzen die Teams.Projektmanagement: Die Teams managen sich selbst. Das Projektcontrolling erfolgt auch im Team selbst. Sehen sie sich als Schnittstelle zur Organisation und arbeiten sie als Übersetzer zwischen den alten und neuen Methoden. Unterstützen Sie Product Owner und Team bei Planungsaspekten mit ihrem know how
Das Team wird sich so
Das Team wird sich so
100% genaue Schätzung (oder auch 95%, etc.)Versuchen Sie mal, jemanden dazu zu bringen, zu schätzen wie hoch der Aufwand für ein schwammiges noch nicht im Detail zu fassendes Ziel ist und das mit 100%iger Genauigkeit. Im besten Fall bekommen Sie eine Zahl mit einem riesigen Puffer.Im schlimmsten Fall fangen Sie an, das Ziel heute genauer zu definieren und den Scope festzulegen. Die Schätzung bleibt aber im Raum stehen und die Zahl ist fix. Egal, wie sich der Scope bis zum Start der Umsetzung auch verändern mag.Das funktioniert nicht.
Teams sehen es oft als Paradigmenwechsel zumindest hoffen Sie esManagement sieht es oft als eine weitere Vorgehensweise – sonst ändert sich nix