Logo weiterlesen.de
Agiles Projektmanagement

Inhaltsverzeichnis

  1. Hinweis zum Urheberrecht
  2. Impressum
  3. Vorwort
  4. Die neue Form des Projektmanagements
    1. Was ist agiles Projektmanagement?
      1. Eine Universallösung?
      2. Die Bausteine des agilen Projektmanagements
    2. Die besten Einsatzmöglichkeiten
      1. Veränderung in klassischen Projekten
      2. Veränderung in agilen Projekten
    3. Die agilen Grundwerte
      1. Das Menschliche ist wichtiger als Prozesse und Technik
      2. Ein funktionierendes Produkt ist wichtiger als Papierkram
      3. Die Nähe zum Kunden ist wichtiger als das Vertragliche
      4. Die Reaktion auf Veränderung ist wichtiger als der Plan
    4. Wie agiles Projektmanagement funktioniert
      1. Der Projektstart
      2. Anforderungen aus Kundensicht
      3. Produktentwicklung: die erste Runde
      4. Feedback zum Teilprodukt einholen
      5. Die Planung anpassen
      6. Produktentwicklung: weitere Runden
    5. Klassische Projekte versus agile Projekte
      1. Die gemeinsame Basis
      2. Das Zieldreieck
      3. Die Rahmenbedingungen
        1. Das Projekt
        2. Projektumfeld
      4. Vertragliches
      5. Die Unterschiede im Überblick
  5. Die agilen Prinzipien
    1. Die 12 Gebote
    2. Mehr Flexibilität im Projekt
      1. Iteration: Produktentwicklung in Zyklen
      2. Inkrement
        1. Keine Inkremente: Prototypen
        2. Warum Iterationen am Anfang oft teurer sind als gegen Ende
      3. Das Zusammenspiel von Iterationen und Inkrementen
    3. Änderungswünschen positiv begegnen
      1. Veränderung begrüßen
      2. Nur das Notwendige erledigen
      3. Warum Reviews mit Kunden so wichtig sind
      4. Retrospektiven als Basis für Verbesserungen im Team
      5. Selbstorganisierte Teams
        1. Die Vorteile der Selbstorganisation
        2. Wie führt man selbstorganisierte Teams?
        3. Gemeinsame Verantwortung: alle für einen, einer für alle
      6. Kooperation von Fachexperten und Entwicklern
  6. Die agilen Techniken
    1. Ein erster Überblick
    2. Projekte steuern: Task Boards, Daily-Standups und WIP-Limits
      1. Mit Task Boards den Überblick behalten
      2. Daily-Standup-Meetings: effektive Treffen
        1. Fehler 1: Falscher Zeitpunkt für die Besprechung
        2. Fehler 2: Falsche Moderation des Ablaufs
        3. Fehler 3: Zu viele oder zu wenige Details
      3. Osmotische Kommunikation
      4. Parallele Arbeit begrenzen mit WIP-Limits
        1. Produktivität erhalten mit WIP-Limits
        2. Maximale Produktivität im Team
    3. Projektanforderungen im Griff: Use Cases, Epics und Persona
      1. Use Cases: Anforderungen aus Kundensicht
      2. User Storys
      3. Epic: Zusammenfassung mehrerer Use Cases
      4. Geschäftswert und MMF
      5. Persona: Kunden typisieren
    4. Alles unter Kontrolle: Planning Poker, Burn-Down-Charts & Co.
      1. Planning Poker: Aufwandsschätzung im Team
        1. Die Schätzkarten
        2. Ablauf einer Sitzung
      2. Story Points: abstraktes Maß für Komplexität
      3. Timeboxing: Termine halten um jeden Preis
      4. Burn-Down-Charts: Fortschrittskontrolle leicht gemacht
      5. Definition of Done: Kriterienkatalog für die Fertigstellung
      6. Earned Value: Kosten und erledigte Aufgaben auf einen Blick
      7. Cumulative Flow und Kanban
    5. Der Mix macht’s: Kombination agiler Techniken
      1. Welche Technik passt zu Ihrem Projekt?
      2. Wie man agile Prinzipien und Techniken mixt
      3. Neue Techniken einführen
    6. Software-Tools
      1. Task Board
      2. Burn-Down-Charts
      3. Chat
      4. Planning Poker
  7. Die agilen Methoden
    1. Was agile Methoden bewirken
    2. Scrum
      1. Begriffe aus der Scrum-Welt
      2. Die Artefakte in einem Scrum-Prozess
        1. Inkrement: das Teilprodukt
        2. Product Backlog: die Anforderungen an das Produkt aus Kundensicht
        3. Sprint Backlog: Basis für die konkreten Arbeiten
      3. Die Rollen in einem Scrum Team
        1. Der Scrum Master
        2. Der Product Owner
        3. Das Development Team
        4. Und wer ist Projektleiter?
      4. Die „Ereignisse“ in einem Scrum-Projekt
        1. Sprints
        2. Sprint Planning
        3. Daily Scrum
        4. Sprint Review
        5. Sprint Retrospective
      5. Techniken und Zusatzregeln für Scrum
        1. Timeboxing
        2. Definition of Done
        3. Unveränderlichkeit
    3. Scrum But
      1. Product Owner außerhalb des Teams
      2. Mehrere Product Owner
      3. Neue Anforderungen im Sprint
      4. Klassischer Projektleiter über Scrum Team
      5. Product Owner mit mangelndem Produktwissen
      6. Sprints folgen nicht direkt aufeinander
    4. Passt das agile Vorgehen zu Ihrem Projekt?
    5. Klassische und agile Methoden mixen
  8. Das Miteinander in agilen Teams
    1. Ein funktionierendes Team: Schlüsselfaktor im agilen Projekt
      1. Konflikte lösen
      2. Mit dem Wertequadrat arbeiten
      3. Agile Werte vermitteln
    2. Aktiv Verantwortung übernehmen
      1. Das Drama-Dreieck
      2. Mehr Selbstverantwortung in Ihrem Team
        1. Verantwortung abgeben
    3. Zusammenarbeit fördern
      1. Gemeinsame Ziele und Lösungen finden
        1. Verankerung in der Projektpraxis
      2. Kooperation und Statusverhalten
        1. Wie sich Statusverhalten ausdrückt
        2. Das Statusquadrat
        3. Der Statusradar
        4. Übungen für die Praxis
    4. Projektmanager und Scrum Master als Team-Coaches
      1. Die Grundhaltung des Coachs: Askese
      2. Ressourcenfokussierung
      3. Grundsatz: Lösungsorientierung
      4. Ja-wenn-Technik
      5. Musterunterbrechung
      6. Metaphern
      7. Systemische Sichtweise
      8. Gesprächs- und Fragetechniken
        1. Wichtige Gesprächstechniken
        2. Fragetechniken
        3. Aktives Zuhören
  9. Glossar
  10. Anhang: Manifest für Agile Softwareentwicklung
  11. Literatur und Links
  12. Der Autor
    1. Dr. Jörg Preußig
  13. Stichwortverzeichnis
  14. Arbeitshilfen online

