0

Projektmanagement Wissenssammlung

In dieser Wissenssammlung findest du Artikel und Neuigkeiten zu allen Themen rund um das Projektmanagement. Wir informieren über Begriffe, Methoden, u.v.m.

Die SCRUM Master Ausbildung des mITSM

In unserer zweiteiligen SCRUM-Ausbildung dreht sich alles um Agilität, Offenheit und Eigenverantwortung. Gut ausgebildete SCRUM Master sind in allen Branchen gesucht. Erlerne die SCRUM-Grundlagen in unserer SCRUM Master Foundation Schulung (2 Tage). Erfahre welche Rollen es gibt und wie das SCRUM-Framework aussieht, wie Sprints funktionieren und welche Artefakte es gibt.

In weiteren zwei Tagen erlangst du tiefes Verständnis für die Rolle und Aufgaben des SCRUM Masters, im SCRUM Master Professional Training. Nach diesen vier Tagen bist du in der Lage das SCRUM-Framework in jedem Umfeld einführen und dabei die Rolle des SCRUM Masters übernehmen zu können. Du hast die Möglichkeit im Anschluss ein eintägiges Add-On zu besuchen, in dem du zusätzlich rollenspezifisches Wissen zum SCRUM Product Owner erlangst.

Projekte erfolgreich planen & umsetzen – mit PRINCE2®

Mit unserer PRINCE2®-Ausbildung lernst du zielorientiertes und effektives Projektmanagement kennen und erfährst wie du es in deiner Organisation umsetzt. Wir bieten sowohl klassisches PRINCE2, als auch PRINCE2 Agile Kurse an. In letzteren wird die Methode um agile Ansätze ergänzt. Es gibt jeweils einen Grundlagenkurs und eine Practitioner-Schulung, wobei du beide Grundlagenkurse jeweils mit beiden Practitioner Trainings kombinieren kannst.


5 Fehler im Projektmanagement und wie man sie vermeidet

Projektmanager müssen an vieles denken und stets den Überblick behalten. Fehler im Projektmanagement führen schnell zu Verzögerungen und unnötiger oder doppelter Arbeit und damit immer zu erhöhten Kosten. Wir haben einige häufige Fehler im Projektmanagement gesammelt und verraten, wie man sie am besten vermeiden kann.

Fehler 1: Mangelnde Unterstützung im Team oder im Management

Fehlt die Unterstützung der entscheidenden Mitarbeiter oder Teams, sind Projekte zum Scheitern verurteilt. In diesem Fall hakt es meist an der Kommunikation: Den Mitarbeitern muss die Dringlichkeit und Bedeutung des Projekts, sowie ihre Rolle darin im Vorfeld klar sein. Unter Umständen muss der Projektmanager sich die Unterstützung des Teams auch erstreiten, indem er den Teammitgliedern die Vorteile aufzeigt und ihnen ihre tragende Rolle verdeutlicht.
Hat ein Projekt nicht die notwendige Unterstützung im Management, wird ein erfolgreicher Abschluss erschwert. Es ist also empfehlenswert, von Anfang an jemanden aus der Führungsebene ins Projekt einzubeziehen.

Fehler 2: Zu wenig Kommunikation und Zusammenarbeit

Vor allem bei standortübergreifenden Teams ist eine enge Zusammenarbeit oft erschwert. Egal, wo sich die Teams befinden, ist es entscheidend, dass es regelmäßige Absprachen gibt. Dafür ist der Einsatz von passenden Tools ein Muss. Wird z.B. das agile Framework SCRUM genutzt, wird ein klarer Rahmen gesetzt: Jeden Tag gibt es ein 15-minütiges Team-Meeting, in dem der aktuelle Arbeitsstand besprochen wird. In einem festgelegten Rhythmus werden die Aufgaben für den kommenden Zyklus geplant.

Fehler 3: Keine klaren Ziele und Erfolgsmetriken

Wenn das Projektziel nicht von Anfang an klar ist, oder es während des Projektes geändert wird, fallen in der Regel erhebliche Mehrkosten an. Es ist also entscheidend für erfolgreiches Projektmanagement, dass das Ziel am Anfang festgelegt und nicht aus den Augen verloren wird. Wenn eine Anpassung des Ziels notwendig wird, sollte dies nur in Absprache mit den Stakeholdern geschehen.

