Advertisement

HMD Praxis der Wirtschaftsinformatik

, Volume 54, Issue 2, pp 251–260 | Cite as

DevOps by Scrumban

  • Philipp SchaeferEmail author
  • Dierk SöllnerEmail author
Schwerpunkt
  • 1.2k Downloads

Zusammenfassung

Auch in klassisch geprägten IT-Organisationen sind agile sowie schlanke Prinzipien umsetzbar und kulturelle Veränderungen in Teams erreichbar. Zu diesem Zweck können Scrum und Kanban verknüpft und als Kombination von Teams angewendet werden, die Entwicklung und Betrieb (=DevOps) für die nächste Evolutionsstufe der Agilität vereinen möchten. Das Kunstwort, das diese IT-Management-Methode umschreibt ist Scrumban. So kann mithilfe von Kanban herkömmliches Abteilungsdenken leichter überwunden werden. Weiterhin können die Herausforderungen einer neuen Teamzusammenstellung und neuer Arbeitsstile besser bewältigt werden. Ergänzt um den organisatorischen Rahmen aus Scrum ist es möglich, temporäre, cross-funktionale Projektteams in hoch performante, motivierte Produktteams zu überführen. Scrumban, das als sinnvolle Kombination von Scrum- und Kanban-Elementen im Einklang mit der DevOps-Philosophie steht, kann dann als Treiber für die nachhaltige Etablierung von DevOps angewendet werden und bei neuartigen Arbeitsprozessen behilflich sein. Dieser Beitrag reflektiert die Erfahrungen eines Software-Entwicklungsteams bei der Nutzung von Kanban- und ersten DevOps-Ansätzen und stellt mit Scrumban einen unterstützenden Management-Ansatz vor. Ziel ist es, Veränderungen, die mit der DevOps-Denkweise verbunden sind, in Unternehmen bestmöglich umzusetzen.

Schlüsselwörter

DevOps Scrumban Scrum Kanban 

DevOps by Scrumban

Abstract

Even in traditional IT organizational structures, agile and lean principles as well as cultural change can be realized successfully. To achieve this purpose, IT teams who want to unite development and Operations on their way to agility, can combine scrum with Kanban. This IT management method is called Scrumban. Kanban overcomes traditional silo thinking and softens the challenge for new team formations including the way of work. Implemented together with the organizational framework of scrum, temporary, cross-functional project teams will be transformed into motivated, high-performance product teams. Scrumban, the intelligent combination of elements from scrum and Kanban, is consistent with the DevOps philosophy and therefore can be seen as the driving force behind DevOps implementations in work processes. This article reflects the experiences of a software developing team while applying both Kanban and DevOps elements. On this basis Scrumban can serve as a management framework which helps to introduce changes that come along with DevOps.

Keywords

DevOps Scrumban Scrum Kanban Agile Lean 

1 Kanban- und DevOps-Ansätze im Praxiseinsatz

DevOps beschreibt eine Philosophie, die versucht, eine Brücke zwischen Entwicklung (Development) und Betrieb (Operationss) zu bauen. Die Absicht dahinter ist, kontinuierliche Softwarebereitstellung sicherzustellen, um schneller auf Marktveränderungen reagieren zu können und Kundenanforderungen besser gerecht zu werden. Dabei sind die gegenläufigen Ansätze einer agilen Softwareentwicklung mit schneller und häufiger Lieferung von neuen Features und dem Anspruch eines sicheren und stabilen Betriebs in Einklang zu bringen. Daher eignet sich dieser Ansatz nicht nur für moderne Internetunternehmen. Vielmehr können davon genauso etablierte, große IT-Unternehmen mit klassischer Aufbauorganisation profitieren. Es reicht dafür, zunächst nur einige Ideen von DevOps in den Abteilungen zu platzieren und umzusetzen sowie die bestehenden Prozesse behutsam anzupassen (Baumann 2015).

