Wie Sie auf agile Software-Entwicklung umstellen – Agile...

Wie Sie auf agile Software-Entwicklung umstellen –Agile Vorgehensweisen

Ausgehend vom Beitrag „Agile Konzepte“

(Kap. 08A01), wird in drei aufeinander

aufbauendenBeitrågen dieUmstellung auf

eine agile Form der SW-Entwicklung be-

schrieben.

Im vorliegenden dritten und letzten Bei-

trag werden kontextabhångige Vorge-

hensmuster zur Umstellung auf agile Ent-

wicklungsmethoden fçr diese Situationen

beschrieben: Entwicklung und Unterhalt

umfassender Individuallæsungen; Ent-

wicklung und Unterhalt von plattformba-

sierten Læsungen; SW-Entwicklung als

Dienstleistung. Die Vorgehensmuster um-

fassen die Ebenen des Portfolio- und Pro-

grammmanagements sowie die Teamebe-

ne und folgen dem agilen (und nicht nor-

mierten) Einsatz agiler und traditioneller

Methoden und Techniken.

Der erste der drei Beitråge (Kap. 08A02)

zeigt, dass diese Umstellung Verånderun-

gen der Unternehmenskultur voraussetzt

und erst dann Methoden und Techniken

der agilen (aber auch traditionellen) SW-

Entwicklung sinnvoll genutzt werden kæn-

nen. Der zweite Beitrag (Kap. 08A03) be-

schreibt im Detail einige Methoden und

Techniken fçr diese Kulturverånderung.

Autor: Hans-Peter Korn

E-Mail: [email protected]

1 Voraussetzungen fçr agile Vorgehensweisen inder Software-Entwicklung

Sie mæchten Ihre SW-Entwicklung auf ein „agiles“ Vorgehenumstellen? Und zwar – so nehme ich an – als eine langfristigwirksame strategische Investition?

In zweiten Teil dieser Reihe (Kap. 08A03) wurde dargestellt,wie die unabdingbaren kulturellen Voraussetzungen verbes-sert werden kænnen, um die fçr die jeweilige Aufgabenstel-lung der SW-Entwicklung am besten passende Vorgehens-weise zu nutzen. Und zwar unabhångig davon, um welcheagile (oder nicht agile) Vorgehensweise es sich handelt.

Teil 2

Umstellen auf Agil – Agile Vorgehensweisen 08A04

Seite 1

16. Aktualisierung E IT-Servicemanagement

Im ersten Teil dieser Reihe (Kap. 08A02) wurde dies in denAbschnitten „Das agile Vorgehen als strategische Investition“und „Wie beginnt ein Unternehmen seine ganz individuelleReise zu seiner persænlichen Art von Agilitåt?“ und „Zuerstgeht die Reise durch denKontinent derKultur, dann erst durchjenen der Vorgehensweisen“ begrçndet:

Der etablierte Kontinent der Unternehmenskultur bestimmt,wie polymorph der Kontinent der Vorgehensweisen sein kannoder muss, nicht aber umgekehrt.Investitionen in die Unternehmenskultur sind langfristig undstrategisch. Sie bilden die tragfåhige Basis fçr kurzlebige undstets anzupassende Vorgehensweisen. Investitionen nur in Vor-gehensweisen sind Verschwendung.

Der hier vorliegende dritte Teil dieser Reihe (Kap. 08A04)geht davon aus, dass Ihr Unternehmen ein gutes Stçck seinerReise in Richtung agile Kultur durch die Landschaften derKommunikations-, Kooperations- und Fçhrungsmethoden (s.Kap. 08A03) hinter sich bringen konnte und nun çber guteFåhigkeiten auf diesen Gebieten verfçgt:

• Robustheit

• Belastbarkeit

• Reaktionsfåhigkeit

• Flexibilitåt

• Innovationsfåhigkeit

• Anpassungsfåhigkeit

Das sind die essenziellen Voraussetzungen, um die fçr diejeweilige Aufgabenstellung der SW-Entwicklung am bestenpassende Vorgehensweise nutzen zu kænnen. Und zwar un-

Teil 1

Wichtig!

Teil 3

KulturelleVorausset-zungen sindgegeben

08A04 Umstellen auf Agil – Agile Vorgehensweisen

Seite 2

E IT-Servicemanagement 16. Aktualisierung

abhångig davon, um welche agile (oder nicht agile) Vorge-hensweise es sich handelt.

2 Muster zum Umstellen auf agile SW-Entwicklung

Gehen Sie jetzt bitte zum Abschnitt „Reisefçhrer durch denKontinent derVorgehensweisen“ im erstenTeil (Kap. 08A02).Rekapitulieren Sie dort bitte diese Abschnitte:

• Was sind die Reiseziele?

• Agiler Umgang mit agilen Vorgehensmodellen

• Einladung zur chaotischen Vielfalt?

• Generelle Muster zum Umstellen auf agile SW-Entwick-lung

– Agile Kultur

– Craftsmanship: SW-Entwicklung als professionellesHandwerk

Rufen Sie sich jetzt jene von Ihnen mit der „Zeitmaschine“ (s.Kap. 08A02, 2) erarbeiteten Ziele Ihres Unternehmens inErinnerung, die sich insbesondere auf den „Kontinent derVorgehensweisen“ beziehen, und notieren Sie hier Stichwortedazu:

Anhand dieser Ziele kænnen Sie entscheiden, welche dernachfolgend imDetail dargestelltenMethoden und Techniken

Das sind IhrespezifischenZiele


Seite 3


der SW-Entwicklung am besten passen und an welchem Vor-gehensmuster Sie sich zu ihrer Einfçhrung orientierenmæchten.

Werfen Sie jetzt nochmals einen Blick auf „Was ist der(wirtschaftliche) Nutzen von all dem?“ (Kap. 08A02, 8). Dortwurde erlåutert, dass das agile Vorgehen der SW-Entwicklungzu keiner klaren Kostenreduktion oder Qualitåtserhæhungfçhrt.

Wenn also Ihre primåren Ziele Kostensenkung und deutlichweniger SW-Fehler sind, dann ist die Umstellung auf eineagile SW-Entwicklung nicht unbedingt das dafçr am bestengeeignete Mittel.

Eine handwerklich professionelle SW-Entwicklung („crafts-manship“), beruhend auf dem Clean Code Development(siehe Kap. 08A02, 7.4.2), ist dann wirksamer als eine agileVorgehensweise als solche ohne diese Vorleistungen.

2.1 Vorgehensmuster zur Umstellung auf agileEntwicklung und Unterhalt umfassenderIndividuallæsungen

Die Charakteristiken und Herausforderungen von großenUnternehmen/Unternehmensbereichen mit der Entwicklungund dem Unterhalt von Individuallæsungen als Hauptaufgabewurden in „Wie reisen Sie mit Ihrem Unternehmen?“ be-schrieben (Kap. 08A02, 3, Punkt 2). Die Hauptaufgaben die-ser Unternehmen/Unternehmensbereiche (etwa des unter-nehmensinternen IT-Bereichs) erfordern ein strategischesPortfoliomanagement fçr die verschiedenen langfristig zuunterstçtzenden individuellen SW-Læsungen und SW-Ser-vices.

„Agil“ nichtunbedingtbilligeroder besser

Craftsmanshipund CleanCode


Seite 4


Es mçssen zwei Arten von Vorgehensweisen in Einklang ge-bracht werden:1. Das Neuentwickeln oder grundlegende Ûberarbeiten kun-

denspezifischer Individuallæsungen.2. Das als „Arbeitsfluss mit unbestimmtem Ende“ gestaltete

Pflegen und Weiterentwickeln der kundenspezifischen Læ-sungen.

Unternehmen dieser Art umfassen bis zu mehreren Tausendoft weltweit kooperierender Informatikspezialisten in vielenverschiedenen Teams. Nicht das Vorgehen und die Methodikin einem kleinen Team ist dort der Knackpunkt, sondern dieKoordination all dieser Spezialisten und Teams auf Pro-gramm- und Portfolioebene. Das erfordert ein Zusammen-spiel mehrerer agiler Vorgehens- und Steuerungsebenen:

• Agiles strategisches PortfoliomanagementEs dient der Koordination, Priorisierung und mittelfristi-gen Ressourcenallokation çber verschiedene Produktlini-en (Applikationsfamilien) und technologische Initiativen(etwa grundlegende Architekturverånderungen) hinweg.Optionen dazu sind SAFe (Kap. 08A01, 3.3.3) oder andereVarianten von Portfolio-Kanban.

• Agiles ProgrammmanagementDie Kooperation vieler Teams innerhalb einer Produktli-nie/Applikationsfamilie (eines „Value Stream“) kann als„Agile Release Train“ z. B. auf der Basis von SAFe (s.„Agile Release Train in [1]) auf der Programmebene ko-ordiniert werden. Es ist „DER“ Schlçssel fçr die team-çbergreifende Steuerung.

• Agiles projektartiges Management zur Neuentwick-lung oder grundlegenden ÛberarbeitungDie Menge an diesbezçglichen Projekten sollte mæglichst

Wichtig!

Zusammen-spielmehrererEbenen

Portfolio-management

Programm-management

Projekte


Seite 5


klein gehalten werden (s. Kap. 08A01, 3.2). Wann immermæglich, sollten auch Neuentwicklungen oder grundle-gende Ûberarbeitungen im Rahmen der etablierten AgileRelease Trains oder – bei einer neuen Produktlinie oderApplikationsfamilie – im Rahmen eines neuen Agile Re-lease Train abgewickelt werden. Die wenigen dann nochwirklich nætigen Projekte mçssen in geeigneter Art mitdem Programm- und Portfoliomanagement verknçpftwerden. Das agile Management von Projekten ist mitPRINCE2 oder DSDM (s. Kap. 08A01, 3.2.1) mæglich.

• Agiles Arbeiten im TeamIm Vergleich zum agilen Programmmanagement fçrmehrere parallele Agile Release Trains und dem agilenPortfoliomanagement sind die Vorgehensweisen und Me-thoden fçr die (Selbst-) Steuerung der agilen Arbeit in-nerhalb eines Teams eher einfach. Schwierig wird dieArbeit im Team vor allem bei mangelhafter teamçber-greifender Koordination und schlechter Abstimmungzwischen den Teams. Innerhalb der Teams kann z.B. mitKanban (insbesondere bei fortlaufenden Wartungsarbei-ten) oder Scrum oder Scrumban oder DSDM gearbeitetwerden.

• Das Bereinigen der historisch gewachsenen und sehrheterogenen System- und Anwendungslandschaftenkann mit „Architectural Epics“ (s. „Architectural Epics“in [1]) auf Portfolioebene und einem „Architectural Run-way“ (s. „Architectural Runway“ in [1]) auf Programm-ebene agil vorangetrieben werden.

Mægliche aufeinanderfolgende Schritte fçr diese Konstellati-on sind nachfolgend in 2.1.1 bis 2.1.12 beschrieben.

Teams

Altlasten-Bereinigung


Seite 6


2.1.1 Das ist bereits erreicht

Wesentliche Elemente der „agilen Kultur“ (vgl. Kap. 08A03)werden praktiziert, insbesondere:

1. Daily Standup

2. transparente Informationen

3. Sichtbarkeit, Verfolgbarkeit, Analysierbarkeit der Zu-sammenarbeit

