Skip to main content
Fachgebiete
Automobil + Motoren Bauwesen + Immobilien Business IT + Informatik Elektrotechnik + Elektronik Energie + Nachhaltigkeit Finance + Banking Management + Führung Marketing + Vertrieb Maschinenbau + Werkstoffe Versicherung + Risiko
DE
EN
Bücher
Zeitschriften
Themenseiten
Organisationspsychologie Projektmanagement Marketing Smart Manufacturing
Weitere Formate
Podcasts Webinare Technik Webinare Wirtschaft Kongresse Veranstaltungskalender Awards
Jetzt Einzelzugang starten
Zugang für Unternehmen
Referenzkunden
SLX-Digitalkonferenz: Zukunftswerkstatt 2024

Mehr Umsatz mit Top-Kontakten

Am 7. Mai erfahren Sie, wie Vertriebsteams Leadgenerierung, Leadnurturing und Leadstrategien effizient steuern können.
Erweiterte Suche
Anmelden
nach oben

2021 | Buch

Einführung Kapitel lesen Erstes Kapitel lesen

Agiles Projektmanagement im Berufsalltag

Für mittlere und kleine Projekte

verfasst von: Ursula Kusay-Merkle

Verlag: Springer Berlin Heidelberg

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten
insite
SUCHEN

Über dieses Buch

Dieses Buch zeigt auf, wie sich agile Methoden des Projektmanagements für die Planung und Durchführung von kleinen und mittleren Projekten im Berufsalltag ganz pragmatisch anwenden lassen. Es betont die leichtgewichtigen und auf die Interaktion in einem Team abzielenden Tools des agilen Projektmanagements. Dabei leitet das Buch zur direkten Umsetzung in einem kleinen eigenen Projekt an. Die zweite, erweiterte und verbesserte Auflage verdeutlicht diesen Ansatz mit zusätzlichen Grafiken. Sie wurde insbesondere auch um eine Diskussion der Rollen Projektleiter und Product Owner in ihren unterschiedlichen Ausprägungen ergänzt. Der neue Scrum Guide 2020 ist bereits berücksichtigt. Das Buch richtet sich sowohl an Projektleiter und Projektkoordinatoren als auch an Fach- und Führungskräfte, die in ihrem Berufsalltag zusätzlich zu ihren Linienaufgaben auch Projekte übernehmen. Auch Product Owner finden viele Techniken, die sie in ihrer Tätigkeit anwenden können.

Inhaltsverzeichnis

Frontmatter
Kapitel 1. Einführung
Zusammenfassung
Es gibt viel Projektmanagementliteratur und viel Geschriebenes zu agilen Methoden. Aber die meisten Projekte sind kleinere Projekte, die von „nebenberuflichen“ Projektleitern geführt werden. Trotz der vielen vorhandenen Literatur fehlt deshalb Fortbildungsliteratur für diese Zielgruppe. Dieses Buch will ganz bewusst praktische Hinweise zur Planung und Durchführung von kleineren Projekten geben – Projekten, die vom Projektleiter selbst oder mit einem kleinen Team umgesetzt werden. In diesem Kapitel erhalten Sie einen Überblick über Inhalte und Aufbau des Buches. Insbesondere schlägt es orientierende „Reiserouten“ für ein selektives Lesen vor.
Ursula Kusay-Merkle

Projektmanagement

