• Business System Development — Als technischer Wissensträger für das Lean Management ist das KPO verantwortlich für die Entwicklung eines Business Systems im allgemeinen, bzw. eines Produktionssystems im speziellen (denken wir beispielsweise an TPS). Darüber hinaus müssen ein Curriculum und die entsprechende Bildungseinheiten um das System entwickelt werden.
• Change Management — Das KPO betreut sämtliche Veränderungen als Berater, Trainer, Betreuer und Katalysator. Es nimmt nicht die Rolle des Initiators an. Es kann lediglich Empfehlungen aussprechen.
• Personalentwicklung — Typischerweise wird ein Unternehmen kurze Zeit nach der Transformation von einem Kaizen-Sensei begleitet, bis es auf eigenen Beinen stehen kann. Das gelingt nur, wenn Kaizen von der gesamten Belegschaft eines Unternehmens verinnerlicht wird. Das KPO beteiligt sich aktiv an der Aus- und Weiterbildung des Personals, sowohl im technischen als auch im organisatorischen Bereich.
• Daily Kaizen etablieren — Der Übergang zum täglichen Kaizen steht dem systematischen Ansatz des Kaizen-Events gegenüber. Ersterer ist eine Frage der Tiefe der Durchsetzung von Kaizen, letzterer ein organisierter Systemansatz des Lean Managements. Beides zusammen ist das ultimative Ziel und verspricht den größten Nutzen der Transformation. Das KPO ist also beim Training der Belegschaft (wichtig hier: Train-the-Trainer) und der Entwicklung von Problemlösungsqualitäten die treibende Kraft. Es ist die einzige Instanz einer Organisation, welche eine echte Kaizen-Kultur auf jeder Ebene schaffen und erhalten kann.
• Kaizen-Events organisieren — Die Organisation von Kaizen-Events ist ganz klar die Domäne des KPO. Als technischer Wissensträger kann nur das KPO die richtigen Themen (Focus Areas), Vorbereitungen und die Nachbearbeitung vollständig organisieren. Das KPO ist hier ganz klar in einer aktiven Rolle.
• Office Management — Das Office im Sinne des Kaizen ist der virtuelle und physische Wirkungskreis des Kaizen Promotion Office. Es dreht sich alles um Informationsaufbereitung und -austausch, Planung von Weiterbildungsmaßnahmen und die Aufrechterhaltung der kontinuierlichen Verbesserungsmaßnahmen durch die jeweiligen Verantwortlichen.

Was braucht’s für einen Kaizen Promotion Office?

Die oben genannten 6 Aufgaben und Ziele des KPO erfordern in weiten Teilen ganz spezifische Fachkenntnisse und Fähigkeiten. Diese unterscheiden sich selbstverständlich sehr stark von der jeweiligen Position, die ein Protagonist innerhalb des KPO einnimmt. Beispielsweise hat ein KP Officer auf Unternehmensebene (meist ein Mitglied der Geschäftsleitung oder Bereichsleitung) einen anderen Focus als der einer Business Unit.

Dennoch lässt sich ein recht gutes Bild von den allgemeinen Kompetenzen solcher Funktionsträger zeichnen. Dazu zählen:

• Fähigkeit zur strategischen Planung und Ausrichtung
• Führungsstärke im Change Management
• Ausgeprägtes Zeit- und Selbstmanagement
• Führungsstärke im Team und die Fähigkeit das Team richtig zu positionieren (im Sinne von Konsensbildung)
• Verantwortung für getroffene Maßnahmen
• Flexibilität
• Das Gespür für Talente und deren Förderung
• Hohe soziale Kompetenz und Kommunikationsstärke

Ganz ohne Zweifel sind einige der genannten Soft-Skills nur sehr schwer zu erlernen (manche haben sie einfach) jedoch können Menschen mit Hilfe intensiven und gezielten Coachings (und nicht zuletzt durch die gesammelte Erfahrung) auf diesen Gebieten große Fortschritte erzielen.

Nun, was die technischen Kenntnisse angeht, quasi all das “was” zu tun ist, so sind es primär die drei Bereiche Lean Principles, Systeme und Werkzeuge (Techniken). Erfahrung ist der beste Lehrer, noch besser ist die Instruktion durch einen erfahrenen Sensei, doch irgendwo muss der Anfang gemacht werden. So bleibt oft nicht anderes übrig, als sich dem Studium des Lean Managements zu widmen.

Es mangelt ganz und gar nicht an Zertifizierungsprogrammen, allerdings wird in den meisten Fällen ein rigoroses Programm abgespult, das einen hohen Zeitaufwand und entsprechende Hingabe abverlangt. Insgesamt sollten auf jeden Fall eine natürliche Neugierde und das Verlangen nach intellektueller Erkenntnis (beides darf ruhig leicht obsessive Züge annehmen) vorhanden sein. Letztendlich bewegen wir uns alle im Kreislauf studieren, anwenden, lernen und leeren. Wissen ist zum Teilen da!

Während es unterschiedliche Ansätze für die Organisationsentwicklung gibt, gehe ich von einem Prozessmodell aus, was bedeutet, daß ich zusammen mit meinen Kunden die Situation untersuche, Probleme identifiziere und Lösungen herbeiführe. Ziel dieses Ansatzes ist, den Kunden mit der Fähigkeit auszustatten, Probleme in Zukunft selbst diagnostizieren und lösen zu können. Statt Abhängigkeit zu fördern, verhelfe ich Unternehmen zu mehr Unabhängigkeit.

Naturgemäß ist jede Beratungstätigkeit auf dem Gebiet der Organisationsentwicklung immer wieder neu und einzigartig, wie die Unternehmen und die Märkte in denen sie sich bewegen. Wenn Du Dich für ein Engagement im Bereich OE interessierst findest Du unten eine Auswahl von Projekten, die ich typischerweise bearbeite. Durch Verbindungen zu unterschiedlichen Beratungsunternehmen kann ich jederzeit und auf Deinen Wunsch hin auf andere Experten für Domänen außerhalb meiner eigenen zurückgreifen.

Was ich als Organisationsentwickler so alles mache

• Team Development — Wie finde ich das richtige Team? Wie führe ich Teams aus der Krise? Wie motiviere ich Teams?
• Strategische Planung — Was möchte ich erreichen? Wie sehen meine Ziele aus? Wie kann ich schwierige Szenarien antizipieren?
• Change Management — Wie führe ich Mitarbeiter nach Fusionen zusammen? Wie rufe ich strategische Initiativen ins Leben? Wie kann ich die Unternehmenskultur positiv beeinflussen?
• Coaching — Der Manager als Mentor? Führungskräftetraining für das mittlere und Top-Management

