Ein Erfahrungsbericht

Klassisch können wir – Agil leben wir

Agilität ist der Herzschlag des 21. Jahrhunderts. Umfangen wird dieses schlagende Herz vom magischen Dreieck. Wie es dazu kam, dass unser Herz hauptsächlich im agilen Beat schlägt, wir aber auch ein Herz für das klassische Projektmanagement haben, erfahren Sie in diesem Bericht.

Im Juli diesen Jahres feiert die K&K Software AG ihr 20-jähriges Bestehen. Angefangen hat alles im Jahr 2000. Durch die ersten erfolgreich abgeschlossenen Projekte stieg das Vertrauen unserer Auftraggeber und es war möglich größere Projekte und Kunden zu gewinnen. Unsere ersten Erfahrungen mit Großprojekten machten wir mit der klassischen Wasserfall- und V-Modellmethode basierend auf umfangreichen Lasten- und Pflichtenheften. Viele Projekte konnten wir mit diesen Umsetzungsstrategien erfolgreich durchführen, bis uns ein komplexes Großprojekt zum Umdenken zwang. Bei diesem Großprojekt waren die Anforderungen nicht klar definiert. Es gab zwar eine Vision, aber noch keinen ausformulierten Plan zur Umsetzung. Im Nachhinein betrachtet war es etwas naiv zu glauben, dass wir die komplexen Anforderungen trotzdem umgesetzt bekommen. Es kam wie es kommen musste. Bereits nach kurzer Zeit war klar, dass dieses Projekt zu Scheitern drohte. Wir mussten uns schleunigst etwas überlegen, damit wir doch noch zu einem Erfolg kommen konnten. Gerade zu dieser Zeit kam ein neuer Softwareentwickler in unser Team. Er berichtete von der agilen Projektmanagementmethode “Scrum”, welche er von seinem vorherigen Arbeitgeber kannte. Interessiert setzten wir uns mit Jeff Sutherland und Ken Schwaber auseinander, den Pionieren des Scrum Framework. Das Vorgehensmodell erweckte großes Interesse bei uns. Im agilen Projektmanagement werden die Entwicklungsteams als selbstorganisierende Einheit betrachtet, welche eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Der Projektleiter nimmt im Scrum eher die Rolle eines Moderators als eines Managers ein. Scrum versteht sich als ein Gegenentwurf von Befehl- und Kontroll-Organisationen und ist prädestiniert für flache Unternehmenshierarchien.* (*Quelle: https://de.wikipedia.org/wiki/Scrum#cite_note-13)

Das agile Manifest

„Wir suchen nach besseren Wegen, Produkte zu entwickeln, indem wir es selbst praktizieren und anderen dabei helfen, dies zu tun. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

Auf dem Foto ist  ein Icon zu sehen - das Icon steht für: Individuen und Interaktionen
Individuen und Interaktionen

mehr als Prozesse und Werkzeuge

 

Auf dem Foto ist ein Icon zu sehen - das Icon steht für: Funktionierende Software
Funktionierende Software

mehr als umfassende Dokumentation

Auf dem Foto ist  ein Icon zu sehen - das Icon steht für: Zusammenarbeit mit dem Kunden
Zusammenarbeit mit dem Kunden

mehr als Vertragsverhandlung

Auf dem Foto ist  ein Icon zu sehen - das Icon steht für: Reagieren auf Veränderung
Reagieren auf Veränderung

mehr als das Befolgen eines Plans

Wir erkennen dabei sehr wohl den Wert der Dinge auf der rechten Seite an, wertschätzen jedoch die auf der linken Seite noch mehr.“

Der agile Ansatz wirkt sich also auf die ganze Organisation im Unternehmen aus. Die Werte im agilen Projektmanagement sollten sich mit denen der eigenen Firmenphilosophie decken. Da sich unsere Philosophie und Arbeitsweise sowieso schon mit den agilen Werten überschnitt, konnten wir uns gut mit diesen identifizieren, was unsere Entscheidung erleichterte. So herrschte in unserem Unternehmen beispielsweise schon immer viel Gestaltungsfreiheit bei der Umsetzung, bei der Auswahl der Arbeitswerkzeuge und den eingesetzten Technologien.

Außerdem schien es als sei Scrum die perfekte Lösung für unsere anfängliche Schwierigkeit mit besagtem Großprojekt. Die Komplexität des oben genannten Projekts war für uns nicht beherrschbar, die Anforderungsdetails änderten sich während der Entwicklung häufig und dem Projektleiter viel es schwer seine Vision den Entwicklern zu vermitteln. Genau hier setzt Scrum an.
Wesentlich für Scrum ist, dass Projekte nicht mehr von A bis Z durchgeplant werden, da es aufgrund der sich ständig ändernden externen Faktoren bei umfangreichen Projekten ohnehin kaum möglich ist, bereits zu Beginn eines Projekts einen endgültigen und allumfassenden Plan zu entwickeln.

Kleine Teile ergeben ein großes Ganzes

Im Gegensatz dazu verfolgt Scrum einen agilen (sprich: wendigen) Ansatz. Es formuliert statt eines endgültigen Plans zunächst nur eine auf Anwenderbedürfnissen und Markterfordernissen basierende Produkt-Vision. Diese werden im weiteren Projektverlauf nach und nach konkretisiert. Die Entwicklung erfolgt nicht geradlinig, sondern in zyklischen Schritten. Die Anwenderbedürfnisse werden dabei zu Projektstart in sogenannten “User Stories” mittels ein, zwei prägnanter Sätze auf den Punkt gebracht.

Ein wesentlicher Bestandteil im Scrum sind die Sprints. Die Sprints teilen das Projekt in kurze Zyklen. Vor jedem Sprintstart werden Anforderungen und Entwicklungsaufträge (in Form von Userstories) neu priorisiert und die Stories mit der höchsten Priorität in den beginnenden Sprint eingeplant um im Sprint dann umgesetzt zu werden. Zum Ende eines jeden Sprints wird eine lauffähige Produktiv-Version an den Enduser ausgeliefert.
Ein Sprint sollte nie die maximale Länge von einem Monat übersteigen. Bei K&K hat sich eine 14-tägige Sprintlänge als sinnvoll herausgestellt. Da so die Zeit kurz genug ist um einen regelmäßigen Austausch zu haben und die Kunden an die Methode zu gewöhnen, aber auch lang genug, damit genügend Zeit für die Umsetzung bleibt und die Meetings nicht zu viel Zeit einnehmen.

Beim agilen Ansatz muss demzufolge weniger Zeit für eine detaillierte Planung vor dem Projektstart aufgewendet werden, da während des Projektes fortwährend weiter geplant wird. Daraus ergeben sich die Vorteile:

 

  • echtes Enduser-Feedback und “Lessons Learned”-Prozess
  • entwickelt man permanent “das Wichtigste zuerst”
  • Software ist immer dem aktuellen Stand angepasst (bezüglich Technik, Anforderungen, Unternehmensstruktur etc.)
Magisches Dreieck im Projektmanagement

Wie verhalten sich die Zielgrößen des magischen Dreiecks im agilen Prozess?

In den meisten Projekten müssen Zielvorgaben für “Zeit”, “Qualität (Inhalt, Umfang)” und “Kosten” gleichermaßen erreicht werden. Die Schwierigkeit dabei ist, dass die unterschiedlichen Größen in Beziehung zueinander stehen. Dies wird im magischen Dreieck verbildlicht. Jede Änderung an einer dieser Größen wirkt sich auf die anderen Größen aus.

Im Scrum werden durch eine fortwährende Priorisierung während des Projektes immer die wichtigsten Teile zuerst bearbeitet. Die Komponenten “Kosten” und “Zeit” werden zu Anfang des Projektes besprochen und dann in die Anzahl der Sprints mit dem entsprechenden Stundenkontingent umgerechnet.

Somit ist der Preis tatsächlich fix
“Ich beauftrage x Sprints á Summe y = Gesamtbudget z”

Der Zeit-Aspekt ist tatsächlich fix
“Die x Sprints á 2 Wochen dauern x mal 2 Wochen”

Inhalt und Umfang sind nicht fix,
aber garantiert näher an den tatsächlichen Kundenbedürfnissen als bei Pflichtenheft+Festpreis, da alle 2 Wochen Benutzerfeedback gesammelt wird aus dem sinnvolle Konsequenzen gezogen werden.

Nochmal Zusammengefasst:

Anstelle eines detaillierten Pflichtenheftes gibt es eine feste Produktvision mit definierter Zeit- und Kostenachse. Dabei wird akzeptiert, dass „Inhalt und Umfang“ vorab nicht exakt fixiert sind.

Mit Scrum wieder auf der Spur

Zurück zu unserem ersten Scrum-Projekt. Schnell wurde uns klar, dass wir den Versuch mit Scrum wagen möchten. Um Scrum in unserem Unternehmen zu etablieren engagierten wir einen zertifizierten Scrum-Trainer von außen, welcher mit initialen Trainings uns schulte und dann auch zeitweise unser Team bei der Arbeit am Projekt anleitete und begleitete. Der Rest erfolgte ganz nach dem “Learning by doing” Prinzip.

Beim Versuch allein sollte es dann nicht bleiben. Nachdem das erste Scrum Projekt erfolgreich umgesetzt wurde, führten wir Scrum in unserem Unternehmen ein. Ein agiles Team wurde gebildet, welches von nun an alle Projekte nach Scrum durchführen sollte. Auch stellten wir einen dezidierten Scrum Master ein, welche unter anderem die wichtigen Aufgaben übernimmt Störungen vom Team fernzuhalten und mit der Moderation von reflektierenden Retrospektiven dazu beiträgt, dass das Team sich fortlaufend verbessern kann.

Und siehe da! Es folgten viele weitere Projekte, die erfolgreich mit Scrum umgesetzt werden konnten, sodass wir mittlerweile auf ein paar Jährchen Erfahrung in der Arbeit mit Scrum zurückblicken können.

Retrospektive als festes Event im Scrum-Prozess

Die Retrospektive gehört zu den Events innerhalb des Scrum-Prozesses. Dieses Event ist dazu da, dass das Team gemeinsam auf den vergangenen Sprint zurückblickt und daraus lernen kann. Klassischerweise wird erörtert: Was lief gut und soll beibehalten werden (Keep), Was lief nicht so gut und soll eliminiert werden (Drop) und was wollen wir in Zukunft versuchen (Try).

Wir können dennoch auch klassisches Projektmanagement

Dennoch wissen wir, dass sich für manche Projekte eher eine klassische Entwicklung anbietet. Selbstverständlich haben wir für eine sehr lange Zeit mit klassischen Methoden Software entwickelt und kennen und können auch nach dieser Methode ein Projekt durchführen. Bei Projekten, die bereits einen genauen Projektumfang haben, kann man eine klassische Projektplanung mit dem Wasserfall- oder V-Modell verwenden. Hierbei erfolgt die Umsetzung einer genauen Spezifikation.
Nachfolgende Gegenüberstellung zeigt, wann sich welche Entwicklungsform bevorzugt anbietet.

Empfohlenes Szenario

Agile Entwicklung

Projektumfang ist eher grob umrissen und wird sich wahrscheinlich verändern.
Eingehen auf Veränderungen während der Entwicklung

Klassische Entwicklung

Projektumfang steht im Detail fest.
Umsetzung einer genauen Spezifikation.

Generelle Charakteristik

Agile Entwicklung

Es wird der Natur von Projekten Rechnung getragen, dass sich die Projektanforderungen, Prioritäten und Detailspezifikationen während des Projektverlaufes ändern.
Das Projekt wird in viele Sprints (typischerweise 2 Wochen) aufgeteilt und in jedem Sprint werden die zu entwickelnden Umfänge neu festgelegt.
Für eine neue, wichtigere Anforderung während der Umsetzung wird eine unwichtigere Anforderung entfernt.

Klassische Entwicklung

Am Anfang wird ein Lastenheft und Pflichtenheft festgelegt und exakt so entwickelt und am Ende des Projektes erfolgt die Abnahme gegen das ursprüngliche Lastenheft.

Was wird beauftragt?

Agile Entwicklung

Eine gewisse Anzahl von Sprints, in der jeweils aus dem Lastenheft formulierte User-Stories mit Akzeptanzkriterien umgesetzt werden.

Klassische Entwicklung

Umsetzung eines Pflichtenheftes (das kostenpflichtig aus dem Lastenheft erstellt wird)

Ergebnis

Agile Entwicklung

Das Ergebnis kann erheblich vom ursprünglichen Lastenheft abweichen.

Klassische Entwicklung

Das Ergebnis ist das ursprüngliche Lastenheft.

Änderungen

Agile Entwicklung

Eine Reaktion auf Veränderungen ist Kern agiler Entwicklung.

Änderungen führen zu keinen Mehrkosten und keinen Verlängerungen (aber zu Abstrichen an anderen wichtigen Funktionen).

Klassische Entwicklung

Änderungen während der Entwicklung führen zu (ggfs. erheblichen) Mehrkosten und Verlängerungen.

Änderungen bedeuten einen vorübergehenden Stopp des Projektes mit Kalkulation, neuem Angebot, Mehrkosten und neuer Freigabe/Bestellung.

Kundennutzen, Reaktion auf Veränderungen

Agile Entwicklung

Es wird in jedem (2-Wochen-) Sprint das mit dem höchsten Kundennutzen entwickelt.

Klassische Entwicklung

Es wird das ursprüngliche Lastenheft (bei Projektende oft mehrere Jahre alt) entwickelt.

Definition der Anforderungen

Agile Entwicklung

Alle Anforderungen werden in Form von User-Stories gepflegt.

Klassische Entwicklung

Im Lastenheft müssen ALLE Angaben stehen, die der Kunde umgesetzt haben möchte. Nur die gemachten Angaben können im von uns erstellten Angebot berücksichtigt werden.

Pflichtenhefterstellung

Agile Entwicklung

Es wird kein Pflichtenheft erstellt.
Der Umfang wird von Sprint zu Sprint neu festgelegt.
Änderungen an den Anforderungen sind so jederzeit möglich

Klassische Entwicklung

Nach Erhalt und Abzeichnung des Lastenheftes durch uns, erstellen wir ein Angebot zur Erstellung eines Pflichtenheftes.

Nach Beauftragung der Pflichtenhefterstellung durch den Kunden, erstellen wir ein Pflichtenheft und ein Angebot für die Umsetzung des Projektes. Das Pflichtenheft enthält weiterführende technische Informationen und genauere Angaben zur Umsetzung durch uns.

Verzichtet der Kunde auf die Erstellung eines Pflichtenheftes, steht uns das alleinige Recht für die Ausgestaltung und Bewertung der Umsetzung zu.

Verzichtet der Kunde auf die Erstellung eines Pflichtenheftes, ist eine Umsetzung des Projektes zum Festpreis mangels genauer Spezifikation nicht möglich. In dem Fall ist entweder eine agile Umsetzung in Sprints oder eine klassische Umsetzung mit Abrechnung nach tatsächlichem Aufwand möglich.

Nicht ausreichend definierte Anforderungen

Agile Entwicklung

Bei Scrum werden Anforderungen als „User-Stories“ formuliert.

Jede User-Story muss mind. 1 „Akzeptanzkriterium“ (besser mehrere Akzeptanzkriterien) zur Abnahme enthalten.

Die Entwicklung erfolgt so, dass die formulierten Akzeptanzkriterien eingehalten werden.

Der Entwickler wird jedes Akzeptanzkriterium vorführen.
Konnte der Entwickler am Ende des Sprints alle Akzeptanzkriterien erfolgreich vorführen, ist diese User-Story erfolgreich abgenommen.

Hat der Kunde vergessen, Akzeptanzkriterien zu formulieren, muss er in einem folgenden Sprint eine neue User-Story mit diesen Akzeptanzkriterien formulieren.

Aufgrund der Projektunterteilung in viele Sprints lernt der Kunde schnell, Akzeptanzkriterien ordentlich zu formulieren.

Klassische Entwicklung

Sollten uns die vom Kunden gemachten Angaben Interpretationsspielraum in der Ausführung der Umsetzung lassen, gehen wir immer von einer Minimal-Umsetzung aus, wie wir die Anforderung im Sinne von Mindest-Akzeptanzkriterien verstehen, um dem Kunden möglichst günstige Preise bieten zu können.

Wenn der Kunde bestimmte Vorstellungen oder Erwartungen von der Umsetzung hat, deren Definition er uns nicht überlassen will, muss er diese zwingend schriftlich formulieren, damit es bei der Abnahme nicht zu Missverständnissen kommt oder zu unterschiedlichen Vorstellungen von der Umsetzung. Im Pflichtenheft werden diese Vorstellungen von uns technisch erläutert. Der Kunde muss bei der Abnahme des Pflichtenheftes daher sorgfältig überprüfen, ob die beschriebenen Umsetzungen vollständig seinen Anforderungen genügen.

Änderung von Anforderungen

Agile Entwicklung

Nachdem agile Entwicklung die Zahl der Sprints festlegt und jederzeit neue Sprints beauftragt werden können, können nach jedem Sprint die Reihenfolge der Anforderungen oder die Anforderungen an sich neu festgelegt werden.

Der Kunde kann die in jedem Sprint zu leistende Arbeit nach jedem Sprint neu festlegen oder auch komplett neue Anforderungen mit aufnehmen. Im Gegensatz zur klassischen Entwicklung entstehen dafür keine Zusatzkosten oder verlängerte Umsetzungszeiträume.

Kern des agilen Ansatzes ist es, dass für jede neue oder geänderte (somit wichtigere) Anforderung (User-Story) eine andere unwichtigere Anforderung entfällt und somit nicht umgesetzt wird. Das Ergebnis bei agiler Entwicklung entspricht in der Regel nicht den ursprünglichen Anforderungen sondern ergibt sich dann aus den in den Sprints tatsächlich umgesetzten User-Stories.

Klassische Entwicklung

Änderungen aller Art, sowohl eine Änderung der Entwicklungsmethode während der Umsetzung, als auch bei klassischer Methode der Änderung von Programmteilen oder bei agiler Methode eine Erweiterung der zu leistenden Sprints, sind jederzeit möglich.

Sie lösen zwingend eine kostenpflichtige Änderung aus („Change Request“) und eine Verlängerung der Projektdauer.

Wünscht der Kunde eine Änderung am Pflichtenheft oder an bereits umgesetzten Arbeitspaketen, wird von uns ein Kostenvoranschlag inkl. Verlängerung des Umsetzungszeitraumes ausgearbeitet und dem Kunden mitgeteilt. Stimmt der Kunde dem Kostenvoranschlag und der Verlängerung des Umsetzungszeitraumes zu, wird diese Erweiterung zum Vertragsbestandteil.

Abnahme

Agile Entwicklung

Bei agiler Entwicklung erfolgt die Abnahme der einzelnen Sprints nach jedem Sprint in einem Review-Meeting. Hierbei sieht der Kunde direkt, welche Anforderungen wie umgesetzt wurden und kann schnell reagieren, indem er seine User-Stories anpasst.

Klassische Entwicklung

Am Ende des Projektes erfolgt die Abnahme gegen das ursprüngliche Lastenheft.

Änderung der Entwicklungsmethode

Agil à Klassisch

Ist jederzeit möglich.
Nach einem Sprint wird das Projekt eingefroren.
Es wird ein Lastenheft über die zu Leistenden Arbeiten erstellt, dann ein Angebot über die Pflichtenhefterstellung.
Wie normaler Projektablauf.
Hinweis: Wechsel Agil à klassisch erzeugt in der Regel höhere Kosten

Klassisch à Agil

Ist jederzeit möglich.
Der aktuelle Projektstand wird bewertet und entsprechend des bisher entstandenen Aufwandes abgerechnet.
Es wird ein neues Angebot für eine Anzahl von Sprints erstellt.

Unwesentliche Mängel

Unwesentliche Mängel können eine Abnahme, sowohl bei klassischer als auch agiler Entwicklung, generell nicht verhindern. Diese Mängel werden nach der Abnahme im Rahmen der Gewährleistung beseitigt.

24. Februar 2020

Abonnieren Sie unseren Newsletter

Jobs bei K&K Software

Unter https://stellen.kk-software.de finden Sie eine Übersicht unserer aktuellen Stellenangebote.

Unsere Lösungen

Eine Frau hört einer nicht eindeutig erkennbaren weiteren Person zu und macht Notizen zum Gespräch.

Von der Idee zur Umsetzung

Typische Fragestellung

Erhalten sie einen kurzen Überblick über beispielhafte Fragestellungen aus bisher durchgeführten Projekten.

Auf dem Foto sieht man ein jungen Mann, der auf eine Pinnwand mit Notizen blickt. Die Notizen beinhalten Texte über Anforderungen an ein Unternehmen.

Effiziente Planung

Anforderungen

Moderne Unternehmen sehen sich heutzutage mit vielen Anforderungen konfrontiert.

Mann zeichnet mit Finger Aufwärtstrend in x- und y-Achse

Auf einen Blick

Die Vorteile von BI

Gute Gründe für Ihre eigenes BI-Projekt

Das Foto zeigt die 27 Mitarbeiter der K&K Software AG.

Mit uns richtig beraten

Darum K&K beauftragen

Jahrelange Erfahrung machen uns zu dem richtigen Partner für Ihr BI-Projekt.

Unser Angebot

Das Foto zeigt eine Business Woman mit Stift und Tabloid in der Hand.

Individuell

Kalkulator

Kalkulieren Sie online die Phase-1 Workshops zum Projektstart und sehen Sie sofort den Festpreis.

Das Foto zeigt 2 Personen bei einem Offline Meeting.

Phase 1

Analyse und Konzeption

Workshop-Phase zur Planung: Eine gute Vorbereitung ist essentiell für den Projekterfolg.

Frau im Schneidersitz am Laptop sitzend sowie ein Balkendiagramm mit Aufwärtstrend und ein Kuchendiagramm

Phase 2

Umsetzung

Alle Leistungen zur Implementierung: Installation, Programmierung, Gestaltung, Schulung.

Auf dem Foto sieht man ein Tablett und Blätter mit Diagrammen und Analysen.

Phase 3

Laufender Betrieb

Arbeiten nach dem Projekt: Wartung der Software, Hotline und Support, Updates und Erweiterungen

30 Tipps für bessere Dashboards

30 Tipps für bessere Dashboards

Die Gestaltung eines übersichtlichen und aussagekräftigen Dashboards ist eine Herausforderung. Mit diesen 30 Tipps werden Sie zum Dashboard-Experten.

mehr lesen
Vorschaubild für eine Übersicht aller veröffentlichten Blogposts. Es zeigt den Textzug "Alle Blogposts" gestaltet im Corporate Design der K&K Software AG.
Alle Blogbeiträge

Hier gelangen Sie zu einer Übersichtsseite mit allen veröffentlichen Blogbeiträgen.

Unternehmen

Aussenansicht Bürogebäude K&K Software AG

K&K Software AG

Über uns

Das sind wir, dafür stehen wir, das zeichnet uns aus.

Laptop und Hand

Daten

Datenschutz

Klicken Sie hier, um zur Datenschutzerklärung von K&K-Software zu gelangen.

Paragraph

Impressum von K&K

Impressum

Klicken Sie hier, um zum Impressum von K&K-Software zu gelangen.

Auf dem Foto sieht man 2 Personen, die Online und Offline mit Stift und Papier und Laptops arbeiten.

Jetzt downloaden

Downloads

Klicken Sie hier, um zu den Downloads zu gelangen.