4. Arbeitsplanung imTeam durch das Team– nicht durch denTeamleiter

5. kontinuierliche Verbesserung der Kooperation im Team

6. Teamarbeit mit Elementen von Scrum

7. Optimierung der Teamstruktur

8. „agile“Art der Fçhrung

9. Fçhren von Teams

10.Teamleiter – neu definiert

Craftsmanship (SW-Entwicklung als professionelles Hand-werk) (vgl. Kapitel 08A02, 7.4.2) ist etabliert, insbesondere:

• Nicht nur funktionierende Software, sondern gut gefer-tigte Software ist das erklårte Ziel.

• Clean Code Development prågt die Arbeitsweise [2].

• Professionelles Requirements Engineering mit schritt-weiser Verfeinerung auf der Basis eines JEDUF (JustEnoughDesignUpFront) (s. Kap. 08A01, 2.1) statt BDUF(Big Design Up Front) ist akzeptiert und wird weitgehendpraktiziert.

• Test Driven Development (TDD) und Acceptance TestDriven Development (ATDD) und die Integration vonEntwicklung und Test werden fortlaufend verbessert.

„Agile Kultur“

Craftsmanshipund CleanCode


Seite 7


• Continuous Integration, Continuous Delivery und Testau-tomation werden fortlaufend verbessert.

• Aktuelle Applikations- und Systemarchitektur ist model-liert und wird schrittweise bereinigt.

• Serviceorientierte Architekturkonzepte werden verfolgt.

2.1.2 Produktlinien/Applikationsfamilien als ValueStream

„Value Streams“ sind langlebige Wertstræme zur Erzielungeines wirtschaftlichen Nutzens. Sie umfassen die Gesamtheitaller Anforderungen, Systemdefinitionen und Entwicklungs-und Auslieferungsschritte, die dazu dienen, fçr ein bestimm-tes Geschåftsthema (z. B. ein spezifisches Segment des Ver-sicherungsgeschåfts) ein integriertes System zu realisierenund zu warten, das dem Unternehmen, einem bestimmtenKunden/Kundenkreis und den Nutzern einen zeitlich unbe-grenzten Fluss von Mehrwert bietet (s. „Value Streams“ in[1]).

Ich benutze hier und im Folgenden das SAFe (s. Kap. 08S01,3.3.3) als Illustration fçr ein agiles Framework der SW-Ent-wicklung, das auch das Programm- und Portfoliomanagementumfasst. Es ist dem Leser çberlassen, was davon er in seinemKontext nutzen mæchte.

„Value Streams“ sind keine einzelnen – stets zeitlich be-grenzten – Projekte. Bestimmte Entwicklungs- und Auslie-ferungsschritte (etwa zur Neuentwicklung von Teilen des in-tegrierten Systems) kænnen jedoch als Projekte innerhalb ei-nes Value Stream angesiedelt und abgewickelt werden.

LanglebigeWertstræme . . .

. . . statt nureinzelnerProjekte


Seite 8


Value Streams sind abgeleitet aus und verbunden mit denlångerfristigen und umfassenden strategischen Themen undInitiativen des unternehmensweiten Portfoliomanagements.

Die bisherige Form des Portfoliomanagements kann jetztnoch beibehalten werden. In der Regel ist dies auf die Bud-getierungsperiode fçr ein ganzes Geschåftsjahr angelegt unddaher nicht sehr flexibel. Es kann in einem spåteren Schrittflexibilisiert werden. Allerdings:

Das Portfolio ist grafisch (nicht als „Zahlenfriedhof“) fçr alleeinsehbar. Und zwar so, dass der aktuelle und zukçnftige un-gefåhre Arbeitsumfang pro Value Stream und Quartal erkenn-bar ist und somit auch angemessen begrenzt werden kann.

2.1.3 Value Streams als Agile Release Trains (ARTs)implementieren

Ein „Agile Release Train“ (s. „Agile Release Train“ in [1]) istdas Gefåß fçr die sich selbst managende Gemeinschaft alljener Teams, die Beitråge fçr einen bestimmten Value Streamleisten. Agile Release Trains (ARTs) sind das Rçckgrat deragilen SW-Entwicklung umfassender Læsungen unter Betei-ligung von hundert bis mehreren tausend Personen. JederART ist ein organisatorisches Konstrukt zum kontinuierlichenSchaffen (Definieren, Entwickeln, Ausliefern, Warten) vonGeschåftswert fçr einen Value Stream und ermæglicht dieAusrichtung aller zu ihm gehærenden Teams auf gemeinsameZiele und dasManagement der Abhångigkeiten zwischen denTeams durch die Teams selbst.

Die zu einem ART beitragenden Teams umfassen typischer-weise insgesamt 50 bis 100 Personen. Bei mehr als 150 Per-

Value Streamsund Portfolio-management

Wichtig!

ARTalsRçckgratder SW-Entwick-lung

Im Zugsitzen allebeteiligtenTeams


Seite 9


sonen (entsprechend der Dunbar-Zahl, das ist die maximaleAnzahl Personen, mit denen eine Einzelperson soziale Be-ziehungen pflegen kann) muss der Value Stream thematischso unterteilt werden, dass sich dann mehrere ARTs bildenlassen.

In Unternehmen mit weniger als 100 Entwicklern sollteneinzelne ARTs nicht weniger als je drei Teams (insgesamtetwa 20 Personen) umfassen. In Unternehmenmit weniger alsetwa 25 Entwicklern kænnen alle einen einzigen ART bilden,aber nur dann, wenn sie gemeinsam an einem einzigen funk-tionalen Themenbereich (einem Value Stream) arbeiten.

Entwicklungsteams mçssen so gebildet sein, dass jedes TeamBeitråge nur fçr einen einzigen ART leistet. Innerhalb jedesART (und nicht ART-çbergreifend!) gibt es ein „DeploymentOperations Team“ (s. „DevOps“ in [1]).

Die Teams, die im selben ART, also „im selben Zug“, sitzen,sind auf ein gemeinsames Ziel und einen gemeinsamen Zeit-plan und Lieferrhythmus auf der Basis von Releases – dieHaltestellen des ART – ausgerichtet und unterstçtzen so dengleichmåßigen Fluss der Produktentwicklung.

2.1.4 Ûberprçfen und anpassen der Teamstruktur

Kænnen alle Teams zu 100 % einem und nur einem ART zu-geordnet werden?

Kænnen die Teams innerhalb eines ART mæglichst unabhån-gig von anderen Teams oder teamexternen Spezialisten ar-beiten? Also so:

• Jedes Team verfçgt çber permanente, stets voll ausgelas-tete und daher ungeteilte Mitglieder/Spezialisten, die ins-

Keine çber-greifendenTeams!

Releases =Haltestellendes ART


Seite 10


gesamt zum Definieren/Realisieren/Testen der Software-produkte oder -services des Teams nætig sind.

• Jedes Team kann pro Release (also innerhalb von zwei bissechsMonaten, nicht unbedingt alle zwei bis vierWochen)und allein (d. h. ohne umfassende Zulieferungen andererTeams und nur gelegentlich unterstçtzt von temporår hin-zugezogenen Spezialisten) eine ins Gesamtsystem inte-grierte und technisch und funktional getestete SW-Teillæ-sung einer teamçbergreifenden End-to-End-Funktionali-tåt des ART herstellen.

• Die SW-Teillæsung eines Teams ist abgegrenzt durchmæglichst wenige und gut definierbare Schnittstellen zuden SW-Teillæsungen der anderen Teams.

• Die SW-Teillæsung jedes Teams ist zu Beginn der Release-Bearbeitung so weit definiert, dass die Schnittstellen als„Stubs“ realisiert werden kænnen.

• Jedes Team realisiert innerhalb der Release-Abarbeitungseine SW-Teillæsung so, dass innerhalb dieser Stubs Zwi-schenresultate mæglichst frçh technisch integriert undfunktional getestet werden kænnen, um den teamçber-greifenden Integrations- und Testaufwand am Ende derRelease-Entwicklung zu minimieren. Die Ergebnisse derregelmåßigen (idealerweise kontinuierlichen) Integrationwerden wåhrend der Release-Bearbeitung in mehrerenteamçbergreifenden „System Demos“ (s. „System Demo“in [1]) vorgefçhrt.

Wie in Kap. 08A03, 3.5.3 beschrieben, wird es in jedem ARTsowohl Feature- als auch Component-Teams geben.

Sehr oft kann das alle Teams eines ART umfassende De-ployment der Teamergebnisse nicht von jedem Team selbstgeleistet werden. Dann wird es pro ART ein Deployment-Operations-Team (s. „DevOps“ in [1]) geben. Ein mehrere

Pro ARTFeature- undComponent-Teams


Seite 11


ARTs çbergreifendes Deployment-Operations-Team ist nichtzu empfehlen.

2.1.5 „WAS“ vom „WIE“ trennen: Pro Team ein TeamBacklog Owner

Die Teamleiter sind herkæmmlicherweise Rahmensetzer so-wohl dafçr, „WAS“ das Team zu leisten hat, als auch fçr das„WIE“. Der Vorteil ist, dass es von der Welt außerhalb desTeams betrachtet den Teamleiter als einzigen Ansprechpart-ner fçr dieses Team gibt. Der Nachteil ist, dass das „WAS“dann allzu sehr von den Mæglichkeiten des Teams, „WIE“ esdie Arbeit leisten kann (Kompetenzen, Auslastung einzelnerSpezialisten, Entwicklungsinfrastruktur), bestimmt wird. Dasjedoch widerspricht dem Ziel, fçr das Unternehmen/die Nut-zer den optimalen „Wert zu schaffen“, als Dach des House ofLean (s. Kap. 08S01, 2.2).

Deshalb ist es essenziell, die Rahmensetzung fçr das „WAS“und das „WIE“ auf zwei Rollen aufzuteilen, die personellgetrennt bleiben. Damit diese klare Trennung gelingt, solltedie Verantwortung fçr das „WAS“ keinesfalls der bisherigeTeamleiter und auch niemand aus dem Team çbernehmen. Essollte besser eine Person aus dem Produktmanagement sein.

Das „WAS“ beschreibt all das, „was“ das Team derzeit undkçnftig zu liefern hat: User Stories, zukçnftige Features,technische Stories, Fehlerbehebungen, Infrastrukturarbeiten,Spikes, Refactorings und so weiter (s. [3]). Vieles davon wirdanlåsslich der Release-Planungen (daran nehmen alle Teamsdes ART teil) vom Team erkannt und formuliert. Dokumen-tiert ist das im „Team Backlog“ (s. „Team Backlog“ in [1]),einer nach Abarbeitungsreihenfolge geordneten Liste all die-ser Dinge.

„WAS“formulieren =Produkt-management

„WAS“ mitTeam erarbei-ten . . .


Seite 12


Verantwortlich jedoch fçr diese Liste und alles, was dort ent-halten ist, sowie fçr die Reihenfolge ist ausschließlich der„Team Backlog Owner“, der zum Agilen Team gehærende„Product Owner“ (s. „Product Owner in [1]). Er ist als einzigePerson fçr die Verwaltung des Team Backlog verantwortlichauch dann, wenn er einzelne seiner Aufgaben von anderenPersonen (etwa im Team oder vom Produktmanagement)ausarbeiten låsst.

