Ein Erfahrungsbericht

Agiles Projektmanagement

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.

Klassische EntwicklungAgile Entwicklung
Empfohlenes SzenarioProjektumfang steht im Detail fest.
Umsetzung einer genauen Spezifikation.
Projektumfang ist eher grob umrissen und wird sich wahrscheinlich verändern.
Eingehen auf Veränderungen während der Entwicklung
Generelle CharakteristikAm Anfang wird ein Lastenheft und Pflichtenheft festgelegt und exakt so entwickelt und am Ende des Projektes erfolgt die Abnahme gegen das ursprüngliche Lastenheft.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.

Was wird beauftragt?

Umsetzung eines Pflichtenheftes (das kostenpflichtig aus dem Lastenheft erstellt wird)Eine gewisse Anzahl von Sprints, in der jeweils aus dem Lastenheft formulierte User-Stories mit Akzeptanzkriterien umgesetzt werden.
ErgebnisDas Ergebnis ist das ursprüngliche Lastenheft.Das Ergebnis kann erheblich vom ursprünglichen Lastenheft abweichen.
Änderungen

Ä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.

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).

Kundennutzen, Reaktion auf VeränderungenEs wird das ursprüngliche Lastenheft (bei Projektende oft mehrere Jahre alt) entwickelt.Es wird in jedem (2-Wochen-) Sprint das mit dem höchsten Kundennutzen entwickelt.
Definition der AnforderungenIm 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.Alle Anforderungen werden in Form von User-Stories gepflegt.
Pflichtenhefterstellung

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.

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

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.

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.

Scrum Master der K&K Software AG Theresa Baumann

Über den Autor

Theresa Baumann kümmert sich als dedizierter Scrum-Master um die Projekt-Koordination unseres agilen Teams. Hier sorgt sie für die Einhaltung der Scrum-Prozesse.

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

Anlagenüberwachung jumbo group smart dry GmbH

Anlagenüberwachung jumbo group smart dry GmbH

Die Einführung von (Echtzeit-)Überwachung und Datenvisualisierung ermöglicht Unternehmen im Umweltsektor tiefgehende Einblicke in ihre Anlagentechnik, verringert Störanfälligkeiten und erhöht die Rentabilität.

mehr lesen
SMARTe Ziele

SMARTe Ziele

SMART, das ist nicht nur Englisch für „klug“ und „gewandt“, sondern auch ein Akronym für eine ebenso kluge und gewandte Herangehensweise im Kommunikationsprozess zur Zielsetzung.

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.

Datenschutzerklärung und Impressum

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

Datenschutzerklärung von K&K

Datenschutzerklärung

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

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

Impressum von K&K

Impressum

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