Fast genauso wichtig wie feste Projektziele ist die Metrik, mit welcher der Projekterfolg später gemessen wird. Im Vorfeld muss also klar definiert sein, wie ein Projektergebnis auszusehen hat, damit es als erfolgreich gilt. So wird sichergestellt, dass alle Stakeholder auf dasselbe Ziel hinarbeiten und ein gemeinsames Verständnis teilen.

Fehler 4: Zu knapper Zeitplan

Ein klassischer Fehler im Projektmanagement ist ein nicht einhaltbarer Zeitplan. Über zu viel Optimismus in der Planungsphase freuen sich die Stakeholder nur zum Projektstart. Wenn aber daraufhin die Deadlines nicht eingehalten werden können, hat niemand etwas davon: Die Stakeholder sind unzufrieden und das Projektteam steht unter erhöhtem Druck.

Fehler 5: Mangelnde Flexibilität

In den klassischen Projektmanagement-Methoden wird zu Beginn des Projektes ein Projektplan aufgestellt. Dieser sollte zur Orientierung dienen – für eine gewisse Flexibilität sollte man trotzdem offenbleiben. Gerade bei komplexen Projekten ist es fast unmöglich in der Planungsphase alle Eventualitäten perfekt abzubilden. Nachbesserungen im Projektplan durchzuführen ist normal und wichtig. Diese Tatsache wurde für die agilen Methoden verinnerlicht: Hier wird regelmäßig, meist im Zwei-Wochen-Takt über die Prioritäten entschieden und die weitere Entwicklung bestimmt.

Wenn du deine Kenntnisse im Projektmanagement erweitern willst, empfehlen wir dir unsere PRINCE2- und SCRUM-Ausbildungen. In PRINCE2 lernst du  zielorientiertes und effektives Projektmanagement. Mit unserer SCRUM Ausbildung lernst du, Projekte mit dem beliebten agilen Framework umzusetzen.

 

Michael Malorny

Michael ist bei uns Produktmanager und Trainer im Bereich Projektmanagement. Davor war er 8 Jahre lang Projektmanager für umfangreiche Software-Entwicklungsprojekte und 6 Jahre als IT-Berater in einer Unternehmensberatung in Service Management-Projekten tätig. Michael ist promovierter Physiker.

Welchen Charakter hat mein Projekt?

Zu Beginn eines jeden professionellen Projektmanagements steht die Frage, um welche Art von Projekt es sich handelt. Die verschiedenen Projekttypen fordern ein unterschiedliches Maß an Akzeptanz im Team und in der Organisation. Somit bergen sie unterschiedlich große Risiken und müssen dementsprechend auf verschiedene Art und Weise angegangen werden.

Welche Projekttypen gibt es und wodurch zeichnen sie sich aus?

Eine beliebte Klassifizierung unterscheidet zwischen 4 verschiedenen Projekttypen. Ein Projekt ist dabei keineswegs auf einen Projekttyp beschränkt. Viele Projekte wandeln ihren Charakter und damit ihr Risiko im Laufe der Zeit.

Routine-Projekt

  • Veränderungsgrad: Gering, es gibt keine übergreifenden Veränderungen in der Organisation.
  • Risiko: Niedrig
  • Beispiele: Bereichsübergreifende Vertriebskampagnen (zeitlich begrenzt)

Innovations-Projekt

  • Veränderungsgrad: Mittel. Firmeninterne Strukturen werden weiterentwickelt, die strategische Ausrichtung bleibt aber bestehen.
  • Risiko: Moderat. Die vom Innovations-Projekt betroffenen Mitarbeiter können zunächst mit Ablehnung auf die Neuerungen reagieren. Die am Projekt Beteiligten sollten sich dieses Risikos bewusst sein und wissen, wie sie diese Vorbehalte moderieren können.
  • Beispiele: Implementierung eines moderneren IT-Systems, Neu-Aufsetzen und Standardisierung von Prozessen und Arbeitsabläufen.

