You will find this article in english below.
Organisationen: Traditionell vs. agil
In Verbindung mit der digitalen Transformation liest man häufig auch von der Notwendigkeit einer Transformation der eigenen Organisation. Ziel ist eine agile Organisation.
Was ist darunter zu verstehen? Was unterscheidet traditionelle Organisationsformen und Methoden von agilen? Wie unterscheidet sich die Arbeit insbesondere bei der Produktentwicklung und einführung, z. B. für eine Software? Wie unterscheidet sich im Fall von Software der spätere IT-Betrieb?
In diesem Artikel möchte ich auf diese Fragen eingehen und die Stärken und Schwächen beleuchten, aber auch die Herausforderungen, die sich nach meiner Erfahrung durch agile Methoden für Organisationen ergeben.
Traditionelle Modelle
Wasserfallmodell
Nach dem Wasserfallmodell werden einzelne Projektphasen sequentiell bearbeitet. Der Fluss des Projekts erfolgt von einer Phase zur die nächsten, ähnlich einem Wasserfall mit mehreren Kaskaden. Die Phasen werden traditionell wie in Abbildung 1 dargestellt, gegliedert.
Abbildung 1 Schema des Wasserfallmodells nach Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0
An der Abarbeitung einer Phase sind häufig, ähnlich wie bei Gewerken bei einem Hausbau, spezialisierte Mitarbeiter beteiligt:
- bei den Beschreibungen der Anforderungen, häufig in Form eines Lastenhefts, Mitarbeiter und spätere Anwender aus den betroffenen operativen Bereichen ggf. unterstützt durch Arbeitskreise und Berater,
- im Entwurf IT-Architekten, die zumeist ein Pflichtenheft und einen Architekturentwurf erstellen, auf dessen Basis häufig ein Festpreisangebot abgegeben und Werkvertrag mit dem implementierenden Dienstleister geschlossen wird,
- in der Implementation Entwickler, die die Lösung auf Basis des Pflichtenhefts und ggf. ergänzenden Informationen der IT-Architekten programmieren,
- in der Überprüfung Tester des implementierenden Dienstleisters mit nachfolgenden Integrations- und Abnahmetests durch den Auftraggeber, an dem dann die Mitarbeiter beteiligt sind, die die Anforderungen beschrieben haben.
Übergreifend koordiniert werden diese Phasen und Mitarbeiter durch einen Projektleiter. Erfolgt die Implementation durch Entwickler des eigenen Unternehmens, so sind die Mitarbeiter häufig in einer Matrix organisiert und temporär dem Projektleiter fachlich zugeordnet.
Klassischer IT-Betrieb
Der klassische IT-Betrieb folgt häufig den Grundsätzen von ITIL. ITIL ist eine Sammlung von Best-Practice-Ansätzen und beschreibt Prozesse, Funktionen und Rollen zum Betrieb von IT-Infrastruktur.
Im klassischen IT-Betrieb hat der zuverlässige und störungsfreie Betrieb die oberste Priorität. Viele Organisationen setzen dabei ITIL dahingehend um, dass die Entwicklung und der IT-Betrieb organisatorisch und disziplinarisch voneinander getrennt sind. Neue Softwarereleases werden in geplanten Zyklen nach eigenen Tests durch Mitarbeiter des IT-Betriebs in produktiven Umgebungen bereitgestellt. Je nach Organisation wird monatlich oder einmal im Quartal ein neues Release bereitgestellt. In Abstimmung mit dem oder den Projektleitern wird festgelegt, welche Funktionen (Features) in ein Release aufgenommen werden. Die Erstellung des Release folgt zumeist dem Wasserfallmodell.
Agile Modelle
Scrum / Kanban
Scrum, als Beispiel für ein verbreitetes agiles Framework, kennt ebenfalls die Tätigkeiten der Anforderungsdefinition, des Entwurfes, der Implementation und der Überprüfung. Allerdings durchläuft nicht das gesamte zu erstellende Gewerk einmal diese Phasen wie im Wasserfallmodell in einem Stück, sondern die Anforderungen werden in mehreren Schritten, sogenannten Sprints, realisiert. Das zu entwickelnde Werk oder die zu erstellende Softwarelösung wird als Produkt betrachtet. Hierbei übernimmt der „Product Owner“ sowohl fachliche als auch budgetäre Verantwortung.
Scrum folgt einem empirischen Ansatz mit den Säulen Transparenz, Überprüfung (Inspect) und Anpassung (Adapt). Das, was man durch regelmäßige Überprüfungen lernt, fließt in Form von Anpassungen in die weitere Produktentwicklung ein. Bei der Überprüfung wird ausdrücklich das Feedback von Kunden berücksichtigt, um das Produkt tatsächlich an den aktuellen Anforderungen des Marktes auszurichten. Außerdem stützt sich Scrum auf die Grundsätze von Lean Thinking, wozu das „Pull-Prinzip“ gehört und das Ziel, Verschwendung zu vermeiden. Der Scrum-Guide ist hier verfügbar.
Das Produkt wird gemeinschaftlich von einem Scrum-Team realisiert. Zum Scrum-Team gehört der Product Owner, das Entwicklerteam und ein „Scrum Master“.
Der Scrum Master ist kein klassischer Projektmanager, sondern eher ein „Facilitator“ für das Scrum-Team. Seine Hauptaufgabe besteht darin, sicherzustellen, dass das Scrum-Team das Scrum-Framework und den empirischen Ansatz korrekt versteht und erfolgreich anwendet. Insbesondere fördert er das Team in der Fähigkeit zur Selbstorganisation. Er hält dem Team auch „den Rücken frei“, indem er dort, wo Engpässe oder Hindernisse (Impediments) entstehen, sich Team-intern und -extern eine Lösung fördert.
Das Entwicklerteam besteht aus Architekten, Entwicklern und Testern. Das Team verfügt über alle erforderlichen Fähigkeiten und Mittel (Ausstattung, Werkzeuge), um das Produkt realisieren zu können.
Zu Beginn der Produktentwickler erstellt der Product Owner gemeinsam mit den Anforderern (Stakeholdern) das sogenannte Product Backlog, eine grobe Liste der Anforderungen. Der Product Owner kommunizierte auch mit Stakeholdern, die nicht nur fachliche Anforderungen an das Produkt haben, sondern in jeglicher Hinsicht Einfluss auf das Produkt nehmen (z. B. Datenschutz, IT-Security, Rechtsabteilung).
Nachdem das Produkt Backlog durch den Product Owner priorisiert wurde, kann die eigentliche Umsetzung beginnen. Das Produkt wird nun schrittweise in sogenannten „Sprints“ realisiert, wie in Abbildung 2 gezeigt. Ein Sprint dauert zwischen zwei und vier Wochen. Danach beginn der Zyklus von Neuem. Inzwischen wurden weitere Anforderungen beschrieben und im Product Backlog priorisiert. Der empirische Ansatz ermöglicht es nun, flexibler (agiler) als im klassischen Wasserfallmodell noch während der Produktentwicklung Anpassungen vorzunehmen, um ein marktgerechtes Produkt entstehen zu lassen.
Abbildung 2 Schema Vorgehen in Scrum-Projekten,
Quelle: DasScrumTeam AG
Ein Sprint ist vergleichbar mit einem Teilprojekt. Zu Beginn eines Sprints plant das Scrum-Team gemeinsam den Umfang des kommenden Sprints. Der Product Owner bringt dazu den Vorschlag für ein Sprint-Ziel ein. Das Entwicklerteam wählt aus dem Product Backlog zum Sprint-Ziel passende Einträge und übernimmt diese in das vom Entwicklerteam gemeinsam verantwortete Sprint Backlog. Nach dem gemeinsamen „Commitment“ des Entwicklerteams zum Sprint-Ziel und dem geplanten Sprint Backlog, beginnt die Realisierung.
Typisch für Scrum ist, dass sich das Entwicklerteam täglich zu einem kurzen, maximal 15-minütigem Meeting trifft, in dem es die Arbeit für den aktuellen Tag abstimmt und eventuelle Hindernisse anspricht.
Am Ende jedes Sprints steht ein betriebsbereites Produktinkrement zur Verfügung, das die geplanten Anforderungen erfüllt. Das Scrum-Team präsentiert dieses Produktinkrement während des sogenannten Sprint-Reviews den Stakeholdern. Während dieses Meetings gibt der Product Owner außerdem einen Überblick über die gesetzten Prioritäten und die Zielsetzungen für den kommenden Sprint. Die Sprint-Review dient somit nicht nur als bloße Demonstrationsveranstaltung, sondern fungiert als interaktives Arbeitsmeeting für das Scrum-Team und die beteiligten Stakeholdern. Idealerweise nehmen daran auch Kunden teil. Die Sprint Review setzt also die empirischen Säulen von Scrum Transparenz, Überprüfung und Anpassung um.
Um die Zusammenarbeit des Scrum-Teams zu verbessern, trifft sich dieses unter Anleitung des Scrum-Masters am Ende des Sprints (Sprint Retrospektive, Lessons learned). Auch dieses Meeting dient zur Überprüfung und hat Anpassung zum Ziel.
Zur Steuerung der Aufgaben des Teams wird Scrum häufig mit Kanban kombiniert. Dieser ursprünglich aus der Automobilfertigung stammende Ansatz wurde auf die Softwareentwicklung übertragen. Die einzelnen Aufgaben werden dabei auf Kanban-Karten notiert und durchlaufen die Softwareproduktion. Als einzelne Produktionsbereiche gelten dabei zumeist Design, Test-Preparation, Development, Test und Deployment. Die Produktion erfolgt typisch für Kanban nach dem Pull-Prinzip. Nachfolgende Produktionsbereiche fordern bei freien Kapazitäten beim vorausgehenden Produktionsbereich neue Aufgaben an. Ein Prinzip von Kanban ist, den Fluss der Arbeit zu visualisieren. So ist auf dem Kanban-Board erkennbar, wie vielen Aufgaben in welchem Produktionsbereich stecken (WiP/Work in Progress). So werden Engpässe in einzelnen Bereichen leichter erkennbar, wodurch der Prozess der Realisierung der Features optimiert werden kann.
Neben Features werden auch Bugs auf Kanban-Karten notiert und durchlaufen ebenso den gesamten Prozess.
Continuous Integration, Continuous Delivery und DevOps
Auf der Basis von agilen Methoden wie Scrum und Extreme Programming haben sich Konzepte etabliert, die eine kurzfristige und doch hohen Qualitätsansprüchen genügende Bereitstellung von Software ermöglichen. Das Konzept der Continuous Integration beschreibt Prozesse, Grundsätze und Anforderungen an Werkzeuge, um fortlaufend und mit einem hohen Automatisierungsgrad qualitativ hochwertige Software zu erstellen. Automatisiert meint dabei nicht, dass die Programmierung selbst automatisiert erfolgt. Diese Tätigkeit obliegt nach wie vor Entwicklern. Die Continuous Integration automatisiert jedoch den Prozess, der aus dem Quellcode eine neue Programmversion des Softwareprodukts baut (Software Build).
Ein wesentliches Element sind dabei automatisierte Tests, sogenannte Unittests. Als Grundlage für einen Unittest dienen Business Cases, die durch den jeweiligen Fachbereich beschrieben werden. Ein Business Case beschreibt einen konkreten Geschäftsvorfall, beispielsweise:
Der Mitarbeiter Müller aus der Niederlassung 0815 erfasst am 15.01.2016 für die Sendung 4711 eine Retoure an den Versender aufgrund einer Annahmeverweigerung durch den Empfänger. Erwartet wird dabei, dass der Mitarbeiter durch die Software einen Fehlerhinweis erhält, da in der Datenbank bereits dokumentiert ist, dass die Zustellung der Sendung am 14.01.2016 erfolgte.
Der Entwickler verwendet den Business Case, um ein kleines Testprogramm zu schreiben. Dieses ruft die Softwarefunktion oder Methode (z. B. eine API-Funktion) auf, die durch den Test überprüft werden soll und durch den beschriebenen Business Case genutzt wird. Dabei nutzt er die konkreten Informationen aus dem Business Case als Parameter für den Funktionsaufruf. Da der Business Case auch das erwartete Ergebnis definiert, kann das Testprogramm dieses mit der tatsächlichen Rückgabe der getesteten Funktion vergleichen. Stimmen erwartetes und tatsächliches Ergebnis überein, so ist der Test erfolgreich, andernfalls fehlerhaft.
Während der automatischen Erstellung eines Software Builds werden alle Unittests durchlaufen. Nur wenn alle Unittests erfolgreich abgeschlossen werden konnten, steht eine neue ausführbare Programmversion zur Verfügung.
Das Konzept der Continuous Delivery führt den Prozess der Continuous Integration fort und beschreibt Techniken und Prozesse, wie neue Programmversionen in kurzen Zyklen für die stabile produktive Nutzung bereitgestellt werden.
Zur Umsetzung von Continuous Delivery beschreibt der DevOps-Ansatz eine entsprechende Philosophie und einen organisatorischen Rahmen. Der Kern liegt darin, wie die Zusammenarbeit zwischen den Entwicklern (Dev) und dem IT-Betrieb (Ops) verbessert werden kann. In klassischen Organisationen sind diese beiden Abteilungen voneinander getrennt und verfolgen kollidierende Ziele: die Entwickler möchten möglichst kurzfristig und häufig neue Programmversionen an den Endanwender ausliefern, um Bugfixes und neue Funktionen bereitzustellen; der IT-Betrieb möchte möglichst selten Änderungen an der produktiven Umgebung, da jede Änderung das potentielle Risiko trägt, den IT-Betrieb zu stören. Der DevOps-Ansatz fördert dabei eine Kultur, die die Zusammenarbeit zum Nutzen des Endanwenders verbessert, ohne Risiken für den stabilen IT-Betrieb zu erhöhen. Das Softwarearchitekturmodell der Microservices legt dabei eine technische Grundlage, um auftretende Fehler und Störungen im Betrieb zu begrenzen und optimal zu behandeln.
Vergleich der Modelle
Welches Vorgehensmodell für welches Projekt besonders geeignet ist, um zuverlässig und kosteneffizient die Projektziele zu erreichen, hängt insbesondere von der Komplexität des Projekts ab und der an dem Projekt beteiligten Persönlichkeiten.
Der Komplexitätsforscher Ralph Douglas Stacey hat für zunehmende Komplexität zwei Treiber identifiziert: Uneinigkeit und Unsicherheit. Übertragen auf ein IT-Projekt bedeutet das, dass wenn Einigkeit zu Vorgehen, Ressourcen und Budget besteht und man genau weiß, was man möchte und keine offenen Punkte bestehen, das Projekt als einfach eingestuft werden kann. In Projekten, in denen Uneinigkeit und Unsicherheit höher ist, steigt die Komplexität bis hin zu chaotisch, wobei chaotisch in diesem Fall nicht negativ zu deuten ist. Welche Komplexität ein Projekt besitzt, wird durch das Projekt selbst, seine Rahmenbedingungen und die Beteiligten bestimmt. Eine hohe Komplexität lässt sich nicht immer vermeiden. Die Unsicherheit wird häufig dadurch getrieben, indem zwar eine Vision von dem finalen Produkt existiert, aber der konkrete Weg zur Realisierung unklar ist und mitunter auch experimentell vorgegangen werden muss. Der Umfang oder die Dauer des Projekts gilt nach diesem Modell nicht als Treiber für Komplexität. Demnach kann der Bau einer großen Anlage, der mehrere Monate in Anspruch nimmt, als kompliziert eingestuft werden, sofern die Faktoren Uneinigkeit und Unsicherheit gering sind.
Das Wasserfallmodell ist insbesondere für Projekte geeignet, die den Komplexitätsgrad einfach oder kompliziert haben, agile Methoden für komplex und chaotisch.
Die Erfahrungen mit agilen Methoden haben gezeigt, dass sich damit kurze bis sehr kurze Produktzyklen mit einer dennoch hohen Qualität realisieren lassen. Sie empfehlen sich, wenn nicht im Detail frühzeitig geplant werden kann, wie das zu erstellende Produkt final aussehen soll (hohe Unsicherheit). Dies wird auch durch den Vergleich der Wertschöpfungskurven der beiden Modelle deutlich (Abbildung 4).
Die graue Linie gibt den Verlauf bei einem klassischen Vorgehensmodell wieder, die orange bei einem agilen Vorgehen. Aufgrund der häufigen Iterationen z. B. in Form von Sprints, entsteht bei der Anwendung von agilen Methoden bereits früh ein erstes Produktinkrement, z. B. in Form eines Klick-Dummys. Die Iterationen ermöglichen es auch, für jede Iteration/jeden Sprint die Anforderungen nachzujustieren. Bei Abschluss des Projekts erhält man so ein Produkt, das den Anforderungen entspricht, die erst zuletzt festgeschrieben wurden. So können praktische Erfahrungen berücksichtigt werden, die während des Projektverlaufs gewonnen wurden. In der Grafik entspricht daher das Produkt den Anforderungen, die zum Zeitpunkt tx definiert wurden.
Klassische Vorgehensmodelle beginnen mit einer längeren Analyse- und Planungsphase. Dazu werden früh im Projekt, in der Grafik zum Zeitpunkt t1, die Anforderungen festgeschrieben, z. B. in Form eines Pflichtenhefts. Entsprechend entspricht das fertige Produkt am Ende des Projekts den Anforderungen zum Zeitpunkt t1.
Die Vorteile der klassischen Methoden werden häufig in einer vermeintlichen Kostensicherheit gesehen: Da zum Zeitpunkt t1 der Funktionsumfang festgeschrieben wird, kann ein Dienstleister den Aufwand zur Umsetzung schätzen und ist in der Lage ein Festpreis anzubieten. Dieser Festpreis wird jedoch in der Praxis nicht selten überschritten, da zum Zeitpunkt t1 Anforderungen übersehen wurden, noch nicht bekannt waren oder erst durch den Fortschritt der Zeit im Projekt hinzukamen. Diese Änderungen erhöhen dann in Form von Projektnachträgen die Kosten.
Kostensicherheit kann in agilen Projekten durch den „Design-to-Budget“-Ansatz sichergestellt werden. Vor jeder Iteration/jedem Sprint definiert der Product Owner ein Budget und stimmt mit dem Team/dem Dienstleister ab, welche Features in diesem Rahmen realisiert werden können. Dies fördert eine Kosten-Nutzen-Abwägung einzelner Funktionen und berücksichtigt das Pareto-Prinzip. Dieses besagt, dass 80 % des Ergebnisses mit 20 % des Gesamtaufwands erreicht werden, wohingegen die verbleibenden 20 % der Ergebnisse 80 % der Kosten verschlingen. Durch eine zielgerichtete Kosten-Nutzen-Abwägung wird häufig deutlich, dass nicht immer eine 100 %-Lösung erforderlich ist, die alle Anforderungen berücksichtigt. Das trägt direkt dazu bei, dass ein Produkt früher verfügbar ist und zu geringeren Kosten. Dabei ist nicht ausgeschlossen, dass zu einem späteren Zeitpunkt weitere Anforderungen umgesetzt werden, die dann jedoch die Erfahrungen berücksichtigen können, die durch die zwischenzeitliche Nutzung des Produkts gewonnen wurden.
Eine Herausforderung in der Anwendung von agilen Methoden besteht jedoch in dem höheren erforderlichen Reifegrad der beteiligten Personen und Organisationen. So hat bei Scrum das Team eine höhere Freiheit in der Umsetzung aber damit auch eine höhere Verantwortung. Außerdem organisiert sich das Team selbst. Beides setzt voraus, dass die Teammitglieder hierzu bereit sind.
Außerdem erfordert Scrum auch von dem Auftraggeber/dem Investor eine höhere Risikobereitschaft, da nicht vor Start eines Projekts exakt definiert ist, zu welchen Kosten und in welcher Zeit das Produkt erstellt werden kann.
Fazit
Grundsätzlich besteht nicht in jedem Projekt die Pflicht, dieses nach agilen Methoden zu bearbeiten. Aufgabenstellungen, die den Komplexitätsgrad einfach bis kompliziert haben, können erfolgreich mit einer klassischen Planung und Durchführung gelöst werden.
Die digitale Transformation stellt Organisationen vor Herausforderungen – bietet aber auch die Chance, neben neuen Technologien einen Wandel der Unternehmenskultur hin zu einer agilen Organisation zu vollziehen. Die meisten externen IT-Dienstleister und einige unternehmensinterne IT-Abteilungen arbeiten bereits mit agilen Methoden. Das vollständige Potential können agile Methoden jedoch nur entfalten, wenn der gesamte Prozess zur Entwicklung und Einführung eines neuen Produkts agile Methoden nutzt – nicht nur der Teil, der durch die IT bearbeitet wird.
Dabei lassen sich Organisationen nicht per Schalter auf agil umstellen – dies ist ein Reifeprozess. Mitarbeiter und Manager benötigen Zeit, um Vertrauen in agile Methoden zu fassen und Praxis und Sicherheit in der Anwendung zu gewinnen. In diesem Prozess können sie zumindest anfänglich durch einen externen Berater unterstützt werden, der in der Anwendung agiler Methoden erfahren ist.
Sie wollen auf meine Erfahrung zurückgreifen?
Dann freue ich mich auf Ihren Kontakt.
Organizations: Traditional vs. Agile
In connection with digital transformation, one often comes across the necessity of transforming one’s own organization. The goal is to achieve an agile organization.
What does this mean? What sets traditional organizational forms and methods apart from agile ones? How does work, especially in product development and implementation, differ, for instance, in the case of software? How does the subsequent IT operation differ in the case of software?
In this article, I aim to address these questions, shedding light on the strengths and weaknesses, as well as the challenges that, in my experience, arise for organizations through agile methods.
Traditional Models
Waterfall Model
According to the Waterfall Model, individual project phases are processed sequentially. The flow of the project moves from one phase to the next, similar to a waterfall with multiple cascades. The phases are traditionally organized as depicted in Figure 1.
Image 1: Diagram of the Waterfall Model by Paul Hoadley, Paul Smith und Shmuel Csaba Otto Traian, CC BY-SA 3.0
In the execution of each phase, specialized personnel are often involved, similar to trades in construction projects:
- In the requirements description phase, often outlined in the form of a requirements specification, employees and future users from the affected operational areas may be assisted by working groups and consultants.
- In the design phase, IT architects typically create a requirements specification and an architectural design. Based on this, a fixed-price offer is often submitted, and a contract is signed with the implementing service provider.
- In the implementation phase, developers program the solution based on the requirements specification and additional information provided by the IT architects.
- In the verification phase, testers from the implementing service provider conduct subsequent integration and acceptance tests, overseen by the client. Employees who described the requirements are often involved in this phase as well.
These phases and personnel are overseen and coordinated by a project manager. If the implementation is carried out by developers from the same company, employees are often organized in a matrix and temporarily assigned to the project manager in terms of expertise.
Traditional IT Operations
Traditional IT operations often adhere to the principles of ITIL (Information Technology Infrastructure Library). ITIL is a collection of best practice approaches that describe processes, functions, and roles for operating IT infrastructure.
In traditional IT operations, ensuring reliable and uninterrupted operation takes top priority. Many organizations implement ITIL in a way that separates the development and IT operations organizationally and disciplinarily. New software releases are deployed in planned cycles after internal testing by IT operations personnel in productive environments. Depending on the organization, a new release may be deployed monthly or quarterly. In coordination with project managers, it is determined which features are included in a release. The creation of the release typically follows the waterfall model.
Agile Models
Scrum / Kanban
Scrum, as an example of a widely used agile framework, also involves activities such as requirement definition, design, implementation, and verification. However, the entire product or solution being developed does not go through these phases in one continuous piece, as in the waterfall model. Instead, the requirements are realized in multiple steps, known as sprints. The product or solution being developed is considered a product, and the „Product Owner“ takes on both functional and budgetary responsibilities.
Scrum follows an empirical approach with the pillars of Transparency, Inspection, and Adaptation. What is learned through regular inspections is incorporated into further product development through adjustments. During the inspection, customer feedback is explicitly considered to align the product with the current market requirements. Additionally, Scrum is based on the principles of Lean Thinking, including the „Pull Principle“ and the goal of avoiding waste. The Scrum Guide is available here.
The product is collaboratively realized by a Scrum Team, which includes the Product Owner, the development team, and a Scrum Master.
The Scrum Master is not a traditional project manager but rather a facilitator for the Scrum Team. Their main task is to ensure that the Scrum Team correctly understands and successfully applies the Scrum framework and the empirical approach. In particular, they promote the team’s ability to self-organize. The Scrum Master also „has the team’s back“ by fostering solutions where bottlenecks or impediments arise, both internally and externally.
The development team consists of architects, developers, and testers. The team possesses all the necessary skills and resources (equipment, tools) to realize the product.
At the beginning of the product development, the Product Owner, together with stakeholders, creates the Product Backlog, a rough list of requirements. The Product Owner also communicates with stakeholders who have influence over the product in various aspects (e.g., data protection, IT security, legal department).
Once the Product Backlog has been prioritized by the Product Owner, the actual implementation can begin. The product is now realized gradually in sprints, as shown in Figure 2. A sprint lasts between two and four weeks. Afterward, the cycle begins anew. Meanwhile, additional requirements have been described and prioritized in the Product Backlog. The empirical approach allows for more flexibility (agility) than in the traditional waterfall model, enabling adjustments during product development to create a market-ready product.
.
Figure 2 – Process Schema in Scrum Projects,
Source: DasScrumTeam AG
A Sprint is comparable to a subproject. At the beginning of a Sprint, the Scrum Team collaboratively plans the scope of the upcoming Sprint. The Product Owner contributes the proposal for a Sprint Goal. The Development Team selects entries from the Product Backlog that align with the Sprint Goal and incorporates them into the Sprint Backlog, which is jointly responsible for the Development Team. After the Development Team’s shared commitment to the Sprint Goal and the planned Sprint Backlog, the implementation begins.
A characteristic feature of Scrum is that the Development Team meets daily for a short, maximum 15-minute meeting, where it aligns the work for the current day and addresses any potential impediments.
At the end of each Sprint, a functional product increment that meets the planned requirements is made available. The Scrum Team presents this product increment to stakeholders during the Sprint Review. During this meeting, the Product Owner also provides an overview of the set priorities and goals for the upcoming Sprint. The Sprint Review serves not only as a mere demonstration event but functions as an interactive working meeting for the Scrum Team and involved stakeholders. Ideally, customers also participate. Thus, the Sprint Review embodies the empirical pillars of Scrum: Transparency, Inspection, and Adaptation.
To enhance the collaboration of the Scrum Team, they gather under the guidance of the Scrum Master at the end of the Sprint (Sprint Retrospective or Lessons Learned). This meeting also serves for inspection and aims for adaptation.
To manage the team’s tasks, Scrum is often combined with Kanban. This approach, originally from manufacturing, has been applied to software development. Tasks are noted on Kanban cards and go through the software production phases. Design, Test Preparation, Development, Test, and Deployment are typically considered as individual production stages. Production in Kanban typically follows the Pull Principle, where subsequent stages request new tasks from the preceding stage when there are available capacities. A principle of Kanban is to visualize the flow of work. The Kanban board indicates how many tasks are in progress in each production stage (WiP/Work in Progress), making bottlenecks in individual stages more easily identifiable, optimizing the process of feature realization.
In addition to features, bugs are also noted on Kanban cards and undergo the entire process.
Continuous Integration, Continuous Delivery and DevOps
Based on agile methods like Scrum and Extreme Programming, concepts have been established to enable the short-term and yet high-quality deployment of software. The concept of Continuous Integration describes processes, principles, and tool requirements to continuously build high-quality software with a high level of automation. Automation, in this context, does not mean that programming itself is automated; developers still handle this task. However, Continuous Integration automates the process of building a new program version from the source code (Software Build).
A crucial element is automated tests, known as unit tests. Business cases, described by the respective business department, serve as a basis for a unit test. A business case describes a specific business scenario, for example:
„Employee Müller from Branch 0815 records a return to the sender for shipment 4711 on 15.01.2016 due to the recipient’s refusal. The expectation is that the employee receives an error message through the software since the database already documents the delivery of the shipment on 14.01.2016.“
The developer uses the business case to write a small test program. This program calls the software function or method (e.g., an API function) that the test aims to verify and is used by the described business case. Using the specific information from the business case as parameters for the function call, the developer compares the expected result defined by the business case with the actual return of the tested function. If the expected and actual results match, the test is successful; otherwise, it is faulty.
During the automatic creation of a software build, all unit tests are executed. Only if all unit tests are successfully completed, a new executable program version becomes available.
The concept of Continuous Delivery extends the Continuous Integration process and describes techniques and processes for providing new program versions for stable productive use in short cycles.
To implement Continuous Delivery, the DevOps approach describes a corresponding philosophy and organizational framework. The core lies in improving collaboration between developers (Dev) and IT operations (Ops). In traditional organizations, these two departments are separate and pursue conflicting goals: developers aim to deliver new program versions to end-users as quickly and frequently as possible to provide bug fixes and new features, while IT operations want to make changes to the production environment as infrequently as possible since each change carries the potential risk of disrupting IT operations. The DevOps approach promotes a culture that improves collaboration for the benefit of end-users without increasing risks for stable IT operations. The Microservices software architecture model provides a technical foundation to limit and handle errors and disruptions efficiently during operation.
Comparison of Models
The suitability of a particular approach for reliably and cost-effectively achieving project goals depends mainly on the complexity of the project and the personalities involved in the project.
Complexity researcher Ralph Douglas Stacey has identified two drivers for increasing complexity: disagreement and uncertainty. Applied to an IT project, this means that when there is agreement on approach, resources, and budget, and one knows exactly what is wanted with no open issues, the project can be classified as simple. In projects where disagreement and uncertainty are higher, complexity increases, ranging up to chaotic, where chaos, in this case, is not necessarily negative. The complexity of a project is determined by the project itself, its conditions, and the participants. High complexity cannot always be avoided. Uncertainty is often driven by the existence of a vision for the final product, but the concrete path to realization is unclear and may require experimental approaches. According to this model, the scope or duration of the project is not a driver for complexity. Therefore, the construction of a large facility taking several months can be classified as complicated if the factors of disagreement and uncertainty are low.
The Waterfall model is particularly suitable for projects with a complexity level that is simple or complicated, while agile methods are suitable for complex and chaotic projects.
Experiences with agile methods have demonstrated their effectiveness in realizing short to very short product cycles with high quality. They are recommended when detailed planning of the final product appearance cannot be done early on (high uncertainty). This is also evident in the comparison of the value creation curves of the two models (Figure 4).
The gray line represents the progression in a traditional approach, while the orange line represents an agile approach. Due to frequent iterations, such as in the form of Sprints, agile methods generate an initial product increment early on, for example, in the form of a clickable prototype. The iterations also allow for adjusting the requirements for each iteration/Sprint. Upon project completion, the result is a product that aligns with the requirements defined most recently. This approach enables the incorporation of practical experiences gained during the project. In the graph, therefore, the product corresponds to the requirements defined at time tx.
Traditional approaches typically commence with an extended analysis and planning phase. Early in the project, at time t1 in the graph, the requirements are documented, for instance, in the form of a requirements specification. Consequently, the final product at the end of the project adheres to the requirements set at time t1.
The advantages of traditional methods are often perceived in terms of cost certainty: Since the scope of functionality is defined at time t1, a service provider can estimate the effort required for implementation and is able to offer a fixed price. However, in practice, this fixed price is often exceeded because requirements were overlooked at time t1, were not yet known, or emerged as the project progressed over time. These changes then increase costs in the form of project supplements.
Cost certainty in agile projects can be ensured through the „Design-to-Budget“ approach. Before each iteration/Sprint, the Product Owner defines a budget and collaborates with the team/service provider to determine which features can be realized within this framework. This promotes a cost-benefit assessment of individual functions and considers the Pareto principle, stating that 80% of results are achieved with 20% of the total effort, while the remaining 20% of results consume 80% of the costs. A targeted cost-benefit assessment often reveals that a 100% solution that accommodates all requirements is not always necessary. This directly contributes to making a product available earlier and at lower costs. It is not excluded that additional requirements may be implemented at a later time, but these can consider the experiences gained through the interim use of the product.
However, a challenge in the application of agile methods lies in the higher required maturity level of the individuals and organizations involved. In Scrum, for example, the team has greater freedom in implementation but also greater responsibility. Additionally, the team organizes itself, which requires team members to be willing to do so.
Scrum also requires a higher level of risk tolerance from the client/investor, as the exact costs and timeframe for creating the product are not precisely defined before the start of a project.
Conclusion:
Not every project is obligated to be processed using agile methods. Tasks with a complexity level ranging from simple to complicated can be successfully addressed with traditional planning and execution.
The digital transformation poses challenges for organizations but also offers the opportunity to undergo a cultural shift towards an agile organization alongside adopting new technologies. Most external IT service providers and some internal IT departments already work with agile methods. However, the full potential of agile methods can only be realized if the entire process of developing and implementing a new product embraces agile methods—not just the part handled by IT.
Organizations cannot switch to agile overnight; it is a maturation process. Employees and managers need time to develop trust in agile methods and gain practical experience and confidence in their application. In this process, they can be initially supported by an external consultant experienced in the application of agile methods.
If you wish to leverage my experience, I look forward to your contact.