ASE: Immer besser mit starken Teams!Agile Software Engineering bei der SAPIn den SAP Labs arbeiten mehr als 10.000 Entwicklungsingenieure in 11 Ländern, über den Globus verteilt. Seit einem Jahr ver-bessern diese Labs ihre Arbeitsweise: Mit Unterstützung des Karlsruher Beratungshauses andrena objects hat die SAP einTrainings- und Coaching-Konzept ausgerollt, mit dem ein Kanon von Softwareentwicklungspraktiken bei der SAP formuliert wird.Elemente aus Scrum und eXtreme Programming ergänzen sich mit bewährten Techniken und Arbeitsweisen aus derProjekterfahrung von andrena und SAP zu „Agile Software Engineering (ASE)“.

Scrum allein genügt nichtUnter der Vielzahl von agilen Projekt -steuerungsmethoden hatte sich Scrum zudiesem Zeitpunkt klar durchgesetzt.Gleichzeitig war in der Community eineDiskussion über Limitierungen von Scrumund notwendige Ergänzungen im Gange –das Stichwort, welches die Diskussionbeherrschte, kam von Matin Fowler undhieß „Flaccid Scrum“ (siehe [Fow] und[Sch10]). Hierbei ging es unter anderem umdie Frage: Was geschieht eigentlich genau

wicklung zugewandt hat. 2005 befasstensich bereits erste Teams mit der Einführungvon Extreme Programming (vgl. [Bec00]).Für den Java Technologiestack und – ver-zögert dann auch für ABAP – werdenPraktiken wie Unit Testing und Refactoringevaluiert und verbreitet. Ab 2006 setzt SAPScrum [SuB02] als offiziell unterstützteOption für die Projektplanung und -steue-rung ein und 2009 löst Scrum den bisherpraktizierten wasserfall-basierten Prozesszur Produktentwicklung endgültig ab.

Die Geschichte der SAP ist geprägt vom ste-tigen Wachstum von einer kleinen Fünf-Mann-Firma in Nordbaden zu einem derweltgrößten unabhängigen Softwareliefe -ran ten mit mehr als 45.000 Mitarbeitern inüber 50 Ländern. Die Geschichte ist reichan Innovationen und Veränderungen.

Vom Wasserfall zu ScrumSo ist es kein Wunder, dass die SAP sichfrüh agilen Methoden der Softwareent -

der au tor

1 www.objektspektrum.de

advertorial

Fahd Al-Fatish

(E-Mail: Fahd.alfatish@andrena.de) hat in Deutschland sein Informatik-Studium 1997abgeschlossen und arbeitete zunächst alsSoftwareent wickler in Smalltalk und Java. Heuteleitet er das Consulting-Geschäfts feld bei derandrena objects AG in Karlsruhe und ist tätig alsCoach und Trainer für Scrum und eXtremeProgramming in verschiedenen Projekten inDeutschland und Europa.

Michael Roemer

(E-Mail: michael.roemer@sap.com) kam als Berater 1999 zur SAP AG. Zurzeit ist er alsLeiter der Abteilung Quality Engineering für dieEinführung von Trainingsmaßnahmen für Entwick -lungsingineure, die Verbesserung von Prozessenund Tools in der Softwareentwicklung und dieEinführung der Qualitätsstrategie verantwortlich.Damit hilft er mit dem Team die Transformation derOrganisation hin zu agilen Entwicklungsprozessenzu unterstützen.

Martin Fassunge

(E-Mail: martin.georg.fassunge@sap.com) ist im weiteren Sinne der Spiritus Rector für dieEinführung von Lean-Prinzipien bei der SAP AG. Erist u.a. Product Owner für ein Lean/Agile CoreTeam, das die Organisation bei der Transformationhin zu schlanken und agilen Prozessen initiiert undunterstützt. Er arbeitet seit über 13 Jahren bei SAP,zuletzt als Development Program Director imManagement im Bereich Technology InnovationPlatform Core.

Timm Reinstorf

(E-Mail: timm.reinstorf@andrena.de) arbeitet seit neun Jahren als Softwareentwicklerund Coach für agile Prozess- und Engineering-Methoden bei andrena. In Softwareprojekten nimmter sowohl die Rolle eines Umsetzers als auch dieeines Coaches ein. Seine Tätigkeiten umfassten bis-her die Bereiche Anforderungsanalyse mitMitarbeitern des Fachbereichs, technische Leitungvon Projekten und Mitarbeit bei der technischenUmsetzung sowie Coaching derEntwicklungsteams.

