Scrum im Stresstest. Scrum Days 2015 Dr. Stefan Barth

Transkript

1 Scrum im Stresstest Scrum Days 2015 Dr. Stefan Barth

2 bis 2009 Wasserfallorientierte Vorgehensmodelle PMI-basiertes Projektmanagement 2009 bis 2011 Erstes Herantasten an agile Vorgehensmodelle Schulungen und Testballons Begleitung eines Großprojekts in der Umstellung auf Scrum, sowohl in einer beratenden als auch softwareentwickelnden Rolle 2013 bis heute Volle Akzeptanz agiler Methoden sowohl in der Entwicklung als auch im Management Bedarfsorientierter Einsatz in allen erdenklichen Kundensituationen Sukzessive Umstellung von Legacy- Projekten auf Scrum Favorisierung von Scrum als Vorgehensmodell in neuen Projekten Ersterstellung agiles Festpreismodell und Implementierung im Vertrieb Aufbau eines an die Scrumabläufe angepassten Projektreportings und Controllings 2

3 Verkaufsargumentation Für Sie ist es von Vorteil, ein agiles Vertragsmodell zur wählen, weil: Das Anforderungsmanagement verlagert sich in die Entwicklungsphase die Vorarbeiten vor dem Projektstart sind deutlich geringer Durch die sprint-orientierte Vorgehensweise können Anforderungen in kurzen Zyklen angepasst werden Die Anpassungen erfolgen nach einem definierten Regelwerk Die Entwicklung orientiert sich nach den fachlichen Schwerpunkten Bereits früh sind fachliche Ergebnisse zu sehen Der Projektfortschritt ist durch die regelmäßigen Reviews transparent 3

4 Das ist erfolgreich! In 2014 wurden 100% der Neukundenprojekte nach einem agilen Vorgehensmodell abgewickelt In 80% der Projekte war dies auch für den Kunden transparent 2 Kunden entschieden sich für einen agilen Festpreis der Rest operierte nach Time & Material 4

5 Drei Beispiele Segment: Öffentlicher Sektor Projektvolumen: 403 PT Laufzeit: Segment: Mittelstand Projektvolumen: ca. 412 PT Laufzeit: Segment: Großkonzern Projektvolumen: 195 PT (fortlaufend steigend) Laufzeit:

6 Die Rahmenbedingungen... der Öffentliche Das Projekt wurde im Kontext eines Rahmenvertrags, der über eine Ausschreibung gewonnen wurde, abgewickelt. Die Anforderungen wurden durch uns beim Kunden erfasst, die Umsetzung erfolgte agil. Vereinbart wurde ein Gewerk auf Basis eines EVB-IT-Vertrags. Dem Kunden war unser agiles Entwicklungsvorgehen bewusst und er hieß es gut. Eine dies dokumentierende, vertragliche Regelung gab es nicht. Regelmäßige Abstimmungsmeetings wurden vereinbart, im Rahmen derer der Projektfortschritt dokumentiert wurde. 6

7 Der Projektverlauf Jan/Feb 2014: Vorprojekt Anforderungsanalyse für den Kunden 30 PT Projektstart: Mai 2014, Zieldatum Okt 2014 Auslieferung finales Release: Nov PT... 4 Nachbeauftragung und Bug Fixing-Phasen, kundeninterne Abstimmungen und Koordination, BSI Sicherheitstest Auslieferung finales Release: Jun PT 403 PT geschätzt: 339 PT 7

8 Projektbestimmende Faktoren Die Komplexität der Umwandlung des Pflichtenhefts in ein qualifiziertes Backlog wurde unterschätzt Die Komplexität der Integration des eigenen IAM-Produkts in den Applikationsstack erwies sich als technische Komplikation Nach der Kernentwicklungsphase (bis November 2014) konnte das Team nicht mehr aufrecht erhalten werden à Teamwechsel kostete Velocity Eine diversifizierte Struktur von Stake Holdern (organisationsübergreifend) verzögerte maßgebliche, fachliche Entscheidungen Die Steuerung der eigenen, weiteren involvierten Dienstleister erfolgte nicht plangerecht Auf der Zielgeraden ergaben sich maßgebliche, fachliche Änderungen, die die Produktion zusätzlich erheblich verzögerten 8

