SCRUM – Eine neue Herausforderung für uns als NAVAX

Viele unserer Kunden stehen vor dem Dilemma, dass Vorgehensweisen und Projektvorgehen nicht mehr zum Unternehmen und den sich verändernden Gegebenheiten passen. Auch unsere Produktentwicklungsabteilung stand Anfang 2015 vor dieser großen Herausforderung.

Zu Beginn des Geschäftsjahres 2015 ist die Produktentwicklungsabteilung „Application Development“ vor die Herausforderung gestellt worden, die Vorgehensweise der Individual-Softwareentwicklung um den Produktionsprozess zu überdenken. Dies hat einerseits aus Engpässen in der Featureentwicklung, aufgrund ansteigender Anforderungswünsche der Kunden, andererseits aus dem Wunsch, einen aktuellen Entwicklungsprozess innerhalb der Abteilung zu adaptieren und anzuwenden, resultiert. Aus dem ständig wachsenden Druck durch die Wirtschaft und Konkurrenzunternehmen haben sich zwei wesentliche Faktoren, welche sich über eine bestimmte Zeitspanne immer mehr in den Mittelpunkt gestellt haben, gezeigt:

  • kürzere Entwicklungszyklen, um neue Features des Produkts veröffentlichen zu können
  • die ansteigende Komplexität der Produkte.

Die Herausforderung zur Entscheidungsfindung gestaltete sich dabei wie folgt:

„Finde eine Methode, welche zum Unternehmen, zur Abteilung, zum Arbeitsbereich passt und auch beim Kunden vertretbar ist. Es soll ein Vorgehensmodell gewählt werden, welches leicht und mit der bestehenden Infrastruktur, dem bestehenden Team und den aktuellen Gegebenheiten im Projektgeschäft umzusetzen ist. Der Prozess soll jederzeit Auskunft darüber geben können, wo das Team in der Bearbeitung der Anforderungen steht. Der Prozess soll dabei langfristig den Fortschritt des Teams in der persönlichen Entwicklung geben können. Das Modell soll jederzeit die Möglichkeit bieten, unvorhergesehene Ausfälle kompensieren und gleichzeitig neue Ressourcen einfach und ohne größere Umstellungen einbinden zu können. Wir wollen Kapazitäten nicht auslagern, sondern unser Produkt ausschließlich firmenintern weiterentwickeln.“

Auf Basis der Anforderungen, unter Berücksichtigung der umliegenden innerbetrieblichen Einflüsse sowie Anforderungen aus dem Projektgeschäft, gestaltete sich recht schnell eine Vision, welche in Richtung „SCRUM“ gehen sollte.

Eine Vision, eine Lösung
Es ist im ersten Moment nicht klar gewesen, wie in relativ kurzer Zeit eine neue Methode für einen essentiellen Teilbereich des Unternehmens gefunden werden soll und welche gleichzeitig einfach zu implementieren ist. Daher ist die Herangehensweise gewählt worden, die Schlüsselpunkte in einem gemeinsamen Teammeeting zu erarbeiten.

Der Fokus nach einer passenden Methode ist darauf gerichtet gewesen, ein Vorgehensmodell für ein 16-köpfiges Team zu finden, welches primär kongruent zu den Unternehmensstrukturen ist und sekundär den Anforderungen des gesamten Teams gerecht wird. In weiterer Folge ist darauf geachtet worden, 2 unterschiedliche Themengebiete in der Entwicklungsabteilung einheitlich abdecken zu können. Folglich ist eine teaminterne Teilung durchgeführt worden, sodass sich jedes einzelne Team mit der gleichen Vorgehensweise explizit auf ihren Aufgabenbereich konzentrieren kann. Dabei ist es weiterhin möglich gewesen, übergreifende Arbeitsaufträge nach der selben Methode zu bearbeiten.

Es ist eine Vision entstanden, welche drei Kernelemente abgedeckt hat:

  • Die kurzen Entwicklungszyklen haben nur das Wesentliche im Blickfeld und lassen trotzdem den Spielraum, um Entscheidungen, auch im späteren Verlauf der Weiterentwicklung des Produkts, treffen zu können.
  • Es muss ein gemeinsames Mindset geschaffen werden, welches aus der Abteilung heraus vertretbar ist und durch klar definierte Rollen auch kommuniziert werden kann.
  • Die Führungspositionen in der Abteilung und auch im Unternehmen unterstützen die Methode und sind von dessen Erfolg überzeugt.