Dies ist so geschehen für ein kleines Software-Entwicklungsteam in einem Hafen- und Transportlogistikkonzern mit 24/7-Betrieb, wo die Steigerung von Software-Stabilität sowie die schnelle, fehlerfreie Lieferung von Software-Produkten elementar sind. Es galt in diesem Arbeitsumfeld perspektivisch ein leistungsfähiges Team aufzubauen, welches ein bevorstehendes Migrationsprojekt für den Einsatz einer neuen Software-Plattform durchführen kann. Im Hinblick darauf wurden neben DevOps- zunächst Kanban-Ansätze in die Arbeitsweise integriert. Die wesentliche Zielvorstellung war es, die bislang getrennten Bereiche für Entwicklung und Betrieb besser zusammenarbeiten zu lassen und qualitativ hochwertige Software effizienter liefern zu können während der laufende IT-Betrieb weiterhin sichergestellt wird.

1.1 Kanban: Einführung von Kanban-Kernpraktiken

Im Team wurden anfänglich einige Kernpraktiken von Kanban umgesetzt. Unter anderem wurde ein Kanban-Board zur Planung und Koordination eingesetzt (vgl. Abb. 1). Arbeit soll unter den schlanken Prämissen umgesetzt werden, dass der Zugang an neuen Aufgaben reguliert wird, dass Aufgaben vollständig beendet werden, dass das Hauptaugenmerk auf Qualität liegt und dass Regeln zur Arbeitsweise aus dem Team selbst hervorgehen.
Abb. 1

Kanban-Board zur Planung und Koordination

Das Kanban-Board selbst teilt sich in Spalten zur Wertschöpfungsphase; Schwimmbahnen repräsentieren gegenwärtig wichtige Termine, hochpriorisierte Themen, aktuelle IT-Projekte und auch Sonstiges (Administration, Support, Kleinaufträge). Es werden demzufolge nicht nur reine Entwicklungstätigkeiten, sondern auch die Arbeitsschwerpunkte des Betriebs zur Infrastruktur und Wartung abgebildet. Unterschiedliche Aufgabentypen wie z. B. neue Software-Features oder aber die Administration der Plattform/wiederkehrende Aufgaben und Produktionsstörungen oder -eingriffe werden über Kartenfarben differenziert. Zugleich wurde die Durchführung eines täglichen Standups zur Kommunikation des aktuellen Arbeitsfortschritts und einer wöchentlichen Planungsrunde für die Besprechung der Aufgaben der kommenden Woche festgelegt. Neben Kundenaufträgen kann hier zugleich jedes Teammitglied neue Karten (Arbeitspakete) einbringen, die dann priorisiert werden. Die Kanban-Praktiken wurden auf einen in Projektphasen iterativen Entwicklungsprozess aufgesetzt und nach der Etablierung in der IT-Projektarbeit dann auf das gesamte Arbeitsspektrum des Teams angewendet.

1.2 DevOps: Organisatorische Anpassungen und technische Hilfsmittel

Während die Zuständigkeiten des abzulösenden Systemumfeldes klar in mehreren Stellen der IT-Abteilungen geordnet waren, mussten für das neue System die Zuständigkeiten erst noch vergeben werden. Ziel war die Schaffung einer organisatorischen Einheit, die sämtliche Arbeiten rund um die Migration auf die neue Software-Plattform plant und durchführt. Also wurden an das hier vorgestellte Team aus der Stelle für ursprünglich reine Software-Entwicklung im abzulösenden System ebenfalls betriebliche und administrative Tätigkeiten zentral adressiert. Dazu sind nach Einführung von Kanban zur Unterstützung und Bewältigung dieser übergreifenden Aufgaben Mitarbeiter aus der Betriebs- und Kundenservice-Abteilung entsendet worden. Die disziplinarische Führungsverantwortung für die entsendeten Mitarbeiter verblieb in den ursprünglichen Abteilungen. Der Themenschwerpunkt der Mitarbeiter bezog sich aber von jetzt an auf die neue Software-Plattform. So entstand innerhalb dieser Stelle ein abteilungsübergreifendes Team, bestehend aus sechs Personen, mit den Arbeitsschwerpunkten Entwicklung, Infrastruktur und Administration. Ein zusätzliches Aufgabengebiet kam dann mit der Herstellung und Pflege von Automatisierungswerkzeugen für Software-Bausteine hinzu. In diesem Team wurden im Rahmen der operativen Arbeit Hilfsmittel hergestellt, die das nahezu vollständig automatisierte Testen der Anwendungsteststufe sowie das Ausrollen von Lieferartefakten ermöglichen. Zunächst sind diese noch nicht über eine Lieferpipeline verkettet.