Frontmatter
Kapitel 2. Projektmanagement – Was versteht man darunter?
Zusammenfassung
Dieses Kapitel definiert zunächst einige grundlegende Begriffe.
Was ist ein Projekt, was ist Projektmanagement, was ist die Rolle des Projektleiters?
Es ist zunächst wesentlich zu definieren, was überhaupt als Projekt angesehen werden kann.
Dieses erste Kapitel klärt den Begriff des Projektmanagements. Gleichzeitig betrachtet es dabei auch die Rolle des Projektleiters.
Gerade im agilen Projektmanagement ist die Rolle des Projektleiters unterschiedlich. Einige Methoden wie Scrum kennen die Rolle so gar nicht. Insofern wird hier erst einmal die Rolle „traditionell“, aber nicht abschließend betrachtet. Die Diskussion wird später wieder aufgegriffen werden.
Was sind die Wissensgebiete oder Themengruppen des Projektmanagements?
Dabei handelt es sich um Themenbereiche des Projektmanagements, die ein spezifisches Wissen erfordern und durch Prozesse mit ihren Voraussetzungen und Ergebnissen sowie den dabei verwendeten Werkzeugen charakterisiert sind.
Diese Wissensgebiete (PMI) oder Themengruppen (ISO 21500) werden zuerst ganz neutral als Themen betrachtet, die im Kontext des Projektmanagements auftauchen. Es gibt sie immer, nur werden sie unterschiedlich im Projekt ausgeprägt.
Im dritten Kapitel werden dann stärker die Unterschiede herausgearbeitet, je nachdem, ob eher „klassisch plangetrieben“ oder „agil value-getrieben“ vorgegangen wird.
Lassen Sie uns aber hier erst einmal die Basis legen.
Darstellung:
Die Darstellung orientiert sich dabei vor allem an ISO 21500.
Ursula Kusay-Merkle
Kapitel 3. Welche Ansätze gibt es?
Zusammenfassung
Ein neues Projekt steht an.
Nun stellt sich u. a. die Frage, wie neuartig das Ergebnis des Projektes sein wird. Handelt es sich um etwas Neues, Komplexes oder etwas, zu dem es noch wenig Erfahrungswerte gibt? Oder wurden bereits ähnliche Projekte gemacht und der Weg zum Ergebnis ist ziemlich klar?
Diese Fragestellung ist wichtig für die Wahl des Ansatzes bei der Planung des Projektes. Grob gesagt: Für eher bekanntes Terrain eignet sich gut das „klassische“ Projektmanagement, für innovative Themen und unbekannteres Terrain, wenn Feedback und kleinere Lieferungen zwischendurch gefragt sind, eher die agile Vorgehensweise.
Wie geht das „klassische“ Projektmanagement vor?
Die klassische Vorgehensweise ist plangetrieben; Alle Überlegungen und Planungen werden im Projektplan schriftlich festgehalten. Im PMBOK® Guide [7] wird sie wegen der detaillierten Planung und der damit getroffenen Prognosen als prognostizierter Ansatz bezeichnet. Aufgrund der umfangreichen Planungsüberlegungen wird er hier in der Folge als plangetriebener Ansatz bezeichnet.
Für die Bewertung des Abwicklungserfolges eines Projektes wird das „magische Dreieck“ des Projektmanagements aus Inhalt und Umfang des Projektes, Zeit und Kosten genutzt. Ein Projekt wird dann als erfolgreich angesehen, wenn es mit dem richtigen Scope (Inhalt und Umfang des Projektes), der entsprechenden Qualität in der vereinbarten Zeit und zu den genehmigten Kosten abgewickelt wird. Dabei ist die Dimension des Scope führend. Er wird zuerst definiert, dann werden die benötigte Zeit und der Finanzbedarf ermittelt. Iterativ, in Schleifen vorgehend, werden gegebenenfalls Scope, Zeit und Kosten ausbalanciert.
Wie sieht im Vergleich dazu die agile Vorgehensweise aus?
Die agile Vorgehensweise stellt den „value“, also den Wert, in den Vordergrund. Dies ist gleich zweifach der Fall:
Der Wert bestimmt letztlich den Inhalt und Umfang des Projektes. In der Regel werden Budget und Zeit festgelegt, die für das Projekt zur Verfügung stehen. Unter dieser Rahmenbedingung soll dann inhaltlich das gemacht werden, was den meisten Nutzen erzeugt. Der Wert („value“) wird innerhalb des Geld- und der Zeitbudgets möglichst maximiert (Abb. 3.1).
Die zweite Bedeutung von „value“ liegt in den agilen Werten. Diesen wird ein eigenes Kapitel gewidmet.
Von den vielfältigen agilen Methoden, die es gibt, sind Scrum und Kanban wichtige Vertreter und am weitesten verbreitet. Beide begrenzen die Menge der Arbeit im System, aber auf unterschiedliche Weise. Damit soll laufende, begonnene Arbeit schneller fertiggestellt werden. Nur abgeschlossene Arbeit bietet einen Nutzen.
Ursula Kusay-Merkle
Kapitel 4. Das agile Wertesystem und Mindset
Zusammenfassung
Im vorhergehenden Kapitel wurden mit Scrum und Kanban zwei gängige agile Methoden kurz vorgestellt. Der Begriff „Methode“ umfasst aber zwei Aspekte:
  • die Beschreibung eines planmäßigen Vorgehens um Ziele zu erreichen
  • eine Art des Handelns.
Bisher ging es primär um das planmäßige Vorgehen, um die Regeln und Prinzipien der Methoden.
Nun wird es um die Denkart, um das Mindset gehen, das hinter der Art zu Handeln steht.
Bekannt ist vielfach das „Manifest für Agile Softwareentwicklung“. Es betont Individuen und Interaktionen, Zusammenarbeit mit Kunden sowie das Reagieren auf und das Anstoßen von Veränderungen. Heute sind die agilen Methoden aber nicht mehr nur in der Softwareentwicklung zu Hause, sondern werden in vielen Bereichen angewandt.
Egal ob ein Projekt mit der Methode Scrum oder Kanban arbeitet, entscheidend ist die Denkart. Allen agilen Ansätzen sind Grundüberlegungen gemein, auch wenn einzelne Werte unterschiedlich betont werden.
Die Werte und Prinzipien werden in diesem Kapitel kurz vorgestellt.
Eine wichtige Aufgabe des Projektleiters ist es, für ein entsprechendes Umfeld zu sorgen. Daher sind gerade auch für Projektleiter diese Werte wichtig. Die Ausprägung der Werte kann auf einem Radardiagramm dargestellt werden. Die eigene Ausprägung kann darauf eingeschätzt und später erneut bestimmt werden. Zwischen den beiden Einschätzungen liegt die persönliche Veränderungsarbeit an einer oder mehreren ausgewählten Dimensionen des Radardiagramms.
Ursula Kusay-Merkle

Projektplanung