Ich spreche hier ganz bewusst nicht (wie bei Scrum) von„Product Owner“ und „Product Backlog“, sondern vom„Team Backlog Owner“ und „Team Backlog“. Denn dann,wenn etliche Feature- und Component-Teams gemeinsam einumfassendes SW-Produkt herstellen, ist es nicht realistisch,dass dieses Produkt von nur einem einzigen Product Ownerverantwortet wird, der fçr jedes Team ein spezifisches Back-log verwaltet undmit jedemTeam die Planungen undReviewsmacht. Eingebçrgert hat sich die Praxis, dass alle Teams ei-gene Owner fçr ihre Backlogs haben (allenfalls fçr zweiTeams einen), die dann ein „Team der Owner“ bilden, dasdann vom „eigentlichen“ Product Owner repråsentiert wird.Außerdem ist es weit hergeholt, bei einem Component Teamvon einem „Product Backlog“ und einem „Product Owner“ zusprechen, da dieses Team ja Systemkomponenten oder sys-temnahe Services und keine „Produkte“ im eigentlichen Sinnrealisiert.

Der Team Backlog Owner entlastet das Team vom Klårenwidersprçchlicher und vom Priorisieren vieler gleichzeitigvorliegender Anforderungen diverser Anspruchsgruppen. Je-des Team verhandelt das „Was“ seiner Arbeit ausschließlichmit seinem Team Backlog Owner, einschließlich der nicht-funktionalen Anforderungen. Die Teams sind fçr den von ih-nen realisierten Lieferumfang nicht mehr gegençber ihremTeamleiter und diversen anderen Anspruchsgruppen (Auf-

. . . verantwort-lich bleibtBacklogOwner

Team Backlogstatt ProductBacklog

Nur der TeamBacklogOwnerverantwortetdas „WAS“


Seite 13


traggeber, Nutzer, QA, Architektur . . .), sondern nur nochihrem Team Backlog Owner gegençber direkt verantwortlich.

Der Team Backlog Owner kann jedoch gegençber all diesenAnspruchsgruppen in græßeren Organisationen nicht als derzuletzt allein Entscheidende auftreten. Das geschieht im Pro-duktmanagement.

Der Interessenabgleich hat im Produktmanagement auf denEbenen des Programm- und Portfoliomanagements stattzu-finden (s. „Product Owner“, Tabelle 1 in [1]). Die Formulie-rung im Scrum Guide [3]:

„The Product Owner is one person, not a committee . . . For

the Product Owner to succeed, the entire organization must

respect his or her decisions.“

ist in græßerenOrganisationen nicht umsetzbar.Wichtig bleibtjedoch, dass nur der Team Backlog Owner die Ergebnisse desInteressenabgleichs durch das Programm- und Portfolioma-nagement im Backlog festhålt und sie nur von ihm allein ge-gençber dem Team vertreten werden.

2.1.6 Die Teamleiter bleiben Rahmensetzer fçr das„WIE“

Die bereits vorhandenen Teamleiter werden „Wie-Verant-wortliche“ im Sinn eines ScrumMaster oder Agile Master (s.„Scrum Master“ in [1] und in [3], Abschnitt „The ScrumMaster“). Sie sind nicht mehr verantwortlich fçr das „Was“.Sie bleiben die Vorgesetzten der Entwickler. Das ist auch keinWiderspruch zu Scrum (vgl. Kap. 08A03, 4.4 u. 4.5) oder eine

Wichtig!

Wie-Verant-wortliche


Seite 14


Behinderung der Selbstverwaltung des Teams, sondern einefçr das Team wichtige Unterstçtzung [4].

Die Team Backlog Owner hingegen sollten zur Organisa-tionseinheit „Produktmanagement“ oder „Servicemanage-ment“ gehæren. Dass damit die Teamleiter (bzw. die Teams alssolche) nicht mehr fçr das „Was“ zuståndig sind, fçhrt oft zuIrritationen bei den Kunden oder Nutzern. Bisher konnten sieja direkt den Teamleiter oder ein Teammitglied ansprechen,um Ønderungswçnsche erfçllt zu bekommen.

Die agilen Teams sind keine temporåren Projektteams, son-dern långerfristig stabile Feature- oder Component-Teams.Deshalb werden sie als Organisationseinheiten der Primåror-ganisation mit jeweils einem Teamleiter als Fçhrungskraftgebildet. Nur so ist gewåhrleistet, dass die individuelle Fær-derung der Teammitglieder auf der Basis der Tag fçr Tag be-obachteten Arbeit erfolgt und nicht „aus der Entfernung viaInformationen aus dritter Hand“, wie es bei Matrixorganisa-tionen oft der Fall ist.

Der Teamleiter setzt gegençber dem Team und vertritt undverteidigt gegençber außen den Rahmen fçr das „Wie“ zurDurchsetzung des Grundsatzes „Nicht nur funktionierendeSoftware, sondern auch gut gefertigte Software“ und derPrinzipien des Clean Code Development. Das Team konzen-triert sich innerhalb dieses Rahmens auf die professionelleRealisierung und das Testen des vom Team Backlog Ownervertretenen „Was“.

2.1.7 Pro „ART“ die Zeitpunkte der externen undinternen Releases bestimmen

Idealerweise wird beim agilen Vorgehen in jeweils sehr kur-zen Zeitabstånden ein auslieferbares Software-Inkrement er-

Agile Teams alsOrg.-Einheitender Linie mitTeamleitern

Produktin-krementein kurzenIntervallenoft nichtmachbar


Seite 15


zeugt. Beim iterativen Vorgehen (etwa bei Scrum-Sprints) istdas alle zwei bis vier Wochen, beim flussorientierten Vorge-hen (etwa bei Kanban) immer dann, wenn etwas fertig ist. Oftaber, insbesondere wenn etliche Teams parallel an einemSoftware-Inkrement arbeiten, oder bei technologisch hetero-genen Systemen, ist es schlichtweg nicht durchfçhrbar, in sokurzen Abstånden ein çber alle Teams und Technologienhinweg im Gesamtsystem getestetes und zuverlåssig lauffå-higes Inkrement auszuliefern – einschließlich der dazu næti-gen Benutzer- und Betriebsdokumentation (s. Kapitel 08A03,Abb. 3).

Und die Nutzer? Sind sie gewillt, regelmåßig alle zwei bis vierWochen oder noch håufiger neue und geånderte Software-funktionen zu erhalten und zu erlernen und ihre Arbeitsab-låufe darauf abzustimmen?

Vom Produktmanagement zu beantworten sind daher dieseFragen:• Wie groß ist die Dynamik bezçglich neuer und geånderter

Funktionalitåten (Nutzererwartungen, Markt und Mitbe-werber)?

• Wie groß also ist pro ART (= Value Stream) die Volatilitåtder Anforderungsånderungen? Øndern sich bis zu 10 % derAnforderungen pro Woche oder Monat oder Quartal?

• Wie håufig wçnschen die Nutzer neue Releases?Die Antworten bestimmen die Håufigkeit der externen, alsoeffektiv ausgelieferten und produktiv gesetzten, Releases proART.

Wenn pro ART die Zeitpunkte der (nicht unbedingt regelmå-ßigen) externen Releases mittelfristig abgeschåtzt sind, stellt

Ûberforderungder Nutzervermeiden

ZeitpunkteexternerReleases


Seite 16


sich folgendeweitere proART zusammenmit allen Teams desART zu beantwortende Frage:

• Wie groß ist die optimale Dauer der INTERNEN Relea-ses?

Interne Releases sind fçr die eigentlichen Nutzer unsichtbar.Sie dienen der Software- oder Produktentwicklung zur kurz-fristigen und realitåtsnahen Integration und Validierung derResultate (s. 1 in „Release“ in [1] und Abb. 3 in „psi-release“in [1]).

Der Takt interner Releases ist regelmåßig und nie långer alsjene minimale Dauer, in der alle zum internen Release beitra-genden Teams gemeinsam ein integriertes „Potentially Ship-pable Increment“ (PSI) liefern kænnen.

Und zwar so, dass die Beitråge aller Teams in eine betriebs-nahe Integrationsumgebung erfolgreich çberfçhrt und dortsowohl technisch (inklusive aller nichtfunktionalen Anforde-rungen) als auch fachlich erfolgreich getestet werden kænnen.Ein Richtwert in großen Unternehmen mit heterogenen Sys-temlandschaften sind acht bis zehn Wochen.

2.1.8 Programmmanagement pro ARTagil gestalten

Das Programmmanagement (s. „Program Portfolio Manage-ment“ in [1]) dient der teamçbergreifende Koordination derFunktionalitåten umfangreicher Systeme pro ART als Abfol-ge stets gleich langer Iterationen (= interne Releases) von achtbis zehn Wochen mit fixierten Qualitåtsanforderungen, je-dochmit mittel- und langfristig verånderlichemUmfang (kein„eisernes Dreieck“: fester Umfang fi fixe Termine fi feste

ZeitpunkteinternerReleases

PSI

Abschied vom„eisernenDreieck“


Seite 17


Kosten, s. Kap. 08S01, 3.2). Ergebnisse des ART sind regel-måßig vorhandene Potentially Shippable Increments (PSIs).Sie werden in einer dynamischen „Roadmap“ (s. „Roadmap“in [1]) geplant.

Pro ART zeigt eine dynamische Roadmap fçr die zukçnftiggeplanten Termine der INTERNEN Releases, das Thema, diejeweiligen Ziele und die geplanten priorisierten Features.

Die Beschreibung des unmittelbar nåchsten internen Releasesder Roadmap stellt eine Verpflichtung gegençber dem Un-ternehmen dar. Fçr die Ausgestaltung der spåteren Releasesgibt es keine verbindlichen Zusagen, deren Umfang ist bes-tenfalls unscharf.

Dass Plåne fçr zukçnftige interne Releases nicht fçr unter-nehmensexterne Verpflichtungen – also gegençber den Kun-den – genutzt werden sollten, ist bei vielen Kundenauftrågenjedoch schwierig durchzusetzen.Gegençber denKundenwirdes in der Regel eine långerfristige und verbindlichere Planungzukçnftiger, jedoch EXTERNER Releases der Kundenlæ-sungen geben mçssen – mit dem damit verbundenen Risiko,dass sich diese långerfristigen Planungen nicht umsetzenlassen.

Vertråge auf der Basis des „Agilen Festpreises“ [5] sind eineLæsung, wenn es ein gutes Vertrauensverhåltnis mit demKunden gibt.

Die Roadmap repråsentiert die jeweils aktuelle Sicht derPrognosen des Unternehmens fçr die zukçnftigen Releases.Diese Sicht ist stets Ønderungen unterworfen, da sich Ent-wicklungsergebnisse, Geschåftsprioritåten und Kundenbe-

DynamischeRoadmap

Nur nåchstesPSI verpflich-tend

Kunden wollenlångerfristigeundverbindlicheZusagen

Option:AgilerFestpreis


Seite 18


dçrfnisse åndern kænnen. Deshalb sollen Plåne fçr zukçnftigeinterne Releases nicht fçr unternehmensexterne Verpflich-tungen genutzt werden. Verpflichtend gegençber dem Unter-nehmen ist nur der unmittelbar bevorstehende interne Re-lease. Inwieweit daraus auch eineVerpflichtung fçr einen demKunden ausgelieferten (also externen) Release abgeleitetwird liegt in der Verantwortung des Produktmanagements.