1.3 Beobachtungen und Erfahrungen des Teams

Das Team hat in der gemeinsamen, täglichen Arbeit Erfahrungen mit Elementen sowohl aus Kanban als auch aus DevOps gesammelt und konnte eine entsprechende Beurteilung vornehmen. Im Ergebnis zeigten sich kulturelle Veränderungen durch den Einsatz von Kanban, die das Verhalten im sozialen Gefüge des neu zusammengesetzten Teams positiv beeinflusst haben. So sind klare Vorteile dieses Kompetenzteams gegenüber der klassischen Abteilungsorganisation ebenso wie charakteristische Merkmale der Agilität zu erkennen:
  • Das Team sieht sich neben der Software-Entwicklung vollständig in der Verantwortung für den Betrieb der Anwendung. Hierbei unterstützen maßgeblich Praktiken aus Kanban zur Koordination von Entwicklungs-, Infrastruktur- und Betriebstätigkeiten sowie Abstimmungstermine und der daraus resultierende, verbesserte Informationsfluss.

  • Die Entsendung von Mitarbeitern hat zu einer besseren Zusammenarbeit geführt, wobei das Team mittlerweile eingespielt ist. Alle Rollen, die zurzeit für die tägliche Arbeit nötig sind, sind mit Spezialisten besetzt, diese haben aber auch ein Grundverständnis für weitere Aufgabengebiete entwickelt.

  • Transparenz, Termintreue, Erfahrungsaustausch sind besser geworden. Zentraler Treffpunkt aller ist das Board, was vor allem hilft, Kommunikationshürden über Abteilungsgrenzen hinweg zu durchbrechen, Mitarbeiter aus Entwicklung und Betrieb effektiv zusammenarbeiten zu lassen und somit das Silo-Denken unterbindet.

  • Mittlerweile ist die Rolle eines Koordinators im Team mit der Kompetenz ausgestattet- unter Achtung der agilen Selbstorganisation- unterstützende Aufgaben zur Abstimmungen mit den internen Kunden und zum Schutz vor äußeren Störeinflüssen ausüben zu können.

  • Automatisierungswerkzeuge für Test und Lieferung verbessern aufgrund erhöhter Software-Qualität und geringerer Fehlerquoten definitiv die Arbeit.

Welche Aufgaben aktuell von welchem Teammitglied bearbeitet werden, was für das Team kurzfristig ansteht und wie und wann die Aufgaben priorisiert werden, lässt sich über die Nutzung der Kanban-Planungswand mit Backlog und wöchentlichem Planungs-Meeting bereits beantworten. Im Sinne einer weitreichenderen DevOps-Philosophie kann der Fokus nun mithilfe der Einbindung weiterer Kanban- und neuer Scrum-Elemente für die IT-Entwicklung, aber auch im -Betrieb vor allem auf den Durchsatz von Arbeitspaketen und die Festigung der Arbeitsweise gelegt werden.

2 DevOps im Einklang mit Scrumban

Das Arbeitsfeld des Teams, in dem Kenntnisse gleichzeitig aus Entwicklung und Betrieb ausschlaggebend für den Erfolg des andauernden Migrationsprojektes sind, ist ein passendes Beispiel für die Anwendung der DevOps-Philosophie. Gleichzeitig können die erfolgversprechenden Ideen hinter DevOps noch besser mit der Arbeitsweise nach Scrumban umgesetzt werden. Dabei sind nicht nur die Elemente aus Kanban zur evolutionären Veränderung, sondern auch solche aus Scrum für die Organisation und Zusammenarbeit im Team sowie mit dem Kunden hilfreich.

2.1 Potenzial der Kombination von Scrum und Kanban für DevOps

Das agile und schlanke Fundament, auf dem Scrum und Kanban beruht, lässt sich letztendlich auch in einzelnen Bestandteilen der DevOps-Philosophie erkennen. Die IT-Wertschöpfungskette wird jetzt vollständig bis zum Kunden mit dem Ziel der Durchflussoptimierung betrachtet, Feedback-Schleifen werden auf allen Ebenen für Qualitätsverbesserungen und den Wissensaufbau eingesetzt und ständiges Experimentieren sowie das Lernen aus Fehlern streben die kontinuierliche Verbesserung an (Kim 2014).

