41 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 Ist die agile Projektmanagementmethode auch für Sie geeignet? Voraussetzungen für die agile Transformation Emadeldin Fawaz, Chris Krupke Für eilige Leser | In Deutschland stehen das agile Projektmanagement und die agile Transformation vor finanziellen und kulturellen Herausforderungen. Auf die wichtigsten Herausforderungen wird eingegangen und sinnvolle Lösungs- Szenarien werden diskutiert. Die Softwareanbieter befinden sich in einer paradoxen Situation: Einerseits müssen sie ihren Kunden ein Höchstmaß an Flexibilität und Akzeptanz für ständige Veränderungen bieten, andererseits müssen sie das Budget und ihre Gewinn- Marge unter Kontrolle halten. Agile Projektmanagement-Methoden werden auf dem deutschen Markt als DIE „one-size-fits-all“-Lösung präsentiert. Diese falsche Annahme wird diskutiert und ein allgemeiner Überblick über die Voraussetzungen für eine agile Transformation gegeben Schlagwörter | Agile Transformation, Agile, Agilität, IT-Projekt-Management, Software-Entwicklung Konventionelle Methoden des Projektmanagements basieren auf einer frühzeitigen Definition der Anforderungen, der Produktspezifikation und der Kostenabschätzung vor Projektbeginn. Die größte Herausforderung auf dem IT-Markt in den letzten Jahrzehnten ist jedoch, dass sich Anforderungen und Produktspezifikationen ständig ändern. Konventionelle Methoden des Projektmanagements sind dementsprechend nicht mehr effizient, um auf ein solches Maß an Unsicherheit zu reagieren. Ein IT-Lösungsanbieter ist verpflichtet, zwischen den sich ständig ändernden Kundenanforderungen auf einer Hand und den vertraglichen Vereinbarungen in Bezug auf Zeit und Budget auf der anderen Hand zu balancieren. Diese Situation erforderte eine neue Methode des Projektmanagements, die beidhändig ( Ambidextrous ) ist. Einerseits müssen wir auf die ständigen Änderungen der Kundenanforderungen schnell reagieren. Andererseits müssen wir dem Kunden einen Rahmen für das Erwartungsmanagement und, was noch wichtiger ist, für die Abrechnung und das Finanzmanagement des Projekts geben. Agile Projektmanagement-Methoden sind die Evolution des Projektmanagements. Der Clou der agilen Methoden liegt in ihrer Einfachheit. Die agile Methode basiert auf gesundem Menschenverstand und zielt genau darauf ab, unnötige Verschwendung von Ressourcen zu vermeiden. Agil, als Wort, bedeutet die Fähigkeit, sich schnell und leicht zu bewegen. Im Marketingkontext spiegelt Agilität die Fähigkeit wider, schnell auf veränderte Kundenanforderungen und Marktdynamik zu reagieren. Die IT-Branche verändert sich rasant. Was zu Beginn eines Softwareprojekts als State-ofthe-art gilt, kann zum Zeitpunkt der Produktauslieferung als veraltet gelten. Einige Branchen wie Medizin, Versorger und Energie sind stark reguliert. Es besteht ein ständiger Bedarf, auf die sich ändernden Anforderungen des Gesetzgebers zu reagieren, insbesondere in Bezug auf Informationssicherheit und Geschäftstransparenz. Geschäftsinhaber sind nun verpflichtet, sofort auf Regelmäßigkeitsstandards zu reagieren. Der Bedarf an Agilität in der Softwareindustrie ist auf seinem Höhepunkt. In der Softwarebranche ist Agilität ein Synonym für die Akzeptanz von Veränderungen ( Embracing Change ). Viele deutsche Unternehmen nutzen den Satz „Wir sind agil“ zur Markenbildung und um ihre Orientierung an der Kundenzufriedenheit zu demonstrieren. In der Praxis sind agile Methoden ein Rahmenwerk für kontinuierliche Entwicklung und kontinuierliche Lieferung. Agil zu werden ist jedoch nicht so einfach, wie es klingt. Viele Unternehmen tun sich schwer mit Wissen | Voraussetzungen für die agile Transformation 42 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 der agilen Transformation. Ein Teil dieses Kampfes ist auf die Unklarheit der Erwartungen zurückzuführen. Es ist sehr wichtig, ein solides Verständnis der agilen Philosophie zu haben, bevor man mit der agilen Transformation beginnt. Agilität erleichtert den „Change“, ist aber mit zusätzlichen Kosten verbunden. Wir sind eher an die „5-Sterne-Restaurant“-Mentalität gewöhnt, bei der „der Kunde immer Recht hat“. Der Lösungsanbieter agiert als Maître d'hôtel , der für die Kundenzufriedenheit verantwortlich ist. Diese Denkweise muss vollständig aufgegeben werden. Agiles Projektmanagement erfordert ein partnerschaftliches Verhältnis zwischen dem Kunden und dem Lösungsanbieter. Der Erfolg von agilem Projektmanagement hängt von der Fähigkeit aller Beteiligten ab, partnerschaftlich zusammenzuarbeiten und die Prinzipien des Agilen Manifests [1] zu beherzigen. In der agilen Produktentwicklung zahlen Sie genau für das, was Sie bekommen. Nehmen wir das Beispiel eines Restaurants. In den USA gibt es einige Restaurants, die es Ihnen erlauben, Ihre Bestellung zu ändern, nachdem Sie sie probiert haben. Allerdings sind solche in der Regel überteuert, weil sie das Risiko einkalkulieren, dass Sie nach der Auslieferung des Produkts eine Änderung verlangen könnten. Dieses Risiko wird Ihnen dann im Voraus in Rechnung gestellt. In iterativen agilen Umfeldern müssen Sie, als Kunde, sich darüber im Klaren sein, dass, wenn Sie Ihre Bestellung immer wieder ändern, Ihnen die bis dahin verschwendeten Zutaten in Rechnung gestellt werden. Wenn der Kunde nach einer Funktion gefragt hat, wird ihm die Entwicklung dieser Funktion in Rechnung gestellt. Wenn er es sich später anders überlegt und darum gebeten hat, sie zu ändern, wird sie ihm erneut in Rechnung gestellt. Jeder Anbieter wird aus einer pragmatischen Geschäftsperspektive dazu tendieren, alle Änderungen zu akzeptieren. Die harte Tatsache ist: Der Lösungsanbieter wird jedes Mal wirtschaftlich profitieren, wenn Sie eine Änderung anfordern, je mehr, desto besser. Jedes Mal, wenn die Business Unit eine Änderungsanforderung (A. K. A. Change Request) sendet, werden die Gesamtkosten des Produkts steigen. Dies belastet die Korrektheit Ihrer Budgetierung und die Fähigkeit des Lösungsanbieters, den Projektplan einzuhalten, enorm. Änderungen werden immer begrüßt und willkommen geheißen. Allerdings muss der Kunde den Unterschied zwischen dem, was er will, und dem, was er braucht, verstehen. Denn was man braucht, ist in der Regel fix. Aber was Sie wollen, kann sich im Laufe der Zeit ändern. Auf jede kleine Änderung zu reagieren, wird mit Kosten verbunden sein. Wenn Sie bereit sind, für das, was Sie wollen, zu bezahlen, wird Sie das zum besten Kunden aller Zeiten machen. Allerdings sollten Sie mit dem, was Sie sich wünschen, vorsichtig sein, denn Sie werden es bekommen. Der wichtigste Faktor für den Erfolg bei der Implementierung agiler Methoden ist, dass der Kunde verstehen muss, dass seine Rechte, Änderungen zu verlangen, zeitlich und wirtschaftlich begrenzt sind. Das Gleichgewicht zwischen Kosten und Flexibilität liegt in der Gesamtverantwortung des Kunden. Kostenvoranschlag, zwischen „ Push “ und „ Pull “ Im konventionellen Projektmanagement werden die Größe und die Bestandteile jedes Arbeitspakets vom Projektmanager festgelegt. Der Projektleiter erstellt verbindliche Kostenschätzungen. Abweichungen von den geschätzten Kosten müssen begründet werden. Die PRINCE2-Methodik empfiehlt, einen tolerierten Spielraum für Kostenabweichungen zu lassen. Da Kostenschätzungen verbindlich sein können, wird die Arbeit auf die Mitarbeiter geschoben ( Push Principal ). Das Push-Prinzip bedeutet, dass jeder Mitarbeiter (oder jedes Team) eine Liste von Aufgaben erhält, die innerhalb eines bestimmten Zeitfensters zu erledigen sind. Die Erfahrung des Projektleiters und sein Führungsstil spielen die entscheidende Rolle bei der Steuerung des Projekts und die Größe der Arbeitspakete. Bei agilem Vorgehen ist die Geschichte anders. Es gibt keinen Projektleiter. Die Verantwortung des Projektmanagements wird zwischen allen Beteiligten aufgeteilt, einschließlich dem Kunden selbst. Die agile Methodik basiert auf der Aufteilung des Projekts in kleine „ Timeboxen “. Timeboxing bedeutet, dass das Projekt in kleine Teilprojekte mit festen Zeitdauern für jedes von ihnen unterteilt wird. Vor dem Start jeder Timebox entscheidet der Kunde, welche Prioritäten gesetzt werden und was zuerst entwickelt werden soll. Am Ende jeder Timebox entscheidet der Kunde, ob er das Projekt auf eine weitere Timebox ausdehnt oder das Projekt mit dem beendet, was bis dahin geliefert wurde. Es ist hier wichtig zu verdeutlichen, dass der Kunde über die Prioritäten entscheidet, nicht aber über die Bestandteile der einzelnen Arbeitspakete pro Timbox. Es ist ein wichtiger Teil der agilen Methodik, das „ Pull-Prinzip “ zu implementieren, d. h., das Team entscheidet über die Größe der Arbeitspakete und deren Komponenten und wird dadurch ein selbstverwaltetes Team. Es wird empfohlen, das Team nicht unter Leistungsdruck zu setzen, da dies die Qualität beeinträchtigen könnte. Die Größe des Arbeitspakets entscheidet nur des Teams. Das Team sollte die Ressourcen, die es hat, analysieren, einschließlich der Anzahl der verfügbaren Personen während der Timebox und der Fähigkeiten jedes einzelnen von ihnen. Dann wählt das Team aus der priorisierten Liste ( Backlog ) die Items aus, die in das kommende Arbeitspaket aufgenommen ( Pulled ) werden. Die höher priorisierten Items sollten zuerst abgeholt werden. Das Team muss Änderungen in den Prioritäten, die vor dem Start jeder Timebox vorgenommen wurden, akzeptieren und seine Pläne entsprechend anpassen. Smart Teams sollten sich auf den aktiven Timebox konzentrieren, aber gleichzeitig im Blick haben, was in den kommenden Timeboxen enthalten sein könnte. Wichtig ist hier zu betonen, dass der Kunde das Recht hat, die Items und deren Prioritäten zu ändern, aber nur VOR dem Start der Timebox. Nach dem Start der Timebox kann der Kunde die Prioritäten der kommenden Timeboxen ändern, nicht aber die aktive Timebox. In katastrophalen oder schwerwiegenden Fällen kann der Kunde die aktive Timebox vorzeitig beenden ( premature Termination ) und die bis dahin entstandenen Kosten tragen. Natürlich hat der Kunde das Recht, figurative Einschätzungen darüber zu machen, wann das Endziel erreicht werden „könnte“ und zu welchen „erwarteten“ Kosten. Die Hochrechnungen und Einschätzungen des Kunden sind für das Team keineswegs verpflichtend und könnten sogar zu Kon- Wissen | Voraussetzungen für die agile Transformation 43 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 flikten / Druck führen, wenn sie mit dem Team geteilt werden. Viele Kunden haben versucht, die Methodik zu überlisten und nach statistischen Korrelationen zu suchen, die die Kosten mit vielen KPIs verknüpfen, wie z. B.: Anzahl der Codezeilen pro Euro, Anzahl der Story Points pro Euro, Anzahl der Merges oder Commits pro Timebox-… etc. So funktioniert es aber einfach nicht. Agile Methoden beruhen auf gegenseitigem Vertrauen zwischen Anbieter und Kunde. Auf der einen Seite ist der Kunde verpflichtet, das Budget jeder Timebox fast als Blackbox zu akzeptieren. Auf der anderen Seite riskiert der Lieferant möglicherweise seine Gewinnmarge, um die strategische Beziehung zu einem wertvollen Kunden aufrechtzuerhalten. Dieses Paradoxon hängt hauptsächlich von der „ Bargaining Power “ der einzelnen Stakeholder ab. Wie die Amerikaner sagen: „ take it or leave it „. Erst Vertrauen verdienen, dann agile Transformation Die agile Projektmanagementmethode ermöglicht den Mitarbeitern, selbst zu entscheiden, welche Quantität sie zu einem bestimmten Zeitpunkt abliefern werden, solange sie sich an den ihnen klar kommunizierten Qualitätsstandard halten werden. Agilität basiert auf Selbstdisziplin. Wenn es im Team keine Selbstdisziplin gibt, kann die ganze Methode nicht funktionieren. Obwohl die Agilität Flexibilität mit sich bringt, gibt es keinen Kompromiss zwischen Flexibilität und Verbindlichkeit ( Commitment ). Zu Beginn muss sich das Team für das Commitment entscheiden, dann wird ihm die Flexibilität ermöglicht, die es innerhalb der Grenzen des eingegangenen Commitments braucht. Wenn das Team sich weigert, ein Commitment zu geben, weckt dies Zweifel an der Zuverlässigkeit des Teams und dementsprechend am Vertrauen in das Team. Das Team entscheidet über den Umfang der Verpflichtung. Commitments sollten zuerst gemacht werden. Dann folgt die Flexibilität. Was bedeutet das für Sie als Manager, Chief Officer oder Coach? Wenn Sie mit einem Team arbeiten, das sich das Vertrauen seiner Vorgesetzten „noch“ nicht verdient hat, dann müssen Sie die agile Transformation verschieben, bis sich dieses Team das Vertrauen verdient hat. Andernfalls begeben Sie sich in einen Kreislauf aus Misstrauen und Verhaltensweisen, die Ihre Bemühungen für eine agile Transformation vollständig gefährden werden. Die Methode wird einfach nicht funktionieren, wenn die Führungskräfte ihren Teams nicht vertrauen. Wie kann ich also messen, ob das Team überhaupt Vertrauen genießt? Nun… Organisationen, die ein hohes Maß an Mikromanagement aufweisen, vertrauen ihren Mitarbeitern noch nicht so sehr. Das Ausmaß des Mikromanagements in Ihrer Organisation wird Ihnen dies deutlich machen. Das ist die nackte Wahrheit, egal was die Unternehmen auf ihrer Website schreiben. Sie dürfen sich nicht von der Spitze des Eisbergs in die Irre führen lassen (Abbildung 1). Eine Fehlerkultur ist jedoch ein weiteres Zeichen dafür, dass den Mitarbeitern vertraut wird. Fehlerkultur ist im Allgemeinen ein wichtiger Erfolgsfaktor für jedes innovative Unternehmen [2]. Fehlende Fehlerkultur zeigt, dass man nicht bereit für Agilität ist. In Agile sollten Sie progressiv planen und „intelligent“ steuern (Smart Control) Es gibt die Vorstellung, dass agiles Management eine Art Laissez faire ist. Manche Mitarbeiter glauben, dass agile Methoden ihnen die absolute Entscheidungsfreiheit geben. Diese Vorstellung ist nicht korrekt. In a Nutshell : Agile Projektmanagement-Methoden wurden entwickelt, um Dilberts Welt zu vermeiden und zu verhindern. Eines der Paradoxa von Dilbert war, dass er früher viel Zeit mit Projektplanung und Risikomanagement verschwendet hat- - einschließlich der Vorhersage von Unvorhersehbarem ( predicting the unpredictable ). Oftmals war der Zeitaufwand für die Planung größer als die Zeit für die Entwicklung des eigentlichen Produkts. Agile Me- Abbildung 1: Kulturebenen-Modell nach Edgar Schein Wissen | Voraussetzungen für die agile Transformation 44 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 thoden versuchten, die Auswirkungen dieses Problems durch den Einsatz von Timeboxen- - bis zu vier Wochen lang- - einzuschränken. Solche kleinen Time-Boxen können mit mehr besseren prognostizierten Risiken und weniger Unsicherheiten geplant werden. Der Aufwand für das Risikomanagement wird reduziert. Agile Best Practices besagen, dass die Zeit, die für die Planung jedes Teilprojekts (Timebox) aufgewendet wird, im Verhältnis zur Länge des Teilprojekts selbst stehen sollte. Es wurde geschätzt, dass eine Stunde Planung für jede Projektwoche angemessen ist. Wir müssen uns der Tatsache stellen, dass Innovation und Problemlösung Zeit kosten. Es ist eine Best Practice im Projektmanagement im Allgemeinen, etwas Luft für Toleranz zu veranschlagen. Es wird jedoch empfohlen, dass das Team eine Vision darüber aufbaut, was als Nächstes kommt. Ungerechtfertigte Überwachung, Mikromanagement und Überkontrolle waren Teil von Dilberts Welt. Dilbert musste täglich so detailliert seine Tätigkeiten beschreiben, dass er keine Zeit hatte, tatsächlich einen Mehrwert für das Produkt zu schaffen. Agilität ist nicht nur eine Methodik, die ausschließlich auf Kosteneinsparungen abzielt, sondern berücksichtigt auch die Psychologie der Menschen. Agile Methoden wurden entwickelt, um ungerechtfertigten Druck auf die Mitarbeiter zu vermeiden. Das Befolgen der Agilen Methoden reduziert das Risiko von Burnouts und Arbeitserschöpfung [3]. Übermäßige Kontrolle wird die Innovationsfähigkeit der Mitarbeiter einschränken. Wir erwarten nicht, dass alle Entwickler einen Teil ihrer Zeit für die Berichterstattung über Aktivitäten und Fortschritte verschwenden. Dies ist auch keine Lean Best Practice. Es wurden spezielle Rollen geschaffen, um benötigte Berichte zu erstellen, wie z. B. der Scrum Master. Es gibt viele agile Toolkits, die nicht-invasive automatisierte Berichtsmechanismen bereitstellen. Leistung und Fortschritt werden automatisch berichtet, ohne dass die Entwickler Zeit für die Erstellung verschwenden müssen. Es werden automatisch generierte, standardisierte Diagramme entwickelt, um Leistung und Fortschritt zu kommunizieren. Es gibt viele agile Tools, die den Fortschritt melden und Aktivitäten und Leistung überwachen, z. B. JIRA Software. Agile und moderne Methoden im Projektmanagement bevorzugen visuelles Reporting. Eine Grafik ist besser als 1000 Worte und spart Zeit und Energie bei der Interpretation. Zum Beispiel können Burn-down- oder Burn-up-Diagramme den Fortschritt auf einen Blick vermitteln. Es gibt eine weit verbreitete Vorstellung unter Entwicklern, dass ein Genie in einer isolierten Umgebung, frei von Hindernissen, arbeiten muss, um eine wertvolle kreative Arbeit abzuliefern. Aus diesem Grund haben einige agile Frameworks, wie z. B. Scrum, neue Positionen erfunden, wie z. B. den Scrum Master. Die Aufgabe des Scrum Masters ist es, das Senior Management mit Fortschrittsberichten zu versorgen. Der Scrum Master ist auch dafür verantwortlich, sich um alle Hindernisse im Unternehmen zu kümmern, die eine reibungslose Arbeit des Teams verzögern oder verhindern könnten. Wem gehört das Produkt: Product Owner vs. Business Owner? Die „Agile Alliance“ zielte im Wesentlichen darauf ab, ein Projektmanagement-Framework zu schaffen, das eine angemessene Kommunikation zwischen dem Kunden und den Entwicklern gewährleistet [4]. Ingenieure oder Softwareentwickler, die die Fähigkeit haben, mit dem Kunden an der Front zu arbeiten, sind sehr selten. Leider ist die Mehrheit der Entwickler nicht auf eine Rolle mit Kundenkontakt vorbereitet und möchte diese eigentlich auch gar nicht ausüben. Persönlichkeitsstudien haben gezeigt, dass Ingenieure im Allgemeinen dazu neigen, sich mehr mit ihrem Beruf zu identifizieren. Ingenieure halten sich in der Regel für Genies und neigen dazu, selbstbewusst zu sein und sich gegen die Zusammenarbeit mit anderen zu wehren, insbesondere mit Nicht-Ingenieuren [5]. Daher müssen wir jemanden mit einer bestimmten Denkweise finden, der dem Kunden gegenübersteht. Kleine und mittelständische Unternehmer, vor allem im Silicon Valley, suchten nach Leuten, die das Geschäft erst wachsen lassen können. In den meisten Stellenausschreibungen war zu lesen, dass der Arbeitgeber nach Leuten sucht, die „Ownership“ übernehmen können, d. h. Leute, die sich im Namen des Arbeitgebers so verhalten können, als ob sie Eigentümer davon wären. Aus dieser Kultur im Hintergrund ist der Name „Product Owner“ entstanden. Der Product Owner ist nicht derjenige, dem das Produkt gehört. Der Product Owner arbeitet für den Dienstleister und seine Aufgabe ist es, dafür zu sorgen, dass das Geschäft reibungslos und profitabel läuft. Der Product Owner ist dafür verantwortlich, dass das gelieferte Produkt der Kundenzufriedenheit entspricht. Er ist der Eigentümer des Kundenzufriedenheitsprozesses. Um als Product Owner erfolgreich zu sein, müssen Sie sich dementsprechend so verhalten, „als ob“ Sie der Eigentümer des Produkts ( the owner of the Product ) sind. Der eigentliche Eigentümer des Produkts wird als „Business Owner“ oder einfach als „The Customer“ oder „Auftraggeber“ bezeichnet. Die Rolle des Product Owners besteht hauptsächlich darin, eine häufige und offene Kommunikation mit dem Kunden zu pflegen, um die Prioritäten zu setzen. Die Prioritäten müssen klar und objektiv gemessen werden Die agilen Toolkits enthalten Methoden zum Abwägen der Kompromisse zwischen dem, was wir brauchen, und dem, was wir wollen. Wir müssen zwischen Bedürfnissen und Wünschen unterscheiden, um die Beurteilung der Prioritäten vornehmen zu können. Bedürfnisse sollten definitiv an erster Stelle stehen. Im Allgemeinen sind die Kunden bereit, für Einfachheit und Eleganz einen Aufpreis zu zahlen. Jede zusätzliche Funktion bringt Ihrem Kunden bis zu einer bestimmten Grenze einen Mehrwert. Nach diesem Schwellenwert bringt jede hinzugefügte Funktion möglicherweise überhaupt keinen Mehrwert mehr und kann sogar die Risiken erhöhen. Die Entwicklung einer Funktion, die möglicherweise überhaupt nicht genutzt wird, ist schlichtweg eine Verschwendung von Ressourcen und kann sogar zu einer zunehmenden Produktkomplexität, Benutzerfrustration und mehr Anrufen bei Kundendienstzentren führen. Das beste Produkt könnte das einfachste Produkt sein, das zuverlässig alle benötigten Funktionen bereitstellt und vom Endbenutzer häufig verwendet wird. Das Kano-Modell [6] ist eine bekannte Technik, die Kriterien und Methoden zur Verfügung stellt, um zu ermitteln, welche Funktionen in Bezug auf die Zufriedenheit der Endbenutzer entwickelt und welche ignoriert werden sollten. Wissen | Voraussetzungen für die agile Transformation 45 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 Es besteht eine lineare Beziehung zwischen der Anzahl der Funktionen und den Gesamtkosten des Produkts. Kano hat jedoch speziell dargestellt, dass die Beziehung zwischen der Anzahl der Funktionen und der Kundenbeziehung mehr oder weniger glockenförmig ist (Abbildung 2). Ein erfahrener Product Owner wird sich nur an den Erwartungen der Kunden und dem Mehrwert für den Endbenutzer orientieren. Ein guter Product Owner arbeitet mit dem Team und den Kunden zusammen und ist bereit, ihm bei Bedarf Erklärungen zu geben. Seine / ihre Aufgabe ist es, die User Stories zu schreiben und dafür zu sorgen, dass die Bedürfnisse der Kunden angemessen dokumentiert und an das Team gut kommuniziert werden. Kurz gesagt: Der Product Owner vertritt das Team nach außen vor dem Kunden und der Scrum Master vertritt das Team nach innen vor der Unternehmensführung. Zusammenfassung: Agil ist nicht für jeden Kontext geeignet Dies ist das wichtigste „Muss Wissen über Agilität“. Agilität ist kein „Plug and Play“-Tool. Es ist auch kein „one-size-fits-all“. Die Agile Alliance hat vier wichtige Werte definiert, die sich in 12 agilen Leitprinzipien widerspiegeln [1 & 4]. Das agile Manifest hat die Leitprinzipien über die agile Methode dargestellt. Es zeigte implizit auch die Voraussetzungen für den Erfolg der agilen Transformation auf. Die agile Transformation ist im Grunde genommen ein Veränderungsprojekt. Der Erfolg in der agilen Umsetzung wird durch feste kulturelle Voraussetzungen umschrieben. Bevor mit der agilen Transformation begonnen wird, muss eine gründliche Analyse über die Kultur und die Bereitschaft zur Veränderung durchgeführt werden. In einem ersten Schritt ist es wichtig zu beachten, dass Agilität von selbstmotivierten Menschen und für selbstmotivierte Entwickler entwickelt wurde. Dies geht aus dem 5. und 11. agilen Prinzip klar hervor. Ausgehend von den Erfahrungen im deutschen Markt beginnen viele Unternehmen die agile Transformation, indem sie externe Coaches einladen, die den Mitarbeitern Zeitmanagement, Priorisierungsmethode und Time-Boxing beibringen. Die meisten agilen Coaches, wenn nicht sogar alle, konzentrieren sich in der Praxis darauf, Selbstmanagement und das Einschätzen der Team-Velocity zu lehren. Das mag zwar nicht verkehrt sein. Wenn Sie jedoch selbstmotivierten Menschen beibringen, wie sie ihre Zeit managen können, werden Sie bei einer besseren Produktivität landen. Wenn Sie selbstmotivierten Menschen beibringen, wie sie ihren Fortschritt einschätzen können, werden Sie bei einem besseren Management landen. Aber es könnte riskant sein, weniger motivierte Menschen zu befähigen, sich selbst zu managen. Die Produktivität an sich wird auf diese Weise vielleicht nicht verbessert. Tatsächlich wird das Pull-Prinzip, das der praktische Grundstein für den Erfolg der agilen Methodik ist, überhaupt nicht funktionieren, wenn die Leute nicht von vornherein hochgradig selbstmotiviert an ihre Arbeit gehen. Das Pull-Prinzip geht davon aus, dass sich jeder Einzelne von sich aus eine neue Aufgabe suchen sollte, wenn die aktuelle Aufgabe zufriedenstellend erledigt wurde. Ein solches Verhalten kann man nur von einem hoch selbstmotivierten Individuum erwarten. Wenn die Leute weniger selbstmotiviert sind, werden sie immer jemanden brauchen, der sie antreibt, sich eine neue Aufgabe zu suchen. In vielen Organisationen wurden der Scrum Master oder der Product Owner mit dieser Aufgabe betraut, was keine agile Best Practice ist. Wenn Ihre Mitarbeiter nicht selbstmotiviert sind, dann ist es wichtiger, in die Steigerung ihres organisatorischen Bürgerverhaltens ( Organisational Citizenship Behaviour ) zu investieren, bevor eine agile Transformation überhaupt in Betracht gezogen wird. Auch die Eigenmotivation ist eine ganz entscheidende Grundlage für Vertrauen. Eine pragmatische Tatsache ist: Führungskräfte werden keine Mitarbeiter befähigen, denen sie nicht von vornherein vertrauen. Yukl und Mahsud [7] illustrierten, dass die Beziehung zwischen den Mitarbeitern und ihren Führungskräften in Phasen verläuft. Am Anfang ist die Führungskraft neu im Team. Sie kennen sich noch nicht. Es gibt noch keine Basis, um Vertrauen und Empowerment aufzubauen. Um Vertrauen in die Leistung und die Qualität der gelieferten Arbeit aufzubauen, wird die Führungskraft in dieser Phase zu Mikromanagement und stärkerer Kontrolle nei- Abbildung 2: Kano-Modell für die Abhängigkeiten zwischen der Erfüllung der Kundenanforderungen und Kundenzufriedenheit. Wissen | Voraussetzungen für die agile Transformation 46 PROJEKTMANAGEMENT AKTUELL · 33. Jahrgang · 02/ 2022 DOI 10.24053/ PM-2022-0035 gen. Mit der Zeit werden die Mitarbeiter Vertrauen gewinnen und zu mehr Empowerment und Selbstmanagement befähigt werden. Agile Methoden wurden für eine reife Leiter-Team-Beziehung entwickelt. Dennoch ist die Beziehung zwischen Vertrauen und Selbstmotivation mehrdimensional. Auf der einen Seite ist es hier wichtig zu beachten, dass Verhaltensweisen wie Vertrauen und Selbstbefähigung von der Spitze der Organisation nach unten gehen (top-down). Das heißt, das obere Management muss dem mittleren Management vertrauen, damit das mittlere Management den Teamleitern vertrauen kann und so weiter und so fort. Von der anderen Seite, wenn die Mitarbeiter nicht selbst motiviert sind, wird man ihnen nicht zutrauen, Selbstmanagement zu praktizieren, und sie können keine Befähigung erhalten. Das geht von unten nach oben. Bevor mit der agilen Transformation begonnen wird, müssen Faktoren bewertet werden, die sich auf das Vertrauen auswirken können, wie z. B. das Verhalten der Mitarbeiter in der Organisation, die wahrgenommene Gerechtigkeit in der Organisation und/ oder die Zufriedenheit der Mitarbeiter. Das Fehlen solcher kulturellen Voraussetzungen könnte die agile Transformation gefährden. Wenn solche kulturellen Voraussetzungen nicht vorhanden sind, ist die Organisationskultur noch nicht bereit für die agile Transformation. Ein erfahrener Change Manager wird hier von großem Wert sein. Denn bevor man sich in die agile See stürzt, muss man zunächst die kulturelle Bereitschaft für die agile Transformation bewerten und einen Plan für das Kulturmanagement haben. Kommunikationsqualität und ein guter Plan für das Kommunikationsmanagement sind Voraussetzungen für die agile Transformation. Dies ist in den 4., 6. und 8. agilen Prinzipien enthalten. Kommunikation bedeutet an dieser Stelle die Verfügbarkeit einer Informationsquelle, wann immer sie benötigt wird. Der Kunde sollte für den Product Owner erreichbar sein und der Product Owner sollte für die Teammitglieder erreichbar sein. Der Product Owner wird nicht in der Lage sein, effizient zu arbeiten, wenn es keinen offenen Kommunikationskanal mit dem Kunden gibt. Es wird nicht erwartet, dass der Kunde 24 / 7 verfügbar ist. Ein guter, offener und zuverlässiger Kommunikationsplan ist jedoch entscheidend. Wenn es ein Problem in der Kommunikation gibt, kann die ganze Methode nicht funktionieren. Es gibt viele Modelle für Kommunikationspläne. Sie müssen das Modell auswählen oder erstellen, das am besten zu Ihnen passt. Danksagung Die Autoren möchten sich bei dem Energie- und Utilitiesmanagement Team der SD&C GmbH für die wertvollen Kommentare und konstruktiven Hinweise bedanken. Ein besonderer ausdrücklicher Dank geht an Maire Krüger und Christoph Gröbler für ihre wertvolle Unterstützung. Literatur [1] Manifesto for Agile Software Development. Available from: https: / / agilemanifesto.org/ . Abrufdatum: 14. 09. 2021 [2] Angst, Robert; Kemmer, Ralf. Fehlerkultur als Erfolgsfaktor im Projektmanagement. PROJEKTMANAGEMENT AKTUELL. September 2020, Issue 6, pp 10-14. DOI: 10.2357 / PM-2020-0087 [3] Venkatesh, V., Thong, J. Y., Chan, F. K., Hoehle, H. and Spohrer, K., 2020. How agile software development methods reduce work exhaustion: Insights on role perceptions and organizational skills. Information Systems Journal, 30(4), pp.733-761 [4] Principles behind the Agile Manifesto. Available from: https: / / agilemanifesto.org / principles.html. Abrufdatum: 14. 09. 2021 [5] Robledo, I. C., Peterson, D. R., & Mumford, M. D. (2012). Leadership of scientists and engineers: A three-vector model. Journal of organisational Behavior, 33(1), 140-147 [6] Kano, N., Seraku, N., Takahashi, F. and Tsuji, S. (1984) Attractive Quality and Must-Be Quality. Journal of the Japanese Society for Quality Control, 41, 39-48 [7] Yukl, G., & Mahsud, R. (2010). Why flexible and adaptive leadership is essential. Consulting Psychology Journal: Practice and Research, 62(2), 81 Eingangsabbildung: © Darkdiamond67/ Shutterstock.com Dr. rer. pol. Emadeldin Fawaz Emad hat seine Promotion (Dr. rer. pol.) an der Universität Potsdam unter der Supervision von Prof. Dr. Eric Kearney (Thema: Leadership und Organisationskultur) abgeschlossen. Er verfügt auch über einen MBA von der Purdue University, USA. Er hat für die US NAVY für mehr als zehn Jahren gearbeitet. Er erhielt die Stellen als Principal Investigator und Senior international Project Manager. Er ist in dem deutschen Markt mit dem Thema Agile Transformation (als Coach und Projektmanager) seit mehr als fünf Jahren vertraut. ORCID-ID: 0000-0001-9317 - 1201 Chris Krupke Mit dem Management agiler Projekte beschäftigt sich Chris Krupke seit 2013, unter anderem mit der am längsten etablierten agilen Methodik DSDM Attern des Agile Business Consortium und im weiteren Verlauf dann auch mit der SCRUM-Methode. In seinem Werdegang hat er die verschiedenen agilen Projektrollen übernommen und kennt damit die verschiedenen Sichtweisen der Beteiligten. Daneben ist er auch mit der klassischen Projektmanagementwelt vertraut und entsprechend zertifiziert. Im Projektgeschäft steht der den Kunden und Partnern inzwischen auch als Coach zur Seite.