Scrum Think big

Scrum für wirklich große Projekte, viele Teams und viele Kulturen
 
 
Hanser, Carl (Verlag)
  • 1. Auflage
  • |
  • erschienen am 13. Februar 2017
  • |
  • 238 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-446-45301-2 (ISBN)
 
- Vor welchen Herausforderungen steht das Management großer Projekte?
- Wie sinnvoll sind agile Skalierungsschablonen?
- Welche Voraussetzungen sollten für eine erfolgreiche Skalierung erfüllt sein?
- Welche Skills brauchen Mitarbeiter in agilen Projekten?
- Wie wird aus einem Projekt eine fraktal skalierte Organisation?

Viele Mitarbeiter an vielen Standorten sollen gemeinsam ein Projekt agil abwickeln - was ist dabei zu berücksichtigen? In kleinen Teams hat sich Scrum als Weg für erfolgreiche Produktentwicklung längst etabliert, doch jetzt geht es um andere Dimensionen. Unter dem Druck der Digitalisierung beginnen selbst Großkonzerne, die Erfahrungen aus agilen Pilotprojekten auf immer größere Teile der Organisation zu übertragen. Agile Skalierungsframeworks versprechen schnelle und einfache Lösungen, diese vorgefertigten Strukturen führen aber nicht zum eigentlichen Ziel: dem agilen Unternehmen.
Boris Gloger beschreibt in diesem Buch einen anderen Weg, der auf seinen eigenen Erfahrungen basiert. Bei der Skalierung von Scrum geht es nicht um die Multiplikation einer Methode, sondern um einen neuen Blick auf das große Projekt als fraktal skalierte Organisation. Gefragt sind entkoppelte Produktarchitekturen, das konsequente Denken aus der Sicht des Kunden, das Projektmanagement-Office als umsichtiger ScrumMaster, die Lust auf frische Skills, gestützt von modernen Infrastrukturen. Und schließlich braucht es eine Führung, die ihre wichtigste Aufgabe darin sieht, Zusammenarbeit über alle Ebenen hinweg zu ermöglichen.

AUS DEM INHALT//
Die Umfeldbedingungen des Skalierens // Kommunikations- und Produktarchitektur // Die passende Infrastruktur // Skills und Professionalität // Produktentwicklung // Good Practices für das skalierte Scrum-Projekt // Die fraktal skalierte Organisation
  • Deutsch
  • München
  • |
  • Deutschland
  • 18,68 MB