[1]

Hinweis zum Urheberrecht

Abbildung

Haufe-Lexware GmbH & Co. KG, Freiburg

Vorwort

Wir agieren in einer schnelllebigen Zeit, in einer Zeit, in der die Konkurrenz nicht schläft und der Kunde König sein sollte, wenn man langfristig auf dem Markt bestehen will. Das klassische Projektmanagement stößt hier schnell an seine Grenzen. Dies vor allem, wenn von Kundenseite bei gleichbleibendem Budget und einem fixen Zeitplan ständig neue Anforderungen gestellt werden. Grund genug darüber nachzudenken, wie man Projekte trotz dieser Herausforderungen so stemmen kann, dass hinterher alle Beteiligten zufrieden sind.[2]

Das agile Projektmanagement kann hier Lösungsansätze bieten. Es stammt nicht etwa aus dem Elfenbeinturm der Wissenschaft, sondern mitten aus der Praxis der Softwareentwicklung – einem Bereich, der wie kein anderer flexibel mit ständig wechselnden Rahmenbedingungen jonglieren muss. Während dort agile Techniken und Methoden mittlerweile unbestritten und spätestens durch Scrum in der Breite bekannt geworden sind, werden sie sonst kaum oder eher zufällig angewendet. Dabei lohnt sich ein bewusster Blick in die agile Projektwelt durchaus. Sie bietet viele hilfreiche Instrumente, die vielleicht auch zu einem Erfolgsfaktor für Ihr Projekt werden können. Dieser TaschenGuide hilft Ihnen herauszufinden, wie Sie das agile Projektmanagement für sich und Ihre Projekte gewinnbringend nutzen können.