Eine fçr alle einsehbare Grafik pro ART zeigt pro internenRelease (PSI) den aktuellen und zukçnftigen ungefåhren Ar-beitsumfang pro Team bezogen auf 70 % seiner Maximalleis-tung. Damit kann der anstehende Arbeitsumfang angemessenbegrenzt werden.

Auf der Ebene des Programmmanagements legen die Pro-duktmanager (es gibt aber auch viele andere Bezeichnungenfçr diese Rolle) die Features des Systems als dynamischeRoadmap fest. Die Rolle des „Product Owners“ gemåß ScrumGuide ist dafçr dann gut anwendbar, wenn jeweils ein Teamallein ein Produkt, vertreten von einem Product Owner, ent-wickelt. In græßeren Unternehmen jedoch sind, wie bereitsvorher in 2.1.5 beschrieben, die Verantwortlichkeiten einesProduct Owner im Sinne von Scrum oft so breit, dass sie auftechnologisch orientierte Team Backlog Owner und auf denMarkt oder die Nutzer fokussierte Produktmanager verteiltsind. Letztere nehmen ihre traditionellen Verantwortlichkei-ten sowohl bezçglich der Produktdefinition als auch der Prå-sentation der Læsung gegençber dem Markt wahr. Unabhån-gig von der firmenspezifischen Bezeichnung nimmt derProduktmanager/das Produktmanagement vor allem folgendeVerantwortungen wahr:

TransparentePlanung,Begrenzungder Arbeiten

Produkt-manager imProgramm-management


Seite 19


• Ownership der Programmvision eines ART und des Pro-gramm-(Release-)Backlogs eines ART

• Managen des Release-Umfangs eines ART auf Feature-Ebene

• Pflegen der Produkt-Roadmap eines ART

• Aufbau eines effektiven Produktmanager-/Team-Backlog-Owner-Teams pro ART

2.1.9 Planung des kommenden „PSI“ (interner Release)eines „ART“

Jede Timebox zur Realisierung eines PSI (= interner Release)einesART beginnt mit einemPlanungstreffen als Kick-off derRelease-Erarbeitung. Diese Release-Planung fçr das nåchstePSI dient der Klårung seines Kontextes und der Ausrichtungder am ART beteiligten Teams auf die Geschåftsziele desReleases. Die Vorgabe fçr das Release-Planungstreffen ist dieaktuelle Vision zusammen mit den Zielen des kommendenReleases und der Zusammenstellung der dafçr benætigten undpriorisierten Features im Programm-Backlog dieses ART.

Im Unterschied zu sonst çblichen Vorgehensweisen des Pro-grammmanagements planen ALLE Mitglieder der am ARTbeteiligten Teams (also typischerweise 50 bis 100 Personen)das Release gemeinsam an ein bis zwei Tagen unter Nutzungbewåhrter Techniken zur Moderation großer Gruppen (s.Abb. 3 in „Release Planning“ in [1]). Die Teams zerlegen diefçr das nåchste PSI in Betracht kommenden Features desProgramm-Backlogs in jene Stories, die sie als Team bear-beiten kænnen. Das ergibt die Team Backlogs fçr das nåchstePSI (den anstehenden internen Release). Wåhrend diesesProzesses klåren die Teams ihre Schnittstellen zu anderenTeams. Sie schåtzen den Umfang ihrer Stories und verhandelnin Kenntnis ihrer Kapazitåt (= Arbeitsgeschwindigkeit), was

VerantwortungProdukt-management

Planungs-meeting mitALLENMitgliedernaller beteilig-ten Teams


Seite 20


sie leisten oder nicht leisten kænnen und damit çber Verån-derungen des Release-Umfangs mit dem Team BacklogOwner und dem Produktmanagement. Zusåtzlich zu dieserPlanung verpflichten sich die Teams gegençber ihrem TeamBacklog Owner auf die zu erreichenden Release-Ziele undpriorisierten Features. Die Ergebnisse der Release-Planungfließen in die Aktualisierung der Roadmap des ARTein.

Ist das nicht viel zu aufwåndig und daher „unbezahlbar“?

Hier die Rechnung:

Zehn Teams (= 60 Personen) arbeiten gemeinsam an eineminternen Release eines ARTund es gibt fçnf interne Releasespro Jahr:

fi 2 Tage6 5 Releases6 60 Personen = 600 Personentage/Jahr

fi Pro Person 180 „produktive“ Tage pro Jahr6 60 Personen= 10.800 Personentage/Jahr

Diese kollaborative Release-Planung beansprucht nur 5,5 %der Entwicklungskapazitåt!Das ist wesentlich weniger als der Aufwand fçr die Behebungder erst im Verlauf der Release-Erarbeitung erkannten Koor-dinationsmångel, die dann auch nur „notdçrftig und on the fly“bereinigt werden und oft zu Folgeproblemen fçhren.

Wenn solche kooperativen Arbeitsweisen als viel zu teuerabgelehnt werden mit dem Hinweis, dass es ja gençge, wenndie Team Backlog Owner allein (also nur zehn statt 60 Per-sonen) all das in nur einem halben Tag erledigen, ist das ein

Ungewæhnlich– aber hocheffizient!

Nur 5,5 % derKapazitåt!

Agil =Kooperation/Konversation,nicht Auftrags-erteilung „vonoben“


Seite 21


Zeichen fçr eine immer noch stark auf „Auftragserteilung vonoben“ und „Koordination durch Repråsentanten“ geprågteKultur. Es hat sich dann noch nicht die Einsicht durchgesetzt,dass ein Unternehmen erst durch die fortlaufende Konversa-tion aller das Unternehmen umfassenden Mitarbeitenden undStakeholder entsteht.

„Agile“ Vorgehensweisen werden dann bestenfalls nur als„Fassade“ sichtbar sein, nicht aber gelebt werden. Das jedocherzeugt mehr Irritationen und Verunsicherungen als Nutzen.Wenn die Kultur nicht stimmt, sollten besser die alten Vor-gehensweisen praktiziert werden.

2.1.10 Agile Arbeit auf Teamebene

Inwieweit einzelne Teams innerhalb dieser PSI-Erarbeitung inAnlehnung an Scrum in Sprints, kontinuierlich mit Kanbanoder Scrumban, einer Kombination aus beidem, oder nacheigenemMuster arbeiten, kann den Teams çberlassen werden.Fçr die Teams ist mit der Relase-Planung pro ART der Rah-men fçr das „WAS“ gesetzt. Der Teamleiter hat die Ver-pflichtung, den Rahmen fçr das „WIE“ zu setzen, um dieErreichung des „WAS“ zu erleichtern.

Die passendenDetails derArbeitsweise – das Bild imRahmen– kænnen die Teams selbst wåhlen. Es liegt insbesondere anden sehr eng kooperierenden Teams, sich selbst gemeinsamangemessen zu organisieren und allenfalls synchronisierteSprints zur besseren Kooperation und Transparenz zu ver-einbaren. Teams mit einem hohen Anteil fortlaufend und un-planbar eintreffender Wartungs- und Supportaufgaben hin-gegen arbeiten besser auf der Basis von Kanban oder Scr-umban mit regelmåßigen teamçbergreifenden „SystemDemos“.

„Agil“ alsFassade?

Jedes Teamwåhlt seineVorgehens-weise selbst


Seite 22


Entscheidend ist, dass jedes Team seine in der Release-Pla-nung zugesagten Ziele erreicht. Das „WIE“ liegt in der Ver-antwortung der Teams.

Schenken Sie „Methodendogmatikern“ keinen Glauben.Glauben Sie vor allem nicht daran, dass ein bestimmtes Vor-gehen wie insbesondere Scrum zuerst 1:1 gemåß einem derbeiden heute vorliegenden Regelwerke (dem „Scrum Guide“der scrum.org und dem „Core Scrum“ der Scrum Alliance)praktiziert werden muss, bevor es teamspezifisch angepasstwird. Gehen Sie auch hier von Anfang an agil vor: Praktizie-ren und intensivieren Sie im Team all das, was passt, undveråndern Sie Ihre Praktiken schrittweise. Die dokumentier-ten Regeln der diversen Rahmenwerke dienen der Orientie-rung, nicht als „Gesetze“. Undwenn sich eine dieser Regel als„schmerzhaft“ herausstellt, dann hæren Sie damit auf undmachen Sie etwas Passenderes. Ihr Unternehmen lebt nichtvom Einhalten fremder Regeln, sondern von den Ihre Kundenzufriedenstellenden und sie hoffentlich auch begeisterndenProdukten und Dienstleistungen, die das Unternehmen„schmerzfrei“ und gewinnbringend realisieren kann.

Denken Sie auch stets daran, dass auf der Ebene des Teams dieSW-Entwicklung als professionelles Handwerk (Craftsman-ship) wichtiger ist als das Befolgen irgendwelcher teamexterndefinierten Vorgehensregeln, um nicht nur funktionierende,sondern gut gefertigte Software zu realisieren.

Fçr die Arbeit bis zur Lieferung des nåchsten PSI (interneReleases) haben alle Teams unabhångig von ihrem Vorgehenjedoch diese Transparenz zu gewåhrleisten:

KeineMethodeum ihrerselbst willen

TagesaktuellsichtbarerArbeitsfort-schritt


Seite 23


Der Arbeitsfortschritt der einzelnen Teams ist tagesaktuell fçralle einsehbar – aber nicht anhand der verbrauchten Stundenoder anhand erarbeiteter Konzepte oder Designs, sondern alsVerhåltnis aus:• Umfang der in der Integrationsumgebung (allenfalls erst

gegençber „stubs“) funktionierenden und vom TeamBacklog Owner akzeptierten Softwareinkremente und derrealisierten Prototypen

im Vergleich zum:• Gesamtumfang der bis zum Release-Zeitpunkt geplanten

Softwareinkremente und Prototypen.

Gleichzeitig steht die Sicherstellung der Qualitåt und nichtder Menge der in jedem PSI gelieferten Ergebnisse im Vor-dergrund. Deshalb gibt es diese weitere Regel:

Der Team Backlog Owner ist verantwortlich dafçr, nur jeneErgebnisse zu akzeptieren, die alle funktionalen und nicht-funktionalen Anforderungen, insbesondere die Kriterien derSoftwarequalitåt, vollståndig erfçllen.Er ist rechenschaftspflichtig dafçr, dass alle diesbezçglich næ-tigen Ûberprçfungen (evtl. auch von teamexternen Stellen)vorgenommen wurden.

2.1.11 Projekte innerhalb eines „ART“

„Projekte“ in ihrer in der ITweit verbreiteten Bedeutung ste-hen im Widerspruch zur agilen SW-Entwicklung (s.Kap. 08A01, 3.2). Andererseits verhilft das „Projekt“ als or-ganisatorisches und kommerzielles Konstrukt zu einer starkenFokussierung darauf, bestimmte Ergebnisse innerhalb einer

Team BacklogOwner rechen-schaftspflichtigfçr SW-Quali-tåt

Projektepassen nichtzur agilenEntwicklungim ART


Seite 24