Akzeptanz-Projekt

  • Veränderungsgrad: Groß, denn hier wird eine Veränderung auf kultureller Ebene herbeigeführt. Als Erfolg gilt eine Verhaltensänderung bei den Mitarbeitern.
  • Risiko: Hoch. Es gilt einflussreiche Multiplikatoren für diese Art von Projekten zu gewinnen. Diese müssen das Projekt unterstützen und die Mitarbeiter ermutigen, ihr Verhalten tatsächlich zu ändern. Entscheidend ist eine offene und frühzeitige Kommunikationsstrategie.
  • Beispiele: Neu-Organisation eines Unternehmensbereiches.

Change-Projekt

  • Veränderungsgrad: Komplex. Meist geht es hier um strategische Neuausrichtungen.
  • Risiko: Sehr hoch. Diese Art von Projekten benötigt für ihre erfolgreiche Umsetzung ein starkes Projektteam, mit starken Führungspersonen und Change-Managern. Die Geschäftsführung sollte stark involviert sein. Es muss frühzeitig eine umfassende Kommunikationsstrategie entwickelt werden, um Akzeptanz zu schaffen.
  • Beispiele: Neuausrichtungen des Produkts, z.B. von B2C zu B2B, oder von analog zu digital. Auch Firmenzusammenschlüsse oder Abspaltungen sind Change-Projekte.

Willst du mehr über Projektmanagement lernen? Wir bieten Fortbildungen im klassischen Projektmanagement PRINCE2 an, und bilden dich zum SCRUM Master aus.


Anforderungsmanagement und Digitalisierung

Der Mensch neigt dazu, in vorgefertigten Lösungen zu denken. Im Zweifelsfall wird das Problem für die gewünschte Lösung passend gemacht – offensichtlich nicht der Weg des großen Erfolges.

Der Grundstein für eine maßgeschneiderte Lösung in Ihrem Digitalisierungsprojekt wird mit einem ordentlichen Anforderungsmanagement und einer gründlichen Anforderungsanalyse gelegt. In Zeiten der Digitalisierung und der zunehmenden Vernetzung ist dies noch essenzieller geworden. Denn zum einen gibt es immer mehr vorgefertigte Lösungen und mehr mögliche Technologien und zum anderen eine immer größere Anzahl an Anbietern für diese.

Anforderungsanalyse als Projekt-Kompass

Deshalb ist es essenziell, zu Beginn eines Projekts alle Anforderungen detailliert und strukturiert aufzunehmen. Eine gute Anforderungsanalyse kann das ganze Projekt hindurch als Kompass dienen. Sobald die Projekt-Realität vom Kompass abweicht, sind Sie vom Weg abgekommen. Selbstverständlich ist eine verlässliche Anforderungsanalyse eine Herausforderung. Denn Anforderungen kommen ja meist nicht aus einer Hand: Sie werden oft von verschiedenen Stakeholdern eingebracht. Jeder priorisiert dabei seine Anforderungen. Einen Überblick über das Gesamt-Projekt zu behalten und alle Anforderungen sinnvoll zu clustern und zu priorisieren, ist somit eine der wichtigsten und schwierigsten Aufgaben des Requirements Engineers.

Oft gibt es vorgefertigte Lösungen, die schon ganz gut passen würden. Aber eben nicht perfekt. Um nicht in Versuchung geführt zu werden, die Anforderungen der vorhandenen Lösung anzupassen, sollten die Anforderungen bestimmt werden, bevor nach vorgefertigten Lösungen geschaut wird.

Wenn du mehr über Requirements Engineering erfahren willst, empfehlen wir dir unsere dreitägige Schulung IREB CPRE Foundation.


Die Bedeutung von Requirements Engineering

IT-Projekte werden immer komplexer. Durch die steigende Technologisierung steigen die Anforderungen der Kunden und Fachabteilungen werden mehr und mehr eingebunden. Je komplexer Projekte werden, desto entscheidender ist es, dass die notwendigen Anforderungen zunächst ermittelt und schließlich optimal definiert, abgestimmt und dokumentiert werden. Dies sind die Aufgaben des Requirements Engineers.

Aus diesen Aufgaben leitet sich die Rolle ab: Der Requirements Engineer vermittelt zwischen den Stakeholdern und dem Entwicklungsteam. Er ist maßgeblich daran beteiligt, dass das zu entwickelnde (Software-)Produkt die vorgegebenen Anforderungen und Rahmenbedingungen erfüllt.

Die Ermittlung von Anforderungen