Gleichzeitig können gute Prozessmanager helfen, Unternehmen aus einer ungeordneten und von Bauchentscheidungen behafteten Existenz in eine geordnete, geplante und zielgerichtete Zukunft führen.

Leistungsangebot

• Die Optimierung der Service-Landschaft durch eine 360°-Analyse der Situation. Sie ist Voraussetzung für einen auf Ihre strategischen Stärken ausgerichteten Implementierungsansatz zur Optimierung Ihrer Prozesse. Ihre Kunden und Mitarbeiter werden es Ihnen danken.
• Ressourcenplanung und Organisationsentwicklung — Mit der Veränderung von Prozessen sind oftmals auch personelle Veränderungen verbunden. Meine ganzheitliche Methodik vernachlässigt diesen Aspekt nicht.
• Die strategische Ausrichtung Ihrer IT-Landschaft auf Ihre Unternehmensziele ist unabdingbar für eine dauerhafte Wettbewerbsfähigkeit, ausgeprägte Agilität und exzellenten Service, sowohl unternehmensintern wie auch für Ihre Kunden.

Meine Aufgabe ist es mit ungetrübtem Blick und unvoreingenommenen Betrachtungen, Ihre Visionen in die Wirklichkeit umzusetzen.

Ganz ähnlich gestalten sich auch die Herausforderungen an die Führungskräfte der Organisationen, welche sich auf die zunehmende Unsicherheit und Intensivierung des Wettbewerbs einstellen müssen. In den meisten Fällen heißt das: weniger ist mehr.

Das mittlere und das Top Management sehen sich meist Problemen gegenüber, für die es keinen klaren Lösungsansatz gibt. Erfolg setzt aber voraus, dass sich Entscheidungsträger gezielt den Innovationen widmen und neue Denkansätze im Unternehmen kultivieren. Das Selbstverständnis, welches Organisationen von sich haben, muss sich den neuen Umständen anpassen.

Historisch betrachtet hat das Training von Führungskräften die Problemlösungskompetenz stark vernachlässigt. So wurde nicht selten die Theorie vertreten, dass jedes Problem mit einer einfachen Lösung zu beseitigen sei, die Kunst bestünde nur darin, die richtige Lösung innerhalb eines akzeptablen Zeitfensters zu finden. Das “Flickschusterei” das Problem nur kurzfristig oder gar nicht beseitigt ist inzwischen hinreichend bekannt.

Die betroffenen müssen sich dann oft fragen lassen: Was hast Du Dir nur dabei gedacht? Dabei müßte man vielmehr fragen: Wie hast Du dabei gedacht?

Eines meiner 10 Prinzipien des Managements ist systemisches Denken, nämlich komplexe Interaktionen auf struktureller, technischer, politischer und personeller Ebene zu erkennen und zu analysieren. Systemisches Denken etabliert eine neue Perspektive, und erlaubt es Managern und Führungskräften das große Ganze besser zu verstehen. Auf diese Weise werden kluge und dauerhafte Lösungen für Probleme gefunden.

Unsere Arbeitsplätze haben sich in den letzten dreißig Jahren enorm verändert. Sie sind schnellebig geworden, wir sind einem Informationsüberluss unterworfen und stehen ständig unter Strom (glücklich ist, wer das spätestens an der Wohnungstür ablegen kann). Gekennzeichnet ist diese Tendenz von der Tatsache, dass, dominiert von der Orientierung an Werten und Zielen, oftmals das Wichtige durch das Dringliche verdrängt wird.

Damit verbunden ist eine der größten Hindernisse systemischen Denkens, nämlich die ungebremste Geschäftigkeit. Vertieft im Sumpf der unendlich vielen Details unserer Existenz ist es nicht schwer, das große ganze aus dem Blick zu verlieren. Das Management ist gefordert, Einfachheit, Klarheit und Sicherheit in einer flüchtigen und komplexen Umgebung zu schaffen.

Vor einigen Jahren, beispielsweise, konnte ich einen Kunden helfen zu erkennen, dass die Lösung zur Bekämpfung schlechter Recruiting-Ergebnisse nicht in der Zentralisierung der internationalen Bemühungen liegt. Als er das große Bild vor sich sah, konnte eine Recruiting-Infrastruktur geschaffen werden, die es erstmals ermöglichte, lokale Talente und hochspezialisierte Fachkräfte für die jeweiligen Standorte zu gewinnen. Das wurde durch systemisches Denken erreicht, weil wir endlich begannen, Beziehungen zu betrachten. Daraus resultierten Muster für nachhaltige Veränderungen und kontinuierliche Verbesserungen.

Aufbauend auf den 7 Todsünden der Verschwendung (YouTube) brachen Produktionsleiter mit Kaizen im Rucksack auf zur Suche nach Muda und Eliminierung derselben. Wurde das richtig und gut gemacht, konnten signifikante Verbesserungen in kurzer Zeit beobachtet werden, welche heute noch anhalten.

Heutzutage wird es immer wichtiger die Verwaltungen solcher Produktionsbetriebe ebenfalls einer solchen Aktivität zu unterziehen.

Warum ist das so? Weil Kunden bessere Produkte und Dienstleistungen zu geringeren Preisen möchten, das ganze natürlich auch schneller als üblich. Aus Kundensicht beginnt die Uhr mit dem Absenden der Bestellung an zu ticken und hört erst auf, wenn das Produkt geliefert oder die Dienstleistung erbracht wurde. Somit lohnt sich ganz gewiss ein Blick über den Horizont des Produktionsalltags hinaus.

Muda im Office

In der Produktion ist Lean Management ein alter Hut und bereits sehr gut etabliert. In der Verwaltung und Administration von Organisationen ist das noch nicht der Fall. Ein Grund ist sicher, dass dieser Bereich noch nicht so viel Aufmerksamkeit erhielt wie der Produktionsbereich, nicht zuletzt weil hier die größten Potentiale lagen.

Auf Produktionsseite verarbeiten wie Material und Teilerzeugnisse zu neuen Produkten. Der Fluß ist klar umrissen, wir können mit dem einzelnen Bauteil förmlich durch die Produktionsstufen wandern. Im Büro, mit all den unterschiedlichsten Tätigkeiten, Informationen und Interaktionen ist der Arbeitsfluß ganz und gar nicht so einfach zu durchschauen. Möchten wir unser Büro also von Muda befreien müssen wir einen anderen Blick auf die Prozesses werfen. Diesen Blick kann man sich aneignen. Wie das geht beschreibe ich diesen Blog Post.