Viel Erfolg dabei wünscht Ihnen

Dr. Jörg Preußig

Mein besonderer Dank gilt meiner Frau Yvonne Brockerhoff. Mit ihrem wertvollen Feedback und dem Design der Grafiken hat sie wesentlich an diesem Buch mitgewirkt.

Die neue Form des Projektmanagements

Ihr Kunde ändert ständig die Anforderungen? Ihre Projektplanung wird immer unverbindlicher? Die Motivation im Team lässt zu wünschen übrig? Agiles Projektmanagement könnte die Lösung für Ihre Probleme sein.[3]

In diesem Kapitel erfahren Sie,

  • warum agiles Projektmanagement entwickelt wurde,

  • für welche Projekte es sich besonders eignet,

  • welche Grundwerte sein Fundament ausmachen,

  • wie es funktioniert.

Was ist agiles Projektmanagement?

Kent Beck und andere erfahrene Softwareentwickler veröffentlichten 2001 das sog. Agile Manifest. Dort formulierten sie – basierend auf ihrer umfangreichen Erfahrung in der Abwicklung von Softwareprojekten – eine Reihe von Ideen, Prinzipien und Werten, die zu einem besseren Vorgehen bei der Softwareentwicklung führen sollten. Sie bekannten sich darin z. B. zu einer neuen Priorisierung von Werten und schufen so das Fundament für das agile Projektmanagement:

  • So sollte bei der Softwareentwicklung der Fokus künftig mehr auf den Individuen und deren Interaktionen als auf den Prozessen und Werkzeugen liegen.

  • Funktionierende Software sollte wichtiger sein als umfassende Dokumentation.

  • Zusammenarbeit mit dem Kunden sollte eine größere Rolle spielen als Vertragsverhandlung.

  • Das Reagieren auf Veränderung sollte wichtiger sein als das Befolgen eines Plans.

Wichtig

Um die agilen Techniken in der Praxis sinnvoll einsetzen zu können, ist es wichtig, auch die agilen Werte und Prinzipien verstanden zu haben.

Nach und nach haben sich verschiedene Techniken herauskristallisiert, um die recht abstrakten Werte und Prinzipien des Manifests in die Praxis umzusetzen. Dazu zählen beispielsweise „Task Boards“, „Daily-Standup-Meetings“ und „User Stories“, um nur einige zu nennen.[4]

Daraus wiederum haben sich die sog. agilen Methoden entwickelt. Schon seit vielen Jahren halten diese Methoden fortschreitend Einzug in die Softwareentwicklung, insbesondere unter den Begriffen „Unified Process“, „Extreme Programming“ und „Scrum“. Seit etwa 2010 haben die verschiedenen Organisationen, die sich mit der Standardisierung und Zertifizierung im Projektmanagement beschäftigen, diese neue Strömung erkannt und unter dem Begriff „Agiles Projektmanagement“ aufgegriffen. So gibt es z. B. beim renommierten Project Management Institute (PMI) seit 2012 eine Zertifizierung zum „Agilen Projektmanager“ (PMI-ACP).

Eine Universallösung?

Mittlerweile werden die agilen Konzepte auch auf Projekte außerhalb der Softwareentwicklung übertragen – was in den meisten Fällen machbar, wenn auch nicht immer ganz leicht ist, wie wir später noch sehen werden.