Bei der Anforderungsermittlung ist zwischen funktionalen und qualitativen Anforderungen an das zu entwickelnde System zu unterscheiden. Es geht darum, Quellen zu finden, aus denen man Anforderungen ableiten kann. Ein Teil der Anforderungen lässt sich aus der Umgebung ziehen, in welche das System später eingefügt wird. Welche Stakeholder gibt es und welche anderen Systeme stehen in direkter Abhängigkeit vom neu zu entwickelnden System? Gibt es ein Konkurrenz-System, oder ein altes System, das abgelöst werden soll? Gibt es Gesetze oder Richtlinien, innerhalb derer sich das neue System eingliedern muss?

Die wichtigsten Techniken, mit denen Anforderungen ermittelt werden können, sind Befragungs- und Beobachtungstechniken. Aber auch Prototyping, dokumentenzentrierte Techniken und Kreativitätstechniken, wie Brainstormings, sind valide Methoden zur Anforderungsfindung.

Herausforderungen im Requirements Engineering

Als Schnittstelle zwischen den Stakeholdern und dem Entwicklungsteam hat der Requirements Engineer mit einigen Herausforderungen zu kämpfen. In der Regel gibt es zwischen den beiden Gruppen verschiedene Level an technischem Verständnis. Die meisten Stakeholder sind nicht tief in der technischen Materie und wissen nicht, wo die Grenzen der Realisierbarkeit liegen. Hier muss der Requirements Engineer vermitteln.

Dasselbe Problem kommt bei der Formulierung der Anforderungen auf: Während sich die Entwickler klar definierte, am besten in Fachsprache formulierte, technische Vorgaben wünschen, sind die Möglichkeiten der Stakeholder an der Stelle meist sehr begrenzt. Der Requirements Engineer muss die Wünsche und Erwartungen der Stakeholder also für die Entwickler in klare technische Anforderungen übersetzen.
Hinzu kommt, dass sich Anforderungen während eines Projekts ändern können. Vor allem bei größeren Projekten, die über einen langen Zeitraum umgesetzt werden, ist dies nicht unwahrscheinlich.

Ausbildung zum Requirements Engineer

Das mITSM bietet eine IREB CPRE Foundation an. CPRE steht für Certified Professional for Requirements Engineering. Es handelt sich dabei um eine standardisierte Ausbildung des IREB – International Requirements Engineering Board. Die Schulung dauert 3 Tage. Du lernst, wie du ein System und dessen Kontext abgrenzen, wie du Anforderungen ermitteln und dokumentieren kannst. Auch die Prüfung, Abstimmung und Verwaltung der Anforderungen sind Teil der IREB CPRE Ausbildung. Die Schulung richtet sich an jeden, der Anforderungen an Softwaresysteme erhebt. Zum Beispiel Solution- und System-Architekten, Produktmanager und Product Owner. Unsere Experten schulen dich Inhouse, in unserem Schulungszentrum in München und in unserem beliebten Online Live Format.


Projektmanagement in 2021 – wo geht die Reise hin?

Der Trend liegt auch 2021 bei agilen Projektmanagement-Methoden. Doch sind diese immer und für alle Projekte geeignet? Wann ist mehr Struktur notwendig und welche Methoden bieten diese?

Agile Methoden

Grundsätzlich gilt, dass nicht für jede Art von Projekt dieselbe Projektmanagementmethode geeignet ist. Für ein komplexes Entwicklungsprojekt – ob es sich um Software, oder ein komplexes Hardware-Produkt handelt – ist eine agile Methode das Richtige. Die bekannteste Methode ist SCRUM. Das umfangreiche Projekt wird dann in kleinere Teilprojekte aufgeteilt, in denen das jeweilige Team agil arbeitet und entwickelt. Es werden Ziele für Entwicklungsperioden, sogenannte Sprints, festgelegt. Nach jedem Sprint gibt es eine Evaluation: Wurden alle Ziele erreicht? Wo muss nachgebessert werden? Welche Ziele sollen nach dem nächsten Sprint erreicht werden? Welche Ziele werden später anvisiert und kommen zunächst in den Backlog? Im Grunde wird also nach jedem Sprint, der in der Regel 1-2 Wochen dauert, nachjustiert.

Klassische Methoden