978-3-446-45301-2 (9783446453012)
3446453016 (3446453016)
weitere Ausgaben werden ermittelt
Boris Gloger ist Deutschlands und Österreichs bekanntester Scrum-Berater. Namhafte deutsche und internationale Unternehmen setzen auf seinen Rat, wenn es darum geht, Scrum richtig einzusetzen. Seine Standards bei der Umsetzung von Scrum haben sich durchgesetzt.
1 - Inhalt [Seite 6]
2 - Vorwort [Seite 10]
3 - Über den Autor [Seite 14]
4 - 1 Die Umfeldbedingungen des Skalierens [Seite 16]
4.1 - 1.1 Hyperspezialisierung [Seite 20]
4.2 - 1.2 Digitalisierung [Seite 24]
4.3 - 1.3 Arbeitsschutzgesetze [Seite 28]
4.4 - 1.4 Professionalität und neue Skills [Seite 30]
4.5 - 1.5 Produktentwicklungszyklen und Projektmanagement [Seite 32]
4.6 - 1.6 Bürokratie und Kontrolle [Seite 41]
4.7 - 1.7 Die Netzwerkorganisation [Seite 47]
4.8 - 1.8 Kapitelausblick [Seite 49]
5 - 2 Architektur [Seite 52]
5.1 - 2.1 Architektur als Ergebnis der Kommunikationsstruktur [Seite 53]
5.1.1 - 2.1.1 Schneller ist besser [Seite 56]
5.1.2 - 2.1.2 Entkopplung [Seite 59]
5.2 - 2.2 Was ist eine agile Produktarchitektur? [Seite 62]
5.2.1 - 2.2.1 Microservices - Grundlage flexibler Architektur [Seite 63]
5.2.2 - 2.2.2 Redundanz und Durchfluss gewährleisten [Seite 65]
5.2.3 - 2.2.3 Die Einheitlichkeit der Produktarchitektur [Seite 72]
5.2.4 - 2.2.4 Technologien und Architektur [Seite 75]
5.2.5 - 2.2.5 Betrieb und Architektur [Seite 76]
6 - 3 Infrastruktur [Seite 78]
6.1 - 3.1 Integration ist alles [Seite 78]
6.2 - 3.2 Räume - bauliche Infrastruktur [Seite 83]
6.2.1 - 3.2.1 Das große Projekt in einem Raum [Seite 84]
6.2.2 - 3.2.2 Flipcharts, Stifte und Haftnotizen [Seite 87]
6.3 - 3.3 Kommunikationstools [Seite 88]
6.4 - 3.4 Entwicklungstools [Seite 96]
6.5 - 3.5 Zusammenarbeit mit Lieferanten [Seite 103]
6.6 - 3.6 Richtlinien und Policies [Seite 107]
7 - 4 Skills und Professionalität [Seite 112]
7.1 - 4.1 Die Skills des Einzelnen [Seite 115]
7.1.1 - 4.1.1 Selbstmanagement [Seite 116]
7.1.2 - 4.1.2 Wissen über die Theory of Constraints [Seite 123]
7.1.3 - 4.1.3 Wissen über neue Formen der Produktentwicklung [Seite 123]
7.1.4 - 4.1.4 Die Rollen mit den richtigen Fähigkeiten ausfüllen [Seite 126]
7.1.4.1 - Die Skills des ScrumMasters [Seite 126]
7.1.4.2 - Die Skills des Product Owners [Seite 128]
7.2 - 4.2 Die Skills des Entwicklungsteams [Seite 131]
7.3 - 4.3 Die Skills des Managements [Seite 134]
8 - 5 Produktentwicklung [Seite 140]
8.1 - 5.1 Agiles Anforderungsmanagement [Seite 143]
8.2 - 5.2 Design Thinking [Seite 145]
8.3 - 5.3 Ein agiler Produktentwicklungsprozess [Seite 149]
9 - 6 Good Practices für das skalierte Scrum-Projekt [Seite 154]
9.1 - 6.1 Mythos zentrale Steuerung [Seite 155]
9.1.1 - 6.1.1 Steering Committee und Projektmanagement-Office [Seite 156]
9.1.2 - 6.1.2 Das richtige Produkt richtig liefern [Seite 158]
9.1.2.1 - Vertrauen und Erfolg: Im Gehirn des Managers [Seite 159]
9.1.3 - 6.1.3 Scrum-Teams: gemeinsam für den Return on Investment verantwortlich [Seite 162]
9.2 - 6.2 Theory of Constraints [Seite 164]
9.3 - 6.3 Die Skalierungstoolbox [Seite 167]
9.3.1 - 6.3.1 Die Meetings [Seite 167]
9.3.1.1 - Das skalierte Daily Scrum oder Scrum of Scrums [Seite 169]
9.3.1.2 - Das ScrumMaster Daily [Seite 174]
9.3.1.3 - Das Product Owner Daily [Seite 174]
9.3.1.4 - Das ScrumMaster Weekly [Seite 175]
9.3.1.5 - Das Product Owner Weekly oder Business Value Estimation Meeting [Seite 175]
9.3.1.6 - Das skalierte Estimation Meeting [Seite 176]
9.3.2 - 6.3.2 Rollen und Teams [Seite 176]
9.3.2.1 - Das ScrumMaster-Team [Seite 176]
9.3.2.2 - Das Product-Owner-Team [Seite 177]
9.3.2.3 - Die Gilden [Seite 178]
9.3.2.4 - Support-Teams [Seite 179]
9.3.3 - 6.3.3 Artefakte [Seite 182]
9.4 - 6.4 Agiles Portfoliomanagement [Seite 184]
9.4.1 - 6.4.1 Wert und Durchfluss [Seite 190]
9.4.2 - 6.4.2 Constraints und Puffer [Seite 193]
9.4.3 - 6.4.3 Cost of Delay - Projekte priorisieren [Seite 194]
9.5 - 6.5 Das agile Projektmanagement-Office [Seite 196]
9.6 - 6.6 KPIs und Reporting [Seite 199]
9.7 - 6.7 Marketing für das agile Projekt [Seite 201]
10 - 7 Die fraktal skalierte Organisation [Seite 204]
10.1 - 7.1 Wer führt die fraktal skalierte Organisation? [Seite 208]
10.2 - 7.2 Ein Leitfaden für die fraktal skalierte Organisation [Seite 210]
10.2.1 - 7.2.1 Glaubenssätze und Werte [Seite 211]
10.2.2 - 7.2.2 Fähigkeiten [Seite 222]
10.2.3 - 7.2.3 Verhalten [Seite 230]
10.2.4 - 7.2.4 Umwelt - Kunde, Dienstleister und Regularien [Seite 231]
11 - Schlussendlich: Es fängt mit Ihnen an! [Seite 234]
12 - Literatur [Seite 238]
13 - Index [Seite 242]
2 Architektur