Jürgen Staader

(E-Mail: juergen.staader@sap.com) ist seit 2000 bei der SAP AG tätig. Dort beschäftigteer sich mit Design und Entwicklung verschiedenerTest- und Entwicklungswerkzeuge für ABAP, C++und Java in wechselnden Rollen als Entwickler,Scrum Master, Product Owner und zuletztDevelopment Manager. Er unterstützt die Lean-Transition der SAP AG als Experte für agileMethoden und ist einer der Initiatoren der ASEInitiative.

zwischen Planning und Review Meeting?Wie kann man da die Qualität der Softwareabsichern?

Software Engineering ist vielschichtigund birgt sehr verschiedenartige Heraus -for derungen. Wir wollen ein einfaches Bildvon 4 Sphären (Abbildung 1) skizzieren,um unser Programm ASE zu erläutern.

1. Da ist zunächst die äußere Sphäre derProjektplanung und -steuerung. Hierbegegnen sich die Welt der Geschäfts -prozesse und die Welt der Software -entwickler. Die zentralen Herausfor -derun gen, die diese Sphäre an ein agilesSoftware Engineering-Konzept stellt,heißen: sicheres Beherrschen einer ite-rativ-inkrementellen Projektplanungund -steuerung sowie die Fähigkeit,schnell und „just in time“ ein gemein-sames Verständnis von Business-Leutenund Softwareentwicklung für dieAnforderungen an das System herzu-stellen. Die Antworten auf diese Heraus -forderungen hat Scrum gegeben undeine Reihe von (mittlerweile) allgemeinanerkannten Regeln, Strukturen, Vor -gehen, Arbeitstechniken und Werkzeu -gen etabliert (siehe auch Abbildung 2).Das ist bei SAP mittlerweile geübtePraxis und einem (in Scrum inhärentvorhandenen) ständigen Ver bes serungs -prozess unterworfen.

2. Die Entwicklung innovativer Produkteund die beständige Innovation desSoftwareentwicklungsprozesses selbstbraucht Hochleistungsteams, das heißt,

Teams, welche die anstehenden Pro -duktentwicklungsaufgaben selbststän-dig abschätzen, umsetzen und in kur-zen Feedbackzyklen gemeinsam mitdem Produktmanagement vorantrei-ben.Auch hier gibt Scrum den Rahmen vor.Scrum etabliert ein Organisations -schema, das dem (Entwicklungs-)Teamdie Hoheit über die Planung seinerAufgaben und die Organisation vonderen Umsetzung gibt (siehe z. B.[Coh05]).Die offene Frage lautete hier: Scrum –genauer gesagt: Scrum, in seinerursprünglichen Form ([SchI]) – fordertzwar selbstorganisierte Teams, gibtaber keine Hinweise dafür, wie ein

Team sich selbst organisieren muss,welche Arbeitstechniken und Werkzeu -ge es nutzen kann, um als Team nachjedem Sprint tatsächlich ein Stück(Inkrement) auslieferbarer Softwareabzugeben.

3. Produktideen müssen schnell und inhoher Qualität mit modernen Engi -neering-Methoden umgesetzt werden.Die Sphäre des Quality Engineeringformuliert die alten Herausforderungennach beständiger Verbesserung vonQualität und Produktivität. In dieserSphäre sind die zentralen Praktiken vontestgetriebener Entwicklung – UnitTesting, Refactoring, Pair Program -ming, Continuous Integration – ange-siedelt.

4. Den inneren Kern unserer Software-Engineering-Sphären schließlich bildetdie Sphäre der Engineering Principles.Diese Prinzipien sind vor fast 40 Jahrenformuliert worden [Lis74]. Die Objekt -orientierung bildet einen seit Jahrenstabilen Rahmen von Prinzipien.Gamma et al. [GHJ95] haben eineReihe von konkreten Anwendungs -mustern formuliert, die geradezu kano-nischen Charakter bekommen haben.Den jüngsten Impuls gab Robert C.Martin (Uncle Bob) mit seiner CleanCode Initiative [Mar08]. Die Väter von Scrum haben übrigensdie Beherrschung dieser Prinzipien alsselbstverständlich vorausgesetzt undsich deshalb ursprünglich hierzu nichtgeäußert.

2Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 advertorial

Abb. 1: Sphären des Softwareentwicklungsprozesses(© andrena objects ag, © SAP AG)

Abb. 2: Von Scrum eingeführte „Best Practices“(© andrena objects ag, © SAP AG)