Das ganz klassische Wasserfall-Modell ist für sehr große Projekte heute weniger beliebt, da am Anfang zu viel festgelegt wird. Das Projekt wird hier in Phasen gegliedert und linear abgearbeitet. Meist gibt es eine vorgegebene Timeline, die es einzuhalten gilt. Doch wie wir wissen, ändern sich im Laufe eines großen Projekts oftmals nicht nur die Anforderungen, sondern auch die Rahmenbedingungen. All das führt dazu, dass der Projektplan angepasst werden muss, was oft aufwändig ist. Für weniger komplexe Projekte kann der klassische Projektmanagement-Ansatz allerdings die bessere Wahl sein. Er bedeutet weniger Management-Aufwand während des Prozesses. Eine Weiterentwicklung des klassischen Wasserfall-Modells ist PRINCE2 (PRojects IN Controlled Environments). Dabei handelt es sich um einen strukturierten Ansatz, dessen Methode auf jedes Projekt angewendet werden kann.

Die Mischung macht’s!

In der Realität sind einzelnen Entwicklungsprojekte meist nicht isoliert zu betrachten. Die Projekte finden in Unternehmen statt, in denen mehrere Projekte parallel in unterschiedlichen Phasen laufen und nebenbei ein Tagesgeschäft bestritten wird. Deshalb ist oft eine Kombination aus klassischem und agilem Projektmanagement die sinnvollste Lösung. PRINCE2 kann hier den übergeordneten Rahmen bieten, in dem die agilen SCRUM-Projekte stattfinden.

Wir sind davon überzeugt, dass beide Methoden auch in 2021 ihre Bedeutung behalten und verstärkt gemeinsam zum Einsatz kommen werden.

Deine Projektmanagement-Ausbildung beim mITSM

Unsere SCRUM Ausbildung setzt sich aus der SCRUM Master & Product Owner (Foundation) und der SCRUM Master (Professional) sowie dem SCRUM Product Owner (Professional) zusammen. Die Foundation- und Professional-Ausbildung dauern jeweils 2 Tage. Wir bieten sie Inhouse, in unserem beliebten Online Live Format, in unserem Münchener Schulungszentrum, sowie in Köln an. Nach der Schulung kannst du jeweils die zugehörige Zertifizierungsprüfung der ICO ablegen.

Die PRINCE2-Ausbildung besteht bei uns aus einer zweitägigen PRINCE2 Foundation-Schulung und der darauf aufbauenden PRINCE2 Practitioner Weiterbildung, die 3 Tage dauert. Sowohl die Foundation als auch die Practitioner Schulung bieten wir klassisch und als Agile-Variane an. Auch hier hast du die Wahl zwischen Inhouse, unserem Online-Live-Format und unserem zentralen Schulungszentrum in München. Die Zertifizierungsstelle ist PeopleCert.


SCRUM vs. Kanban: Welche agile Methode für wen?

Projektarbeit und damit Projektmanagement nimmt in Unternehmen einen immer größeren Stellenwert ein. Dabei gibt es Projekte, die klassisch organisiert sind, mit einem Wasserfallmodell. Für viele Projekte ist diese Art der Organisation allerdings nicht geeignet. Wer ein komplexes Projekt bewältigen muss, in der Lage sein möchte, flexibel zu reagieren und den Teammitgliedern eigenverantwortliches Arbeiten ermöglichen möchte, der managed sein Projekt agil.

Es gibt eine Menge agiler Methoden und Frameworks zum Projektmanagement. Zwei der bekanntesten sind Scrum und Kanban, die sich beide auf das agile Manifest stützen. Während Scrum ursprünglich aus der Softwareentwicklung stammt, wurde Kanban entwickelt, um die Produktionsprozesse beim japanischen Automobilhersteller Toyota zu optimieren. Beide Methoden werden heute in den verschiedensten Branchen, Projekttypen und Unternehmen angewandt. Was haben Scrum und Kanban gemeinsam und wo liegen die Unterschiede zwischen ihnen? Und vor allem, welche Methode eignet sich besser für mein Projekt?

Gemeinsamkeiten der agilen Methoden