Frontmatter
Kapitel 5. Der rote Faden: Von der Projektvision zu Roadmap und Meilensteinen
Zusammenfassung
Sie bekommen als Projektleiter den Auftrag, eine Veränderung oder Verbesserung mittels eines Projektes herbeizuführen, einen neuen Prozess zu gestalten oder ein Produkt zu entwickeln.
Wie können Sie Ihr Projekt planen?
Lassen Sie uns zuerst im Überblick die einzelnen Schritte durchgehen: Ausgangspunkt ist die Grundidee, die Vision. Nach weiteren Stationen wie der Projektgenehmigung können die Anforderungen im sogenannten Produkt Backlog gesammelt werden. Anschließend wird festgelegt, in welchen „Wellen“ oder Releases die Anforderungen umgesetzt und die Lösung eingesetzt werden kann.
Zusätzlich erhalten Sie einige erste Hinweise für Workshops. Agile Methoden legen sehr viel Wert auf die Interaktion und das gemeinsame Arbeiten. Sie werden daher gerade hier in der Planung einige Tools kennenlernen, bei denen Ergebnisse gemeinsam in Workshops erarbeitet werden.
Dieses Kapitel will Ihnen – wie der Name sagt- einen „roten Faden“ und eine „Überblickskarte“ für die Projektplanung bieten. Einzelne Stationen der Karte werden in eigenen Kapiteln im Detail behandelt werden. Sie lernen aber in diesem Überblickkapitel bereits einige wichtige Begrifflichkeiten der agilen Planung kennen.
Ursula Kusay-Merkle
Kapitel 6. Die Vision
Zusammenfassung
„All we need is one direction“. Die Vision gibt die Zielrichtung vor. Sie ist im übertragenen Sinn wie eine Fahne, die vor dem Projekt hergetragen wird.
Die Vision ist das Zielbild des Projektes oder des Produktes:
  • Was macht seinen Mehrwert aus?
  • Was soll mit dem Projekt/Produkt erreicht werden?
  • Was ist das Endergebnis oder Endprodukt?
Bevor wir uns dem Thema zuwenden, wie praktisch eine Vision im Projekt entwickelt werden kann, folgen noch einige grundlegende Überlegungen zur Erarbeitung der Vision und zu ihrem Einsatz im Projekt.
Ursula Kusay-Merkle
Kapitel 7. Die Project Charter – der Projektauftrag
Zusammenfassung
Eine Project Charter ist die Basis für ein Projekt und definiert Ziele, Inhalte, wichtige Risiken und Stakeholder und stellt die grundlegende Vorgehensweise dar. Sie geht damit deutlich über die Vision hinaus. Es mag formalistisch klingen, aber die Erstellung und Abstimmung der Project Charter ist ein wichtiger Schritt, um zu überprüfen, ob zumindest Sponsor und Projektleiter das gleiche Bild haben. Sehen Sie die Project Charter als Chance, dies herauszufinden!
Eine Project Charter also auch bei agiler Vorgehensweise? Ja, denn auch hier bleibt die Grundidee bestehen:
  • der Abgleich des Verständnisses des Projektleiters und des Sponsors und
  • die Beauftragung und gleichzeitige Genehmigung, Ressourcen des Unternehmens einzusetzen.
Auch wenn es Ihren Elan erst mal bremsen mag: Schreiben Sie eine Project Charter und gehen Sie diese mit dem Sponsor durch, selbst wenn dies nicht explizit gefordert ist!
Gleichzeitig ist im agilen Umfeld auch von der Team Charter die Rede, die die Zusammenarbeit des Teams betrifft.
Ursula Kusay-Merkle
Kapitel 8. Die Stakeholder – Betroffene und Beteiligte
Zusammenfassung
Stakeholder sind Betroffene und Beteiligte am Projekt, aber auch jeder, der ein berechtigtes Interesse am Projekt hat.
Sie können mit ihrem Wissen eine große Hilfe für den Projektleiter sein, aber auch eine große Herausforderung darstellen.
Wichtig ist, alle Stakeholder zu identifizieren, da verpasste Stakeholder meist auch verpasste Anforderungen bedeuten. Kennen Sie vielleicht auch Projekte, die zumindest vorübergehend zum Stillstand kamen, weil z. B. Mitbestimmungsrechte des Betriebsrates verletzt worden waren (§ 87 BetrVG)?
Ursula Kusay-Merkle
Kapitel 9. Das Product Backlog und die Verantwortung dafür
Zusammenfassung
Backlog ist im Englischen der Auftragsbestand. Vielfach heißt es, im Product Backlog stünden alle Anforderungen. Der englische Begriff beschreibt aber, dass es mehr als nur die Anforderungen sind. Es ist einfach alle Arbeit, die im Rahmen des Projektes anfällt.
Präziser gesagt ist das Product Backlog eine sortierte Liste, in der die angedachten und gewünschten To-dos für das Projekt gesammelt werden.
Bei den To-dos kann es sich handeln um:
  • Anforderungen,
  • Fehler, die noch beseitigt werden müssen,
  • Know-how-Transfer,
  • Dokumentationsarbeit,
  • Usw.