Die Architektur eines Produkts ist die erste und wichtigste Voraussetzung für eine gelungene Skalierung. Es ist die Architektur, durch die sich ein Produkt vergrößern und erweitern lässt, genau so kann sie das Wachstum des Produkts oder Projekts behindern. Teams können durch die Architektur zu Bottlenecks werden oder sie kann Teams dazu bringen, unabhängig voneinander zu arbeiten. Die Skalierung eines Projekts wird also vom Rahmen bestimmt, den die Architektur vorgibt. Architektur ist immer auch Projektstruktur und beeinflusst dadurch die Kommunikation und Interaktion. Ich werde Ihnen in diesem Kapitel nicht sagen, wie eine skalierbare Architektur aussehen muss. Ich liefere Ihnen also keine Blaupausen, sondern architektonische Muster, die Sie in jedem Projekt anwenden können ? auch in nichtagilen Projekten.

Mein erster Job nach dem Studium führte mich zu Electronic Data System (EDS). Auf einem Mainframe entwickelten mein Entwicklungsteam und ich unter Cobol eine Applikation, mit der Gut- und Lastschriften für die Fahrzeuge eines Automobilkonzerns erstellt werden konnten. Die erfahrenen Entwickler erzählten mir vom Frontend, vom Backend und einer sogenannten "Three Tier Architecture". Ich lernte, logische und physische Datenmodelle zu unterscheiden, und ich erfuhr, dass man auch objektorientiert statt prozedural programmieren kann. Mein damaliges Entwicklungsteam machte mich mit Business Modelling vertraut und kurz darauf begann der große Hype: Internet. Ich lernte etwas Wesentliches: Das eigene System sollte modular entwickelt werden und über Interfaces mit anderen Systemen arbeiten. Die Module mussten so geschrieben werden, dass sie vollkommen autark von allen anderen Systemen funktionieren konnten. Und das alles noch auf einem Mainframe. Später sprachen wir auf den ersten agilen Entwicklerkonferenzen von emergenten Software- und Systemarchitekturen, also von Architekturen, die erst im Laufe der Zeit entstehen. Eigentlich wächst ein System also, aber wie sollte das gehen: Ich selbst hatte noch gelernt, dass man ein Datenbankmodell nicht einfach ändern kann, es wäre ein zu großer Aufwand. Diese Annahme war auch korrekt. Zumindest in der Toollandschaft der 1990er-Jahre.