Zunächst gilt, dass beide agilen Methoden einfach zu verstehen, aber schwer zu beherrschen sind. Sie sind nicht besonders komplex, ihr Erfolg hängt voll und ganz von den Teams, deren Motivation und Selbstorganisation ab. Beide funktionieren nach dem Pull-Prinzip, das heißt die Teammitglieder bekommen ihre Aufgaben nicht automatisch zugeschoben, sondern nehmen Aufgaben aktiv an sich. Sowohl Scrum als auch Kanban ist agil, lean, transparent und stellt Produktinkremente in kurzen Abständen bereit.

Produkt vs. Prozess

Der wichtigste Unterschied zwischen den beiden Methoden sind die verschiedenen Fokusse. Während Scrum sich auf die iterative Produktentwicklung konzentriert, soll mit Kanban eine kontinuierliche Prozessverbesserung erreicht werden. Es lässt sich zusammenfassen, dass du für eine komplexe Produktentwicklung mit Scrum gut beraten bist. Willst du ein Projekt umsetzen, das vielleicht kompliziert, aber nicht komplex ist? Bei dem du Wert auf einen optimalen Prozessfluss legst und Engpässe im Prozess aufdecken willst? Dann ist Kanban das Richtige für dich.

Erfahre mehr zu den beiden agilen Frameworks. In 2 Tagen vermitteln wir dir die Inhalte von Kanban, oder bilden dich innerhalb von 4-5 Tagen zum SCRUM Experten aus.


Der Product Owner – Allrounder des Projektteams

In der Agilen Softwareentwicklung gibt es ein Team-Mitglied, das viele verschiedene Bälle in der Luft hält: Der Product Owner. Seine Rolle ist im Scrum Guide sehr schwammig definiert. Er trägt einen großen Teil der Verantwortung den Wert des Produktes zu maximieren. Wie er das anstellt, variiert von Organisation zu Organisation. In der Realität bedeutet das, dass er mehrere Rollen aus- und erfüllen muss:

Der Product Owner als Produktmanager

Die Rolle, an die man beim Product Owner zuerst denkt, ist die des Produktmanagers. Meist wird die Position des Product Owner durch einen Produktmanager besetzt. Als solcher trägt er die Verantwortung dafür, dass das Produkt dem Kundenbedarf entspricht und gleichzeitig wirtschaftlich ist. Folglich ist es entscheidend, dass der Produktmanager während der Entwicklungsphase den Markt und die Kundenzufriedenheit im Blick behält. Daraus resultiert oft, dass er im Team Ansprechpartner für die Kundenbedürfnisse ist und somit als User-Experience-Experte wahrgenommen wird.

Der Product Owner als Requirements Engineer

Die zweite wichtige Rolle, die der Product Owner ausfüllt, ist die des Requirements Engineer. Er ist verantwortlich dafür, dass das zu entwickelnde Produkt die Anforderungen aller beteiligten Stakeholder erfüllt. Es gilt also zunächst einmal die Stakeholder zu identifizieren und deren Anforderungen aufzunehmen. Diese zu ermitteln, sie genau zu verstehen und zu priorisieren sind entscheidende Aufgaben des Requirement Engineer. Oft stehen Anforderungen von verschiedenen Stakeholdern in Konflikt miteinander. Hier zu moderieren und die Stakeholder gut zu betreuen, zeichnet einen Requirements Engineer aus. Die aufgenommenen und priorisierten Anforderungen nimmt der Product Owner in die einzige Anforderungsquelle des Entwicklungsteams auf, das Product Backlog.

Der Product Owner als Leader und Teammitglied

Der Product Owner gibt mit seinen Anforderungen also automatisch die Richtung in der Entwicklung vor. Auch wenn es im Scrum-Team keinen Projektleiter gibt, nimmt der Product Owner so automatisch eine inoffizielle Leader-Rolle ein. Er behält den Fortschritt der Entwicklung im Blick und kommuniziert ihn regelmäßig ans Team, agiert so als motivierende Kraft. Es ist nicht unüblich, dass der Product Owner das Reporting übernimmt, sofern es eines gibt. Auch behält er den Gesamtkontext und das Ziel des Projekts im Auge. Nicht zu vergessen ist allerdings, dass der Product Owner innerhalb des Scrum Teams die wichtige Rolle des Team-Mitglieds innehat. Gemeinsam mit den Entwicklern und dem Scrum Master arbeitet er daran, dass ein Produkt mit Wert entsteht. Dabei unterstützt er die Entwickler, hält sich wie das restliche Team dabei an die Scrum-Regeln und Werte.