Was ist Muda?

Im weitesten Sinne, kann Muda in jeder Operation oder Aktivität gefunden werden, die dem Endprodukt oder der Dienstleistung Mehrkosten auferlegt, ohne erkennbaren Mehrwert für den Kunden zu erzeugen. Betrachten wir administrative Aufgaben und Prozesse, so könnten folgende Aktivitäten potentielle Kandidaten sein:

• die Bewegung und Sortierung von Unterlagen
• Ablage von Unterlagen
• Wiederkehrende Tätigkeiten gleicher Art
• Wiederholung aufgrund von Fehlern
• Warten auf Freigaben von Dokumenten oder Tätigkeiten
• Unnötige Überprüfung getaner Arbeit
• Ineffiziente Workflows
• Veraltete und inadequate Software

Ein strategischer Ansatz zur Beseitigung von Quellen der Verschwendung würde, ebenso wie im Produktionsbereich, zu folgenden positiven Auswirkungen führen:

• Reduzierung der Verarbeitungszeiten, schnelle Antwortzeiten auf Kundenanfragen
• Eliminierung aller unnützen Aktivitäten
• Einfache, logische und schnell zu erlernende Arbeitsprozesse
• Reduzierung von Fehlern und damit verbundener Mehrarbeit
• Ständige Verbesserung durch das Team
• Geringere Kosten
• Hohe Moral und Leistungsfähigkeit des Teams

Wo fangen wir an?

Ein guter Ausgangspunkt sind immer Kernprozesse. Typischerweise gibt es in einem Unternehmen nicht so viele. Beispiele für Kernprozesse könnten die Auftragsbearbeitung oder die Produktentwicklung sein. Diese Prozesse untersuchen wir auf die Erfüllung Deiner subjektiven Erwartungshaltung hinsichtlich Qualität, Kosten und Zeitaufwand.

Zur Unterstützung sollten stets abstrahierte Flußdiagramme zur Hilfe genommen (Du hast doch welche, oder?) und die jeweilgen Prozess Owner (auch die existieren in Deiner Firma, nicht wahr?) hinzugezogen werden. Mit Hilfe der Diagramme besteht für alle beteiligten ein gemeinsames Verständnis für den aktuellen Prozessablauf und welche funktionalen Bereiche verantwortlich für welche Teilprozesse sind.

Anschließend müssen wir nur noch ein messbares Ziel und einen Zeitplan für die Prozessoptimiertung definieren. So etwas könnte beispielsweise lauten: “Beantwortung von 95% aller Kunden anfragen innerhalb von 12 Studen bis zum Ende des zweiten Quartals”.

Techniken und Werkzeuge

Als Kenner des Kaizen möchte ich daher besonderes Augenmerk auf folgende Werkzeuge zur Identifikation von Muda legen:

1. Analyse der Wertschöpfungskette
2. Prozessmodellierung
3. Pareto-Analyse und Fischgretendiagramme
4. Theory of Constraints (von SixSigma)

Zu den empfehlenswerten Techniken zur Beseitigung von Muda gehören:

5. Value Stream Mapping
6. One Piece Flow Processing
7. Prozesse mit minimalen Fehlerquellen (Poka Yoke)
8. Das sog. Cellular Processing

Diese acht Schritte sind der Schlüssel zum Lean Office.

Extrem wichtig ist bei der Implementierung der ausgewählten Strategie, das Du stets den gesunden Menschenverstand anwendest und nicht gegen ihn arbeitest.

Fazit

Das war ein kurzer Exkurs in das Lean Office, welches immer wichtiger wird um den Kreislauf der Optimierungsbemühungen, welche in der Produktion begannen, zu schließen.

Zusätzlich ist es enorm empfehlenswert, zusätzliche Anstrengungen im Bereich der Führungsqualität, der Selbstbestimmung und der Stärkung von Partnerschaften mit Lieferanten zu unternehmen, da hier ganz enorme Verbesserungspotentiale verborgen liegen.

Ausführlicher möchte ich an dieser Stelle ausdrücklich nicht werden, da sich ganze Bücher mit diesem Thema befassen und neben dem Kaizen-Aspekt insbesondere soziale und politische Betrachtungen eine wichtige Rolle spielen.

Mehr Flexibilität, höhere Qualität, geringere Durchlaufzeiten, besserer Kundenservice, optimale Kommunikation zwischen Abteilungen und KollegInnen. All das erreichst Du mit Kaizen. In Ergänzung mit 5S (Seiri 整理, Seiton 整頓, Seisō 清掃, Seiketsu 清潔 und Shitsuke 躾) wird auch die Büroarbeit in neuer Effizienz erstrahlen.

Mein KAIZEN-Programm für Dich:

Eine typische Dienstleistung umfasst meine Präsenz vor Ort zur Evaluierung der aktuellen Umgebung uns Aufnahme der besonderen Eigenschaften Deines Unternehmens. Ich erfasse und demonstriere die Auswirkungen der Veränderungen auf alle Rollen über alle Ebenen hinweg.

Übrigens, folgende Artikel könnten für Dich interessant sein:

• Prozesse für agiles Softwareprojektmanagement
• Agilität für Projektmanager

Übrigens, folgender Artikel könnte für Dich interessant sein: Präsentieren wie die Profis

Agile Entwicklungsmethoden haben die Industrie im Sturm erobert. Das liegt hauptsächlich daran, das es einfach funktioniert: höhere Erfolgsraten, bessere Qualität, gesteigerte Kundenzufriedenheit, besseres ROI (Return On Investment) und schnellere Markteinführung (Time To Market).

In diesem Artikel beginnen wir mit einer allgemeinen Betrachtung des Agilen Prozessmodells um die unterschiedlichen Ansätze in den richtigen Kontext setzen zu können. Anschießend betrachten wir das vorgestellte dreistufige Modell genauer und erfahren wie die drei aufeinander aufsetzen. Zum Abschluß wenden wir das Modell beispielhaft auf die Entwicklung einer Software an und enden mit einigen Hinweisen für eine erfolgreiche Einführung agiler Softwareentwicklung.

Das agile Prozessmodell