Ende 1999 war Extreme Programming noch weitgehend unbekannt und auch fünf Jahre später hatte noch immer kaum jemand verstanden, wie man das machen sollte, was sich Kent Beck da ausgedacht hatte. Doch die Ideen klangen verlockend und vor allem klangen sie logisch. Es war das Thema auf Konferenzen und einige Softwareentwickler schrieben begeistert Tests. Aber es flammten auch die ersten Glaubenskriege auf: Braucht man nun eine Architektur oder entwickelt sie sich emergent? Und dann hörten wir von Conway's Law (Conway 1968): "Organizations which design systems [.?.?.] are constrained to produce designs which are copies of the communication structures of these organizations."

2.1 Architektur als Ergebnis der Kommunikationsstruktur

In den Entwürfen von Systemen spiegelt sich laut Melvin Conway also die Kommunikationsstruktur einer Organisation wider. Wenn man sich genauer damit auseinandersetzt, was Conway geschrieben hatte, wird klar, warum viele Softwaresysteme so komplex sind, wie sie es eben sind. Zunächst bauen einzelne Abteilungen jeweils ihr System, danach werden die Einzelsysteme miteinander verbunden. Allerdings passiert das oft nicht so, wie ich es in meinem ersten Team gelernt habe: über klar definierte Schnittstellen und nach genauen Absprachen zwischen den Abteilungen. Vielmehr gibt sich jede Abteilung einfach mit dem zufrieden, was sie bekommen kann und strickt ihre eigene Applikation um. Ein Beispiel: Ein Unternehmen baute ein System, das man als Middleware bezeichnen kann. Bei vielen großen Kunden ist dieses System seit mehr als einem Jahrzehnt im Einsatz. Heute hat es aber nicht alle Funktionalitäten, die von den Kunden benötigt werden, weil die Entwickler vor zehn Jahren noch gar nicht wissen konnten, was in den Systemen der Zukunft wichtig sein würde ? die Kunden wussten es ja selbst nicht. Als sich der Bedarf der Kunden allmählich änderte, war das Unternehmen zunächst einfach zu langsam und konnte nicht für jeden Kunden sofort die passende Lösung entwickeln. Also bauten die Kunden ihre eigenen Behelfslösungen um die existierende Applikation herum, die sogenannten "Workarounds". Als das Softwareunternehmen sein Produkt an die Erfordernisse der Kunden anpasste und damit die eigene Architektur änderte, verursachte genau diese Anpassung ein neues Problem: Nun funktionierten die Workarounds nicht mehr. So verrückt es klingt: Der Softwareanbieter baute seine "richtige" Architektur wieder zurück.

Ein Manager jenes österreichischen Telekommunikationsunternehmens, bei dem ich nach EDS arbeitete, bezeichnete diese Art, Softwaresysteme zu entwickeln, als "Mushroom-Architektur". Überall schießen Systeme und Applikationen aus dem Boden. Sie sind nicht so elegant miteinander verbunden, dass man leicht weiterentwickeln kann, meistens weiß niemand mehr, wie diese Systeme miteinander verbunden sind. Konsequenterweise beginnen die verschiedenen Systeme irgendwann, völlig unkontrolliert und unerwartet aufeinander zu reagieren. Entwickelt ein Team an einer Applikation weiter, funktioniert plötzlich in einer anderen Applikation etwas nicht mehr, das bisher keine Probleme gemacht hat. Bei diesem Telekommunikationsunternehmen erlebte ich, wie man sich zunächst mit Release-Management behelfen wollte, nur um wenig später zu merken, dass man auch mit dieser Maßnahme dem Komplexitätsproblem nicht beikommen konnte. Ganz im Gegenteil: Alle Prozesse in der Entwicklung wurden noch langsamer. Viele Telekom-Unternehmen starteten daher in den frühen 2000er-Jahren kostspielige Infrastrukturprojekte und versuchten, mit Middleware die Lage wieder in den Griff zu bekommen. Als Middleware bezeichnet man in der IT-Systemlandschaft jene Systeme oder Programme, die als Datendrehscheibe für alle Applikationen dienen. Gut vergleichbar mit dem Kabelbaum eines Autos, nur viel komplizierter.