Außerdem ist die Liste sortiert. Damit ist gemeint, dass alle To-dos priorisiert sind: Die wichtigen Dinge stehen oben, nach unten hin nimmt die Priorität ab.
Aber Achtung: Nur weil ein To-do im Product Backlog steht, ist damit noch nicht versprochen, dass es auch getan wird! Das Product Backlog ist ein dynamisches Konzept.
Das Product Backlog ist emergent, d. h., es entwickelt und verändert sich, die Sortierung kann sich ändern, neue To-dos können hinzukommen, andere entfallen.
Die hoch priorisierten Einträge im Product Backlog sind auch detaillierter. Sie sind mit den Informationen versehen, die für die Umsetzung notwendig sind. Niedrig priorisierte To-dos sind vielleicht derzeit nur als Vermerk vorhanden. Aber es wird noch keine Zeit in die Aufbereitung investiert.
Interessant ist der Begriff „Product Backlog“ und nicht etwa „Project Backlog“. Hier kommt die Produktsicht der agilen Methoden zum Tragen. Daher besteht ein Product Backlog auch so lange, wie es das entsprechende Produkt gibt – also über ein Projekt hinaus.
Laut Scrum Guide [2] beinhaltet das Product Backlog auch das Produkt-Ziel als Planungsziel des Teams. Auf dieses wird hier nicht näher eingegangen werden, da über die Ausrichtung bereits im Rahmen der Vision Kap. 6 gesprochen wurde.
Damit stellt sich auch die Frage nach der Verantwortung für dieses wichtige Artefakt: Ist es der Projektleiter oder der Product Owner (PO)? Wo liegen die Unterschiede in diesen Rollen? Da die Rolle des PO relativ neu ist, wird sie in den Unternehmen unterschiedlich gelebt. Auch dies hat natürlich Auswirkungen und muss daher näher betrachtet werden. Dazu wird ein Modell verschiedener Stufen der Product Ownership vorgestellt.
Ursula Kusay-Merkle
Kapitel 10. Das Product Backlog initial befüllen
Zusammenfassung
Derzeit liegen vor: eine Project Vision, eine Project Charter, ein Stakeholder-Register.
Nun geht es darum, die Anforderungen der Stakeholder an die Lösung zu sammeln und in einem ersten Schritt eher intuitiv zu strukturieren. Dies ist die initiale Füllung des Product Backlogs. Korrekter könnten wir sagen: Der Anfang davon, denn wir werden nach und nach weitere Aspekte betrachten.
In der „agilen Welt“ gibt es viele interessante Workshop-Formate. Für das initiale Füllen des Product Backlogs werden zwei Alternativen vorgestellt: „Prune the Product Tree“ und „Remember the Future“.
Teilweise können dabei die Anforderungen bereits grob priorisiert werden. Dem Thema Priorisierung als solches widmet sich dann ein eigenes Kapitel, Kap. 11.
Ursula Kusay-Merkle
Kapitel 11. Priorisieren – Was ist wie wichtig?
Zusammenfassung
Das Product Backlog ist die Sammlung der To-dos im Projekt. Die Sortierung der Items gibt gleichzeitig die Reihenfolge der Umsetzung vor: Die wichtigsten Items stehen oben, die weniger wichtigen weiter unten. Da bei agilen Projekten in der zur Verfügung stehenden Zeit der Nutzen und Wert maximiert werden sollen, ist dies ein ganz wichtiges Kriterium bei der Priorisierung.
Die Reihenfolge im Backlog kann von verschiedenen Überlegungen beeinflusst werden, z. B.
  • Geschäftswert,
  • Bedeutung aus Kundensicht,
  • Risiken,
  • Cost of Delay (Verzögerungskosten),
  • Komplexität in der Umsetzung oder Aufwand und Kosten in der fortlaufenden Pflege usw.
Nach grundlegenden Überlegungen zum Priorisieren wird es praktisch mit verschiedenen Möglichkeiten der Priorisierung: interaktiv im Team, spielerisch oder eher klassisch.
Zu den vorgestellten Tools gehören:
  • relative Schätzung mit T-Shirt-Größen,
  • einfaches Priorisieren,
  • Abstufung mit MuSCoW,
  • Monopoly Money, 100-Punkte oder „Buy a Feature“,
  • Planning Poker® bzw. Estimation Poker,
  • Wall Estimation,
  • Weighted Shortest Job First (WSJF).
Dieses Kapitel tanzt hier in der Planung insofern etwas aus der Reihe:
  • Das Thema Priorisieren ist nicht nur auf die Planung und damit das initiale Füllen und Sortieren des Product Backlogs beschränkt. Auch wenn neue Anforderungen hinzukommen, wird priorisiert.
  • Gleichzeitig gibt es viele interessante Ansätze, wie das Priorisieren im Team gestaltet werden kann. Hier will dieses Kapitel auch einige gängige Verfahren vorstellen. Ziel dabei ist, dass Sie diese einordnen können, wenn sie Ihnen im Unternehmen oder in der Literatur begegnen.
Ursula Kusay-Merkle
Kapitel 12. Themes, Epics, Features, User Stories, Tasks – To-dos in unterschiedlicher Granularität
Zusammenfassung
Im agilen Umfeld werden die To-dos mit unterschiedlichen Namen belegt, je nachdem, ob es sich noch um ein grobes Thema handelt oder ob es eine kleine Aufgabe, ein Task, ist.
Leider ist der Sprachgebrauch nicht ganz standardisiert. In jedem Fall bilden die Begriffe eine Art Hierarchie der Anforderungen ab. An der Basis stehen die großen Themes und in der Spitze die kleinen Tasks zur konkreten Umsetzung.
Ein Theme ist wirklich nur ein Thema oder eine Idee, quasi eine Überschrift. Es ist damit die gröbste Form einer Anforderung und bildet in der Hierarchie der Anforderungen die Basis.
Meistens wird unter einer Epic ein Teil eines Themas verstanden. Damit ist zum Abarbeiten eines Themas die Umsetzung mehrerer Epics notwendig.
Ein Feature kann entweder synonym zu Epic verwandt sein, eine kleinere Einheit als eine Epic bezeichnen oder eine größere als eine Epic.
Dieses Buch nutzt einfach nur den Begriff Feature.
Der Begriff „User Story“ ist am wenigsten eindeutig:
  • Er bezeichnet zum einen die Art, wie eine Anforderung formuliert wird. Damit ist eigentlich das User-Story-Format gemeint.
  • Er kann gleichzeitig eine Untermenge von Features sein, sodass durch die Umsetzung mehrerer User Stories wiederum ein Feature oder eine Epic abgearbeitet werden kann.
