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
Themenseiten
Organisationspsychologie Projektmanagement Marketing Smart Manufacturing
Bücher
Zeitschriften
Weitere Formate
Podcasts Webinare Technik Webinare Wirtschaft Kongresse Veranstaltungskalender Awards
Jetzt Einzelzugang starten
Zugang für Unternehmen
Referenzkunden
MTZ-Fachkongress

Antriebe und Energiesysteme von morgen


Austausch von Automobil- und Energiewirtschaft

Am 14./15. Mai geht es in Chemnitz um die Mobilitätswende durch Elektro- und Wasserstofffahrzeuge.
Erweiterte Suche
Anmelden
nach oben

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

Inhaltsverzeichnis

Frontmatter
Kapitel 1. Einführung
Zusammenfassung
Es gibt viel Projektmanagementliteratur und Vieles zu agilen Methoden. Aber die meisten Projekte sind kleinere Projekte, die von „nebenberuflichen“ Projektleitern geführt werden. Trotz der vielen vorhandenen Literatur fehlt Fortbildungsliteratur für diese Zielgruppe. Dieses Buch will 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 „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.
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 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 (Project Management Institute, A Guide to the Project Management Body of Knowledge PMBOK® Guide Sixth Edition. Project Management Institute Inc., Newtown Square, 2017 [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.
Die zweite Bedeutung von „value“ liegt in den agilen Werten. Diesen wird ein eigenes Kapitel gewidmet.
Scrum und Kanban
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. Durch die Beschreibung der beiden Methoden wird die agile Vorgehensweise noch deutlicher herausgearbeitet.
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 und
  • 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 allen 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“ 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.
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. Einführung in das Product Backlog – ein Ort für alle Arbeit
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 emergent, d. h. es entwickelt und verändert sich, die Sortierung kann sich ändern, neue To-dos können hinzukommen, andere entfallen.
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 Workshopformate. Für das initiale Füllen des Product Backlog 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 soll, 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®,
  • Wall Estimation.
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.
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 können User Stories auf der Ebene der Epics oder Features stehen.
  • 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 erfasst.
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.
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.
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 einen Teil der Kundenanforderungen erfüllen und gleichzeitig 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 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 eine Roadmap, die uns etwas mehr die zeitliche Reihenfolge der Umsetzung zeigt.
Als Tool dafür wird das Story Mapping vorgestellt.
Sie ist kein Ersatz für das Product Backlog, sondern bietet einen Überblick über das Produkt. Sie ist damit eher breit angelegt und dient der Kommunikation und dem Aufbau gleichen Verständnisses bei allen Stakeholdern.
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 kann 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 – so weit 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 damit 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.
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 „Häppchen“ Sie bereits Nutzen stiften 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.
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 eingesetzt. Durch Kanban wird 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. „Mach 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.
Ursula Kusay-Merkle
Kapitel 19. Die Kanban-Praktiken und was sie für die Projektarbeit bedeuten
Zusammenfassung
Kanban beruht auf sechs Praktiken:
  • Mach Arbeit sichtbar.
  • Limitiere den Work in Progress, also die Menge an begonnener Arbeit.
  • Manage Flow.
  • Mach 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.
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 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, dass 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
2018
Verlag
Springer Berlin Heidelberg
Electronic ISBN
978-3-662-56800-2
Print ISBN
978-3-662-56799-9
DOI
https://doi.org/10.1007/978-3-662-56800-2

Premium Partner

    Bildnachweise