cCredit: Ein Produkt der SIX Card Solutions Deutschland GmbH

cCredit ist ein international einsetzbares Produkt zur kartengestützten Abwicklung von Zahlungen am Kassenplatz. Als solches unterliegt es einer Reihe von Vorschriften und Anforderungen, auf die wir keinen Einfluss haben und das Verhalten der Software sehr genau vorgeben. Dazu gehören unter anderem die von Kreditkartenunternehmen herausgegebene EMV Spezifikation (Kreditkarten), die vom ZKA herausgegebene DC POS Spezifikation, oder die ep2 Spezifikation für die kartengestützte Zahlungsabwicklung in der Schweiz. Ergänzend dazu werden erhebliche Anforderungen an den Prozess der Softwareentwicklung und dessen Dokumentation durch die Regularien des Payment Card Industry (PCI) Security Standards Council gestellt.
Durch diese Vorschriften von außen gibt es wenig Spielraum und Entscheidungsfreiheit, das Verhalten des Systems in seiner Kernfunktion zu verändern.

Andererseits werden die Anforderungen, in denen sich überhaupt Freiräume für das Produktverhalten bieten, typischerweise von Kundenwünschen geleitet. Diese Wünsche werden von Projektleitern während der Produktentwicklung vertreten. Die Weiterentwicklungen des Produkts werden daher häufig als eigenständige Projekte verwaltet und wurden bis vor einiger Zeit auch so geführt.

Ausgangslage

Die Einführung von Scrum als Entwicklungsprozess ist bei der SIX Card Solutions schon seit längerer Zeit im Gespräch. Das Scrum Vorgehen erschien uns passend zu der von der Unternehmensleitung vorangetriebenen „Lean Management“-Initiative, was die Akzeptanz eines agilen Vorgehensmodells im oberen Management erhöhte. Für uns am Standort Norderstedt war das ab  Oktober 2009 Grund genug, uns eingehender mit der Theorie von Scrum zu beschäftigen und erste  Erfahrungen zu sammeln. Nach der Lektüre verschiedener Bücher und Erfahrungsberichte aus dem Internet fühlten wir uns bereit für die ersten Pilotprojekte.
Diese verliefen zwar weitgehend zufriedenstellend, trotzdem blieben noch eine Reihe ungelöster Probleme und das Gefühl, das Potential, das Scrum bietet, nicht auszuschöpfen. Wie groß dieses brachliegende Potential tatsächlich ist, haben wir erst später lernen müssen.

Ablauf

Wir haben uns daher entschieden, externe Hilfe in Form einer Schulungsmaßnahme und nachfolgendem, projektbegleitenden Coaching in Anspruch zu nehmen. Die Wahl des Anbieters fiel wegen ihres professionellen und vor allem offensichtlich agilen Vorgehens in der Beratung auf agile42.  
Nachdem die Entscheidung getroffen wurde, uns von agile42 beraten zu lassen, führte diese zunächst ein Assessment durch, in dem die Mitarbeiter des Unternehmens interviewt wurden. Aus den Ergebnissen der Interviews hat unser Berater Andrea Tomasini von agile42 einen Vorschlag mit strategischen Maßnahmen und dem weiteren Vorgehen erarbeitet und vorgestellt. 
Zunächst wurde ein Workshop mit dem IT-Management am Standort Norderstedt durchgeführt, in dem die Prinzipien des Lean Managements präsentiert wurden. Anhand sehr anschaulicher Beispiele und Übungen konnten wir die Zielsetzung und Vorteile von „Lean“ erfahren und bekamen eine erste Vorstellung davon, wohin die Reise gehen würde. In diesem Workshop wurde auch unserer späterer Coach Ralf Kruse eingeführt.
Fortgesetzt wurde die Beratungsleistung mit zwei Workshops, in denen die handelnden Personen mit Ihrer neuen Rolle vertraut gemacht wurden. In zwei Tagen haben die zukünftigen Product Owner die Schwerpunkte ihrer Aufgaben sowie eine Reihe von Werkzeugen und Methoden zur effizienten Erfüllung dieser Aufgaben kennen gelernt.
In weiteren zwei Tagen haben die Entwicklungs- und QA – Mitarbeiter (das „Team“) anhand von anschaulichen Fallbeispielen die Grundlagen schlanker Prozesse im Allgemeinen und Scrum im Besonderen kennen gelernt. Ralf Kruse, ein anderer agiler Coach von agile42, hat Ihnen gleichzeitig die Freiheit, aber auch die Verantwortung verdeutlicht, die das Team in Scrum hat.