Trainingsstacks haben die identischekonzeptionelle Grundlage

■ Der Schwerpunkt liegt auf derVerbesserung des Umgangs mit UnitTests und einer nachdrücklichen Emp -feh lung von testgetriebener Entwick -lung ebenso wie auf Pair Programming

■ Ein Training in einer „Reinraum-Umgebung“ alleine genügt nicht.Unmittelbar im Anschluss an ein ein-wöchiges Training, in dem die BestPractices vermittelt und im Team geübtwerden, wird das Gelernte im eigenenProjekt in drei einwöchigen Kurzsprintsauf seine Alltagstauglichkeit überprüft.Diese drei Wochen werden von erfahre-nen Coaches begleitet.

■ Training und Coaching sind derStartpunkt eines Prozesse der kontinu-ierlichen Verbesserung – sowohl derEntwicklungsteams und ihrer Prozesseals auch des Programms selbst.

ZieleDas Ausbildungsprogramm ist vielschich-tig. Die von uns formulierten Ziele lassensich in vier Bereichen beschreiben:

■ Der erste Bereich betrifft das ThemaQualität. Der zentrale Hebel sollte dieVermittlung der Praktikabilität vonTest Driven Development sein.

■ Den zweiten Bereich bildet dieFähigkeit der Teams, regelmäßig (nachjedem Sprint oder in einer durch „LeanProduct Development“ vorgegebenenTaktung) auslieferbare, nutzbareSoftware zu liefern. Dies beinhaltet dieFähigkeit, den Aufwand abzuschätzen,Iterationen verlässlich zu planen undebenso verlässlich zu liefern. Dazugehören auch die Reduzierung von

unserem Programm ASE an Scrum-Teams(Entwicklungsteam + Scrum Master + Pro -duct Owner) richten müssen. Scrum-Teamssollten schon im Training, und erst recht imanschließenden Coaching, erfahren, was esheißt, als Team zu lernen, als Team besserzu werden.

Das Konzept ASE heißt zusammengefasst:■ Kanonisierung von Best Practices,

Training und Coaching – Entwicklungeines gemeinsamen Erfahrungshori -zonts von Software Engineering – ein-gebettet in Scrum

■ Vermittlung dieser Best Practices ininitialen Trainings (1 Woche)

■ An jedem Trainingstag nicht mehr als40 Minuten Theorie

■ Entwicklung von spezifischen Trainingsfür unterschiedliche Technologiestacks(Java Web, Java RCP, ABAP). Alle

Mit der flächendeckenden Einführung vonScrum im Jahre 2009 hatte also SAP einmächtiges Werkzeug für die Projekt -steuerung. Gleichzeitig arbeiten bei derSAP AG über mehrere tausend hochqualifi-zierte Software-Ingenieure, die mit ihrenjeweiligen Technologiestacks (im Wesent -lichen ABAP und Java) bestens vertrautsind.

Der nächste Schritt lautete also, ein kon-zernweit einheitliches Verständnis zu ent-wickeln, wie diese Bereiche zu verbindensind. Hier genau setzt ASE an. DerSchwerpunkt liegt folglich in den beidenmittleren Sphären unseres Modells: TeamEmpowerment und Quality Engineering(siehe Abbildung 3).

Eine Überschneidung mit den von Scrumeingeführten Praktiken ist nicht zufällig,sondern gewollt. Scrum bietet dieseAndockpunkte geradezu an: Iterations -planung, Definition of Done und Inkre -men telle Lieferung. Wir passen so ASEnahtlos in Scrum ein.

Kenntnisse und Fertigkeiten in der inne-ren Sphäre „Engineering Principles“ setzenwir in unserem Programm voraus. Es hatsich allerdings in der Zwischenzeit gezeigt,dass Training und konsequente Anwen -dung von ASE die eine oder andere Lückeauch hier transparent machen. Die Teamsmüssen dann entscheiden, wie sie dieseLücke schließen wollen.

ASE: Training und Coachingfür die Scrum-Teams Die ersten Gespräche von SAP und andrenahaben schnell gezeigt, dass wir uns mit

advertorial

3 www.objektspektrum.de

Abb. 3: Vom Programm ASE abgedeckte "Best Practices"(© andrena objects ag, © SAP AG)

Referenzen

[Bec00] Kent Beck: Extreme Programming Explained. Embrace Change 2000

[SuB02] Ken Schwaber, Mike Beedle: Agile Software Development with Scrum 2002

[Coh05] Mike Cohn: Agile Estimation and Planning, 2005