Im Zusammenhang mit Softwareprojekten und damit verbundenen Prozessen wird immer wieder von Maturity gesprochen. Daß es sich dabei um einen inzwischen überladenen Begriff handelt ist nicht Verdienst der exzellenten Arbeit des Software Engineering Istitute (SEI) der Carnegie Mellon University, die das Capability Maturity Model Integrated (CMMI) entwickelt hat und eine Abwandlung speziell für die Durchführung von Softwareprojekten CMMI-DEV hervorbrachte. Vielmehr wurde der Begriff Maturity auf die Prozessoptimierung angewandt, während das hier vorgestellte Agile Process Maturity Model (APMM) vielmehr bemüht ist, einen Rahmen für die agile Softwarenentwicklung zu stellen, so daß die unterschiedlichen Methoden in den richtigen Kontext gesetzt werden können. Wir könnten auch sagen: das APMM ist das schlanke Geschwister vom CMMI.

Wie angedeutet ist APMM ein dreistufiges Modell dessen Ebenen aufeinander aufsetzen:

Abbildung 1

Die drei Stufen sind folgendermaßen zu verstehen:

Level 3: Scaling Agility

Stufe 3 konzentriert sich auf einen wichtigen Skalierungsfaktor in agilen Prozessen, beispielsweise Teamgröße oder der Grad der geographischen Verteilung des Teams. Es muß sich dabei aber nicht immer um eine quantitative Größe handeln, denn auch der Einfluß von Regulatorien oder der Grad der Einhaltung von Standards sind skalierend Faktoren in agilen Entwicklungsprozessen.

Level 2: Disciplined Agility

In Stufe 2 schauen wir über den Tellerrand hinaus und decken den gesamten Software Delivery Life Cyle (SDLC) ab. Beispiele sind Dynamic System Development Method (DSDM) und OpenUP (Open Unified Process).

Level 1: Agile Software Development

Stufe 1 betrachtet nur einen kleinen Teil des gesamten Entwicklungsprozesses, da nur die agilen Aspekte des Manifestos von Bedeutung sind. Beispiele sind Scrum oder XP.

Das Modell mag zum jetzigen Zeitpunkt noch nicht besonders einleuchtend sein. In den folgenden Abschnitten beleuchten wir jede Stufe genauer und gehen immer wieder auf die Bedeutung im APMM ein.

Stufe 1: Agile Software Development

Die agilen Methoden auf Stufe 1 decken nicht den gesamten SDLC ab, sondern orientieren sich an den Werten des Agile Manifesto und vestehen sich als eine ganzheitliche Sammlung von empfohlenen Vorgehensweisen. Beispiele für die Implementierung der Stufe 1 sind die bekannten Vertreter:

Scrum

Projekt- und Anforderungsmanagement sind die Stützpfeiler von Scrum. Mittels Iterationen (Scrum spricht von Sprints) werden Zyklen zur Produktreifung definiert. Gepaart mit diversen Praktiken wie täglichen Stand-Up Meetings, Verwendung von Product Backlogs und klaren Rollen wie beispielsweise ScrumMaster und Product Owner entsteht ein Planungsgerüst, welches ganz nach Definition durch das Manifesto auf die Erstellung lauffähiger Software ausgerichtet ist. Abbildung 2 zeigt den Scrum Life Cycle.

Extreme Programming (XP)

XP ist eine Sammlung von Praktiken für die Softwareentwicklung, mit Fokus auf Programmiertechniken. Beispielsweise sind Pair Programming (zwei Entwickler an einem Modul gleichzeitig), Test-First Design (erst der Unit Test, dann die Implementierung) und Continuous Integration einige der propagierten Techniken für die Softwareentwicklung mit XP. Darüber hinaus bekennt sich auch XP zu Dingen wie Collective Ownership um die Bedeutung selbstorganisierender Teams herauszustellen.

Agile Data

Datenlastige Anwendungen erfordern oftmals andere Herangehensweisen als beispielsweise Steuerungssysteme. Für solche Fälle eignet sich Agile Data sehr gut, da hier nicht nur die Organisation und Entwicklungstechniken betrachtet werden, sondern auch die Modellierung, Datenbanktest und Database Refactoring.

Abbildung 2

Stufe 2: Disciplined Agility

Auf Ebene zwei wird der agile Prozess von Stufe 1 erweitert und berücksichtigt den gesamten SDLC. Der wesentliche Unterschied zu Stufe 1 ist die Berücksichtigung einzelner Aspekte des Prozesses (nicht der Techniken oder Technologien), beispielsweise Testing oder Process Improvement. Ganz typisch handelt es sich bei Discplined Agility auch um einen evolutionären, iterativen Entwicklungsansatz zur Produktion hochqualitativer Software, der sich durch den Einsatz von Risiko- und Value-Driven Management { Value-driven Managment bedeutet in diesem Zusammenhang, die aktuellen Marktentwicklungen während des gesamten SDLC immer wieder zu bewerten um sicherzustellen, daß ein gewinnbringendes Produkt entsteht, welches auf dem Markt bestehen kann. } auszeichnet.

Disciplined Agility vertraut auf qualifizierte und selbstorganisierende Teams, die von einer frühzeitigen und starken Einbindung der Auftraggeber profitieren. Auf diese Weise kann das Team die Anforderungen des Auftraggebers besser verstehen und auf Veränderungen schneller reagieren. Auf der anderen Seite ist der Entwicklungsprozess transparent und kann jederzeit vom Auftraggeber durch aktive Mitwirkung, beispielsweise in Form häufigen Feedbacks, korrigiert werden.

Beispiele für agile Prozesse der Stufe 2 sind:

Open Unified Process (OpenUP)

OpenUP erweitert und kombiniert bekannte Praktiken aus Scrum, XP, AD und RUP für die Anwendung auf verteilte, virtuelle Teams. Dabei werden Methoden wie Whole Team, Stand-Up Meetings, Risikomanagement, TDD, aktive Einbindung der Auftraggeber und Continuous Integration angewandt. OpenUP ist ein Open Source Framework, das Teil des Eclipse Process Framework ist.

Rational Unified Process (RUP)

RUP ist ein umfassendes Rahmenwerk für Prozesse in der Softwareentwicklung, das unterschiedlich ausgeprägt werden kann, je nachdem wie die es die aktuelle Situation erfordert. Eignet sich für sehr agile wie auch traditionelle Ansätze gleichermaßen. Es deckt die Praktiken Risk Management, Whole Team, TDD, Business Process Sketching und Continuous Integration ab.

Dynamic System Development Method (DSDM)

DSDM eignet sich besonders für Applikationen mit komplexen Benutzeroberflächen. Es ist ein agiler Ansatz, der von Rapid Application Development abgeleitet wurde und sehr stark auf Rapid Prototyping, Testing, Machbarkeitsstudien und Reversible Changes setzt.