Das beste Training bringt aber nur etwas, wenn die neu erworbenen Kenntnisse auch sofort in die Praxis umgesetzt werden können. Daher schloss sich an das Training der Mitarbeiter eine Phase der praktischen Anwendung an. Ralf , mittlerweile mit dem Beinamen „Ralf42“ versehen, hat in seiner Funktion als Coach die ersten zwei Sprints des neu gebildeten Scrum Teams begleitet und so auch den Scrum Master an seine neue Rolle herangeführt. Er hat die Erstellung der ersten Revision des Product Backlog  durch die Product Owner eng begleitet und auch bei der Vorbereitung des ersten Planning die Product Owner unterstützt.
Der Coach hat im weiteren Verlauf der zwei von ihm begleiteten Sprints geholfen, ein cross-funktionales Team für die Produktentwicklung zu formen, statt für jedes Projekt neue Teams zu gründen. Es ist gelungen, dem Team seine Aufgaben und seine Verantwortung zu verdeutlichen und bei Bedarf mit kurzen Übungen, die im Training besprochenen Kompetenzen, zu vertiefen. Einige Methoden, z.B. die relative Aufwandsschätzung, haben wir erst durch das Coaching wirklich begriffen. Der Umgang mit weiteren Aufgaben des Teams, die nicht direkt zur Weiterentwicklung des Produkts beitragen, wurde vom Team mit Hilfe des Coaches angemessen gelöst.
Im Rahmen der vierwöchigen Begleitung hat unser Coach es auch geschafft, die Kommunikation des Scrum Teams mit den weiteren Stakeholdern in geregelte Bahnen zu lenken und die Stakeholder von dem Nutzen des neuen Entwicklungsvorgehens zu überzeugen.

Ergebnisse

Durch die von agile42 begleitete Einführung des Scrum Prozesses in der Entwicklung von cCredit haben sich in kurzer Zeit Verbesserungen eingestellt, die wir zuvor vergeblich alleine herbeizuführen versucht haben.
Die Grenzen zwischen den Bereichen „Entwicklung“ und „Test“ sind in der täglichen Arbeit kaum noch zu erkennen. Die mit der Realisierung befassten Mitarbeiter verstehen sich als ein Team mit einem gemeinsamen Ziel, das es zu erreichen gilt – wobei jeder Mitarbeiter seine Expertise einbringen kann. Das Team organisiert heute seine Aufgaben weitgehend selbst, die Product Owner behalten aber die Kontrolle über die Weiterentwicklung des Produkts. Durch die Etablierung eines Verbesserungsprozesses hat das Team die Gelegenheit, das eigene Handeln regelmäßig zu reflektieren und zu verändern. Dies führt zu einer kontinuierlichen und sichtbaren Weiterentwicklung des Entwicklungsprozesses. Für das Team ergeben sich zuvor unbekannte Möglichkeiten das eigene Arbeitsumfeld zu beeinflussen, was zu einer höheren Zufriedenheit und Motivation der Mitarbeiter führt.

Die Planung der zu bewältigenden Projektaufgaben und Weiterentwicklungen am Produkt cCredit konnte in den letzten sechs Monaten spürbar verbessert werden. Die Menge der vom Team zu erledigenden Arbeiten ist transparenter geworden, wodurch Product Owner und interne Auftraggeber zu einer realistischeren Erwartungshaltung bezüglich der Möglichkeiten des Teams kommen. Außerdem können die anstehenden Aufgaben zentral gesteuert und mit ihrer Priorität versehen werden. Durch die Umstellung des Schätzverfahrens auf relative Schätzungen konnten die Aussagen zum erwarteten Aufwand zur Realisierung neuer Produktfeatures  verbessert werden.Eine weitere Steigerung erwarten wir durch die zukünftige Verbreiterung der empirischen Grundlage. Dank der besseren Einschätzung der Leistungsfähigkeit des Teams und des Umfangs der Aufgaben ist die mittelfristige Releaseplanung erheblich zuverlässiger geworden.
Durch die enge Zusammenarbeit zwischen Entwicklern und Testern, gepaart mit klaren Vereinbarungen, was „fertig“ eigentlich bedeutet, haben alle Beteiligten einen einheitlichen und realistischen Blick auf den Fortschritt und die Qualität des in Arbeit befindlichen  Produktreleases. So lässt sich die Planung regelmäßig an die Gegebenheiten der realen Welt anpassen und kurzfristige böse Überraschungen bleiben aus.

Fazit

Nach über einem Jahr „experimentellem Scrum“ in Eigenregie sind für uns im Nachhinein betrachtet viele – wenn nicht alle – wichtigen Aspekte agiler Softwareentwicklung im Dunkeln geblieben. Erst die breiter angelegte Unterstützung durch agile42 hat uns den mentalen Zugang zu Scrum ermöglicht. Dabei wurden wir weniger mit vorgefertigten Lösungen und Präsentationen konfrontiert, als vielmehr mit den Grundlagen versehen, die es uns selbst ermöglichen, angemessene Lösungen zu finden. 

Für so ziemlich jede Fragestellung und jedes Problem konnte unser Coach uns einen Lösungsansatz aufzeigen. Die Mitarbeiter von agile42 haben sich nicht gescheut, dabei auch unangenehme Aspekte auf den Punkt zu bringen.
Mittlerweile verwenden wir in unserem Sprachgebrauch ein neues Attribut für Rollenverständnisse und Verhaltensweisen: Es gibt eine Unterscheidung in  die Zeit „vor Ralf42“ und „nach Ralf42“ – mit dem Coaching durch agile42 hat eine neue Zeitrechnung im cCredit Entwicklungsbereich begonnen.