Unter Berücksichtigung dieser Punkte ist in SCRUM eine geeignete Methode für individuelle Softwareentwicklung und –weiterentwicklung gefunden worden. Nach einer gemeinsamen Zustimmung zu der agilen Softwareentwicklungsmethode ist ein Plan ausgearbeitet worden, mit welchem in kleinen Schritten die Übernahme geprüft werden sollte.

Einführung SCRUM bei NAVAX – erste Versuche
Zu Beginn galt es, Rahmenbedingungen für den Test zu schaffen. Die Einführung ist, unter Berücksichtigung gängiger SCRUM Meetings, als „SCRUM light“ definiert worden. Zu einem bestimmten Zeitpunkt sind tägliche Abstimmungsmeetings in Form eines „daily standup“ bzw. Schätzungsmeetings, „Grooming“, abgehalten worden. Für die organisatorische Überwachung, zur Einhaltung der Vorgehensweise, sind in einem Excel File folgende Werkzeuge erstellt worden:

  • ein separater Product Backlog für zusätzliche Informationen zu einzelnen Tickets
  • strukturierte Iterationszyklen im 2-Wochen Rhythmus, wobei sich eine Iteration auf 10 Arbeitstage beläuft
  • Aufwandschätzung der einzelnen Tickets in Stunden, unter einer wahrscheinlichen Auslastung von 80% pro Tag und unter Berücksichtigung der Capacity bei geplanter Abwesenheit eines Entwicklers
  • Einführung der Bewertungsmethode PERT, zur Ermittlung einer genaueren Aufwandschätzung
  • EVA-Analyse Sheet, zur Ermittlung des Burndown Chart

Ein weiterer Punkt ist das Controlling gewesen, welches in einem separaten Bereich durchgeführt worden ist. Dieses hat sich aus der Kontrolle nach 4 Perioden bzw. nach einem halben Jahr zusammengesetzt und sollte den Fortschritt des Development Teams sowie die Effizienz der „SCRUM light“ Methode als ganze Einheit und deren Umsetzung bewerten. Um in der Testphase zukünftige Aufwände besser abschätzen zu können, ist ebenfalls ein Forecast für Projekte, welche das Produkt selber und das Produktteam belasten könnte, angelegt worden. Für die organisatorische Umsetzung sind 2 neue Positionen, ein zusätzlicher SCRUM Master für das Team und ein Product Owner für die Vertretung der Wünsche der Stakeholder (in unserem Fall das jeweilige Projektteam), ernannt worden. Nachdem ein Teil des Application Development Teams ein halbes Jahr mit der „SCRUM light“ Methode verbracht hat, sind folgende Punkte bei einer Retrospektive zusammengefasst worden:

  • Steigerung des Fachwissens im jeweiligen Entwicklungsbereich beim Development Team
  • zeitnahe Auslieferung von Neuentwicklungen an interne Abteilungen und den Kunden
  • kurze Kommunikationswege, aufgrund von chronologisch abgehaltenen Meetings
  • iterative, unkomplizierte Anpassung des Prozesses, aufgrund der Flexibilität der Methode
  • hohes Maß an Selbstorganisation des Development Teams

Wir sind sehr zufrieden mit dem derzeitigen Stand der Dinge und werden diese Projektmethode sicher fortsetzen. Für uns als Development-Team passt es perfekt.

Autor: Michael Koch, MSc

Michael Koch ist Organisational Lead im Bereich Application Development bei NAVAX. Seit seiner Ausbildung an der Fachhochschule Burgenland (BSc, Internettechnologien) und der Fachhochschule Technikum Wien (MSc, Multimedia & Softwareentwicklung) beschäftigt er sich mit den Themen agiles Projektmanagement & Organisationsprozesse. In seiner bisherigen beruflichen Laufbahn als Projektmanager (Techtalk) und Technical Sales Support (NextiraOne) konnte er weitere Erfahrungen in den genannten Bereichen sammeln. In seiner Freizeit verbringt er Stunden hinter dem Herd und verköstigt Freunde und Familie. Die restliche Zeit widmet er dem Sport (Volleyball), Handwerken & der persönlichen Weiterbildung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

This site uses Akismet to reduce spam. Learn how your comment data is processed.