9 Projektbilanz Budgeteinhaltung Zeitlinien Fachlichkeit 9

10 War der agile Ansatz richtig? Der Kunde hat die Möglichkeiten des agilen Anforderungsmanagements nicht genutzt Die regelmäßigen Projektabstimmungen mit sichtbaren, fachlichen Ergebnissen schaffte Vertrauen auf der Kundenseite Klassisches Anforderungsmanagement und Backlog-Erstellung parallel zu betreiben, erzeugt sinnlose Zusatzaufwände Die Teammotivation war durchgängig hoch und ein hochwertiges Softwareprodukt (kürzeste Deploymentzyklen, hohe Testautomatisierung, Softwaresicherheit) wurde erstellt trotz einer eher unattraktiven Fachlichkeit In der Nachbeauftragungsphase kam uns und dem Kunden das Vorgehensmodell aufgrund der kurzfristigen Repriosierungsmöglichkeiten entgegen 10

11 Die Rahmenbedingungen... der Mittelständler Das Projekt wurde über eine Ausschreibung gewonnen, ein vorangegangener Kundenkontakt bestand nicht. Der Kunde fand großes Interesse an dem agilen Vorgehensmodell - verspürte aber auch ein Misstrauen, ob er am Ende das erhält, was er benötigte (Aussage Kunde: bereits zweimal mit Wasserfallmodellen gescheitert). Vereinbart wurde ein Gewerk auf Basis eines agilen Festpreismodells. Den größten Wert legte der Kunde auf die Einhaltung des Zeitplans. 11

12 Der Projektverlauf Jan 2015, Projektstart Entwicklungsphase Jan Juni PT Lieferung des finalen Releases am Folgereleases geplant (minor Bugs, strittige Themen, neue Features) 412 PT geschätzt: 269 PT 12

13 Projektbestimmende Faktoren Die in unserem agilen Vertragsmodell vorgesehene Initialphase (Übertragung der Anforderung in ein qualifiziertes Backlog) wurde übersprungen. Der PO wurde zu gering in seinem Aufwand eingeschätzt Das Vorgehensmodell wurde offensichtlich nicht klar genug dargestellt die Kundenerwartung war eine andere Das Misstrauen seitens des Kunden bezügl. des Vorgehens konnte im Projektverlauf nicht zerstreut werden Trotz anderer Regelungen wurde das Backlog nicht als verbindlich abgenommenes Artefakt zur Leistungserbringung verstanden, am Ende glaubte der Kunde nach Best Choice zwischen Ausschreibungsartefakten und Backlog wählen zu können. Wünsche waren selbst im Sprintzyklus nicht stabil zu halten Im Projektverlauf erschien plötzlich ein Drittdienstleister mit komplexen Schnittstellen, der streng ein Wasserfallvorgehen betrieb bei dem straffen Projektplan kaum einzubetten 13

14 Projektbestimmende Faktoren Das kundenseitige Misstrauen schlug schwer auf die Teammotivation Das Team wurde in der Umsetzungsphase zur Einhaltung der Zeitlinien bis zur Schmerzgrenze vergrößert Es konnte jeweils nur mit großem Aufwand der Austausch von Features im Backlog durchgeführt werden. Der Kunde hatte stets sehr konkrete Vorstellung, wie viel Aufwand bestimmte Aspekte maximal haben dürfen Der Kunde forderte immer wieder Wasserfallartefakte: Zeitlaufplanung über den aktuellen Sprint hinaus, Umrechnung von SP in PT, etc. 14

