Was ist agiles Programmmanagement?

Flexibles Programmmanagement ist ein Ansatz für die Verwaltung mehrerer zusammenhängender Projekte (ein Programm), der auf flexiblen Prinzipien wie Flexibilität, Zusammenarbeit, iterativer Entwicklung, Priorisierung von Kunden-Feedback und kontinuierlicher Verbesserung beruht.

Agilität ist eine Philosophie mit einer Reihe von Prinzipien und nicht mit einer bestimmten Methodik. Es gibt jedoch etablierte agile Methoden, die oft Teil des flexiblen Programmmanagements sind, darunter Scrum, Extreme Programming (XP) und Kanban. Flexibles Programmmanagement wurde ursprünglich von und für die Softwarebranche entwickelt, um Kunden schneller einen größeren Mehrwert zu bieten. Mittlerweile gibt es aber auch Anwendungen, die andere Branchen miteinbeziehen.

Agiles Programmmanagement umfasst in der Regel mehrere verwandte Projekte. Einzelne Projekte können mit einem agilen Framework verwaltet werden, aber agiles Programmmanagement integriert eine Reihe von Projekten während des gesamten Lebenszyklus in ein einziges zusammenhängendes Ganzes. Auf einer höheren Ebene könnten eine Reihe von Programmen und zugrundeliegenden Projekten im Rahmen einer umfassenderen Portfoliomanagementstrategie organisiert werden.

Agiles Projektmanagement konzentriert sich auf ein bestimmtes Projekt und die Verwaltung von Zielen, Zeitplänen, Ressourcen und Teams, die mit diesem einen Projekt verbunden sind. Agiles Programmmanagement überwacht eine Gruppe verwandter Projekte und die Strategie, die diese Projekte mit umfassenderen Unternehmenszielen zusammenführt. Diese beiden Disziplinen teilen viele der gleichen Funktionen, unterscheiden sich jedoch in ihrem Umfang, wobei agile Programmmanager eine umfassendere Rolle etwa bei der Programmstrategie, beim Risikomanagement und bei der Stakeholderkommunikation spielen.

Vereinfacht kann man sagen, dass sich das Projektmanagement eher mit der taktischen und zeitgerechten Durchführung eines einzelnen Projekts befasst. Das Programmmanagement hingegen verfolgt einen strategischeren Ansatz, um den umfassenden Erfolg der einzelnen Projekte im Zuständigkeitsbereich des Programms zu koordinieren.

Projektmanagement als Disziplin begann in den 1950er Jahren in den Vereinigten Staaten Gestalt anzunehmen. In den 1990er Jahren wurde eine Gruppe von Methoden, die als „Wasserfall“ bezeichnet werden, formalisiert, bei denen jede Phase eines Projekts abgeschlossen werden muss, bevor das gesamte Team zur nächsten Phase übergeht. Doch als Software immer leistungsfähiger und komplexer wurde, erwiesen sich das traditionelle Projektmanagement und die Wasserfallmethoden als umständlich und als nicht ideal für Projekte, die schnell voranschreiten und häufigen Änderungen unterliegen.

Im Jahr 2001 erstellte eine Gruppe von Softwareentwicklern das agile Manifest für flexibles Projektmanagement, das vier Schlüsselwerte und zwölf Prinzipien umfasst. Die Schlüsselwerte sind:

• Individuen und Interaktionen über Prozesse und Tools
  
  
• Funktionierende Software vor umfassender Dokumentation
  
  
• Zusammenarbeit mit Kunden vor Vertragsverhandlungen
  
  
• Reagieren auf Veränderungen vor Befolgen eines Plans

Die bevorzugten Werte bedeuten nicht den Verzicht auf die nicht bevorzugten Werte. Die agile Philosophie verbietet nicht etwa die Anwendung eines Plans, sondern legt mehr Wert darauf, auf unvermeidliche Veränderungen zu reagieren und sich darauf vorzubereiten.

Diese agilen Prinzipien erfreuen sich im Softwareentwicklungsprozess zunehmender Beliebtheit, doch die Philosophie geht weit über die agile Softwareentwicklung hinaus. Agile Prinzipien werden heute in vielen verschiedenen Branchen eingesetzt, von der Mode über die Biotechnologie bis hin zur Regierung.