Ein Task ist dann ein Schritt zur Umsetzung einer User Story. Tasks werden erst sehr zeitnah vor der Umsetzung einer User Story durch das Umsetzungsteam geplant.
Für Sie ist diese Begriffswelt vor allem dann wichtig, wenn Sie sich mit agilen Methoden und Tools weiter beschäftigen wollen, denn dann werden Sie Ihnen immer wieder begegnen.
Für dieses Buch werden Theme, Feature und User Story definiert und näher beschrieben werden. Der Schwerpunkt liegt dabei auf den User Stories.
Gerade bei User Stories wird oft vom „Schneiden“ gesprochen. Gemeint ist das Aufsplitten einer großen Anforderung in mehrere kleinere. Dies führt uns wieder zu einem ganz signifikanten Unterschied zwischen klassischem Projektmanagement und agiler Vorgehensweise. Das Zerteilen erfolgt beim agilen anders. Ziel einer Iteration ist immer mindestens ein potenziell auslieferbares Inkrement. Also etwas, das bereits einen Nutzen bietet. Anhand eines konkreten Beispiels wird der Unterschied zwischen einem herkömmlichen Vorgehen mit einem Projektstrukturplan und seinen Arbeitspaketen und dem agilen „Schneiden“ gezeigt.
Tab. 12.1 zeigt die in diesem Buch verwendeten Bezeichnungen für To-dos unterschiedlicher Feinheit:
Ursula Kusay-Merkle
Kapitel 13. Risiken und Nebenwirkungen
Zusammenfassung
Was sind Risiken?
Risiken sind Unwägbarkeiten, die im Falle des Eintretens den Projektverlauf oder das Ergebnis positiv oder negativ beeinflussen können.
Dies ist eine interessante Definition, denn Risiken sind im Sprachgebrauch negativ belegt. Es werden Bedrohungen darunter verstanden. Unwägbarkeiten können aber auch positive Auswirkungen haben und sind damit Chancen. Beide Varianten werden unter dem Begriff „Risiko“ verstanden.
Agile Methoden bieten viele Möglichkeiten, Risiken zu adressieren. Dadurch gibt es immer wieder Diskussionen, ob man in agilen Projekten überhaupt „Risikomanagement“ braucht. Dwight D. Eisenhower, der amerikanische General und Präsident, soll gesagt haben: „In preparing for battle I have always found that plans are useless, but planning is indispensable.“ Auch wenn es sich bei Projekten selten um Schlachten handelt, das Vorausdenken und Planen ist genauso unabdingbar.
Die Begriffe des Risikomanagements werden anhand eines alltäglichen Beispiels herausgearbeitet.
Im Anschluss werden die Prozesse des Risikomanagements erläutert. Zum Identifizieren der Risiken werden zwei Techniken vorgestellt: das „Sailboat“ (Segelschiff) und eine Ursache-Risiko-Tabelle. Nach dem Brainstorming zum Identifizieren von Risiken werden sie bewertet und priorisiert. Als letzter Schritt folgt in der Planung noch das Festlegen von Risikobewältigungsmaßnahmen.
Ich habe Seminare für angehende Fachinformatiker gegeben: Sie bekamen jeweils ein Projektmanagementseminar, darauf ausgerichtet, dass sie in Projekten gut mitarbeiten können und verstehen, was ein Projektleiter sich von ihnen an Informationen, aber auch von der Haltung her wünscht. Dazu gehörten auch Projektsimulationen.
Wir begannen früher ganz klassisch:
  • Was sind Risiken?
  • Wie funktioniert Risikomanagement im Projekt?