definierten Zeit mit definierten Kosten zu erzielen, und esschafft dafçr spezielle temporåre Verantwortlichkeiten (Len-kungsausschuss, Projektleiter, Projektteam). Wenn jedoch ineinem Unternehmen alles als „Projekt“ betrachtet und orga-nisiert wird, fçhrt das zu kaum zu bewåltigenden Koordina-tionsproblemen, zu einem Ûbermaß an projektbedingtenMeetings und bei den in der Regel gleichzeitig an mehrerenProjekten beteiligten Mitarbeitenden zu einem die Produkti-vitåt beschrånkenden Multitasking.

Mit dem Widerspruch zwischen der projektunabhångigenkontinuierlichen Arbeit in einem ART einerseits und derzeitlich begrenzten Fokussierung auf Projekte kann so um-gegangen werden:

• Verhindern Sie eine ausufernde „Verprojektisierung“: In-itialisieren Sie Projekte nur dann, wenn diese Fokussie-rung im Rahmen der çblichen Arbeiten eines ART sichernicht erreicht werden kann. Initiieren Sie also kein Projekt,wenn z.B. ein oder mehrere Releases fast ausschließlicheinem speziellen Fokus (etwa der Entwicklung einesneuen Funktionskomplexes innerhalb des ART) gewidmetwerden kænnen.

• Formulieren Sie enge Kriterien dafçr, was „echte“ Pro-jekte von eher „normalen“ Aufgaben und Vorhaben un-terscheidet, so, dass hæchstens 25 % ihrer aktuellen Pro-jekte als „echte“ Projekte verbleiben.

• Projekte mit einer Durchlaufzeit von mehr als sechs Mo-nate sollte es nicht geben. Unterteilen Sie umfassendereVorhaben in kleinere Projekte, die auf der Ebene des Pro-grammmanagements eines ART koordiniert werden.Denken Sie daran: Gemåß Abbildung auf Seite 4 imCHAOS-MANIFESTO 2013 der Standish Group [6] wa-ren kleine Projekte von 2003 bis 2012 fast achtmal er-

Mit Wider-spruchpragmatischumgehen

FokussierteReleasesstatt Projekte

MassiveReduktion vonProjekten

KeineGroßprojekte


Seite 25


folgreicher als große – egal, ob sie (gemåß Abbildung aufS. 25 in [6]) „agil“ oder mit „Wasserfall“ abgewickeltwurden. Der Projekterfolg korreliert mit der Projektgræße,„agil“ oder „Wasserfall“ machen kaum einenUnterschied.

• Und: Projekte dçrfen nur jeweils einen ART betreffen –andernfalls mçssen sie in Teilprojekte pro ART unterteiltund auf der Ebene des Portfoliomanagements koordiniertwerden.

• Projekte sind wenn immer mæglich Konstrukte auf derEbene des Programmmanagements eines bestimmtenART. Deren „deliverables“ sind in das Programm-Backlogdes ART integriert und dort speziell markiert. Es gibtkeine vom Programm-Backlog des ART getrennten Pro-jekt-Backlogs. Die fçr Projekte zu leistenden Arbeitenfließen anlåsslich der Release-Planungen des ART in dieTeam Backlogs ein und sind dort speziell markiert.

• Auf Teamebene kænnen die Arbeiten fçr einzelne Projektein den Planungstafeln in speziellen „swimlanes“ erschei-nen.

• Dass Projekte mæglichst nur als Konstrukte im Pro-grammmanagement behandelt werden, sollte auch beiNeuentwicklungen individueller Kundenlæsungen prakti-ziert werden, auch wenn sie auf Kundenseite in der Regelals „Projekte“ gesehen und beauftragt werden.

• In speziellen Fållen kann innerhalb eines ART fçr einProjekt ein temporåres Projektteam, bestehend aus Mit-gliedern der schon bestehenden Teams, gebildet werden.

• Als absolute Ausnahme kann fçr ein Projekt ein weiterer –zeitlich begrenzter – ART mit mehreren Teams gebildetwerden. Es ist dann jedoch zu vereinbaren, welche SW-Teile nach Projektabschluss von welchen permanentenARTs zur weiteren Betreuung çbernommen werden undwelche Teams dieser permanenten ARTs vorher bereits in

Projekte sindKonstrukteim Programm-management

Projekt-spezifischeTeams alsAusnahme


Seite 26


die Arbeit des temporåren „Projekt-ART“ einbezogenwerden.

• Fçr das Management von Projekten innerhalb einer agilenKultur eignen sich PM-Methoden, die mit Prinzipien wie„Just Enough Design Up Front“ und „Inkrementelle Lie-ferung von Ergebnissen“ gut vereinbar sind. Das trifftinsbesondere fçr PRINCE2 und DSDM zu. Die Rolle desProjektleiters ist dabei im Bereich des Programmma-nagements/Team Backlog Owner anzusiedeln, nicht aufder Ebene des Teamleiters/Agile (Scrum) Master.

2.1.12 Agiles Portfoliomanagement

Das Portfolio (alles zu „Portfolio“ in [1]) umfasst die Ge-samtheit der strategischen Themen (s. Abb. 1 in „PortfolioVision“ in [1]). Deren Prioritåten steuern die Investitionen aufUnternehmensebene. Aufgabe des Portfoliomanagements istes, dass die zukçnftig geleistete Arbeit tatsåchlich der Um-setzung der Geschåftsstrategie dient. Die strategischen The-men bestimmen die Portfolio-Vision, dargestellt als umfang-reiche Initiativen in Form von Epics. Sie fließen im Verlaufder Zeit in verschiedene Agile Release Trains ein.

Die Verantwortung fçr die Erarbeitung der Themen und Epicstragen die Portfoliomanager, das sind entweder die „Owners“der Geschåftsbereiche oder die Produktgremien und anderePersonen, die gegençber ihren Stakeholdern verantwortlichsind.

Zweck der vom Portfoliomanagement erarbeiteten Themenist es, auf dem Markt differenzierende und konkurrenzfåhigeKernprodukte anzubieten. Diese Themen haben eine weitauslångere Lebensdauer als die Epics. Gruppen solcher Themenkænnen bis zu einem Jahr oder långer unveråndert bleiben.

PM-MethodenmçssenJEDUF undProdukt-inkrementeunterstçtzen

Portfolio-managementzur Umsetzungder Geschåfts-strategie

„Themen“ desPortfoliossind langlebig


Seite 27


Es gibt zwei Arten von aus den strategischen Themen abge-leiteten Epics:

• Business-Epics stellen die græßte Verdichtung der Nut-zerbedçrfnisse dar.

• Architektur-Epics repråsentieren große technologischeVorhaben als Voraussetzung zur Entwicklung umfassen-der Læsungen, die die laufenden und zukçnftigen Unter-nehmensbedçrfnisse unterstçtzen. Deshalb erfordert dieSystemarchitektur in einem agilen Unternehmen regel-måßige Investitionsçberlegungen.

Epics sind Entwicklungsvorhaben zur Lieferung wertschaf-fender Ergebnisse fçr ein Investment-Thema und werden imPortfolio Backlog festgehalten, priorisiert, geschåtzt undlaufend gepflegt. Vor der Release-Planung eines ARTwerdensie vom Programmmanagement und den Team Backlog Ow-ners in spezifische Features aufgeteilt.

Epics kænnen dargestellt werden in Stichworten, in Formnutzersprachlicher „Stories“, in ein oder zwei Såtzen, als Vi-deo, als Prototyp oder in irgendeiner anderen Form, die ge-eignet ist, die Absicht der Produktinitiative auszudrçcken.Ziel der Epics ist die Beschreibung der strategischen Absicht,nicht dieGenauigkeit.Mit anderenWorten: Ein Epicmuss nurso weit im Detail beschrieben werden, wie damit eine zu-kçnftige Diskussion darçber ausgelæst werden kann, welcheFeatures ein Epic impliziert.

Busines-Epicswerden imKanban-System der Business-Epics(s. „Business Epic Kanban“ in [1]), Architektur-Epics imKanban-System der Architektur-Epics (s. „Architectural EpicKanban“ in [1]) erfasst. In beiden Kanban-Systemen erfolgtder weitere Bearbeitungsfluss unter Einhaltung der fçr Kan-ban typischen „Work In Progress“(WIP)-Begrenzungen.

Business-Epics

Architektur-Epics

„Epics“beschreibenwertschaffendeErgebnisseeines „The-mas“

Je ein Port-folio-KanbanfçrBusiness- undArchitektur-Epics


Seite 28


Damit wird die bisher çbliche recht starre Jahresplanung durcheine rollende und flexible Planung ersetzt.

2.2 Vorgehensmuster zur Umstellung auf agileEntwicklung und Unterhalt von plattformbasiertenLæsungen

Die Charakteristiken und Herausforderungen von großenUnternehmen/Unternehmensbereichen mit der Entwicklungund dem Unterhalt von plattformbasierten Læsungen alsHauptaufgabe wurden im Abschnitt „Wie reisen Sie mit Ih-rem Unternehmen?“ (Kap. 08A02, 3, Punkt 1) beschrieben.

Die Hauptaufgaben auch dieser Unternehmen erfordern einstrategisches Portfoliomanagement fçr die verschiedenen jenach Service Agreements mehr oder weniger langfristig zuunterstçtzenden kundenspezifischen plattformbasierten SW-Læsungen, zusåtzlich aber auch fçr die fortlaufende Pflege derkundenneutralen Plattform(en) fçr einzelne Produktlinien.

Diese Arten von Vorgehensweisen mçssen aufeinander abge-stimmt werden:1. Das Neuentwickeln oder grundlegende Ûberarbeiten kun-

denspezifischer plattformbasierter Læsungen, ohne dabeidie generelle Plattform zu verkomplizieren oder mit sepa-raten Speziallæsungen zu unterlaufen.

2. Das als „Arbeitsfluss mit unbestimmten Ende“ gestaltetePflegen und Weiterentwickeln dieser kundenspezifischenLæsungen.

Wichtig!

Abstimmen derVorgehens-weisen


Seite 29


3. Das Neuentwickeln oder grundlegende Ûberarbeiten derkundenneutralen Plattform(en) mit konsequenter Einhal-tung und fortlaufender Optimierung einer modularen, ser-viceorientierten Gesamtarchitektur.

4. Das als „Arbeitsfluss mit unbestimmtem Ende“ gestaltetePflegen und Weiterentwickeln dieser kundenneutralenPlattform(en).

Mehr noch als beim vorangehenden Vorgehensmuster zurUmstellung auf agile Entwicklung und Unterhalt plattform-unabhångiger umfassender Individuallæsungen sind hier nichtdas Vorgehen und die Methodik in einem kleinen Team dieHerausforderung, sondern die Koordination all dieser Spe-zialisten und Teams auf Programm- und Portfolioebene.

Diese vier Arten von Vorgehensweisen zusammen bilden einhochkomplexes Gebilde. Es kann nicht auf der Basis umfas-send geplanter Gesamtkoordinationsprozesse und Verant-wortlichkeiten „beherrscht“ werden. Zudem kooperieren insolchen Unternehmen in der Regel weltweit mehrere Hundertbis zu vielen Tausend Informatikspezialisten in Hundertenverschiedener Teams. Die heute auf diesem Gebiet tåtigenUnternehmen haben daher gelernt, mit dieser Komplexitåteinigermaßen erfolgreich umzugehen (sonst gåbe es sie nichtmehr) – oft natçrlichmit sehr unkoordiniert bis chaotisch oderbçrokratisch-schwerfållig anmutenden Arbeitsweisen.