Agiles Projektmanagement ist eine Antwort auf die zunehmende Geschwindigkeit, mit der Projekte abgewickelt werden müssen, und auf die Erkenntnis, dass in vielen Projekten Abweichungen vom Plan eher die Regel als die Ausnahme sind. Letzteres gilt insbesondere dort, wo die Anforderungen an das Produkt (das Projektergebnis) zu Beginn des Projektes nicht vollends klar sind.

Beispiel:

Dies kann der Fall sein, weil der Kunde zu Anfang noch nicht exakt weiß, was er braucht, oder weil die Beteiligten die Komplexität des Produktes noch nicht ganz durchdrungen haben.[5]

Bei herkömmlichem Projektmanagement führt eine Veränderung der Anforderung fast zwangsläufig zu höheren Kosten oder längerer Projektlaufzeit. Beim agilen Projektmanagement werden solche Änderungen von vornherein angenommen. Dies hilft dabei, die Kosten einzudämmen und den Zeitplan einzuhalten.

Die Bausteine des agilen Projektmanagements

Zu verstehen, was hinter dem agilen Projektmanagement steht, fällt leichter, wenn man zwischen agilen Werten, Prinzipien, Techniken und agilen Methoden unterscheidet. Die folgende Grafik zeigt, wie diese aufeinander aufbauen.

Abbildung

Systematik des agilen Projektmanagements

Was steckt hinter den Bausteinen des agilen Projektmanagements?
Agile WerteSie spiegeln die wesentlichen Grundsätze im agilen Projektmanagement wider: ein Mehr an Flexibilität und ein Weniger an unnötigen Strukturen. Sie können auf dieser Ebene bereits prüfen, ob das agile Projektmanagement überhaupt zu Ihnen, Ihrem Unternehmen und Ihrem Team passt.
Agile PrinzipienSie beschreiben grundsätzliche Herangehensweisen an das Projektmanagement. Zu diesen Prinzipien zählen z. B. sog. Iterationen und die Selbstorganisation von Teams. Es ist oft gar nicht so leicht, wie es auf den ersten Blick scheint, die Prinzipien auf die eigene Projektwelt zu übertragen.
Agile TechnikenDas sind relativ leicht verständliche, konkrete Maßnahmen, die Sie in Ihr Projektmanagement einbauen können. Die Techniken geben Ihrem Projektmanagement die nötige Struktur. Vor ihrer Anwendung gilt es zu überlegen, welche Technik in welcher Form zu Ihrem konkreten Projekt passt.
Agile MethodenSie sind Vorstrukturierungen auf der Ebene von Prozessmodellen. Hier werden Prinzipien und Techniken zu einem schlüssigen Prozess kombiniert. Im Allgemeinen müssen diese Methoden für jedes Projekt und Projektumfeld mehr oder weniger angepasst werden.[6]

Die besten Einsatzmöglichkeiten

So mancher wird sich die Frage stellen, wozu man überhaupt eine andere, eine neue Form des Projektmanagements benötigt. Schließlich hat sich doch die klassische Variante in vielen Bereichen lange Jahre bewährt.

Veränderung in klassischen Projekten

Im klassischen Projektmanagement geht man davon aus, dass die Stakeholder (einfach ausgedrückt: die Personen, die ein Interesse an dem Projekt haben) zu Beginn des Projektes einen relativ hohen Einfluss nehmen können, der jedoch mit weiterem Fortschreiten des Projektes immer mehr abnimmt. So kann der Kunde am Anfang bestimmen, was er genau als Projektergebnis haben möchte. Je weiter das Projekt fortschreitet, desto mehr schwindet sein Einfluss auf das Ergebnis. Denn zum einen sind die Projektergebnisse vertraglich festgelegt. Zum anderen ist er immer weniger in das Projekt eingebunden. Geht man beim Projektmanagement also ganz klassisch vor, so beschreibt der Kunde zu Beginn einmalig, was er haben möchte. Am Ende bekommt er dann das, was der Auftragnehmer als Kundenwunsch verstanden hat.