Was den agilen Ansatz von früheren Methoden wie dem Wasserfallmodell unterscheidet, ist, dass agile Methoden von Anfang an so konzipiert sind, dass sie iterativ, kooperativ und flexibel sind. In einem agilen Programmmanagementsystem werden Projekte schnell erstellt und regelmäßig überprüft, besprochen und als Reaktion auf die Reaktion des Teams oder Kunden geändert. Es wird von Anfang an davon ausgegangen, dass sich Pläne und Herangehensweisen ändern und dass nicht um jeden Preis am ursprünglichen Plan festgehalten werden kann. Einzelne Teammitglieder haben die Möglichkeit, sich zu äußern, ohne eine so strenge Hierarchie wie bei anderen Ansätzen.

Da agiles Programmmanagement eher eine Philosophie als eine konkrete Methodik ist, können die Einzelheiten agiler Praktiken von Unternehmen zu Unternehmen oder von Programm zu Programm erheblich variieren. Es gibt jedoch einige Aspekte, die im agilen Programmmanagement häufig zu finden sind.

Flexibles Programmmanagement umfasst mehrere einzelne Projekte; dass sowohl das gesamte als auch jedes einzelne Projekt in einem flexiblen Framework organisiert werden kann. Flexibles Programmmanagement umfasst eine ganzheitliche, übergreifende Sicht auf eine Gruppe von Projekten. Dazu gehören oft Elemente, die es bei der Verwaltung einzelner Projekte nicht gibt, wie z. B. Budgetierung, Gesamtstrategie und langfristige Analyse.

Schnell auf Veränderungen zu reagieren ist ein zentraler Grundsatz der flexiblen Philosophie. Daher nutzt das flexible Programmmanagement den Wandel als Gelegenheit, den Kurs anzupassen und Verbesserungen vorzunehmen, die dem Kunden einen Mehrwert bieten. Wenn Projekte für den Abschluss in kleinere Abschnitte unterteilt werden, können Unternehmen flexibler sein und schneller reagieren

Ein Schlüsselaspekt des agilen Programmmanagements liegt in seinem iterativen Ansatz. Einzelne Projekte innerhalb des Programms durchlaufen mehrere Versionen, wobei die Produktentwicklungsteams die Ergebnisse jedes Mal diskutieren und verbessern. Es ist wichtig, kontinuierlich funktionierende Ergebnisse zu liefern, sei es ein ganzes Projekt oder ein einzelner Aspekt. Es ist außerdem wichtig, das Produkt mit jeder Iteration auf der Grundlage von Feedback, KPI und sich ändernden Anforderungen zu optimieren.

Bei der Priorisierung von agilem Vorgehen steht das persönliche Gespräch im Vordergrund der langwierigen E-Mail- oder anderen textbasierten Kommunikation. Während ein E-Mail-Thread aufgrund von Zeitbeschränkungen oder verpassten E-Mails Stunden, Tage oder sogar Wochen dauern kann, kann eine persönliche Kommunikation dieselbe Aufgabe in wenigen Minuten erledigen.

Agiles Programmmanagement, als übergreifende Sicht auf ein Programm, muss den Fokus auf Effizienz und die Entfernung unnötiger oder umständlicher Elemente legen. Dokumentation ist ein Mittel zum Zweck, nicht der Zweck selbst, und sollte nur das enthalten, was notwendig ist.

Ehrlichkeit und Offenheit sind der Schlüssel zu einem erfolgreichen agilen Programm. Gespräche sollten es allen Teammitgliedern ermöglichen, ihre Meinung zu äußern. Bei diesem Managementansatz zählt die Stimme jedes Einzelnen und wird gehört.

Gleichzeitig muss es akzeptabel sein, undurchführbare Ideen herauszufiltern, ohne dass sich der Vorläufer dieser Idee entmutigt fühlt, sich in Zukunft zu äußern. Der Erfolg von „Retrospektiven“ (oder „Retros“, also Bewertungen nach dem Projekt, bei denen Feedback eingeholt wird), hängt auch von der Transparenz des Teams ab.

Agiles Programmmanagement als Philosophie erfordert kein bestimmtes Framework. Aber viele Projektmanagement-Frameworks, darunter Scrum und Kanban, sind eng mit der flexiblen Philosophie verbunden. Hier sind einige der beliebtesten Frameworks.

Scrum ist ein Framework für die gemeinsame Arbeit an Teamprojekten. Der Name, obwohl er wie einem Akronym wirkt, stammt in Wirklichkeit aus dem Rugby-Sport und bezeichnet eine Situation, bei der die Spieler die Arme ineinander verhaken, um sich gemeinsam gegen ihre Gegner zu drücken. Es ist eine Art Kavallerieangriff ohne Pferde.

Im flexiblen Kontext umfasst ein Scrum-Team drei Rollen:

• Projektmanager: Er ist das Bindeglied zwischen dem Scrum-Team und den Stakeholdern, wobei es sich um Benutzer, Kunden oder eine Muttergesellschaft handeln kann. Der Projektmanager ist dafür verantwortlich, externe Faktoren wie Budget, Personal und Feedback an das Scrum-Team zu kommunizieren sowie die Stakeholder über den Fortschritt des Teams zu informieren.
  
  
• Scrum Master: Der Scrum Master ist weniger ein traditioneller „Boss“ als vielmehr ein Lehrer der Scrum-Methode, ein Dirigent, der für Anleitung, Kommunikation und Problemlösung sorgt. Scrum Master sind normalerweise nicht für die Einstellung und Entlassung von Mitarbeitern zuständig.
  
  
• Entwickler oder Teammitglieder: Dieser Begriff kann abweichen, wenn es sich um ein Scrum-Team außerhalb der Softwarebranche handelt. Unabhängig davon, ob diese Rolle als Entwickler, Teammitglied oder Mitarbeiter bezeichnet wird, gibt es hier keine Hierarchie. Idealerweise ist das Team zwischen drei und neun Mitgliedern groß – größere Gruppen sind für einen Scrum Master schwieriger zu führen. Teams können sich auch selbst organisieren, wobei Einzelpersonen entscheiden, wen und was das Team für den Erfolg benötigt, ohne viel Planung durch das Management.

Scrum hat ein paar spezifische Konzepte, die es von anderen teambasierten Organisationsmodellen unterscheiden. Das Product Backlog ist eine Sammlung aller Aufgaben, Ideen, Anforderungen, Ergebnisse und Ressourcen, die das Team während des Scrums benötigen könnte. Sie kann (und sollte) vom Team ständig aktualisiert und überwacht werden, um ihre Effizienz und Vollständigkeit zu gewährleisten.

Bei einem Scrum wird die Arbeit in Sprints aufgeteilt, die normalerweise zwischen einer und vier Wochen dauern. Im Sprint arbeiten die Teammitglieder daran, ein bestimmtes Ziel zu erreichen. Dieses Ziel kann ein Arbeitsmodell, ein Mockup, ein Prototyp oder auch nur eine Funktion oder ein Element des fertigen Produkts oder der fertigen Lösung sein.

Während des Sprints treffen sich die Teammitglieder einmal pro Tag in einem „Daily Scrum“ oder „Stand-up“. Diese Meetings finden gemäß den Scrum-Prinzipien auf äußerst hohem Niveau statt. Beim Daily Scrum, das nicht länger als 15 Minuten dauert, teilen die Teammitglieder kurz und mit möglichst wenigen Details ihren Fortschritt und erklären, welche Hindernisse ihre Arbeit beeinträchtigen. Manchmal finden sich einzelne Teammitglieder nach dem Daily Scrum in einem separaten Meeting zusammen, um die im Daily Scrum erwähnten Punkte weiter zu besprechen.

Am Ende eines Sprints trifft sich das gesamte Team (Teammitglieder, Scrum Master und Projektmanager), um das Erreichte zu überprüfen und zu besprechen. Der Projektmanager kann alle Änderungen von Stakeholdern wie Benutzern oder dem größeren Unternehmen übermitteln, und nach der Diskussion kann das Team diese Änderungen in den nächsten Sprint einbeziehen.

Kanban ist ein visuelles System zur Verwaltung und Verfolgung von Projekten. Kanban-Boards bieten eine visuelle Darstellung des Projektfortschritts eines Teams, bei dem einzelne Teilaufgaben in eine von wenigen Kategorien eingeordnet werden. Dazu gehören in der Regel:

• Backlog: Alle Aufgaben, die noch nicht in eine andere Kategorie verschoben wurden – zu Beginn des Projekts befinden sich alle Aufgaben im Backlog
  
  
• Erledigen: Aufgaben, die gerade bearbeitet werden
  
  
• Bewertung: Aufgaben, deren erste Fertigstellungsphase erreicht wurde und die von einer anderen Person bewertet werden
  
  
• Abgeschlossen: Aufgaben, die abgeschlossen sind.

„Kanban“ setzt sich aus den japanischen Wörtern für Schild („kan“) und Tafel („ban“) zusammen und bedeutet in etwa Werbetafel oder Nachrichtenbrett. Ein Kanban kann sowohl analog als auch digital sein. Bei der analogen Variante werden für einzelne Aufgaben oft physische Post-it-Notizen verwendet, die nach der Erledigung in die nächste Spalte verschoben werden.

Es gibt auch viele digitale Versionen von Kanban-Boards, die besonders für Projektteams nützlich sein können, in denen einige oder alle Mitglieder Remote-Mitarbeiter sind.