„Umstellung auf agiles Vorgehen“ bedeutet fçr diese Unter-nehmen, all das, was heute bereits situativ und empirisch be-grçndet (statt auf der Basis starrer Prozesse und Verantwort-lichkeiten) funktioniert, beizubehalten und zu stårken – undSchwachstellen schrittweise zu eliminieren.

HochkomplexesGesamtgebildeist nichtbeherrschbar

Das Funktio-nierendebeibehaltenund stårken


Seite 30


Erforderlich ist ein agiles (also situativ adaptierbares) Zu-sammenspiel mehrerer agiler Vorgehensweisen und Steue-rungsebenen wie bereits vorher fçr die Entwicklung und denUnterhalt umfassender Individuallæsungen beschrieben, jetztaber mit der zusåtzlichen Berçcksichtigung kundenneutralerPattformen. Das bedeutet:

• Ein agiles strategisches Portfoliomanagement einerseitsfçr die kundenspezifisch zu entwickelnden und zu war-tenden Læsungen und anderseits – zusåtzlich – fçr dieProduktlinien der Plattform. Optionen dazu sind auch hierSAFe oder andere Varianten von Portfolio-Kanban.

• Ein agiles Programmmanagement wie vorhin beschrieben,hier jedoch zusåtzlich die Produktlinien der Plattformumfassend.

• Die Kooperation vieler Teams innerhalb eines „ValueStream“ (= eines „Agile Release Train“) kann auch hierz. B. auf der Basis von SAFe auf der Programmebene ko-ordiniert werden. Hier ist die Koordination auf der Basisvon Agile Release Trains jedoch komplexer als vorhin, dadiese sowohl die Arbeiten fçr kundenspezifisch zu entwi-ckelnde und zu wartende Læsungen als auch die ArbeitenzurWeiterentwicklung undWartung der Produktlinien derPlattform umfassen mçssen.

• Projekte zur Neuentwicklung oder grundlegenden Ûber-arbeitung der Produktlinien der Plattform sollten wennimmer mæglich vermieden werden. Sie wçrden das Ge-samtgebilde noch komplexer machen. Diese Arbeitensollten stets im Rahmen von Agile Release Trains abge-wickelt werden.

• Projekte zur Entwicklung individueller Kundenlæsungensollten mæglichst nur als Konstrukte auf der Ebene desProgrammmanagements existieren, auch wenn sie auf

SituativadaptierbaresZusammen-spiel

Portfolio-management

Programm-management

ART

Projektevermeiden

Kunden-projekte alsKonstruktedes Programm-managements


Seite 31


Kundenseite in der Regel als „Projekte“ gesehen und be-auftragt werden.

• Die wenigen dann noch wirklich nætigen Projekte mçssenin geeigneter Art mit dem Programm- und Portfolioma-nagement verknçpft werden.

• Das agile Management dieser Projekte ist mit PRINCE2oder DSDM mæglich. Oft aber wird seitens der Kunden(z. B. bei Auftrågen der æffentlichen Verwaltung) einVorgehen basierend auf einemBDUF vorgeschrieben. Dasfçhrt zu etlichen Inkompatibilitåtenmit dem inkrementell-adaptiven Vorgehen, ausgehend von einem JEDUF. Hiersollte dem Kunden entgegengekommen werden und imSinn der „agilen Agilitåt“ das vom Kunden gewçnschteVorgehen so weit als mæglich praktiziert werden.

• Das agile Arbeiten im Team hingegen ist auch hier imVergleich zum agilen Programmmanagement fçr mehrereparallele Agile Release Trains und dem agilen Portfolio-management bezçglich der Vorgehensweisen und Metho-den fçr die (Selbst-)Steuerung der agilen Arbeit innerhalbeines Teams eher einfach. Innerhalb der Teams kann auchhier mit Kanban (insbesondere bei fortlaufenden War-tungsarbeiten) oder Scrum oder Scrumban oder DSDMgearbeitet werden.

Mægliche aufeinanderfolgende Schritte fçr diese Konstellati-on sind nachfolgend in 2.2.1 bis 2.2.13 beschrieben:


Wie in der vorherigen Konstellation (Entwicklung und Un-terhalt umfassender Individuallæsungen) im Abschnitt 2.1.1beschrieben. Dabei wird besonders darauf geachtet, die mo-dulare, serviceorientierte Architektur der Plattform konse-quent einzuhalten und fortlaufend zu optimieren. Dabei ver-

Wenn „Projek-te“, dann mitPRINCE2oder DSDM

Teams wåhlenihr Vorgehenselbst


Seite 32


folgen alle das Ziel, dass kundenspezifische Læsungen dieeigentliche Plattform weder komplizierter machen noch mitseparaten Speziallæsungen unterlaufen.

2.2.2 Produktlinien/Applikationsfamilien als ValueStreams

„Value Streams“ sind – wie ebenfalls in der vorherigen Kon-stellation beschrieben – auch hier als langlebige Wertestræmezur Erzielung eines wirtschaftlichen Nutzens zu verstehen.

Nun aber gibt es zwei verschiedene Arten von Wertestræmen:

1. Weiterentwicklung und Wartung der Produktlinien derPlattform

2. Entwicklung und langfristige Wartung von plattformba-sierten Kundenlæsungen

Beide Arten umfassen die Gesamtheit aller Anforderungen,Systemdefinitionen und Entwicklungs- und Auslieferungs-schritte, die dazu dienen, ein integriertes System (die Platt-form oder eine umfassende Kundenlæsung auf ihrer Basis) zurealisieren und zu warten.

„Value Streams“ sind auch hier keine einzelnen – stets zeitlichbegrenzten – Projekte, auch nicht im Fall kundenspezifischerLæsungen.

Wie aber kænnen die Value Streams beider Arten gebildetwerden? In „Value Streams“ in [1] werden einige essenzielleFragen als Orientierungshilfe gestellt. Eswird dabei auch klar,dass die Festlegung der Value Streams von der strategischenAusrichtung des Unternehmens geprågt sein muss und nichtprimår eine Frage nur der operativen Optimierung ist.

Wertestræmefçr Plattformund Kunden-læsungen

Wertestræme(ValueStreams) vonStrategiebestimmt


Seite 33


Zwei Strukturprinzipien bieten sich an:

1. Die Value Streams repråsentieren die Produktlinien derkundenneutralen Plattform. Angemessen ist das dann,wenn sich die Einmaligkeit des Unternehmens vor allemaus der Einzigartigkeit der Plattform ergibt und nicht aufden spezifischen auf ihrer Basis realisierten kundenspe-zifischen Læsungen beruht und der Aufwand fçr die Ent-wicklung kundenspezifischer Læsungen imVergleich zumAufwand fçr die Plattform klein ist. Kundenlæsungenwerden dann innerhalb der Value Streams fçr die Pro-duktlinien der kundenneutralen Plattform entwickelt undbetreut.

2. Es gibt Value Streams einerseits fçr die Produktlinien derkundenneutralen Plattform und andererseits solche fçrcharakteristische Arten kundenspezifischer Læsungen(z. B. Branchen, Unternehmensgræße . . .) und mægli-cherweise Value Streams fçr je einen sehr großen Kundenmit einer umfassenden spezifischen Læsung. Bei dieserStrukturierung in getrennte Value Streams fçr die Platt-form einerseits und fçr Kundenlæsungen andererseits istdas Risiko allerdings hoch, dass kundenspezifische Læ-sungen die generelle Plattform komplizierter machen odermit kundenspezifischen Sonderlæsungen unterlaufen.

Beide Strukturprinzipien liefern Value Streams, die im Be-reich der Entwicklung und Wartung als Agile Release Trains(ARTs) implementiert werden und Teams mit insgesamthæchstens 150 Personen pro ART umfassen sollten. In einemgroßen Unternehmen dieser Art mit 6.000 Mitarbeitendenwird es also etwa 50 bis 60 ARTs und ebenso viele ValueStreams geben, die es auf der Ebene des Portfoliomanage-ments abzustimmen gilt.

Nur diePlattformbestimmtValue Streams

Value Streamsfçr Plattformund Kunden-læsungen

Value Streamsals ARTsimplemen-tieren


Seite 34


Trotz der Neustrukturierung in Value Streams kann die bis-herige Form des – in der Regel auf der Budgetierungsperiodefçr ein ganzes Geschåftsjahr und daher nicht sehr flexiblen –Portfoliomanagements eventuell noch beibehalten und erst ineinem spåteren Schritt flexibilisiert werden. Allerdings:

Das Portfolio ist grafisch (nicht als „Zahlenfriedhof“) fçr alleeinsehbar. Und zwar so, dass der aktuelle und zukçnftige un-gefåhre Arbeitsumfang pro Value Stream und Quartal erkenn-bar ist und somit auch angemessen begrenzt werden kann.

2.2.3 Value Streams als Agile Release Trains (ARTs)implementieren

Das fçr die vorherige Konstellation (Entwicklung und Un-terhalt umfassender Individuallæsungen) in 2.1.3 Geschrie-bene trifft auch hier zu, jedoch mit diesen Erweiterungen:

Beim Strukturprinzip „Value Streams einerseits fçr die Pro-duktlinien der kundenneutralen Plattform und andererseits fçrcharakteristische Arten kundenspezifischer Læsungen“ gibtes zwei Gruppen von Teams: Einerseits die Teams in denAgile Release Trains fçr die Entwicklung der Plattform undandererseits die Teams in den Agile Release Trains fçr kun-denspezifische Læsungen. Wenn hingegen die Value Streamsnur von kundenunabhångigen Produktlinien der Plattformbestimmt werden, gibt es keine zwei Gruppenvon Teams bzw.ARTs.

Jeder dieser ARTs umfasst Teams mit insgesamt 50 bis 100(max. 150) Personen und jeder ART ist ein weitestgehendautonomes soziales Handlungssystem, um das kaum zu leis-tende zentralistische Management Hunderter Teams und

Wichtig!


Seite 35


Spezialisten zugunsten des Vertrauens in die Selbststeue-rungsfåhigkeit sozialer Systeme abzubauen.

Wie aber kann im Fall „Value Streams einerseits fçr die Pro-duktlinien der kundenneutralen Plattform und andererseits fçrcharakteristische Arten kundenspezifischer Læsungen“ si-chergestellt werden, dass die ARTs derWeiterentwicklung derProduktlinien der kundenneutralen Plattform von den ARTsder kundenspezifischen Læsungen befruchtet werden unddass umgekehrt die ARTs der kundenspezifischen Læsungendie Neuerungen der Plattform rasch kennenlernen?

2.2.4 Plattformgruppen als Sekundårstruktur

Die Abstimmung der Weiterentwicklung der Produktliniender Plattform mit der Entwicklung kundenspezifischer Læ-sungen ist mit formalisierten Prozessen und Verantwortlich-keiten in Gestalt von Repråsentanten der Teams, die dieseKoordination leisten sollen, kaum machbar. Stattdessen sinddie fçr eine agile Unternehmenskultur essenziellen Kommu-nikationsråume zu schaffen.