Außerdem geht das klassische Projektmanagement davon aus, dass Änderungen am Projektauftrag umso teurer werden, je später sie eingebracht werden. Wenn der Kunde in der Anfangsphase sagt, dass er etwas anders haben möchte, ist es noch relativ billig, diese Änderung zu berücksichtigen. Wenn er gegen Ende des Projektes mit einem Änderungswunsch kommt, entstehen relativ hohe Kosten, um ihn zu berücksichtigen.[7]

In dem Projektmanagement-Handbuch des Project Management Institutes (A Guide to the Project Management Body of Knowledge, 4. Ausgabe 2008, Pennsylvania, USA) wird dies als grundlegender Zusammenhang im Projektmanagement verstanden und akzeptiert. Die folgende Grafik veranschaulicht das.

Abbildung

Auswirkungen von späten Änderungen im klassischen Projektmanagement

Den Zusammenhang zwischen den Kosten und dem Zeitpunkt des Änderungswunsches verdeutlicht auch das folgende Beispiel.

Beispiel:

Zu Beginn eines Brückenbau-Projektes wird man versuchen, die Vorstellungen der verschiedenen Stakeholder (Ämter, Bürger, Experten, Verbände usw.) zu berücksichtigen. Später ist das schon schwieriger: Sind dann die ersten Brückenpfeiler gesetzt, wird eine Veränderung z. B. der Nutzlast oder des Verlaufs der Brücke sehr teuer. Die Möglichkeit der Stakeholder, zu diesem Zeitpunkt noch Einfluss zu nehmen, wird damit deutlich begrenzt.

Veränderung in agilen Projekten

Was beim Brückenbau gilt, muss aber nicht unbedingt in allen anderen Bereichen des Projektmanagements so sein. Und tatsächlich hat sich im Laufe der letzten zehn Jahre immer stärker gezeigt, dass der Zusammenhang aus der Abbildung oben in vielen Projekten verstärkt Schwierigkeiten bereitet.[8]

  • Ein wichtiger Grund dafür ist die zunehmende Geschwindigkeit, mit der sich das Umfeld eines Projektes verändert. Wenn eine Firma heute ein Projekt startet und dabei von einer bestimmten Marktsituation ausgeht, dann hat sich diese am Ende des Projektes meist bereits geändert. Somit ist das Produkt, so wie es ursprünglich beschrieben wurde, nur noch bedingt nutzbar. Vielleicht gibt es neue Schnittstellen, die nicht berücksichtigt wurden, oder einen Mitbewerber mit einem neuen Produkt, das man hätte beachten müssen.

  • Auch ist es kaum realistisch, dass der Kunde zu Beginn eines Projektes genau beschreiben kann, wie das Produkt aussehen soll – vor allem nicht, wenn es sich um komplexe oder neuartige Produkte handelt. Zudem ist die Beschreibung von Anforderungen, die meist nur schriftlich stattfindet, stets anfällig für Missverständnisse.

Für einen erfolgreichen Projektverlauf wäre es daher viel sinnvoller, wenn der Kunde und andere Stakeholder immer wieder Einfluss nehmen könnten und die Kosten für dadurch entstehende Änderungswünsche trotzdem nahezu konstant blieben. Genau dies ist das Ziel des agilen Projektmanagements. „Agil“ im Sinne von „beweglich“ und „reaktionsschnell“ bezieht sich also auf den Umgang mit Änderungen der Projektanforderungen.

Wichtig

Wie gehen Sie mit den Unsicherheiten um, die Ihr Projekt unweigerlich begleiten? Das agile Projektmanagement greift diese Unsicherheiten systematisch auf und versucht, sie zum Vorteil des Kunden und des Projektes insgesamt zu nutzen.[9]

Die folgende Grafik veranschaulicht diesen wichtigen Unterschied zwischen klassischem und agilem Projektmanagement.

Abbildung

Veränderung im Projekt: klassisch versus agil

