Digital-Dienstleister in Ihrer Region
Anbieter. Bewertungen. Jobs.

Aktuelle Beiträge

Output-Management / DEVK / Best Practice
„Als Insel kann eine agile Arbeitsweise nur begrenzte Wirkung entfalten.“

Die DEVK-Versicherungen wollen durch agile Arbeitsweisen mehr Transparenz in ihre Softwareentwicklung bringen. Mit Betriebsorganisator Marc Buchwitz sprach SERVICE.REPORT.IT darüber, welchen Herausforderungen er bei diesem Digitalisierungs-Projekt begegnet.

Dokumentenmanagement.jpg/

SERVICE.REPORT.IT: Agiles Arbeiten ist ein weites Feld. Wie setzen Sie dieses Konzept bei der DEVK um?
 
Buchwitz: Wir arbeiten bei der DEVK nach der Scrum-Methode. Wir erhalten unsere Aufträge nicht mehr direkt von unseren disziplinarisch Vorgesetzten, sondern treffen alle zwei Wochen auf unseren Sprint-Sitzungen mit dem Product-Owner zusammen, der uns die Projekte vorstellt, die momentan akut bedient werden müssen. Im Team entscheiden wir dann, was wir in welchem Umfang innerhalb der nächsten 14 Tage schaffen und sagen das auch verbindlich zu. Bei Bedarf holen wir uns Experten hinzu, die uns helfen, die Dinge pünktlich zu erledigen
 
SERVICE.REPORT.IT: Sie haben die agile Arbeitsweise im September 2018 gestartet. Welche Vorteile bietet sie für die tägliche Arbeit?
 
Buchwitz: Als Team verstehen wir immer besser, worum es geht. Wir können besser abschätzen, was wir schaffen und welche Aufträge zu groß sind. Das kommunizieren wir auch explizit. Wir sagen ganz klar, was definitiv bis zum nächsten Sprint fertig ist, was schief gehen könnte und was wir lieber erst in den nächsten Sprints angehen. Das hat viel mit Verantwortung und Kommunikation zu tun, beispielweise wenn es Abweichungen vom Plan gibt, etwa wenn jemand krank wird. Aber es beugt eben auch Enttäuschungen bei den Product-Ownern und den Stakeholdern vor.
 
SERVICE.REPORT.IT:  Welche Ziele verfolgen Sie mit der agilen Arbeitsweise?
 
Buchwitz: Unser Ressort-Vorstand hat 2016 die Einführung agiler Arbeitsweisen in der Software-Entwicklung beschlossen. Im Output-Management haben wir ein Software-Upgrade zum Anlass genommen, damit anzufangen. Wir wollen unsere Arbeit transaparent machen. Hauptziel ist es, den Fachbereichen, unseren Kunden, schnell Ergebnisse zu präsentieren, um mit deren Feedback eine ideal abgestimmte Lösung zu entwickeln. Das bedingt natürlich auch, dass sich die Fachbereiche wirklich mit dem Thema auseinandersetzen und unsere Review-Termine wahrnehmen.
 
SERVICE.REPORT.IT: Was ist Ihre Erfahrung? Welche Fehler sollte man auf keinen Fall machen?
 
Buchwitz: Man muss diese Arbeitsweise überzeugend erklären, da man die Menschen nicht dazu zwingen kann. Man kann eine agile Arbeitsweise nicht einfach in ein Unternehmen tragen, das sich damit nicht auskennt. Ich hatte schon Scrum-Erfahrungen, als ich vor rund einem Jahr zur DEVK gewechselt bin. Seitdem haben wir viel Zeit investiert, um alle Kollegen auf ein Verständnis-Level zu bringen. Zudem haben wir unsere Vorgehensweise angepasst. Beispielsweise haben wir festgestellt, dass uns die 15-minütigen Dailys nichts bringen. Wir kommen daher nur zweimal die Woche zusammen. Das entspricht zwar nicht dem klassischen Scrum-Framework, ist aber für uns das ideale Vorgehen. Die  zweiwöchentlichen Sprintwechsel werden hingegen mittlerweile als großer Mehrwert angesehen und helfen dem Team und dem Product-Owner ein Gefühl füreinander zu bekommen. Wir scheinen dabei einiges richtig gemacht zu haben. Denn die anfangs schärfsten Kritiker im team sind heute die größten Befürworter.   
 