Bei Scrum als Vertreter der agilen Vorgehensmodelle war der IT-Betrieb allerdings bislang außen vor. Anfänglich half die agile Bewegung, die Herstellung von Software-Produkten mit den Zielen des Kunden zusammenzubringen und Feedback-Zyklen zwischen der IT-Entwicklung und dem Kunden einzurichten, was aber im Lebenszyklus einer Anwendung nur eine kurze Teilstrecke ausmacht (Massem 2015). Und die Herausforderungen, vor die Unternehmen bei Scrum gestellt werden, gelten ebenfalls für die Einführung von DevOps. Hierarchien müssen infrage gestellt und organisatorische Anpassungen der Aufbauorganisation durchgeführt werden. Unterdessen scheitern Scrum-Einführungen häufig an der Durchsetzung organisatorischer Änderungen, die jedoch zur Förderung der Selbstorganisation notwendig sind (Roock 2011). Hier offenbaren die Gemeinsamkeiten von Scrum und DevOps gleichzeitig Schwächen.

Insofern scheint die schlanke Steuerungsmethode Kanban für DevOps besser als Scrum geeignet zu sein. Mitsamt dem Verständnis für den ununterbrochenen Fluss von Arbeit und für Pull-Systeme gibt es keine Notwendigkeit mehr für Iterationen zum Erreichen von Agilität (Ladas 2008). Allerdings zeigt auch Kanban im Praxiseinsatz Schwächen für DevOps. Es besteht nämlich die Gefahr, dass evtl. die Abstimmung des Teams mit dem Kunden vernachlässigt wird, was beim DevOps-Ansatz allerdings definitiv nicht gewünscht ist. Kanban legt Wert auf hohe Produktivität, aber nicht auf die Interaktion mit den Stakeholdern (Coutinho 2014). Mit DevOps werden die traditionelle Rollenverteilung aufgeweicht und eher cross-funktionale Teams, wie sie in Scrum üblich sind, aufgestellt. Entwickler sind überdies verantwortlich für den Betrieb der von ihnen geschriebenen Anwendungen und stehen dazu im Kontakt mit dem Kunden (Vogels 2006). Gleichwohl unterstützt Kanban hierbei wenig.

2.2 Die sich anbietende Konsequenz: Scrumban

Scrum und Kanban für sich betrachtet, lassen die Erkenntnis zu, dass sich bei beiden Ansätzen für DevOps Herausforderungen ergeben. Sie müssen aber keine Alternativen darstellen; die Verknüpfung von Scrum und Kanban empfiehlt sich vielmehr aus ganzheitlicher Sicht. Folglich erscheint die Kombination lohnenswert, da mit Scrum zunächst die reine Entwicklung betrachtet wird und Kanban zusätzliche Prozessbausteine der Wertschöpfungskette verbessern möchte (Roock 2011). Die benötigte Methode heißt Scrumban. Mit Scrumban werden sodann Teams befähigt, Scrum-Praktiken einzusetzen und diese mit Kanban-Elementen zu verbessern. Dazu können die tägliche Abstimmung, Retrospektive-Termine und Reviews aus Scrum zählen, verbunden mit den Kapazitätsgrenzen und klaren Ausführungsreihenfolgen aus Kanban (Tal 2015). Im Vergleich zu den ursprünglichen Ausprägungen von Scrum und Kanban gibt es allerdings auch einige Unterschiede in der Arbeitsweise. Tab. 1 zeigt die Abweichungen von Scrumban zu Scrum und Kanban.
Tab. 1

Modifikation von Scrumban (Reddy 2016)

Änderungen in Scrumban …

… im Vergleich zu Scrum

… im Vergleich zu Kanban

Anerkennung der Rollen des bestehenden Managements mit der Zielvorstellung selbst organisierter Teams innerhalb festzulegender Organisationsgrenzen

Möglichkeit, alternativ auch Spezialisten im Team einzusetzen

Beachtung des Fluss-Prinzips

Mit Scrum festgeschriebenes Vorgehensmodell als Prozessbasis

Möglicher Einsatz von Iterationen, falls geeignet

Deutlichere Formalisierung von Ereignissen, ähnlich wie in Scrum, zur kontinuierlichen Verbesserung