Irgendwann die Trainerfrage: „Was für Risiken in eurem Projekt könnt ihr euch vorstellen?“
– Schweigen –
Zaghafte Meldung: „Das Büro brennt ab???“
Das ist das Problem des Risikomanagements: Es kommt meist abstrakt daher. Dabei praktizieren wir es alle auch im Alltag. Wir nennen es nur nicht so. Lassen Sie uns also ganz praktisch beginnen.
Ursula Kusay-Merkle
Kapitel 14. Minimum Viable Product & Minimum Marketable Features – Warum es so wichtig ist, in „Wellen“ oder „Häppchen“ zu denken
Zusammenfassung
Sie haben nun die Anforderungen gesammelt, geschnitten, Sie können sie priorisieren und schätzen.
Im Prinzip gibt die Priorisierung bereits die Reihenfolge der Umsetzung vor.
Nun kommen aber zwei interessante Konzepte aus der Produktentwicklung: Minimum Viable Product (MVP) und Minimum Marketable Feature (MMF).
Beim MVP wird die Frage gestellt: Was ist das „kleinste Produkt“, mit dem ein Maximum an Feedback bei möglichst geringem Aufwand möglich ist?
Beim MMF geht es um die Bündelung von Funktionalitäten, die nur einen Teil der Kundenanforderungen erfüllen und gleichzeitig schon einen Wert für den Kunden bieten.
Diese beiden Begriffe werden in der Praxis nicht trennscharf genutzt. Entscheidend ist die Idee dahinter:
Jede Entwicklung birgt als Kernrisiko, dass das Produkt von Kunden nicht angenommen wird. Mit dem MVP wird genau dieses Risiko adressiert. Die Produktidee wird mit möglichst kleinem Aufwand getestet. Dieses Konzept wird analog auf weitere MVPs oder MMFs angewandt.
Dies ist ein fundamentaler Unterschied zum häufigen Vorgehen. Es wird nicht der „große Wurf“ angestrebt, sondern ein erster Test mit einem „richtigen“ Produkt gemacht.
Inspect and Adapt: Durch das Aufteilen in „Häppchen“ werden zwei wichtige Leitgedanken adressiert:
Nie zu lange am Stück am Projektergebnis arbeiten, ohne Feedback einzuholen, und Feedback am besten immer zu Konkretem, zu etwas Anwendbarem, nicht nur zu Ideen oder abstrakten Konzepten geben.
Ursula Kusay-Merkle
Kapitel 15. Die Story Map und die Roadmap – Die Zuordnung der To-dos zu den „Häppchen“
Zusammenfassung
Wenn wir die bisherige agile Planung mit der traditionellen plangetriebenen Methode vergleichen, dann scheint das Thema „Scope“ im Vordergrund zu stehen: To-dos mit unterschiedlichen Detaillierungsgraden: Themes, Features, User Stories.
Dann wurden auch die Risiken betrachtet.
Für die zeitliche Abfolge kennen wir bisher nur die Sortierung des Product Backlogs: Was weiter oben steht, kommt schneller dran als die To-dos, die weiter unten einsortiert sind.
Das Product Backlog ist aber nur eine eindimensionale Liste, sodass Zusammenhänge, Alternativen usw. nicht dargestellt werden können und dadurch auch Funktionalitäten oder To-dos leicht übersehen werden können. Wir benötigen also ein Tool, um übersichtlicher planen zu können.
Die Story Map ist eine übersichtliche, prozessorientierte Darstellung der Anforderungen. Sie stammt wie so vieles im agilen Umfeld aus der IT. Dabei werden die Interaktionsschritte mit dem System aus Benutzersicht aufgelistet. Für alle Schritte werden die verschiedenen Alternativen untereinander gesammelt und priorisiert. Nach dem Einfügen von Meilensteinlinien zeigt die Story Map die Kombination der Product Backlog Items, die aus fachlicher Sicht in einem Release geplant sind. Wie Sie an einem Beispiel sehen werden, lässt sich das Story Mapping auch außerhalb der IT einsetzen. Es dient der Planung der Vorgehensweise und ist ein Werkzeug für die inhaltliche Vorbereitung des Product Backlogs.
Die Story Map ist kein Ersatz für das Product Backlog, sondern bietet einen Überblick über die Produktentwicklung. Sie ist damit eher breit angelegt und dient der Kommunikation und dem Aufbau gleichen Verständnisses bei allen Stakeholdern.
Die komprimierte Zusammenfassung der Ziele der einzelnen Releases aus der Story Map und die voraussichtliche zeitliche Einordnung zeigt die Roadmap.
Ursula Kusay-Merkle
Kapitel 16. Schätzen der Dauer und Meilensteinplanung
Zusammenfassung
Bisher wurde in der Planung der Scope betrachtet. Durch die Story Map ist das Minimum Viable Product definiert. Die Story Map zeigt auch, was von Inhalt und Umfang her jeweils zwischen zwei Meilensteinlinien getan werden soll.
Somit gibt es bereits eine grobe Übersicht über die Reihenfolge, in der Scope voraussichtlich umgesetzt werden wird. Aber nach jedem Meilenstein können und sollen bei neuen Erkenntnissen der Scope und die Reihenfolge des Vorgehens überprüft werden. Es kann zu neuen Priorisierungen kommen, es könnten neue To-dos aufgenommen werden, bei anderen könnte die Entscheidung lauten, sie zu ändern oder gar entfallen zu lassen.
Somit steht gerade die zeitliche Planung unter dem Vorbehalt des „Dazulernens“.
Dieses Kapitel geht von der Story Map aus. Im Anschluss wird – soweit noch nicht geschehen – die Komplexität der Arbeiten geschätzt. Die Meilensteinlinien der Story Map führen zu den Meilensteinen der zeitlichen Planung.
Agile Methoden arbeiten empirisch und deshalb mit Erfahrungswerten.
Mit Erfahrungswerten kann aus der Schätzung der Komplexität heraus eine erste zeitliche Prognose abgegeben werden.
Mit wechselnden Teamzusammensetzungen und bei neuartigen Projekten gibt es diese Erfahrungswerte zum Zeitpunkt der Planung noch nicht. Dieses Kapitel zeigt für diesen Fall kurz Wege auf, wie mit dieser Problematik umgegangen werden kann.
Als ich dachte, das Buch sei weitgehend fertig, und es für eine letzte Kontrolle durchgegangen bin, las ich nochmals die Schritte in der klassischen Projektplanung. Die Terminplanung fehlte beim agilen Projektmanagement. So ganz übergehen wollte ich das Thema jedoch nicht.
Wie konnte das passieren?
Der Hintergrund ist vermutlich einfach darin zu sehen, dass in vielen kleinen Projekten keine „echte“ Terminplanung gemacht wird. Wenn die Projekte neben dem Alltagsgeschäft laufen müssen, ist jede genauere Terminplanung sehr volatil. Kunden haben immer Vorrang.
Wie hilft bei so einer Ausgangslage agiles Vorgehen?
Bildlich gesprochen: Die „großen“ (sprich: wichtigen) Steine müssen immer zuerst ins Glas, die kleineren passen als Lückenfüller immer wieder dazwischen.
Im Product Backlog oder auf der Story Map stehen die wichtigsten To-dos oben. Somit ist dies schon mal eine ideale Ausgangslage.
Noch ein Bild: Stellen Sie sich vor, Sie sind mit dem Auto unterwegs und kommen an einem Schild mit der Entfernungsangabe vorbei – wie in Abb. 16.1.
Wenn Sie Ihre Durchschnittsgeschwindigkeit und die Strecke kennen, können Sie abschätzen, wann Sie in etwa ankommen werden, oder?
In der Story Map haben wir bereits Meilensteinlinien gezogen. Nun stellt sich also die Frage, wie „weit“ ist es bis zum nächsten Meilenstein? Wann werden wir ankommen, sprich fertig werden?
Dies zeigt schematisch Abb. 16.2.
Was können wir demnach für die „agile Terminplanung“ nutzen?
  • Wir kennen bereits die „Strecke“ durch die Story Map.
  • Wir müssen jetzt noch die „Entfernung“ in Erfahrung bringen, also die Komplexität der anstehenden Arbeiten auf der Strecke ermitteln.
  • Dann benötigen wir unsere durchschnittliche Geschwindigkeit.