Lass dich bei uns in nur 4 Tagen zum Scrum Product Owner ausbilden! Besuche dafür die zweitägige Scrum Foundation, den ersten Tag des Scrum Master Professional-Trainings und das eintägige Scrum Product Owner Add-On.


Mit Agilität aus der Krise?

Krisen sind gerade präsent in der Geschäftswelt. Viele Unternehmen haben im vergangenen Jahr durch die Pandemie und allem, was mit ihr einherging und noch immer einhergeht, eine ausgewachsene Krisensituation erlebt. So gab es unter anderem veränderte Nachfrage, Komplikationen in der Beschaffung und Produktion, sowie die großflächige Umstellung auf Homeoffice.

Die Krise haben viele Unternehmen zum Anlass genommen, um auf agiles Projektmanagement umzustellen. Denn dieses gilt als modern und zukunftsorientiert – wer agil arbeitet, kann schneller auf Veränderungen reagieren, Prozesse leichter anpassen und empowered seine Mitarbeiter durch wenig Hierarchie und viel Freiheit.

Doch ist eine Krise der richtige Zeitpunkt, um agile Methoden einzuführen?

Die Antwort ist eigentlich klar: Nein. In einer akuten Krise geht es um das Fortbestehen des Unternehmens, es geht darum, Halt zu geben und die fragile Situation wieder zu stabilisieren. Es ist nicht der richtige Zeitpunkt für große Umbrüche. Besonders bei der Umstellung auf agiles Projektmanagement handelt es sich um eine Veränderung des Mindsets und der Unternehmenskultur. Dies erfolgreich zu schaffen fordert eine gewisse Entspannt- und Lockerheit, denn ein agiler Grundsatz lautet: Experimentieren und bereit sein aus Fehlern zu lernen.

Sobald die akuten Feuer gelöscht sind, das Team wieder die notwendige Orientierung hat, kann die Umstellung auf agiles Projektmanagement eingeleitet werden.


SCRUM vs. Kanban – Gemeinsamkeiten & Unterschiede

Bei SCRUM und Kanban handelt es sich um zwei essenzielle agile Projektmanagement-Methoden. Ihnen beiden liegen die Prinzipien zugrunde, die im agilen Manifest niedergeschrieben wurden.

Viele Gemeinsamkeiten…

Die Methoden haben sehr viele Gemeinsamkeiten: Sie sind lean, arbeiten nach dem Pull-Prinzip und liefern in kurzen Abständen neue Produktinkremente. Beide konzentrieren sich in den Entwicklungszyklen jeweils auf eine limitierte Anzahl an Anforderungen/Tasks, die im neuen Produktinkrement umgesetzt werden. Beide Methoden zielen darauf ab, die Effizienz durch hohe Transparenz zu steigern.

Und doch anders…

Der maßgebliche Unterschied zwischen den beiden Methoden ist, dass in SCRUM die Rollen klar definiert sind: Der Product Owner trägt die Produktverantwortung und definiert und priorisiert die Anforderungen. Der SCRUM Master ist dafür verantwortlich für die SCRUM-Rahmenbedingungen zu sorgen. Nachdem es diese Rollen in Kanban nicht gibt, ist hier oft ein agiler Trainer hilfreich, um die Einführung zu unterstützen.

Wann eignet sich welche Methode?

Welche Methode nun für wen geeignet ist, hängt von der Art des Projekts ab, an dem du arbeitest. In einem nicht besonders komplexen Projekt, in dem es vor allem um Effizienz der Prozesse und Steigerung der Produktivität geht, ist Kanban die geeignetere Methode. Je komplexer die Projekte sind, z.B. in der Entwicklung eines High-Tech Produkts, desto mehr kommen die Stärken von SCRUM zur Geltung.

Die nächsten Termine für unsere Kanban-Schulungen findest du hier. Über diesen Link kommst du zu unseren SCRUM-Schulungen.

Michael Malorny

Michael ist bei uns Produktmanager und Trainer im Bereich Projektmanagement. Davor war er 8 Jahre lang Projektmanager für umfangreiche Software-Entwicklungsprojekte und 6 Jahre als IT-Berater in einer Unternehmensberatung in Service Management-Projekten tätig. Michael ist promovierter Physiker.
+49 89 - 44 44 31 88 0