Für Scrumban gilt besonders der Grundsatz der Visualisierung. Echtzeitinformationen am Board sollen zur Koordination verschiedenster Geschäftsanforderungen, Störungen, Priorisierungen sowie Verbesserungen herangezogen werden (Reddy 2016). Das zentrale Element von Scrumban zur Steuerung ist somit das Kanban-Board und nicht mehr der Scrum-Sprint als künstlicher Organisationsrahmen. So erlaubt Scrum zusammen mit Kanban eine schnellere Reaktionsfähigkeit am Kanban-Board. Zumal die Möglichkeit, zusätzlich unvorhersehbare Anforderungen zu priorisieren und flexibel in den Arbeitsprozess einzubinden, gegeben ist (Swisher 2014).

2.3 Eignung von Scrumban für Organisationen, die DevOps anstreben

Die Arbeitsweise nach Scrumban kann zur Einführung der DevOps-Philosophie dienlich sein. Es ist in Scrumban kein Widerspruch, vorübergehend Sprints als organisatorischen Rahmen in der Entwicklung für Releases oder zu fixen Terminen in den Anfängen des Kulturwechsels hin zu DevOps einzusetzen. Idealerweise müssen Releases aber nicht mehr über Sprints geplant werden und Probleme, die eine anzustrebende Liefer-Pipeline behindern, geraten verstärkt in den Vordergrund. Folgender Ablauf bei Scrumban kann so typischerweise vorkommen (Burrows 2015):
  1. 1.

    Visualisierungen, Standup-Meetings um das Board herum und die Einführung von WIP-Limits beschleunigen die Fertigstellung von Arbeitspaketen.

     
  2. 2.

    Spätere Prozessschritte geraten nach der sichtbaren Fertigstellung verstärkt in den Fokus, sofern diese eine kontinuierliche Lieferung behindern.

     
  3. 3.

    Releases können aus dem Sprint Planning genommen und bei der Abarbeitung verschiedenen Arbeitstypen oder Serviceklassen am Board zugeordnet werden.

     
  4. 4.

    Das Sprint Planning wird einfacher und muss nicht mehr die Schätzung der zutreffenden Menge von Arbeitspaketen für einen Sprint enthalten.

     

Mit der Nachverfolgbarkeit inkrementeller Entwicklung am Board über den gesamten Software-Lebenszyklus kann also ein Ansammeln von technischen Schulden vermieden werden. In Bezug darauf ist die Darstellung sämtlicher Tätigkeiten aus Entwicklung und Betrieb erforderlich. Scrumban hat dabei den Anspruch, möglichst den Aufwand für Planung zu reduzieren. Da DevOps einen stabilen, ausbalancierten und hoch performanten Arbeitsprozess anstrebt, kann dies auch erreicht werden.

3 Gestaltungsempfehlungen zu Scrumban

Es gibt bisher keinen anerkannten Leitfaden für Scrumban im Einsatz für DevOps. Als Rahmenwerk versetzt Scrumban Teams aber sehr wohl in die Lage, für DevOps nicht nur schlanke Methoden, sondern auch agile Vorgehensmodelle gemeinsam als Management-Methode bedarfsgerecht einzusetzen. Damit kann die hier vorgestellte, konkrete Ausprägung von Scrumban als durchaus passende Option für Teams betrachtet werden, die Software stabil und schnell liefern und die DevOps-Philosophie verfolgen möchten.

3.1 Treiber der DevOps-Philosophie

Zunächst ist eine iterative Software-Entwicklung die notwendige Bedingung für DevOps in einer frühen Stufe der Agilität. Auf Unternehmensleitungsebene muss zweifelsohne zudem sehr wohl die Bereitschaft vorhanden sein, Strukturen der Organisation gegebenenfalls zu verändern sowie bei Bedarf technisch aufzurüsten und im Rahmen von Continuous Delivery Automatisierungstechniken zu verwenden.

Organisationen, die planen, agile Entwicklungspraktiken einzuführen oder beabsichtigen, das bisherige agile Vorgehen in einzelnen Teams auf weitere Bereiche der Organisation auszuweiten, müssen die agile Kultur und Denkweise respektieren. Als optimale Zielvorstellung agiler Transformationen in Unternehmen zählt hierbei momentan DevOps. Die Verwendung von agilen Vorgehensmodellen und vor allem das Verständnis für Agilität sind dadurch die Voraussetzung für DevOps. Auf dem Weg dorthin können schlanke Management-Ansätze wie Kanban den entscheidenden Beitrag liefern.