Feature-Driven Development (FDD)

FDD zeichnet sich durch den Einsatz von Modellierungstechniken und kurzen Iterationen aus. Zu den typischen FDD-Praktiken gehören Class Ownership (PDF), Domain Object Modeling, Development by Feature, Feature Teams und regelmäßige Übersetzungen der Software (Regular Builds). Eine ausgezeichnete Kurzbeschreibung von FDD findest Du unter The Coad Letter: Issue 70.

Eine akstrahierte Darstellung eines vollständigen SDLC wird in Abbildung 3 dargestellt. Als Beispiel erweitern wir Scrum um wichtige Aspekte des SDLC, denn zum ersten wird eine explizite Projektgründungsphase (Project Inception) allen anderen Aktivitäten vorangestellt, in der wir erste Modelle konstruieren, das Team bilden und die finanzielle wie auch institutionelle Unterstützung des Auftraggebers sichern. Zum zweiten integrieren wir unabhängige Tests, um sicherzustellen, daß Fehler nicht durchs Raster fallen, was insbesondere auf nicht-funktionale Merkmale und Integrationstest zutreffen kann. Die nächste Erweiterung von Scrum betrifft das Product Backlog, das nicht nur priorisierte Aufgabenelemente berücksichtigt, sondern auch Tätigkeiten wie die Teilnahme an Trainings (auch zu fachfremden Disziplinen), Feedback zu Arbeiten anderer Teams und die Bewertung von Fehlern sowie deren Einordnung in das Backlog. Das letzte Merkmal des beschriebenen agilen SDLC ist die ausdrückliche Einführung einer Übergangs- und Produktionsphase (Release to Manufacturing).

Abbildung 3

Stufe 3: Berücksichtigung von spezifischen Faktoren

Zu Beginn der agilen Bewegung wurden die Praktiken zunächst auf kleinere überschaubare Projekte angewandt und relativ pragmatisch angegangen. Heutzutage wenden Organisationen agile Methoden auf ein weitaus größeres Wirkungsspektrum an. Agilität der Stufe 3 berücksichtigt die Komplexität der Projekts in Bezug auf bestimmte Faktoren, die wie Skalierungen angewandt werden können. Folgende Tabelle faßt einige Faktoren zusammen, die Auswirkung auf die Komplexität eines Projekts haben.

Jedem Faktor ist eine Komplexitätsskala zugeordnet und jedes Team wird eine andere Kombination aufweisen, so daß der Prozess, die Teamstruktur und die Werkzeuge den Rahmenbedingungen angepaßt werden müssen. Agile Prozesse der Stufe 1 im APMM funktionieren am besten wenn alle Faktoren in der Skala auf der linken Seite liegen (eine geringe Komplexität aufweisen.) Prozesse der Stufe 2 zeichnen sich durch einen oder mehrere Faktoren aus, deren Komplexität entweder in der Mitte oder auf der rechten Seite der Skala liegen. Liegen fast alle Faktoren auf der rechten Seite wird der Entwicklungsprozess extrem komplex und bedarf spezieller Werkzeuge zur Koordinierung verteilter Teams, Metriken zur Überwachung der Compliance und Berater, die auf beispielsweise auf Risikomangement und andere geschäftsspezifische Disziplinen spezialisert sind.

Während Stufe 1 und Stufe 2 tatsächlich als eigenständige Prozesse charakterisiert werden können, ist die Stufe 3 als Leitfaden für die Bewertung der Projektkomplexität mittels einer einfachen Skala gedacht. Letzendlich wirken sich die Erkenntnisse aus Stufe 3 auf den Prozess der Stufe 2 dahingehend aus, daß bestimmte Schritte/Abläufe unterschiedlich gewichtet sind und einer eigenen internen Analyse unterzogen werden, um dem identifizierten Komplexitätsgrad in diesem Bereich gerecht zu werden.

Was bedeutet das für die Praxis?

In der Praxis wird in fast allen agilen Methoden aus Stufe 1 eine Projektinitiierung durchgeführt, allerdings nicht immer explizit mit der klaren Zielsetzung, die Finanzierung des Projekts zu sichern und ausführlich Zeit für eine Definition der initialen Anforderungen und der gewünschten Vorgehensweise einzuplanen (Länge der Iterationen, Zusammenstellung des/der Teams, Wahl des Prozessmodells, etc.). Es ist nicht unüblich zwischen ein bis zwei Wochen dafür anzusetzen.

Im Idealfall nehmen daran Teil:

• die Auftraggeber: Product Manager/Owner, Business Owner und Process Owner
• die Auftragnehmer: Key Account Manager und Business Consultant, Senior Developers, CTO

An der Zusammensetzung sehen wir schon, daß wir nicht nur das Ziel haben, die Anforderungen zu verstehen, sondern auch Risiken zu minimieren, was primär durch die Vertreter der Auftraggeber garantiert wird, die in diesem Beispiel teilweise redundant sind, dadurch aber jeweils eine eigene Sicht auf mögliche Risiken ermöglichen.

Parallel dazu entwerfen CTO und die Senior Developers eine vorläufige, grobe Architekture, identifizieren Subsysteme und Schnittstellen und tragen wichtige Informationen zur Aufteilung der Arbeit auf das oder die Teams zusammen. Je nach Schwerpunkt des Produkts sind die Business Consultant beispielsweise auf Compliance in regulierten Umgebungen spezialisiert oder sind externe Berater zum Thema Baurecht, weil das Endprodukt eine Software für Ausschreibungen in der Baubranche ist.

Der Product Owner (erfahrungsgemäß oftmals Product Manager des Auftraggebers) priorisiert die Anforderungen und versorgt die Teammitglieder mit Details über Geschäftsprozesse. Er/Sie wird dabei von den Business Ownern und/oder Process Ownern unterstützt.

Nachdem die erste Iteration (Inception) vorbei ist, wird in der zweiten der Fokus auf die Entwicklung eines Proof of Concepts gelegt um zu zeigen, daß die gewählte Architektur tatsächlich funktioniert. Am Ende der Iteration wird dem Auftraggeber das Ergebnis präsentiert, wobei sich das Team hier ausschließlich auf die Demonstration der kritischen Systemeigenschaften konzentriert. Beispielsweise könnte eine kritische Anforderung sein, daß eine Anwendung 5.000 Transaktionen pro Minute bei durchschnittlich zehn angemeldeten Benutzern für mindestens 24 Stunden verarbeiten können muß.