Mit diesen Informationen können wir abschätzen, wann wir ankommen werden.
Ursula Kusay-Merkle

Projektdurchführung und Steuerung

Frontmatter
Kapitel 17. Der rote Faden: Von der Gestaltung eines Kanban-Boards bis zur praktischen Arbeit mit dem Board
Zusammenfassung
Das Projekt ist geplant: Sie haben eine Roadmap erarbeitet, überlegt, mit welchen Lieferungen im Sinne von Lieferungen Sie bereits Nutzen erzielen können, und sich für die erste Welle bereits etwas mehr mit den To-dos beschäftigt.
Nun kann die Durchführung starten. Wir beginnen wie bei der Projektplanung wieder mit dem „roten Faden“ und verschaffen uns einen ersten Überblick.
Nach Begriffsdefinitionen gibt ein kleines Beispielboard erste Orientierung.
Anschließend werden die sechs Kanban-Praktiken im Überblick vorgestellt, bevor sie in den nachfolgenden Kapiteln jeweils im Detail besprochen werden.
Dieses Kapitel ist quasi „Kanban in a nutshell“ als erster Überblick. In den nachfolgenden Kapiteln werden die Themen weiter vertieft werden (Abb. 17.1).
Ursula Kusay-Merkle
Kapitel 18. Einführung in Kanban
Zusammenfassung
Kanban wurde ursprünglich in der Produktion eingesetzt.
Heute wird es auch in der Wissensarbeit angewandt. Durch Kanban werden die Arbeitsmenge und der Fluss der Arbeit sichtbar und steuerbar gemacht. Gleichzeitig folgt Kanban einfachen Regeln und ist relativ einfach zu implementieren. Kanban kennt Werte wie Transparenz, Balance, Respekt usw.
Es beruht auf vier Grundprinzipien:
  • Starte mit dem, was du jetzt machst.
  • Verfolge inkrementelle, evolutionäre Veränderung.
  • Respektiere initial Prozesse, Rollen, Verantwortlichkeiten und Jobtitel.
  • Fördere Leadership auf allen Ebenen in der Organisation.
Die sechs Praktiken wurden bereits im vorhergehenden Kapitel vorgestellt, wie z. B. „Mache Arbeit sichtbar“.
Aber wie gehören Werte, Grundprinzipien und Praktiken zusammen? Dies will dieses Kapitel beleuchten. Bei einem Kanban-System geht es nicht nur um die Mechanik, sondern vor allem auch um eine Arbeitskultur.
Für die Steuerung der Durchführung wird hier Kanban vorgestellt. David J. Anderson und Andy Carmichael beschreiben Kanban so: Es beschäftigt sich mit dem Design, Management und der Verbesserung des Arbeitsflusses (Flow Systems) für die Wissensarbeit [1] (Abb. 18.1).
Für die Darstellung von Kanban in diesem Buch gibt es mehrere Gründe:
  • Kanban arbeitet nicht mit einer festen Taktung und ist daher flexibler bei schwankendem Arbeitsvolumen oder sich rasch ändernden Prioritäten.
  • Auf einem Kanban Board können nicht nur ein Projekt abgebildet werden, sondern beispielsweise auch andere Aufgaben. Dadurch kann die Gesamtbelastung sichtbar gemacht und damit besser gesteuert werden.
  • Der Fokus liegt auf dem Fluss der Arbeit: „Stop starting, start finishing“.
  • Von der Begrenzung der angefangenen Arbeit mithilfe eines WIP-Limits profitiert die Produktivität. Der Kontextwechsel, das Context Switching von einem Thema zum anderen wird reduziert.
  • Feedback und kontinuierliche Verbesserung stärken die Effizienz und reduzieren Verschwendung: vermeidbare (Doppel-)Arbeiten, unnötige Meetings, unnötige Übergaben, Wartezeiten usw.