In vielen Unternehmen bewåhrt sind Kommunikationsråumein Form themenzentrierter „Communities“ quer zur Linien-struktur. Im vorliegenden Fallwåren das quer zu denARTs derkundenspezifischen Læsungen gebildete Gruppen, die dieARTs der kundenneutralen Plattform erweitern. Beispiels-weise so: Eine als ART implementierte Produktlinie derPlattform befasst sich mit „Fakturierung und Zahlung“. AlleSpezialisten in den ARTs der kundenspezifischen Læsungen,die sich dort mit „Fakturierung und Zahlung“ beschåftigen,bilden zusammen mit den „Plattformleuten“ des ART „Fak-turierung und Zahlung“ mehre Plattformgruppen zum Thema„Fakturierung und Zahlung“. Mehrere deshalb, damit jededieser Gruppen nichtmehr als etwa 25 Personen umfasst. Jede

Abstimmungder Plattform-/Kunden-læsungs-ARTs

FormalisierteAbstimmungvia Repråsen-tanten unrea-listisch

Themenzen-trierte„Communi-ties“als Kommuni-kations-råume


Seite 36


dieser Gruppen trifft sich monatlich zu einem „Fçhrungs-Meeting“, wie im Abschnitt „Anpassbare Kreise statt starrerHierarchien“ (Kap. 08A03, 4.1) beschrieben wurde. Die Er-kenntnisse der einzelnen Plattformgruppen zum Thema„Fakturierung und Zahlung“ fließt in die Planungsmeetingsdes ART „Fakturierung und Zahlung“ ein. Dort sind ja alleMitglieder dieses ART in den diversen Plattformgruppen zudiesem Thema vertreten.

Wenn derartige Kommunikationsråume als „zu teuer“ abge-lehnt werden, ist das auch hier – wie bereits vorhin beimAufwand fçr die Planungsmeetings pro ART erwåhnt (Ab-schnitt 2.1.9) – ein Zeichen einer noch stark auf „Auftrags-erteilung von oben“ und „Koordination durch Repråsentan-ten“ geprågtenKultur. Es hat sich dann noch nicht die Einsichtdurchgesetzt, dass ein Unternehmen erst durch die fortlau-fende Konversation aller das Unternehmen umfassendenMitarbeitenden und Stakeholder entsteht.

2.2.5 Ûberprçfen und Anpassen der Teamstruktur

Hier ist das in der vorherigen Konstellation (Entwicklung undUnterhalt umfassender Individuallæsungen) im Ab-schnitt 2.1.4 dazu Geschriebene ohne Einschrånkungen oderErgånzungen anwendbar.

Das gilt auch fçr diese nåchsten Schritte:

2.2.6 „WAS“ vom „WIE“ trennen: pro Team ein TeamBacklog Owner

Siehe Abschnitt 2.1.5

Ungewohnt –aber sehreffektiv!


Seite 37


2.2.7 Die Teamleiter bleiben Rahmensetzer fçr das„WIE“


2.2.8 Pro „ART“ die Zeitpunkte der externen undinternen Releases bestimmen


2.2.9 Programmmanagement agil gestalten


2.2.10 Planung des kommenden „PSI“ (interner Release)eines „ART“


2.2.11 Agile Arbeit auf Teamebene


2.2.12 Projekte innerhalb eines „ART“


2.2.13 Agiles Portfoliomanagement



Seite 38


2.3 Vorgehensmuster zur Umstellung auf agile SW-Entwicklung als Dienstleistung

Die Charakteristiken und Herausforderungen von Firmen imBereich der SW-Entwicklung als Dienstleistung wurden imAbschnitt 3 „Wie reisen Sie mit Ihrem Unternehmen?“ imersten Teil dieser Reihe beschrieben (Kap. 08A02, 3).

Die Hauptaufgaben dieser Dienstleister ergeben sich aus demAnbieten von SW-Entwicklungskapazitåt (Spezialisten samtEntwicklungsinfrastruktur) imRahmen isolierter und oft ganzunterschiedlicher Kundenprojekte bis zur Inbetriebnahme derLæsung. Wartungs-, Anpassungs- und Erweiterungsarbeitenfçr diese Læsungen werden nur gelegentlich und speziell be-auftragt.

In der Regel kænnen diese Auftråge nicht långerfristig, etlicheMonate im Voraus, abgeschåtzt werden. Ein strategischesPortfoliomanagement erçbrigt sich daher oder reduziert sichauf die Festlegung jener Branchen, Kundenarten, Technolo-gien und Entwicklungsinfrastruktur, auf deren Basis das Un-ternehmen mit seinen Spezialisten heute und in Zukunft tåtigsein kann und will.

Nur wenn die Entwicklung von Individualsoftware im Rah-men eines Werkvertrags mit dem zu erbringenden Funkti-onsumfang beauftragt wird, kann der Dienstleister das Vor-gehensframework und die Entwicklungsmethodiken freiwåhlen. In aller Regel werden solche Auftråge dann als iso-lierte Projekte – oft im Haus des Dienstleisters – abgewickelt.

Diese Projekte erfordern beim Auftragnehmer in der Regelden Einsatz nur eines fçr dieses Projekt arbeitenden Teams,selten einer Handvoll Teams, manchmal auch nur einzelner

Isolierte,ganz unter-schiedlicheKunden-projekte

StrategischesPortfolio-managementkaum machbar

Vorgehens-weise nurbedingt selbstwåhlbar

Ein biswenige Teamspro Projekt


Seite 39


Personen. Ein ausgefeiltes Programmmanagement ist dahernicht erforderlich.

Oft aber werden nur SW-Entwicklungskapazitåten innerhalbvon græßeren und vom Auftraggeber selbst gemanagten Pro-jekten zur Verfçgung gestellt Der Auftraggeber bestimmtdann das Vorgehen und Teile der Methodik. Der Anbietermuss sich daher in verschiedensten Vorgehens-Frameworksund Methodiken professionell bewegen kænnen.

In jedem Fall kann (und soll) die SW-Entwicklung als pro-fessionelles Handwerk (Craftsmanship) praktiziert werden.Das steht kaum im Widerspruch zu irgendeinem der vorge-gebenen Frameworks. Diese Craftsmanship – und nicht dasBeherrschen irgend eines Vorgehensmodells – begrçndet dieWettbewerbsfåhigkeit des Dienstleisters.

Die Vorgehensweisen dieser Dienstleister sind geprågt• vom projektbasierten Arbeiten zur Entwicklung individu-

eller Kundenlæsungen mit einem (selten mehreren) tempo-råren Projektteam. Das agile Management dieser Projekteist mit einer auf das jeweils nætige Minimum zurechtge-schnittenen flexiblen und adaptiven PM-Methode wiePRINCE2 oder DSDM mæglich;

• von der Fåhigkeit, bei der Mitarbeit in Entwicklungsteamsdes Auftraggebers dessen Vorgehensweisen professionellanwenden zu kænnen;

• von Methoden und Werkzeugen zur projektçbergreifendenmittelfristigen Einsatzplanung auf Personenebene, diemæglichst einfach gestaltet sind und von den Betroffenenselbst (und nicht von einer zentralen Planungsinstanz) ge-pflegt werden kænnen;

• von all dem, was zur „Craftsmanship“ gehært.

Gesamtprojektoft vomKundengemanagt

CraftsmanshipalsWettbewerbs-faktor


Seite 40


Mægliche aufeinanderfolgende Schritte fçr diese Konstellati-on sind nachfolgend in 2.3.1 bis 2.3.8 beschrieben:


Wesentliche Elemente der „agilen Kultur“ werden praktiziert,insbesondere:

• Daily Standup (mit den nicht gerade bei Kunden arbei-tenden Personen) und etwa zweimal pro Woche mit allenPersonen unter Nutzung virtueller Kanåle (wegen der inden Håusern diverser Kunden eingesetzten Personen)

• Transparente Informationen und Sichtbarkeit, Verfolg-barkeit, Analysierbarkeit der Zusammenarbeit unter Nut-zung virtueller Kanåle

• Arbeitsplanung im Projektteam durch das Team – nichtdurch den Projektleiter

• „Agile“ Art der Fçhrung mit all jenen Einschrånkungen,die sich aus der matrixartigen Organisation ergeben (dieSpezialisten arbeiten in mittelfristig immer wieder wech-selnden Teams des Unternehmens oder der Kunden)

Craftsmanship (SW-Entwicklung als professionelles Hand-werk) ist etabliert, insbesondere:

• Nicht nur funktionierende Software, sondern gut gefer-tigte Software ist das Ziel.

• Clean Code Development prågt die Arbeitsweise.

• TDD und ATDD und die Integration von Entwicklung undTest, Continuous Integration, Continuous Delivery undTestautomation werden fortlaufend verbessert, soweit diesin den Entwicklungsumgebungen der Kunden mæglich ist.

WesentlichepraktizierteElemente

Craftsmanshipist etabliert


Seite 41


2.3.2 Ûberprçfen und Anpassen der Teamstruktur

Die in temporåren Projektteams des Dienstleisters oder derKunden arbeitenden Mitarbeitenden nach Mæglichkeit soeinsetzen, dass:

• jedes temporåre Projektteam beim Dienstleister çber per-manente, stets voll ausgelastete und daher „ungeteilte“Mitglieder/Spezialisten verfçgt, die insgesamt zum Defi-nieren/Realisieren/Testen der Softwareprodukte oder-services nætig sind;

• jederMitarbeitende des Dienstleisters immer nur in einemTeam des Dienstleisters bzw. des Kunden eingesetzt ist(kein „Multitasking“).

2.3.3 Bei (temporåren) Projektteams des Dienstleistersdas „WAS“ vom „WIE“ trennen

Ûblicherweise sind die Projektleiter Rahmensetzer sowohldafçr, „WAS“ das Projektteam zu leisten hat, als auch fçr das„WIE“. Der Vorteil ist, dass es pro Projektteam aus Kunden-sicht einen einzigen Ansprechpartner sowohl fçr das „WAS“als auch fçr das „WIE“ gibt. Der Nachteil ist, dass das funk-tionale „WAS“ allzu sehr vom machbaren „WIE“ (Kompe-tenzen im Team, Auslastung einzelner Spezialisten, Ent-wicklungsinfrastruktur) bestimmt wird und umgekehrt derProjektleiter das „WIE“ zu sehr einschrånkt. Deshalb ist esessenziell, die Rahmensetzung fçr das „WAS“ und das „WIE“auf Rollen aufzuteilen, die personell getrennt sind. Damitdiese klare Trennung gelingt, sollte die Verantwortung nur fçrdas „WAS“ (nicht das „WIE“) der gegençber dem Kunden inErscheinung tretende Projektleiter çbernehmen. Mit dem„WAS“ beschreibt der Projektleiter all das, „was“ das Teamderzeit und kçnftig zu liefern hat: User Stories, zukçnftigeFeatures, technische Stories, Fehlerbehebungen, Infrastruk-

TemporåreProjektteams

Kein Projekt-Multitasking

Projektleiter =„WAS“-Ver-antwortlicher =Team BacklogOwner


Seite 42


turarbeiten, Spikes, Refactorings usw. Auch wenn einzelnedieser Dinge im Team erarbeitet werden, bleibt er als Pro-jektleiter allein verantwortlich fçr diese Liste und alles, wasdarin enthalten ist, und fçr die Reihenfolge der Eintråge. Er istals einzige Person fçr die Verwaltung des Team Backlog ver-antwortlich.