Zwei Facetten von Kanban sind diesbezüglich förderlich: Zum einen entsprechen die zugrunde liegenden, schlanken Leitprinzipien der DevOps-Philosophie und ergänzen Continuous Delivery, zum anderen kann Kanban als Steuerungsmethode für die Einführung von zunächst Scrum-Praktiken und darüber hinaus zum Übergang hin zu DevOps verwendet werden und eine tiefgreifende Agilität erzeugen.

Für DevOps muss neben der Software-Entwicklung allerdings zugleich der Betrieb samt Tagesgeschäft näher betrachtet werden. Der Fokus von Kanban-Elementen liegt nun vordergründig auf der moderaten, aber kontinuierlichen Verbesserung, um den gleichbleibenden Fluss von Arbeitspaketen über die gesamte IT-Wertschöpfungskette zu gewährleisten. Dazu zählen dann die Software-Entwicklung, Testdurchführungen, Wartungstätigkeiten, technische Infrastrukturbereitstellung und der Betrieb mitsamt Inbetriebnahmen und dem Anwender-Support. Bezüglich der Übernahme dieser Verantwortungen wären dann ferner die agilen Kernelemente der Zusammenarbeit mit dem Kunden und der Selbstorganisation von Teams geeignet. Die Realisierung ist in den formalen Ereignissen von Scrum vorgeschrieben, deren Anwendung wiederum durch Einsatz eines Kanban-Boards erleichtert würde. So lassen sich also Elemente sowohl aus Scrum als auch aus Kanban als Treiber für DevOps einsetzen, wobei mit Scrumban gegenwärtig die Möglichkeit gegeben, diese je nach Bedarf und innerhalb zu definierender Organisationsgrenzen zu bündeln.

3.2 Optimale Ausgestaltung von Scrumban für DevOps

Die Kernpraktiken zu Kanban können allesamt verwendet sowie um einige Elemente von Scrum angereichert werden, was zur Etablierung einer agilen Kultur unter DevOps hilfreich sein kann. Losgelöst von der Tatsache, ob Scrum schon für die Software-Entwicklung im Einsatz ist oder klassisch entwickelt wird, geht mit der Einführung von Scrumban die Verwendung eines Kanban-Boards einher (vgl. Abb. 2).
Abb. 2

Scrumban für DevOps mit Kanban-Board im Mittelpunkt

Während sich mit Kanban die gesamte IT-Lieferkette kontrollieren und steuern lässt, können die dazu benötigten Teams nach Scrum organisiert werden. Die optimale Zusammensetzung für DevOps besteht aus den Elementen:
  • Visualisierung der kompletten IT-Wertschöpfungskette über den Anwendungslebenszyklus anhand eines Kanban-Boards einschließlich WIP-Limits sowie der Klassifizierung anfallender Arbeiten und täglicher Standups zur Steigerung der Stabilität und des Durchsatzes von Arbeitspaketen.

  • Etablierung von Feedback-Schleifen von regelmäßigen Retrospektive- und Review-Terminen für einen kontinuierlichen Lernprozess sowie zur Reflektion der Zusammenarbeit.

  • Iterationen als Basis des Verständnisses für den anzustrebenden, ununterbrochenen Fluss von Arbeit.

  • Gesteigerter Fokus auf Qualität durch Automatisierung, kleinere Lieferumfänge und kürzere Durchlaufzeiten mit Continuous Delivery.

  • Nutzung eines zentralen Backlogs zur einfachen Planung und Priorisierung.

  • Einsatz geeigneter Metriken zur kontinuierlichen Verbesserung im Rahmen des PDCA-Zyklus.

  • Aufbau eines selbstorganisierten, cross-funktionalen Teams, welches die vollständige Verantwortung für ein Software-Produkt übernehmen kann und sich – evtl. unterstützt von einer koordinierenden Rolle wie bspw. die des Scrum Masters – mit dem Kunden abstimmt.