SERVICE.REPORT.IT: Wo liegen die größten Herausforderungen?
 
Buchwitz: Die Fachbereiche an das agile Arbeiten anzubinden, st die wichtigste Aufgabe. Als Betriebsorganisator bilde ich zwar explizit die Schnittstelle zwischen Fachbereichen und IT. Ich kenne die Bedürfnisse beider Seiten also sehr gut. Mal sind die Projekte fachlich getrieben, mal seitens der IT. Aber als Insel im Unternehmen kann eine agile Arbeitsweise natürlich nur begrenzt Wirkung entfalten. 
 
SERVICE.REPORT.IT: Wo genau liegt das Problem?
 
Buchwitz: Nehmen wir als Beispiel die Entwicklung einer Landingpage. Die fachlichen Wünsche sind klar. Der DEVK-Kunde, der die Webseite besucht, soll das und das machen können. Während der Programmierung aber stellen sich dann aber weitere Fragen. Wo liegen die Daten? Was soll damit geschehen? Wenn die Softwareentwicklung während des Sprints dafür in der Fachabteilung keinen Partner hat, der diese Fragen zeitnah und verbindlich beantworten kann, dann kann das Team auch nicht zuverlässig in zweiwöchigen Rhythmen planen. Mit anderen Worten: Es genügt nicht, der Softwareentwicklung alle Freiheit und Flexibilität zu geben, wenn die klassische Linienorganisation bei langwierigen Abstimmungs- und Entscheidungsprozessen bleibt.
 
SERVICE.REPORT.IT: Was fordern Sie?
 
Buchwitz: Wir benötigen eine zweite Phase für die Organisationsentwicklung und ein Change Management für alle Bereiche. Dieser Anstoß muss vom Vorstand kommen. Das kann niemand für sich alleine lösen.
 
SERVICE.REPORT.IT: Herr Buchwitz, wir danken für das Gespräch.

 

--

Das Interview führten wir im Nachgang des "Forum Output Management ", einer Veranstaltung unseres Bildungspartners KongressMedia, die am 19. / 20. Januar 2019 in München stattfand. Das nächste "Forum Output Management" findet am 25. / 26. September 2019 in Frankfurt a.M. statt. 

 

--

SCRUM-Glossar:

Scrum zählt zu den agilen Prozessen für die Softwareentwicklung und das Projektmanagement. Andere Methoden nennen sich z.B. Crystal, Extreme Programming (XP) oder Feature Driven Development (FDD). Scrum bietet eine schlanke Projektmanagement-Methode u.a. mit einfachen Regeln, wenigen Rollen, mehreren Arten von Meetings, eine iterative Vorgehensweise sowie viel Selbstorganisation und Eigenverantwortung in interdisziplinären Teams.

Wichtige Rollen übernehmen der Product-Owner und der Scrum-Master. Der Product-Owner vertritt die fachliche Sicht, stellt Anforderungen und beurteilt die Umsetzung seiner Wünsche im Hinblick auf Funktionalität, Benutzbarkeit, Performanz und Qualität. Der Scrum-Master sorgt dafür, dass der Prozess läuft und die Regeln eingehalten werden.

Das Daily Scrum Meeting findet typischerweise an jedem Arbeitstag statt. Es dauert nicht länger als 15 Minuten und dient dem Team dazu, sich abzustimmen und gegenseitig zu informieren.

Die Sprints dauern normalerweise 30 Kalendertage. Innerhalb jedes Sprints entwickelt das Team ein Projekt inkrementell weiter und stellt die Ergebnisse der Auftraggeberseite auf den Sprint-Sitzungen vor. Der Product Owner entscheidet dann über einen Produktiveinsatz des Inkrements.

Veröffentlicht am 06.03.2019


Assoziierte Fokusthemen