Der Projektleiter als Team Backlog Owner entlastet das Teamvom Klåren widersprçchlicher und vom Priorisieren vielergleichzeitig vorliegender Anforderungen diverser An-spruchsgruppen. Das Team verhandelt das „WAS“ seinerArbeit ausschließlich mit seinem Projektleiter als TeamBacklog Owner, einschließlich der nichtfunktionalen Anfor-derungen. Das Team ist fçr den realisierten Lieferumfang nurgegençber seinem Projektleiter als Team Backlog Owner undnicht diversen anderen Anspruchsgruppen direkt verantwort-lich.

2.3.4 Rahmensetzer und Unterstçtzer fçr das „WIE“ beitemporåren Projektteams des Dienstleisters

Neben dem Projektleiter als Team Backlog Owner hat jedesProjektteam einen „Wie-Verantwortlichen“ im Sinn einesScrum Master oder Agile Master. Im Unterschied zu den fçrlångere Zeit existierenden Teams der vorherigen zwei Kon-stellationen sind sie keine Teamleiter. Im Einvernehmen mitder – hier aber von der tagtåglichen Arbeit „ihrer“ Mitarbei-tenden entkoppelten – Fçhrungsperson kçmmert sich dieserAgile Master auch um die individuelle Færderung der Team-mitglieder auf der Basis der von ihm Tag fçr Tag miterlebtenArbeit.

(Bei in Teams des Kunden entsandten Mitarbeitenden desDienstleisters ist auch das nicht gegeben. Dort muss sich dievon der tagtåglichen Arbeit „ihrer“ Mitarbeitenden entkop-

„WIE“-Verantwort-licher =Agile Master


Seite 43


pelte Fçhrungsperson bei ihrer Fçhrungsarbeit auf Informa-tionen des Kunden stçtzen.)

2.3.5 Agiles Vorgehen bei den im Haus des Dienstleistersabgewickelten Projekten

Inwieweit Projekte „agil“ abgewickelt werden kænnen, istumstritten (s. Kap. 08S01, 3.2).

Wenn der Kunde mit dem Begriff „Projekt“ jedoch nicht be-reits zu Beginn klare und detaillierte Ziele und vereinbartezeitliche und finanzielle Ressourcen versteht, sondern ein-verstanden ist, dass die Ziele zu Beginn nur grob definiert undim Projektverlauf im Rahmen der Termine und Kosten inAbsprache mit ihm ohne ein langwieriges Change RequestManagement veråndert werden kænnen, ist ein inkrementell-adaptives Vorgehen mæglich. Im Rahmen der Initialisie-rungsphase wird dann ein Projekt-Backlog, bestehend aus„Features“ (nicht bereits aus „Stories“) als eine der wichtigs-ten Grundlagen der Projektsteuerung erarbeitet.

Das agile Projektvorgehen insgesamt kann auf der Basis eines– auf das unbedingt nætige Minimum „zurechtgeschnittene“ –PRINCE2 oder DSDM erfolgen.

Die vertragliche Regelung sollte auf einem „agilen Festpreis“[5] beruhen.

2.3.6 Pro im Haus des Dienstleisters abgewickeltemProjekt die Zeitpunkte der externen und internenReleases bestimmen

Idealerweise sollte beim agilen Vorgehen alle zwei bis vierWochen, beim flussorientierten Vorgehen immer dann, wennetwas fertig ist, ein auslieferbares Software-Inkrement er-

Ideal alle zweibis vierWochen


Seite 44


zeugt werden. Das setzt jedoch voraus, dass das mæglicher-weise recht heterogene System des Kunden ein in so kurzenAbstånden in seinem System getestetes und zuverlåssig lauf-fåhiges Inkrement auszuliefern erlaubt und die Nutzer beimKunden gewillt sind, regelmåßig alle zwei bis vier Wochenoder noch håufiger neue und geånderte Softwarefunktionenzu erhalten und zu erlernen und ihre Arbeitsablåufe daraufabzustimmen.

Vom Projektleiter zu klåren ist daher:

• Wie groß also ist die Volatilitåt der Anforderungsånde-rungen? Wieviel Prozent der Anforderungen åndern sichpro Woche oder Monat oder Quartal?

• Wie håufig wçnschen die Nutzer neue Releases?

Die Antwort bestimmt die Håufigkeit der externen, also ef-fektiv ausgelieferten und produktiv gesetzten Releases.

Wenn fçr das Projekt die Zeitpunkte der (nicht unbedingt re-gelmåßigen) externen Releases mittelfristig abgeschåtzt sind,stellt sich folgende weitere zusammen mit allen Teams desProjekts zu beantwortende Frage:

• Wie groß ist die optimale Dauer der internen (fçr die ei-gentlichen Nutzer unsichtbaren) Releases?

Deren Takt ist regelmåßig und nie långer als jene minimaleDauer, in der alle zum internen Release beitragenden Teamsgemeinsam ein „Potentially Shippable Increment“ (PSI) soerzeugen kænnen, dass die Beitråge aller Teams in eine be-triebsnahe Integrationsumgebung erfolgreich çberfçhrt unddort sowohl technisch (inklusive aller nichtfunktionalen An-forderungen) als auch fachlich erfolgreich getestet werdenkænnen.

Projektleiterklårt


Seite 45


2.3.7 Planung des kommenden „PSI“ eines im Haus desDienstleisters abgewickelten Projekts

Hier ist das in Abschnitt 2.1.9 dazu Geschriebene sinngemåßanwendbar, wobei „Agile Release Train“ durch „Projekt“ er-setzt ist und das „Programmmanagement“ durch den „Pro-jektleiter“.

2.3.8 Agile Arbeit in den Teams der im Haus desDienstleisters abgewickelten Projekte

Inwieweit einzelne Teams innerhalb der Realisierung einesPSI in Anlehnung an Scrum in Sprints oder mit Kanban oderScrumban oder nach eigenemMuster arbeiten, kann auch hierden Teams çberlassen werden. Fçr die Teams ist mit der Re-lease-Planung pro Projekt der Rahmen fçr das „WAS“ gesetzt.Der Agile Master hat die Verpflichtung, den Rahmen fçr das„WIE“ zu setzen, ohne dabei das „WAS“ zu erschweren.

Alles Weitere entspricht dem fçr die vorherigen zwei Kon-stellationen zu „Agile Arbeit auf Teamebene“ bereits Ge-schriebenen.

3 Rçckblick auf alle drei Teile der Reihe „Wie Sieauf agile SW-Entwicklung umstellen“

Ausgehend vom Beitrag „Agile Konzepte“ (Kap. 08A01),wurde in drei weiteren aufeinander aufbauenden Beitrågendie Umstellung auf eine agile Form der SW-Entwicklung be-schrieben.

Der erste Beitrag (Kap. 08A02) zeigte, dass diese UmstellungVerånderungen der Unternehmenskultur voraussetzt. Dassind langfristige und strategisch relevante Investitionen. Erst

Konzepte

Verånderungder Unterneh-menskultur


Seite 46


auf dieser Basis kænnen die jeweils angemessenen und ver-gleichsweise kurzlebigenMethoden und Techniken der agilen(aber auch „traditionellen“) SW-Entwicklung sinnvoll genutztwerden. Der erste Beitrag gab einen zusammenfassendenÛberblick çber einige Methoden und Techniken zur Kultur-verånderung und schlug danach einen agilen Umgangmit denMethoden und Techniken der agilen SW-Entwicklung vor,wobei die „Craftsmanship“ und das „Clean Code Develop-ment“ unabhångig von der Vorgehensweise zentrale Bedeu-tung haben.

Der zweite Beitrag (Kap. 08A03) beschrieb im Detail einigeMethoden und Techniken fçr diese Kulturverånderung imBereich der Kommunikation, Kooperation und Fçhrung, undzwar:

• Etablierte Konversationsråume

• Daily Standup

• Erfahrungs- und Praxisgemeinschaften

• Transparente Informationen

• Unternehmensinterne Kommunikation mittels SocialMedia

• Sichtbarkeit, Verfolgbarkeit, Analysierbarkeit der Zu-sammenarbeit

• Arbeitsplanung imTeam durch das Team– nicht durch denTeamleiter

• Kontinuierliche Verbesserung der Kooperation im Team

• Teamarbeit mit Elementen von Scrum

• Optimierung der Teamstruktur

• Anpassbare Kreise (statt starrer Hierarchien) mit Fçh-rungsmeetings, wæchentlichen taktischen Meetings undDaily Standup Meetings

Methoden undTechniken zurKulturverån-derung


Seite 47


• Change Events: Nur den Rahmen setzen, das Bild malenlassen

• „Agile“Art der Fçhrung

• Fçhren von Teams

• Teamleiter – neu definiert

Im dritten Beitrag (Kap. 08A04) wurden Vorgehensmusterzur Umstellung auf agile Entwicklungsmethoden fçr dieseSituationen beschrieben:

• Entwicklung und Unterhalt umfassender Individuallæ-sungen

• Entwicklung und Unterhalt von plattformbasierten Læ-sungen

• SW-Entwicklung als Dienstleistung

Diese drei Vorgehensmuster umfassen die Ebenen des Port-folio- und Programmmanagements und die Teamebene undfolgen demagilen (und nicht „normierten“) Einsatz agiler und„traditioneller“ Methoden und Techniken.

Das Vorgehensmuster fçr die Umstellung auf agile Entwick-lung und Unterhalt plattformbasierter Læsungen ist das um-fassendste, bestehend aus diesen Schritten:

• Voraussetzungen

• Produktlinien/Applikationsfamilien als Value Streams

• Value Streams als Agile Release Trains (ARTs) imple-mentieren

• Plattformgruppen als Sekundårstruktur

• Ûberprçfen und anpassen der Teamstruktur

• Das Was vom Wie trennen: pro Team ein Team BacklogOwner

Kontext-abhångigeVorgehens-muster


Seite 48


• Die Teamleiter bleiben Rahmensetzer fçr das Wie.

• Pro ART die Zeitpunkte der externen und internen Re-leases bestimmen

• Programmmanagement agil gestalten

• Planung des kommenden PSI (interner Release) einesART

• Agile Arbeit auf Teamebene

• Projekte innerhalb eines ART

Diskussionsforum zum Thema „agile SW-Entwicklung“

Dieser letzte und alle vorangehenden Beitråge der Serie zumThema „agile SW-Entwicklung“ bieten viel Diskussionsstoff.Deshalb hat der Autor dazu in Xing ein Diskussionsforumeingerichtet:

tinyurl.com/py8wgke

Ihre Beitråge und Fragen sind willkommen!

[1] scaledagileframework.com/glossary/

[2] Oberrath, Reick; Vollmer, Jærg: Clean Coding Cosmos.In: OBJEKTspektrum. 11/12.2013

[3] scaledagileframework.com/ -

agile-software-requirements-model/

[4] Korn, Hans-Peter: Agile Fçhrung: Ein Oxymoron? In:OBJEKTspektrum, Ausgabe 05/2014

[5] Opelt, Andreas: Der agile Festpreis: Leitfaden fçr wirk-lich erfolgreiche IT-Projekt-Vertråge. Carl Hanser, 2012

[6] Standish Group: CHAOS MANIFESTO 2013.

versionone.com/assets/img/files/ -

ChaosManifesto2013.pdf

XING-ForumzurBeitragsserie

Quellen


Seite 49


Wie Sie auf agile Software-Entwicklung umstellen – Agile...

Documents

Transcript of Wie Sie auf agile Software-Entwicklung umstellen – Agile...