Infolge der Visualisierung des beabsichtigten, kontinuierlichen Flusses von Arbeitspaketen am Kanban-Board und des Informationsaustausches mittels der Scrum-Ereignisse erwächst eine Kultur der Zusammenarbeit und offenen Kommunikation zwischen Teammitgliedern aus der Entwicklungs- und Betriebsabteilung. Durch den Einsatz von Scrumban kann demnach ein ganzheitlicher Arbeitsprozess für sämtliche Tätigkeiten aus Software-Entwicklung und -Betrieb einschließlich des Tagesgeschäftes entstehen, der von den Teammitgliedern eines zentralen DevOps-Teams beherrscht wird.

Im Vorfeld müssen für eine erfolgreiche DevOps-Einführung allerdings sowohl der Einsatz von Automatisierungswerkzeugen als auch organisatorische Anpassungen in Erwägung gezogen werden. Umgestaltungen in klassischen IT-Organisation sind dabei oft schwierig; anfangs kann versuchsweise ein kleines, cross-funktionales Team, zusammengestellt aus Spezialisten der Abteilungen Entwicklung und Betrieb, die Aufgabe erhalten, ein Software-Produkt unter Zuhilfenahme von Scrumban ganzheitlich zu betreuen.

Der Nachweis, dass agile zusammen mit schlanken Prinzipien umsetzbar sind, die agile Kultur gelebt werden kann und darüber hinaus in klassisch geprägten IT-Organisationen Veränderungen möglich sind, wurde in Grundzügen bereits am Beispiel des neu aufgestellten Entwicklungsteams des Hafenlogistikkonzerns erbracht. Denn das abteilungsübergreifende Produktteam aus Spezialisten der Entwicklungs-, Kundenservice-, und Betriebsabteilung hat mittlerweile sämtliche Kenntnisse über den vollständigen Lebenszyklus der zu betreuenden Plattform erworben, identifiziert sich mit dieser und kann das komplette Aufgabenspektrum eigenverantwortlich und in effizienter Zusammenarbeit bearbeiten.

Literatur

  1. Baumann J (2015) DevOps light: DevOps in regulierten Umgebungen. OBJEKTSpektrum 02/2015:42–45Google Scholar
  2. Burrows M (2015) Kanban, Verstehen, einführen und anwenden. Dpunkt, HeidelbergGoogle Scholar
  3. Coutinho R (2014) Support of DevOps: Kanban vs. Scrum. http://devops.com/2014/07/29/kanban-vs-scrum/. Zugegriffen: 25. Nov 2016Google Scholar
  4. Kim G (2014) The phoenix project resource guide. In: Kim G, Behr K, Spafford G (Hrsg) The phoenix project. IT Revolution, Portland, S 347–382Google Scholar
  5. Ladas C (2008) Scrumban and other essays on Kanban system for lean software development. Modus Cooperandi, SeattleGoogle Scholar
  6. Massem F (2015) Operations heute und morgen. http://heise.de/-2624295. Zugegriffen: 25. Nov 2016Google Scholar
  7. Reddy A (2016) The Scrumban [R]Evolution, getting the most out of agile, scrum, and lean Kanban. Addison-Wesley, New YorkGoogle Scholar
  8. Roock A (2011) Scrum und Kanban sinnvoll kombinieren. https://www.projektmagazin.de/artikel/scrum-und-kanban-sinnvoll-kombinieren_919223. Zugegriffen: 25. Nov 2016Google Scholar
  9. Swisher WP (2014) Implementing Scrumban. https://switchingtoscrum.files.wordpress.com/2013/12/implementing-scrumban_v1-32.pdf. Zugegriffen: 25. Nov 2016Google Scholar
  10. Tal L (2015) Agile software development with HP agile manager. Springer, New YorkCrossRefGoogle Scholar
  11. Vogels W (2006) A conversation with Werner Vogels, learning from the Amazon technology platform. ACM QUEUE 4(4):14–22. http://queue.acm.org/detail.cfm?id=1142065. Zugegriffen: 25. Nov 2016Google Scholar

Copyright information

© Springer Fachmedien Wiesbaden 2017

Authors and Affiliations

  1. 1.Hamburger Hafen und Logistik AGHamburgDeutschland
  2. 2.IT Servicemanagement und agile OrganisationsentwicklungGöttingenDeutschland

Personalised recommendations