Durch die richtige Wahl der Teammitglieder und einer ausführlichen Projektgründungsphase konnte das Gesamtrisiko des Projekts drastisch reduziert werden, weil zum einen die Anforderungen richtig verstanden wurden und demonstriert werden konnte, daß die kritischste Komponente den ersten Test bestanden hat.

Was die Projektkommunikation betrifft, ist es stets empfehlenswerte eine Single Point of Communication Strategie zu verfolgen. In Bezug auf Projektkoordination, Ressourcenplanung usw. kommunizieren zwischen Auftragnehmer und Auftraggeber lediglich Key Account Manager (Auftragnehmer) und Product Manger (Auftraggeber). Fachspezifische Themen koordiniert die Teamleitung mit den Business Consultants auf Auftragnehmerseite und den Business und Process Ownern auf Auftraggeberseite. Idealerweise, aber praktisch leider kaum durchführbar, sind die Business und Process Owner stets verfügbar und nehmen an täglichen Meetings teil. Besonders in komplexen Projekten mit hohem Risiko ist dieser Punkt obligatorisch.

Technische Fragen beantwortet die Senior Developer und der CTO in täglichen Meetings.

Abschließende Gedanken

Viele Organisationen konnten ihre agilen Prozesse erfolgreich skalieren (Stufe 3) und Du kannst es auch. Wenn Du Dir treu bleibst und nicht der Rhetorik der Vertreter aus Stufe 1 erliegst ist das schon ein wichtiger Schritt. Du solltest versuchen, mindestens einen agilen Prozess der Stufe 2 zu etablieren, da der gesamte SDLC berücksichtigt wird und nicht nur ein Teil davon (nur die Konstruktionsphase). Sei darauf vorbereitet, daß Du Dich über kurz oder lang in einer Situation befinden wirst, in der Dein Prozess skalieren muß (Stufe 3) und das viele Teams unterschiedlich skaliert werden müssen. Mit einem realistischen, maßgeschneiderten Ansatz kann der ROI gesteigert, die Qualität erhöht und die Kundenzufriedenheit maximiert werden.

Der Übergang zu agilen Methoden fordert unsere eingeschliffene Wahrnehmung von der Disziplin des Software Engineering, und damit verbunden auch Managementmethoden und Führungsstile, heraus. Agilität wirkt sich auf alle Rollen eines Teams unterschiedlich aus und eröffnet die Gelegenheit auf völlig neue Art und Weise zusammenzuarbeiten.

Besonders für Projektmanager ändert sich die Methodik im agilen Umfeld. Agilität erfordert ein völlig neues Framework für das Zeitmanagement, Kostenberechnung und Anforderungsmanagement. Zusätzlich wird des Projektmanagers Liebling, die Vorhersehbarkeit des Projektablaufs, stark strapaziert, denn nun heißt es: Embrace Change! {Ron Jeffries}. Risikomanagement wird nun unmittelbar von der Auslieferung lauffähiger Software bestimmt. Zusammenarbeit, Förderung individueller Stärken, ein serviceorientierter Führungsstil, Coaching und die Teamzusammenstellung sind essenzielle Fähigkeiten, die Projektmanagern helfen, agile Teams effektiv und zielgerichtet zu führen.

Mit diesen zusätzlichen Fähigkeiten ausgestattet, lernen agile Projektmanager wie sie in einer ungewissen und sich ständig ändernden Welt noch besser zur Wertschöpfung beitragen können.

Traditionelles Projektmanagement

Die meisten traditionellen Projekte betrachten den Gültigkeitsbereich (engl. Scope) als wichtigstes Abgrenzungskriterium eines Projektes. Oftmals tritt der Scope in Form einer langen List mit Produktanforderungen in Erscheinung.

Projektmanager arbeiten evtl. mit Ressource Managers zusammen um Abschätzungen für jeden funktionalen Bereich zu ermitteln, der von den Anforderungen betroffen ist. Diese Abschätzungen werden in der Regel in Arbeitsstunden oder -tagen dokumentiert, ohne genaue Informationen über die eigentliche Implementierung der Anforderungen. Anschließend werden daraus die notwendigen Personentage, Ressourcen und andere Faktoren abgeleitet, so dass davon wiederum eine Kostenschätzung hergeleitet werden kann. Das wir davon aber weit entfernt sind, wird in den folgenden Ausführungen deutlich.

Am Anfang des Projekts verfügt das Team über wenig verwertbare Informationen über die Quantität der notwendigen Arbeit. Gleichermaßen weiß auch das Projektmanagement nicht genau, welche Teammitglieder welche Aufgaben erledigen werden oder wie die Ressourcen allgemein auf das Projekt optimal verteilt werden können.

Mit nur sehr wenigen Informationen über die tatsächliche Lösung (das Produkt) und über die Arbeitsaufteilung ist es fast unmöglich eine zuverlässige Aussage über ein Fertigstellungsdatum zu treffen. Projektmanager erstellen Projektpläne auf diesen unvollständigen Informationen und geben ihr bestes, das Projekt nach diesem vom Auftraggeber abgesegneten Plan abzuwickeln.

Diese Herangehensweise hat sich in der Vergangenheit nicht als zuverlässige Methodik zur Abschätzung von Projektdauer, -größe und -kosten bewiesen. Was die Sache noch schlimmer macht ist die Tatsache, dass von der Annahme einer absoluten Sicherheit über die Vollständigkeit, Korrektheit und Unveränderlichkeit der Anforderungen ausgegangen wird und die Methodik Veränderungen gar nicht vorsieht.

Agiles Projektmanagement kurz und knapp

Agiles Projektmanagement geht von der Prämisse aus, das Softwareprojekte unvorhersehbar sind und dass Marktveränderungen zu unmittelbaren Korrekturen der Anforderungen an das Produkt führen. Die Ungewissheit über Marktentwicklungen führt automatisch zu veränderten Anforderungen während der gesamten Laufzeit des Projekts, und je unsicherer die Entwicklungen sind, desto besser muss das Team darauf eingestellt werden.

Aus diesen Gründen ist der Scope eines Projekts ein denkbar schlechter Ausgangspunkt für die Planung von Softwareprojekten und Erhebung von Leistungskennzahlen eines solchen. Stattdessen geht die Planung agiler Projekte von den beiden Faktoren Zeit und Kosten aus, da diese beiden Rahmenbedingungen meist zu Beginn des Projekts feststehen. Die Auftraggeber wissen in der Regel wie viel Geld sie in das Projekt investieren möchten und wann es spätestens einsatzbereit sein muss.