Extreme Programming (XP) ist eine flexible Methode, die ursprünglich für Softwareentwickler entwickelt wurde, um die Qualität, Reaktionsfähigkeit und Geschwindigkeit von Software zu verbessern. Das Grundkonzept ist eine Form von Flexibilität, die sich auf noch kleinere Ausbrüche von testbaren Erstellungszeitplänen stützt.

Unter XP wird jedes einzelne Element eines Gesamtprojekts wiederholt getestet und manchmal sogar mit Tests bombardiert, die darauf abzielen, es zu zerstören. Diese einzelnen Aspekte werden dann oft wöchentlich gemeinsam getestet, um maximale Kompatibilität sicherzustellen.

In der Kommunikation setzt XP auf Einfachheit bis zum Äußersten. Die Dokumentation soll so minimalistisch wie möglich sein, damit andere Teammitglieder sie verstehen können, mit einfacher Sprache, Konzepten und Metaphern. Diese Einfachheit erstreckt sich auch auf das eigentliche Design der Aufgabe. XP-Projekte werden oft ohne Berücksichtigung zusätzlicher Funktionen für die Zukunft entworfen, da diese als irrelevant für die Veröffentlichung des Projekts angesehen werden. Dies wird manchmal auch als YAGNI (You Aren't Gonna Need It, Das wird nicht gebraucht) bezeichnet.

XP ist nicht für jedes Projekt die richtige Lösung. Daher ist es wichtig, XP nur für Projekte zu verwenden, die keine Skalierbarkeit oder größere Überarbeitung benötigen.

SAFe besteht aus einer Reihe von Prinzipien und Praktiken, die auf der Lean-Flexiblen-Entwicklungsmethode, DevOps und Systemdenken basieren. Das Scaled Agile Framework (SAFe) wurde (wie der Name schon sagt) für die Skalierung agiler Frameworks in großen Unternehmen entwickelt, um mehrere Projekte aufeinander abzustimmen und Cross-Funktionalität und Interoperabilität zu gewährleisten. Dies geschieht in erster Linie durch eine Struktur, die PI-Roadmaps (Planning Increment) umfasst.

Die Aufgaben innerhalb dieser Roadmaps werden auf verschiedene Weise bezeichnet, um die Identifizierung aus der Vogelperspektive zu erleichtern. Zu den Identifizierungen gehören „Enabler“ (Abhängigkeiten von anderen Aufgaben), „Epics“ (größere Initiativen, die auf einen bestimmten Geschäftsbedarf zugeschnitten sind) und „Stories“ (gewünschte Funktionalität, entweder aus Benutzer- oder Geschäftssicht).

Disziplinierte Flexibilität wird eher als eine Reihe von Prinzipien, Versprechen und Richtlinien betrachtet als eine vollständige Methodik. Es handelt sich um einen leichten, minimalen und hybriden Ansatz für das Programmmanagement mit viel Freiheit für die einzelnen Teammitglieder.

Einige agile Frameworks wie Scrum und SAFe enthalten präskriptive Methoden und Schritte. Diese Spezifität kann für bestimmte Projekte großartig sein, aber DA zielt darauf ab, den Teammitgliedern mehr Freiheit und Agilität zu bieten. Das Grundkonzept ermöglicht es ihnen, die Konzepte und Frameworks auszuwählen, die für ihren jeweiligen Workflow ideal sind. Scrum mag für einige funktionieren, für andere jedoch nicht, insbesondere im Rahmen eines größeren Programms. DA legt viel Macht in die Hände von Einzelpersonen und eignet sich daher am besten für Projekte mit Teammitgliedern, die hochgradig sachkundig und unabhängig sind und bereits mit grundlegenden agilen Konzepten vertraut sind.

Large-Scale Scrum, kurz LeSS genannt, ist eine Version von Scrum, die speziell für größere Teams oder Gruppen von Teams entwickelt wurde, als Scrum ursprünglich vorsah. LeSS umfasst zwar immer noch Sprints, tägliche Scrum-Meetings und Prüfungen, verfügt jedoch über ein paar zusätzliche Richtlinien, die sicherstellen sollen, dass größere Teams ihre Ziele erreichen, indem sie flexibel Methoden skalieren, ohne ihre Substanz zu verlieren.

In LeSS arbeiten alle Teams an einem gemeinsamen Sprint und nicht wie im flexiblen Projektmanagement an einzelnen Sprints, die von einzelnen Teams geplant werden. Es gibt auch ein gemeinsames Backlog, das alle Aufgaben enthält, die für das gesamte Programm benötigt werden. Und die Planung für den Sprint umfasst zwei Arten von Meetings: ein Gesamtplanungsmeeting für alle Teams und dann individuelle Sprint-Planungsmeetings für die einzelnen Teams.

Nexus ist ein Framework, das Scrum ähnelt, mit einigen Ergänzungen, Subtraktionen und Änderungen. Der Hauptunterschied besteht darin, dass das Nexus Integration Team hinzukommt, eine separate Gruppe von Teammitgliedern, die als Coaches fungieren. Der NIT umfasst häufig Mitglieder der Scrum-Teams und ist dafür verantwortlich, Blockaden zu beseitigen, Unterstützung zu leisten und die Teams durch flexible Prozesse zu coachen. Das NIT hat seine eigenen Meetings, getrennt vom täglichen Scrum.

Scrum ist zwar ein phänomenales Konzept für bestimmte Projekte im Rahmen des agilen Projektmanagements, aber wenn wir über agiles Programmmanagement sprechen, geht es eigentlich um Teams von Teams. Hier kommt Scrum@Scale ins Spiel.

Bei Scrum@Scale gelten alle Mitglieder des agilen Teams als Teil eines austauschbaren Scrum-Teams, was eine disziplinübergreifende Zusammenarbeit ermöglicht. Um die Herausforderungen eines größeren Programms in Echtzeit zu bewältigen, gibt es einige neue Teammitglieder. Der Chief Product Owner (CPO) erstellt ein einzelnes Backlog für alle Scrums und stimmt sich mit den einzelnen Product Ownern ab. Eine ähnliche Rolle hat der Master of Scrum Masters, der die Arbeit zwischen den Scrum Mastern koordiniert.

Lean ist eine Methodik, die darauf abzielt, Ineffizienzen zu reduzieren und kontinuierliche Verbesserungen für die Qualität der Ergebnisse zu erzielen. Es wird oft als unter dem Begriff der Agilität zusammengefasst. Während flexibel eine Philosophie ist, ist Lean eine Methodik mit spezifischeren Tools und Richtlinien. Lean legt großen Wert auf die Minimierung von Ineffizienz und Verschwendung, während Agile sich vor allem auf Iteration, Feedback und Agilität konzentriert.

Lean hat fünf Hauptprinzipien:

• Wert identifizieren: Finden Sie im Grunde genau heraus, was das Ziel ist, und eliminieren Sie alles, was keinen Mehrwert schafft.
  
  
• Wertstrom abbilden: Verwenden Sie ein Management-Tool wie Kanban-Boards, um die Produkt-Roadmap zu visualisieren. Im Wesentlichen die Visualisierung des Projektplans von Anfang bis Ende.
  
  
• Workflow erstellen: Bauen Sie den Workflow mit bestimmten Schritten auf und achten Sie dabei auf alle denkbaren Hindernisse. Das Ziel ist es, einen möglichst flüssigen Workflow zu schaffen.
  
  
• Einrichtung eines Pull-Systems: Bei einem Pull-System werden neue Aufgaben nur aufgrund von Kundenbedarf und nur dann erstellt, wenn die Teammitglieder für weitere Aufgaben bereit sind. Das wird oft mit einer Aufgabenwarteschlange gemacht.
  
  
• Kontinuierliche Verbesserung: Verwenden Sie eine Vielzahl von Techniken, um kontinuierlich Wert zu schaffen und das Produkt zu verbessern. Dazu gehören beispielsweise Methoden und Philosophien wie Lean Six Sigma und Kaizen oder strukturierte Frameworks wie Scrum, die fortlaufende Tests und nützliche Feedbackschleifen fördern.

Flexibles Programmmanagement mit den zugehörigen Methoden bietet viele Möglichkeiten zur Verbesserung der Projektabwicklung.

• Spezifität: Durch kontinuierliche Iteration können flexible Teams genau das eingrenzen, was der Kunde will, anstatt zu versuchen, das gesamte Projekt blind zu verbessern.
  
  
• Effizienz: Flexibles Programmmanagement umfasst Grundsätze, die darauf abzielen, Verschwendung, Dokumentation und Bürokratie zu reduzieren.
  
  
• Vielseitigkeit: Dank schneller Reaktionszeiten auf Kundenfeedback ist Vielseitigkeit ein grundlegender Bestandteil des agilen Programmmanagements. Agile Teams wissen noch vor Projektbeginn, dass im Laufe des Prozesses Änderungen vorgenommen werden.
  
  
• Team-Moral: Flexibles Programmmanagement fördert Offenheit, Transparenz und befähigt einzelne Teammitglieder, ihre Meinung zu äußern. Hierarchie ist weniger wichtig als Ehrlichkeit und dediziert Teamarbeit.