[Fow] http://martinfowler.com/bliki/FlaccidScrum.html

[Sch10] http://www.andrena.de/know-how/scrum

[SchI] Interview mit Ken Schwaber in OS 3/2010

[Lis74] Barbara Liskov: Programming with Abstract Data Types (1974),

http://en.scientificcommons.org/42608342

[GHJ95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns: Elements

of Reusable Software, 1995

[Mar08] Robert C. Martin: Clean Code, 2008

„Konsolidierungsphasen“ nach dereigentlichen Entwicklung, die Er -höhung der Qualität und die Ent -wicklung einer Team-Velocity alsPlanungsgrundlage.

■ Der dritte Bereich ist die Produk tivi -tätssteigerung – nicht nur vermittelt überden erwarteten Quali tätssprung und dieFähigkeit der Scrum Teams, in kurzenAbständen auslieferbare Produkte zuentwickeln, sondern auch über verein-heitlichte Engineering-Prozesse.

■ Der vierte Bereich, nur indirekt betriebs-wirtschaftlich fassbar, aber vielleicht mitden weitgehendsten Impli kationen: DieBefähigung der Teams, zu planen, zusteuern und nach ihren Qualitäts -

maßgaben zu entwickeln. Es ging darum,dass Teams sich als Team mit einer eige-nen Teamidentität erfahren und als Teamgesamtverantwortlich handeln.

Uns war klar, dass wir diese Ziele nicht miteiner Woche Training erreichen können. ImTraining vermitteln wir den Teams: „Sokann es gehen!“ In den drei WochenCoaching im Projektkontext vermittelnwir: „Es geht auch in Eurem Projekt!“

ErgebnisseNach einem Jahr haben wir eine Vielzahlvon Teams an Standorten in 8 Ländern trai-niert und gecoacht. Die Reaktion derTeilnehmer (Teams, Scrum Master, Product

4Online-Themenspecial Agility 2011

Online-Themenspecial Agility 2011 advertorial

„The ASE training not only taught very useful I techniques, it also changed the mind-set in the team.“

„I feel quite more confident about my engineering skills now.“

„the only real team training at SAP“

„TDD really changes our way of thinking about software developing and testing.

„Good training will use this as a benchmark for future trainings in SAP.“

„all teams we collaborate with should do that“

„mehr solche Kurse!“

„Best SAP course ever!!!“

„Eine echte Bereicherung für Entwickler bei SAP“

„best training I attended at SAP:-), many info, good portions, very good sample[?cashing?], can make use of a lot of contents directly“

Abb. 4: Zitate von Kursteilnehmern

Abb. 5: Beispiele für die Entwicklung vonTests und Testabdeckung bei gecoachtenTeams

Owner, z. T. auch Linienmanager) war mitwenigen Ausnahmen sehr gut, oft sogarenthusiastisch. Abbildung 4 gibt einigeZitate von Teilnehmern unmittelbar nachBesuch der initialen Trainingseinheit wider.

Das ASE-Programm wird von SAPResearch in einem Survey begleitet.Teilnehmer werden vor den Trainings undnach drei Monaten zu Ergebnissen befragt.Leider liegen bei Redaktionsschluss nurvorläufige Ergebnisse vor. Diese zeigen aberschon jetzt: Es gibt nicht nur eine sehr gro-ße theoretische Akzeptanz bei allenBefragten (Entwickler, Scrum Master,Product Owner und Managern). Diegelernten Praktiken wurden zu einemhohen Grad dauerhaft in den Projektalltagübernommen.

Aber auch quantitativ lassen sich ersteErgebnisse vorzeigen. So konnte ein großerTeil der trainierten Teams die Test -abdeckung in und nach dem Coaching sig-nifikant erhöhen (vgl. Abbildung 5).

Der Enthusiasmus ist groß, jetzt gilt es,die Mühen der Ebenen zu meistern:Weiteres Roll Out, sodass der Kanon vonASE zum gemeinsamen und akzeptiertenBezugspunkt aller Engineering-Teams derSAP wird. Unterstützung der Teams imProjektalltag, sodass nicht unter der Lastvon Termindruck und Alltagsschwierig -keiten Qualität und Engineering-Disziplingeopfert werden. Beständige Verbesserungund Ausdehnung des ASE-Programms.

Und die richtig gute Nachricht zumSchluss! Auch Sie können von ASE profi-tieren. Bereits jetzt ist das ASE-Programmfür Java für Dritte zugänglich! ■