Anforderungen werden in agilen Projekten in kleine Häppchen des antizipierten Endprodukts aufgeteilt, und möglichst unabhängig voneinander herausgelöst, so dass sie einzeln priorisiert und implementiert werden können, ohne sich an eine bestimmte Reihenfolge halten zu müssen. Kleine überschaubare, unabhängige Module sind kritisch für die Fähigkeit mit Veränderungen im Projektverlauf fertig zu werden, ohne dass sie besondere Auswirkungen auf das Projektteam nach sich ziehen.

Innerhalb von zuvor vereinbarten Iterationen, meist in einer länge zwischen zwei und vier Wochen, werden immer wieder Häppchen aus dem Backlog realisiert, so dass nach einer Iteration andere Features nachrücken und ggf. wieder neu priorisiert werden können.

Agile Teams stellen nun langsam fest, wie viele dieser Fragmente sie innerhalb einer Iteration fertigstellen können und verstehen dadurch wie viele der Anforderungen des Projekts sie innerhalb des Budgets und Zeitplans realisieren können.

Agile Projektplanung

Projektmanager agiler Teams befassen sich primär mit zwei Leistungsindikatoren: die Größe des Backlogs und Velocity. Das Product Backlog ist die Liste der Anforderungen an das Endprodukt. Es besteht meist aus einer priorisierten Ansammlung von Features, die das Team sofort umsetzen kann. Die einzelnen Positionen eines Backlogs wurden entweder in Stunden, Tagen oder abstrakten Maßeinheiten, wie Story Points, abgeschätzt. Die Zahl aller Elemente ist die Gesamtgröße des Product Backlogs.

Velocity beschreibt wie viele Elemente des Backlogs vom Team innerhalb einer Iteration erledigt werden konnten. Diese Größe kann über ein festgelegten Zeitraum gemessen werden und repräsentiert den Durchsatz des Teams oder die Geschwindigkeit in der das gesamte Backlog abgearbeitet werden kann. Das Fertigstellungsdatum wird durch eine einfache Formel berechnet:

Iterationen bis zur Fertigstellung = Größe des Backlog / Dauer einer Iteration

Die ideale Geschwindigkeit (ideal Velocity) ist der Durchsatz welcher notwendig ist, um das Backlog vollständig innerhalb des vorgegebenen Zeitraums und der angesetzten Kosten umzusetzen. Die eigentliche Geschwindigkeit ist der wahre Durchsatz des Teams in jeder Iteration. Die Differenz zwischen der idealen und der eigentlichen Geschwindigkeit ist der wichtigste Indikator über den Projektfortschritt in Relation zu den Erwartungen des Auftraggebers. Je dichter die beiden Größen bei einander liegen umso wahrscheinlicher ist es, dass das gesamte Product Backlog termingerecht realisiert werden kann.

Teams mit vorhersagbarem Durchsatz können eine durchaus fundierte Vermutung über einen möglichen Fertigstellungstermin anstellen. Wenn Zeit und Kosten unveränderliche Größen sind, kann die Anzahl der umgesetzten Features innerhalb dieser Grenzen abgeschätzt werden.

Teams mit schwankendem Durchsatz sind nicht vorhersehbar und führen in der Regel zu unterschiedlichen Ergebnissen bei der Projektabwicklung. Das konstante Beobachten des Durchsatzes erlaubt Projektmanagern viel über das Team zu lernen und zu erfahren wie bestimmte Ergebnisse bei der Projektabwicklung zustande kommen.

Agile Teams führen

In agilen Projekten übernimmt das Team die Verantwortung für die Auslieferung und sollte daher die notwendigen Freiheiten erhalten, dies es benötigt um sich selbst bestmöglich zu organisieren. Das Team kann autonom entscheiden wie es die Arbeit erledigen möchte. Agile Projektmanager können das Team unterstützen indem Sie die Entscheidungen neutral bewerten und dem Team mitteilen, ob es mit diesem Ansatz erfolgreich ist oder eher nicht.

Um die Wahrscheinlichkeit einer erfolgreichen Projektabwicklung zu unterstützen können Projektmanager den Kontext des Projektes aktiv gestalten. Sie können die Umgebung des Teams verändern, die Entscheidungsfindung im Team fördern und Autonomie zusagen wann immer möglich. Agile Projektmanager gehen von den besten Qualitäten der Teammitglieder aus, gehen auf individuelle Stärken ein und respektieren das Team als gleichwertiger Partner. Sie helfen die Kultur zu verändern und fördern ein gesundes Arbeitsklima.

Die Autonomie kommt mit einem Preisschild und das heißt häufige Produktveröffentlichungen. Das Team bekennt sich am Beginn einer jeden Iteration zu einem gemeinsamen Ziel und ist auch selbst verantwortlich für die Einhaltung desselben. Es ist für agile Projektmanager unabdingbar im Team eine Kultur der Selbstverantwortung zu bilden und mit dem Team kontinuierlich daran zu arbeiten. In diesem Aspekt ist der Projektmanager verantwortlich, Policies, Prozeduren und Metriken zu etablieren, die die Gesamtleistung der Projektabwicklung steigern.

Zusammenarbeit mit agilen Teams

Nicht jedes Team wird einen dedizierten Projektmanager benötigen. Viele agile Teams tragen einem oder mehreren Teammitgliedern diese Rolle an, sofern sie qualifiziert sind und über ausreichend Kapazitäten zur Wahrnehmung der Doppelrolle verfügen. Ein Mitglied der Entwickler oder ein Product Owner kann als PM für kleine Teams fungieren.

Ein Projektmanager wird nicht selten beauftragt die Lücke zwischen dem Team und dem Auftraggeber auszufüllen oder Aktivitäten außerhalb des Teams zu organisieren und zu verwalten. Desweiteren werden sie häufig in agilen Teams benötigt, um Kommunikationspläne zu erstellen oder die Zusammenarbeit zwischen mehreren agilen Teams zu koordinieren.

Der Projektmanager muss immer bemüht sein, ein gleichwertiges Mitglied des Teams zu sein und andere Mitglieder bei der Erstellung von Plänen und anderen Tätigkeiten einzubinden. Auf diese Weise wird eine solide Basis für eine vertrauensvolle Zusammenarbeit und hohe Integrität des Teams geschaffen.

Jede Iteration beginnt mit intensiven Sitzungen gefolgt von ad-hoc-Interaktionen zwischen Teammitgliedern. Projektmanager können das Team bei der Selbstfindung unterstützen in dem sie es bei der Planung der Ziele einer Iteration konstruktiv beraten, so dass sie realistisch sind und auf Basis eines vertretbaren Durchsatzes eingestuft wurden. Die Übernahme der Leistungsüberwachung innerhalb und zwischen den Iterationen ist eine weitere Tätigkeit für Projektmanager, damit das Team mehr Zeit für die Abarbeitung des Product Backlog hat.