Ursula Kusay-Merkle
Kapitel 19. Die Kanban-Praktiken und was sie für die Projektarbeit bedeuten
Zusammenfassung
Kanban beruht auf sechs Praktiken:
  • Mache Arbeit sichtbar.
  • Limitiere den Work in Progress, also die Menge an begonnener Arbeit.
  • Manage Flow.
  • Mache Prozessregeln explizit.
  • Implementiere (häufige) Feedbackmechanismen.
  • Führe gemeinschaftlich Verbesserungen durch.
In diesem Kapitel werden diese Praktiken im Detail vorgestellt. Es führt schrittweise durch die Praktiken und hilft, diese im Selbstmanagement und der Projektarbeit praktisch anzuwenden.
Gerade bei der ersten Praktik, der Visualisierung der Arbeit, werden Beispiele verschiedener Möglichkeiten aufgezeigt. Frei nach Frank Sinatra geht es um „I do it my way“. Es gibt kein Kanban Board für „alle Fälle“. Es ist immer speziell auf die Situation anzupassen und wird sich im Laufe der Zeit und mit der Erfahrung auch ändern. Das Kapitel will dazu einladen, dies direkt auszuprobieren.
Im Fokus des Buchs stehen Projekte, die neben dem Alltagsgeschäft gestemmt werden. Daher werden Messmethoden und Diagramme wie das Cumulative Flow Diagram hier nicht behandelt. Dafür sei auf weiterführende Literatur verwiesen.
Ursula Kusay-Merkle
Kapitel 20. Kanban auf verschiedenen Ebenen einsetzen – die Kanban Flight Level
Zusammenfassung
Kaban kann auf verschiedenen Ebenen eingesetzt werden – von der persönlichen bis hin zur Unternehmensebene.
Dieses Kapitel stellt kurz die verschiedenen Ebenen vor:
Flight Level 1 – Operative Ebene mit einem Projekt oder einem Team mit und ohne koordinierten Input.
Flight Level 2 – Koordinierung der Zusammenarbeit mehrerer Teams mit Blick auf den Value Stream (Wertstrom).
Flight Level 3 – Strategisches Portfoliomanagement
Die Flight Level sind kein Reifegradmodell. Sie stellen vielmehr ein Kommunikationsinstrument dar, um darzustellen, welche Einsatzmöglichkeit und Wirkung Kanban auf den verschiedenen Ebenen hat. Je höher der Level, desto größer die Wirkung in Richtung Agilisierung des Business.
Ursula Kusay-Merkle

Die Gestaltung von Meetings und Workshops

Frontmatter
Kapitel 21. Die Gestaltung von Meetings und Workshops
Zusammenfassung
Da agile Methoden die Zusammenarbeit zwischen Menschen betonen und Menschen generell an erste Stelle setzen, folgen Tipps zur Gestaltung von Meetings. Gerade wenn immer wieder Lessons Learned gesammelt und Verbesserungen daraus abgeleitet werden sollen, ist es wichtig, über ein gewisses Repertoire an Gestaltungsmöglichkeiten und Problemlösungstools zu verfügen.
Dieses Kapitel bietet einige Grundlagen für die Moderation von Workshops und Besprechungen. Dabei kann dieses Kapitel natürlich nicht spezialisierte Bücher ersetzen, will aber grundlegenden Rat zu folgenden Themen geben:
  • Die Rolle des Moderators, insbesondere bei der Doppelrolle Moderator und Teilnehmer.
  • Das Handwerkszeug des Moderators mit Fragen, Paraphrasieren und Visualisieren. Ziel dabei ist immer, das gemeinsame Verständnis sicherzustellen und die Gruppe zu einem Ergebnis zu führen.
  • Die Phasen der Moderation werden vorgestellt und dabei einige „klassische“ Werkzeuge für die Erarbeitung von Lösungen vorgestellt.
  • Die Vorbereitung, Durchführung und Nachbereitung von moderierten Besprechungen und Workshops … Dabei werden die Hinweise zur Retrospektive (Abschn. 19.​6.​1) ergänzt. Kreative Ideen für die Gruppenbildung oder Möglichkeiten der Abstimmung oder um ein Stimmungsbild zu erhalten werden vorgestellt.
  • Den Abschluss bilden Anregungen für Regeln, einmal vom grundlegenden Verhalten her, aber auch ein Meeting-Knigge, in dem Tipps für Einladende und Teilnehmer von der Vorbereitung bis zur Nachbereitung von Meetings gegeben werden. Der Meeting-Knigge ist ein konkretes Beispiel eines deutschen Unternehmens, das damit die Spielregeln für seine Besprechungen festgehalten hat.
Ursula Kusay-Merkle
Backmatter
Metadaten
Titel
Agiles Projektmanagement im Berufsalltag
verfasst von
Ursula Kusay-Merkle
Copyright-Jahr
2021
Verlag
Springer Berlin Heidelberg
Electronic ISBN
978-3-662-62810-2
Print ISBN
978-3-662-62809-6
DOI
https://doi.org/10.1007/978-3-662-62810-2

Premium Partner

    Bildnachweise