Beim agilen Projektmanagement können die Stakeholder also während des Projektverlaufs immer wieder ihre Anforderungen justieren. Durch den Einsatz agiler Prinzipien und Techniken sollen die Kosten für Änderungen niedrig bleiben. Eine nahezu konstant flache Kostenkurve wie in der Grafik oben ist natürlich ein Ideal, das in der Praxis agiler Projekte nicht immer zu erreichen ist. Entscheidend ist, dass das Verhältnis zwischen den beiden Kurven stimmig ist. Sie dürfen Änderungen nur in dem Maße zulassen, in dem Sie auch die Kosten für Änderungen im Griff haben. Denn die Gesamtkosten des Projektes sollen ja im vorgegebenen Rahmen bleiben.

Bei der Softwareentwicklung ist es einfacher, eine flache Kostenkurve in den Projekten trotz Änderungen zu erreichen. Dort können durch automatisierte Tests und moderne Entwicklungswerkzeuge Änderungen mit relativ geringem Aufwand realisiert werden. In anderen Projektfeldern ist dies auch möglich, man muss allerdings intensiver nach Möglichkeiten Ausschau halten.

Wichtig

In der Praxis stößt man immer wieder auf Chaos-Projekte, die sich hinter dem Begriff „agil“ verschanzen. Nur Projekte, in denen systematisch agile Techniken eingesetzt werden, um die in der Grafik dargestellten Ziele zu realisieren, sind echte agile Projekte.[10]

Die agilen Grundwerte

Im Agilen Manifest, quasi der Gebotstafel für das agile Projektmanagement, werden dessen Grundwerte wie folgt beschrieben:

  • Menschen und deren Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge (Originaltext: „Individuals and interactions over processes and tools“).

  • Ein funktionierendes Produkt ist wichtiger als umfassende Dokumentation („Working software over comprehensive documentation“).

  • Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen („Customer collaboration over contract negotiation“).

  • Die Reaktion auf Veränderung ist wichtiger als das Befolgen eines Plans („Responding to change over following a plan“).

Die agilen Werte geben noch keinen konkreten Hinweis darauf, was genau man bei „klassischen“ Projekten ändern kann, um agiler zu werden. Insofern lassen sie sich zwar leicht auf Projekte außerhalb der Softwareentwicklung übertragen. Unklar bleibt jedoch, welchen Nutzen das für ein Projekt bringt.

Im wesentlichen können Sie an dieser Stelle jedoch für sich feststellen, ob Sie diese Werte grundsätzlich teilen, und damit auch eine gewisse Affinität zum Agilen Projektmanagement haben, oder ob Sie den Werten eher kritisch gegenüberstehen. In meiner Seminarpraxis zeigt sich häufig, dass Teilnehmer, die diese Werte gutheißen, auch Projekte leiten, die von ihrer Struktur her stärker vom Agilen Projektmanagement profitieren können, und umgekehrt. Zwar sind viele, jedoch nicht alle Projekte in gleichem Maße für den Einsatz agiler Techniken geeignet.[11]

Das Menschliche ist wichtiger als Prozesse und Technik

Ein wesentlicher agiler Grundwert ist es, dass Menschen und deren Zusammenarbeit wichtiger sind als Prozesse und Werkzeuge. An sich ist das eine Selbstverständlichkeit, in der Realität sieht es oft anders aus. Der Einsatz von Kommunikationstechnologien hat das Projektmanagement sehr vereinfacht. Es hat sich aber auch gezeigt, dass diese Technologien in sinnvollem Maße eingesetzt werden müssen, damit die Kommunikation zwischen den Beteiligten nicht leidet. Dazu ein Beispiel, das vielen bekannt vorkommen wird: Bei Softwareprojekten gibt es manchmal E-Mail-Verkehr in Pingpong-Manier, bei dem letztlich nur noch Verantwortung hin und her geschoben wird. Dabei wäre ein persönlicher Austausch in einem Telefonat zur Klärung viel effektiver.

Noch komplexer wird das Problem beim Einsatz sog. Issue-Tracker. Das sind Systeme, die der automatisierten Verfolgung von Kundenanfragen und Softwareanforderungen dienen. Sie implementieren meist ziemlich komplizierte Prozesse, die es für den einzelnen Mitarbeiter einzuhalten gilt. Wenn dann zeitkritische Situationen entstehen, z. B. weil eine Lösung unbedingt kurzfristig benötigt wird, muss irgendjemand die Entscheidung treffen, den Prozess zu umgehen. Dazu gibt es aber nur sehr selten klare Vorgaben seitens der Projektleitung, und es fällt dem Einzelnen dann leicht, sich hinter dem Prozess „zu verstecken“. Als Folge bleiben z. B. wichtige Kundenanfragen unbeantwortet.[12]