Die meisten agilen Ansätze definieren eine Rolle des Projektmanagers nicht explizit. In Scrum, beispielsweise, werden viele typtische Zuständigkeiten eines Projektmanagers auf den ScrumMaster und den Product Owner verteilt. Die Rollen innerhalb des Projektteams zu identifizieren und Verantwortlichkeiten zu definieren ist die wichtigste Aufgabe des Projektmanagers, insbesondere wenn er sich in ein bestehendes Team integrieren muss.

Neue Fähigkeiten für Projektmanager

Ein agiler Projektmanager muss viel mehr Führungsqualitäten aufweisen als in traditionellen Projekten. Seine Aufgabe ist es, die Kommunikation zwischen den Teammitgliedern zu fördern, die Motivation zu steigern, und organisatorische Hindernisse zu beseitigen, die einer erfolgreichen Projektabwicklung im Wege stehen könnten. Dazu gehört auch, das Team einfach Team sein zulassen, es autonom im eigenen Interesse entscheiden zu lassen. Neben diesen Soft Skills müssen Projektmanager den gesamten Prozess der Softwareentwicklung in einem neuen Licht betrachten.

Agilität erlaubt dem Projektmanager, sich von den ganzen vielen kleinen Details der Produktlösung wie beispielsweise Implementierungsdetails zu entfernen und sich auf Techniken wie rollierende Planung{zeitlich nahe Fakten sind deutlicher erkennbar als weit entfernte Fakten; die Planung kann somit nur über ein paar Wochen, höchstens zwei Monate erfolgen} und progressive Elaboration {Arbeitspakete werden im Laufe der Zeit immer weiter verfeinert, so dass wir bei der Planung von zunächst grob abgezeichneten Arbeitspaketen ausgehen} konzentrieren um Projektpläne zu definieren. Auf Seite des Auftraggebers führt das oft zu Irritationen, da sie in der Regel gewohnt sind, bereits zu Projektbeginn über alle Details, wie Kosten, Zeit und Umfang, vollständig informiert zu sein. Projektmanager müssen lernen wie progressive Elaboration Risiken minimieren und die Erfolgschancen eines Projekts steigern kann. Ein solides Verständnis über die agile Softwareentwicklung hilft Projektmanagern zu verstehen, wie agile Teams optimal organisiert, welche Fähigkeiten benötigt werden und welche Besonderheiten agile Teams auszeichnen.

Die Dynamik und kollaborative Entscheidungsfindung agiler Teams zu verstehen ist wichtig, den agiles Projektmanagement heißt sich selbstorganisierende Teams zu führen. Projektmanager nehmen hier in erster Linie die Rolle eines Dienstleisters und Mediatoren an und müssen in der Lage sein, das Team zu motivieren eigene Entschlüsse zu fassen. Mit diesen Fähigkeiten sind Projektmanager in der Lage, Anregungen aus dem Team und anderer Beteiligter zu akzeptieren und gleichzeitig das Bekenntnis zum Projekt zu steigern.

Traditionelle Projekte in neuem Gewand

Zwar ist der Übergang zu agilen Methoden nur selten einer Entscheidung des Projektmanagers zu verdanken, allerdings gibt es vieles was er beisteuern kann, um dem Unternehmen zu zeigen wie wertvoll agile Methoden sein können.

In traditionellen Projekten erstellt der Projektmanager einen Projektplan, der beschreibt, wie das Projekt abgewickelt wird. Oftmals geschieht das nach dem Vorbild des PMBOK (PMI Project Management Body of Knowledge) oder anderen PM-Frameworks. Auch wenn es sich bisher nicht so angehört hat, kann vieles in agilen Projekten anhand traditioneller Frameworks beschrieben werden. Diese Ansätze können oftmals in den Kontext einer traditionellen Projektplanung integrierte werden.

Oftmals sind Projektmanager mit der Aufgabe betraut, spezifische Aktivitäten während des Projektablaufs zu beobachten und zu beurteilen. Work Breakdowns, beispielsweise, sollen in der Regel auf Ergebnissen und nicht auf Aktivitäten beruhen. PMs können diese Breakdowns einfließen lassen in dem sie einfach die Features des Product Backlog berücksichtigen. Auf diese Weise können traditionelle Methoden zur Abschätzung beibehalten werden.

Desweiteren sind Gantt-Diagramme des traditionellen Projektmanager’s Liebling. Manche Organisationen setzen die Erstellung eines Gantt-Diagramms als Teil des Projektplans bereits vor Projektstart voraus. Iteratives Planen mit dem Projektteam hilft, den Projektplan mit dem Team zu synchronisieren. Die Erkenntnisse aus der Iteration können in den nächsten Planungsworkshop einfließen und den Projektplan weiter verfeinern.

Tägliche Projektmeetings sind in agilen und traditionellen Projekten gleichermaßen etabliert, besonders wenn Projekte mit außerordentlich hohem Risiko realisiert werden. Diese täglichen Prüfpunkte erhöhen die Sichtbarkeit zwischen Teammitgliedern und erlauben dem Projektmanagement einen Echtzeiteinblick in den Projektfortschritt. Diese Meetings können die Bindung im Team fördern und die Übernahme einer gemeinsamen Verantwortung für das Projekt bewirken.

Fazit

Die richtigen Produkte schneller auf den Markt zu bringen als die Konkurrenz ist kritischer als je zu vor. Traditionelle PM-Frameworks sind nicht flexibel genug, um mit sich ständig ändernden Rahmenbedingungen zu Recht zukommen. Die Agile Projektabwicklung erlaubt Teams Produkte auszuliefern, die innerhalb des Budgets und des Zeitrahmens liegen und die wichtigsten Features des Auftraggebers beinhalten.

Die Projektmanager können dabei eine Schlüsselrolle spielen. Allerdings müssen sie ihre Denkweise hinsichtlich der Zeit-, Kosten- und Ressourcenplanung ändern um mit Ungewissheit, Veränderungen und Risiken fertig zu werden. Sie müssen neue Fähigkeiten verinnerlichen und neue Ansätze zur Planung, Überwachung und zum Controlling von Projekten erlernen. Gut ausgebildete Projektmanager setzen den Rahmen für erfolgreiche Projekte und Teams liefern sie.