16 War der agile Ansatz richtig? Der Kunde konnte sich mental nicht von einem klassischen Projektsteuerungsansatz lösen Der agile Ansatz wurde gezielt dazu genutzt, Budget/Feature zu optimieren. Dies geschah nicht partnerschaftlich, sondern auf pressierend/taktierender Ebene Das agile Vorgehensmodell hat im dritten Projektanlauf zum ersten Mal dazu geführt, dass der Kunde eine funktionsfähige Applikation erhielt Das tarent-seitige Projektmanagement hat sich dem nicht entschlossen genug entgegengestellt, Vertrauen konnte nicht geweckt werden tarent-seitig wurde dem Kunden mitgeteilt, dass über die vertragliche Leistung hinaus keine Beziehung mehr aufrecht erhalten wird 16

17 Die Rahmenbedingungen... der Großkonzern Das Projekt wurde Anfang 2014 offiziell ausgeschrieben Mitte 2014 wurde der Zuschlag erteilt, die Diskussion über das Vorgehensmodell wurde gestartet Ausgangspunkt: ein hinreichendes Lastenheft lag nicht vor Aufgrund von Budgetfragen wurde das Projekt auftraggeberseitig auf Eis gelegt Eine Wiederbelebung erfolgt im Dezember 2014 mit einem kleineren Budget und der nun geforderten Geschwindigkeit geschuldet nach einem Time & Material mit der gemeinsamen Verpflichtung auf ein minimum viable product im April 17

18 Der Projektverlauf Projektstart und Umsetzungsphase I Dez 2014 bis Feb PT Umsetzungsphase II Feb 2015 bis Mai PT... aktuell: weitere 300 PT in Planung 201 PT geschätzt: 195 PT 18

19 Projektbestimmende Faktoren Ein sehr erfahrenes, kleines Team arbeitete von vornherein auf Basis modernster Technologien und einem Fokus auf CD Der Kunde stellte einen Projektmanager als PO mit großer Projekterfahrung, aber keiner Erfahrung in agilem Umfeld Nach anfänglichen Schwierigkeiten (Schnitt der Stories, Story-Änderungen im Sprint, Abnahmen im Sprint) stabilisierte sich das gemeinsamen Vorgehen Der PO war 2 Tage in der Woche im Team anwesend. Dies führte zu wachsendem Vertrauen in die Leistungsfähigkeit des Teams PO und Team entwickelten sich zu einem kreativen Gespann 19

21 War der agile Ansatz richtig?... Kunde entwickelte massives Vertrauen Das Projekt wurde trotzt anfänglich sehr unklarer Anforderungen, erfolgreich abgeschlossen Fachliche Ziele, Zeitziele, Budgetziele wurden hierbei eingehalten Das minimum viable product dient dem Kunden bereits seinerseits zur Kundengewinnung Die entwickelte Software hat eine extrem hohe Testabdeckung, committeter Code kann binnen Minuten in Produktion sein 21

22 Erfolgsfaktoren! Der Kunde kennt sich mit agilen Verfahren aus oder lässt sich bewusst darauf ein. Er kann nicht dahin erzogen werden zumindest nicht durch ein Softwareentwicklungsunternehmen Kunde und Team arbeiten persönlich eng zusammen andernfalls covert man das agile Vorgehen besser und fällt auf klassische Darstellungsmechanismen zurück Der Kunde darf nicht mit einer Misstrauensvermutung hinsichtlich des Vorgehensmodells in das Projekt einsteigen er muss seinerseits davon überzeugt sein Auftraggeber und Auftragnehmer müssen die Vision teilen Es muss ein einheitliches Verständnis der Ausprägung des Auftragnehmer Auftraggeber Verhältnisses bestehen: Mit dem Start eines Projekts sitzt man im selben Boot! 22

23 Vielen Dank!

24 Dr. Stefan Barth COO Mail: Rochusstraße Bonn Voltastraße Berlin Telefon: +49 (0) Telefax: +49 (0)