Beispiel:

In einem großen Unternehmen werden Kundenanfragen mit einem Issue-Tracker-Tool erfasst. Herr Meier nimmt die Anfrage am Telefon entgegen und trägt sie im Tool ein. Da er sie nicht selber bearbeiten kann, weist er sie Frau Schulze zu. Die hat gerade wenig Zeit, schreibt einen Kommentar an die Anfrage und weist sie Herrn Zobel zu. So geht es noch ein paar Mal weiter. Nach einer Woche ruft der Kunde wieder an. Herr Meier schaut im Tool nach und stellt fest, dass noch niemand wirklich an der Anfrage des Kunden gearbeitet hat.

Im agilen Projektmanagement sind dagegen Personen und deren Kooperation miteinander wichtiger als Prozesse und Werkzeuge. Um die Probleme zu vermeiden, die mit dem übermäßigen Gebrauch von Prozessen und Werkzeugen einhergehen, sollen einfache Strukturen genutzt werden. Dazu gehören kurze Kommunikationswege und gemeinsame Verantwortlichkeiten, damit Entscheidungen von verschiedenen Einzelpersonen schneller getroffen werden können. Natürlich ist es dann auch wieder wichtig, sie schnell an alle Entscheidungsträger und Betroffenen zu kommunizieren.

Beispiel:

Ein Mitarbeiter aus der Qualitätssicherung findet einen Fehler im Produkt. Da ihm der Fehler kritisch erscheint, trägt er ihn nicht wie vorgesehen einfach nur in ein System ein. Er ruft kurz in der Entwicklungsabteilung an und bespricht das Problem mit einem Entwickler. Der Entwickler kommt vorbei, lässt sich das Problem erklären und macht sich dann sofort daran, den Fehler zu beheben.[13]

Ein funktionierendes Produkt ist wichtiger als Papierkram

Im klassischen Projektmanagement gibt es eine Vielzahl von Papieren und Dateien, die der Dokumentation der Projektstrukturen, des -fortschrittes und des -ergebnisses (Liefergegenstand) dienen. In der Praxis zeigt sich, dass sowohl die Projektmitarbeiter als auch die Kunden nur selten Informationen aus der Dokumentation ziehen, sondern lieber direkt jemanden fragen, den sie für kompetent halten.

Denken Sie z. B. an das Textverarbeitungsprogramm Word. Wie viel Prozent der dort vorhandenen Funktionen sind Ihnen bekannt? Vermutlich weit weniger als ein Fünftel! Und wie viel Prozent der von Ihnen benutzten Funktionen haben Sie in einer Dokumentation nachgelesen? Wie viele dagegen haben Sie sich durch das Fragen anderer Benutzer oder durch Ausprobieren angeeignet? Letzteres war bzw. ist vermutlich Ihre Hauptlernmethode. Genauso verhält es sich auch bei Projektmitarbeitern, die nur selten die Projektdokumentation in dem Umfang lesen, wie deren Autoren es sich erhoffen.

Im agilen Projektmanagement wird nur so viel Dokumentation erzeugt, wie tatsächlich notwendig ist. Als viel wichtiger wird es angesehen, dass die Software funktioniert, bzw., allgemein gesprochen, dass das Produkt für den Kunden sinnvoll einsetzbar ist. Statt Energie in umfangreiche Dokumentation zu stecken, sollen die Teammitglieder sich also auf eine gute Abstimmung untereinander und mit dem Kunden konzentrieren.[14]

Natürlich verzichtet das agile Projektmanagement nicht auf Dokumentation, die wirklich wichtig ist. Dokumentation, die mit dem Produkt ausgeliefert werden muss, wird dort als Teil des Produktes verstanden. Sie kann genauso wie der Rest des Produktes agil entwickelt werden.

Beispiel:

In einem Projekt für die Pharmaindustrie wird ein Maschinenbauteil entwickelt, dass anschließend zur Produktion von Medikamenten eingesetzt werden soll. Zur Qualitätssicherung gibt es strenge Auflagen an die Dokumentation des Bauteils selber und den Entwicklungsprozess. Ohne diese Dokumente darf das Bauteil nicht verwendet werden. Daher sind die Dokumente hier im Verständnis des agilen Projektmanagements Teile des Produkts.

Die Nähe zum Kunden ist wichtiger als das Vertragliche

Das klassische Projektmanagement arbeitet in der Regel mit ausführlichen Vertragsdokumenten, die möglichst genau und verbindlich das beschreiben, was dem Kunden geliefert werden soll. Je komplexer das Projekt ist, desto umfangreicher und verzwickter können diese Beschreibungen werden, da beide Seiten (Auftragnehmer und Auftraggeber) versuchen, sich im Hinblick auf eventuelle Missverständnisse möglichst gut abzusichern. Am Ende eines Projektes stehen dann häufig Diskussionen, wie genau bestimmte Stellen im Vertrag gemeint waren und ob diese und jene Anforderung nun im Projektumfang enthalten ist oder nicht. Nicht selten kommt es dann zu massiven Unstimmigkeiten oder gar Rechtsstreitigkeiten.

Beim agilen Projektmanagement steht die Zufriedenheit des Kunden mit dem gelieferten Produkt im Vordergrund. Dazu soll eine gute Zusammenarbeit zwischen beiden Seiten beitragen. Sie wird insbesondere durch das Prinzip des iterativen Vorgehens umgesetzt (mehr dazu im Kapitel „Die agilen Prinzipien“). Dabei baut das agile Projektmanagement auf systematisches Zwischenfeedback vom Kunden, das im Projektverlauf berücksichtigt wird. Dies macht die Absicherung durch Vertragsdokumente weitaus weniger erforderlich als beim klassischen Projektmanagement.[15]

Beispiel:

Ein Logistikunternehmen lässt in einem großen, klassisch gemanagten Projekt seine Prozesssteuerungssoftware ablösen. Am Ende stellt sich heraus, dass nicht alle Anforderungen wie gewünscht umgesetzt wurden, obwohl dazu umfassende Vertragsverhandlungen stattgefunden haben. Nun werden in enger Zusammenarbeit mit dem Lieferanten der Software die notwendigen Anpassungen vorgenommen. Bei der „Schuldfrage“ und dem damit verbundenen Finanziellen einigt man sich auf einen pragmatischen Mittelweg.

Dieses Beispiel zeigt, dass auch in klassischen Projekten – Verträge hin oder her – am Ende meist eine enge Kooperation gesucht wird. Warum also nicht gleich darauf setzen?

Die Reaktion auf Veränderung ist wichtiger als der Plan

Beim klassischen Projektmanagement geht man davon aus, dass das Produkt sowie der Projektverlauf planbar sind. Wie bereits dargestellt, ändern sich die Anforderungen an das Produkt jedoch oft während des Projekts. Die häufigsten Gründe dafür sind Veränderungen im Projektumfeld und die Komplexität der Anforderungen. Letztere führt häufig dazu, dass der Kunde selbst erst im Verlauf des Projektes mehr Verständnis dafür entwickelt, was er eigentlich will. Insgesamt stößt der klassische Ansatz in der Praxis also auf ein Problem. Im Agilen Manifest heißt es dazu: „Je mehr du einem Plan folgst, desto mehr bekommst du das, was du geplant hast, statt dem, was du brauchst“.[16]

Das agile Projektmanagement sieht demgegenüber Veränderung als festen Bestandteil eines Projektes.

Wollen Sie wissen, wie es weiter geht?

Hier können Sie "Agiles Projektmanagement" sofort kaufen und weiterlesen:

Amazon

Apple iBookstore

buchhandel.de

ebook.de

Thalia

Weltbild

Viel Spaß!



Kaufen







Empfehlen