Diese Middleware sollte es also richten. Sie sollte das Chaos der Applikationen und Programme, der Datengräber und Fehlplanungen entwirren. Aber sie tat es nicht. Die Systeme wurden immer nur komplexer und die Projekte teurer und teurer. Aus meiner heutigen Sicht wurde dabei die wichtigste Voraussetzung des Aufräumens nicht erfüllt: Wer aufräumt, muss auch wegwerfen. Wer alles Alte aufhebt, kann nicht umbauen oder renovieren und schon gar nicht für die Zukunft planen. Der Ballast, den man mit sich herumschleppt, wird ständig größer, schwerer und unübersichtlicher. Genau das passiert bei vielen Softwareprogrammen in Unternehmen: Anstatt alles, was nicht mehr verstanden wird, einfach auszumisten, werden Applikationen am Leben erhalten ? weil man nicht mehr weiß, was sie genau tun.

Aufräumen, wegwerfen und dann: miteinander reden

Aber ich will die aufräumenden Softwareentwickler in Schutz nehmen. Niemand will für das Aufräumen bezahlen, denn Projekte sind Investitionen. Wie soll man den Aktionären klarmachen, dass ständig aufgeräumt werden muss? Das Aufräumen als eine Investition in die Zukunft zu verstehen, fällt vielen schwer. Man bekommt auf den ersten Blick ja nichts dafür, außer einem aufgeräumten System, das eigentlich schon aufgeräumt sein sollte. Aufräumen kostet Arbeit, Zeit und meist auch ein wenig Geld.

In vielen Unternehmen sind die Architekturen der Systeme und Programme so miteinander verwachsen, dass es so gut wie unmöglich scheint, sie wieder aufzulösen und zu entwirren. Sieht man sich Conway's Law noch einmal genauer an, wird deutlich, warum das passieren muss: Die Informationsstrukturen in einem Unternehmen ändern sich schneller, als man sie mit Hilfe von Software nachbilden kann. Ändert sich nun die Informationsstruktur der Realität (des Business) und werden zum Beispiel dezentrale Abteilungen und Prozesse zentralisiert, müsste sich das unterstützende Softwaresystem sofort mitändern. Genau das kostet aber sehr viel Geld, das man nicht jedes Mal ausgeben will, wenn sich innerhalb der Organisation etwas ändert.

Das gilt nicht nur für Software. Auch Hardwareprodukte werden nicht unabhängig von den Informationsstrukturen entworfen, entwickelt und gebaut ? in diesem Fall sind es die Lieferantenstrukturen. Aus meinen Beobachtungen ziehe ich den Schluss, dass die Abhängigkeiten im Hardwarebereich sogar noch stärker sind. Deshalb ist es so wichtig, mit den richtigen Lieferanten zu arbeiten und Schnittstellen nicht nur am Anfang der Zusammenarbeit, sondern regelmäßig abzustimmen und gegebenenfalls zu testen, um Änderungen zu erlauben. Wird etwas gemeinsam entwickelt, das beide Seiten der Lieferkette gut beherrschen, ist das meistens kein Problem. Doch wehe, wenn die Lieferkette dysfunktional aufgesetzt wurde und nicht über Dinge geredet wird (manchmal aus seltsamen Gründen auch nicht geredet werden darf), über die unbedingt miteinander geredet werden müsste. Ich habe auch schon erlebt, dass Kunden die fehlende Kommunikation zwischen den Herstellern und ihren Lieferanten ausbaden müssen.

Abgesehen davon, dass solche Setups an sich dysfunktional sind, ist vollkommen klar, warum so ein Projekt nicht erfolgreich sein kann:

  • Niemand kennt die Architektur des Gesamtprodukts.

  • Niemand hat ein ähnliches Produkt bereits gebaut, aber die Budgets und Deadlines stehen fest.

  • Bei Fehlern kann man sich nicht gemeinsam auf die Suche nach der Ursache machen, denn das wäre eine Grenzüberschreitung. Die Folge: Verzögerungen.

  • Nicht die Teammitglieder, die täglich am Produkt arbeiten, treffen die...

Dateiformat: EPUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat EPUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

25,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung des WebShops erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok