Es gibt nur ein Projektmanagement

Agil, klassisch, hybrid – was ich von diesen Unterscheidungen halte habe ich schon hinreichend kundgetan z.B. in meiner kleinen Polemik „Warum hybrides Projektmanagement Bullshit ist„. 

Ich halte die Frage nach den PM-Schulen für grundlegend irreführend. Es gibt nur ein Projektmanagement. Statt ideologischer Grundsatzdiskussionen braucht es eine differenzierte Betrachtung. Vielmehr als auf das Etikett kommt es darauf an, was dahinter steckt, um erfolgreich zu sein braucht ein Projektmanagement vor allem drei Dinge:

These 1: Die Auftragsklärung und die Auseinandersetzung mit den Prämissen für Planung und Steuerung sind elementar.

Was sich zunächst trivial anhört, wird in der Praxis schnell oberflächlich übergangen. Der Projektauftrag, die Aufgabe ist meist weniger eindeutig und klar als es zunächst anmutet und wer sich nicht von Anfang an damit auseinandersetzt erlebt oft ein böses Erwachen.

Hinter den Prämissen für Planung und Steuerung verbergen sich eigentlich ganz einfache Fragen: wer plant wann, was, in welcher Tiefe, mit welchem Zeithorizont mit welcher Verbindlichkeit und welchem Vorgehensmodell. Was zunächst für die Planung gilt, lässt sich auch generell auf die Organisation im Projekt übertragen: zentrale oder dezentrale Steuerung (Selbstorganisation ist hier ein Zauberwort).

Die PM-Schulen liefern uns eine (unlautere) Abkürzung bei der Beantwortung dieser Fragen. Zum jeweiligen Zeitpunkt und im jeweiligen Kontext müssen wir uns diesen Fragen immer wieder aufs Neue stellen und ja, es kann durchaus sinnvoll sein diese Fragen mitunter unterschiedlich zu beantworten.

Warum dies so ist habe ich auf dem PMCamp München versucht mit einer Life Cycle Betrachtung zu erklären.

Selbst in einem so klassisch geprägten Umfeld wie dem Bauprojektmanagement haben wir Spielraum bei der Beantwortung dieser Fragen. Auch wenn die Projektplanung zunächst klassisch startet, gibt es innerhalb der einzelnen Gewerke sicher agilen Spielraum, bei unvorhergehenen Ereignissen auf der Baustelle oder auch später bei Betrieb und Unterhalt eines Bauwerks.

Wir haben Abhängigkeiten und Vorgaben, seien es Firmenvorgaben oder Industriestandards, amtliche Zulassungsverfahren oder eine Baugenehmigung, die uns in ein sequentielles Korsett zwingen – ob wir wollen oder nicht (ich hatte hierzu mal eine interessante Diskussion mit einem Software-Entwickler aus der Automobilindustrie, aber da gibt es noch viel mehr Branchen angefangen von Pharmazie, Medizintechnik, Luft- und Raumfahrt, ….).

Wenn wir uns im konkreten Kontext mit diesen Fragen auseinandersetzen, werden einige Schalter bereits gesetzt sein, ob wir wollen oder nicht. Vielleicht ergibt sich dann etwas wie ein hybrides Bild, aber ich würde es nicht so nennen wollen, weil es sich nicht um ein Cherry-Picking sondern um eine differenzierte Ausarbeitung handelt.

These 2: Jedes Projekt braucht Agilität.

…aber nicht jedes Projekt braucht agiles Projektmanagement. Diesen Satz habe ich Drings im PM-Krimi (Teil 1, 2, 3, 4, 5, 6) sagen lassen und er entspricht meiner Überzeugung. Agilität ist eine notwendige Eigenschaft im Umgang mit Unvorhergesehenem. Und egal ob uns die Komplexität oder das Chaos mit Ungewissheit konfrontieren: in Projekten müssen wir immer damit rechnen, dass sich Anforderungen oder Voraussetzungen ändern oder Unvorhergesehenes eintritt, ja vielleicht sogar unser Projekt von einem Moment zum anderen obsolet wird, obwohl wir gar nichts falsche gemacht haben. Auch in diesem Bereich gibt es ein paar Zauberwörter, wie Resilienz, Fehlerkultur, Changemanagement und…und…und….

These 3: Mindset, Kommunikation und Transparenz sind die wesentlichen Erfolgsfaktoren in Projekten.

Dem agilen Projektmanagement liegt ein Mindset zugrunde, dass im agilen Manifest zum Ausdruck kommt. 

Ein solches oder ein vergleichbares Mindset tut jedem Projekt gut, egal mit welchem Vorgehensmodell und Prämissen gearbeitet wird. Letztlich ist es lediglich Ausdruck eines gesunden Menschenverstandes. Es ist Grundlage für eine „Projektkultur“.

Warum braucht es eine solche Projektkultur? Nun, eine gemeinsame Haltung, zumindest als kleinster gemeinsamer Nenner bildet die Basis für ein Team. Um im Team erfolgreich zu arbeiten braucht es neben dieser Basis die Etablierung von Kommunikation, die letztlich Transparenz zu Vorgehen und Projektgegenstand schafft.

Agile Vorgehensweisen haben eine ganze Reihe von Kommunikationsritualen und Prozessen etabliert, aber gerade bei der Skalierung oder der Implementierung in einem Umfeld ohne entsprechendes Mindset entstehen dann agile „Zombie-Projekte“.

Es gibt aber noch einen weiteren Grund für ein solches Mindset und die Werte von Teamarbeit – nein, das hat nichts damit zu tun, dass ich ein naiver Gutmensch bin: wir sind in Projekten i.d.R. auf eine gewisse Freiwilligkeit und Motivation aller Beteiligten angewiesen. Das Zusammenspiel von Linie und Projekt ist beileibe nicht so selbstverständlich und reibungsfrei wie es sein sollte. Auch die Zusammenarbeit im Team ist keine Selbstverständlichkeit. Die Befristung von Projekten stellt viele Beteiligte vor eine persönliche Herausforderung. Interessenskonflikte sind vorprogrammiert.

Kein Patentrezept!

Diese drei Thesen liefern leider kein Patentrezept, sondern zwingen uns uns auf den eigenen Hosenboden zusetzen, die Ärmel hochzukrempeln und uns mit unserem Projekt und unserer Umwelt auseinander zusetzen. Wie immer gibt es keine einfachen Antworten, sondern wir brauchen eine differenzierte Betrachtung. Vielleicht ist diese differenzierte Betrachtung das, was der eine oder andere unter hybriden Projektmanagement versteht. Wenn diese Differenzierung nicht erfolgt, dann sind wir ganz schnell beim Zusammenpanschen von Tütensuppen und so praktisch Tütensuppen (und einfache Antworten) auch sein mögen, auf Dauer vergeht mir da der Appetit und ich glaube nicht, dass auf dieser Basis erfolgreiche Projektarbeit nachhaltig möglich ist. Küchen-Sterne sind damit auf jeden Fall nicht zu gewinnen.

PM-Krimi (3): Antipoden Klassisch. Agil.

Die Verdächtigungen waren offen ausgesprochen, aber dennoch so vage, dass es niemand gewagt hatte gegen Sherlock oder Drings direkt vorzugehen. Es war aber offensichtlich, dass die anderen Workshop-Teilnehmer die beiden nun mieden, wie der Teufel das Weihwasser.
Und so kam es, dass ausgerechnet Sherlock und Drings gemeinsam an der Bar zu sitzen kamen.
Den Anfang machte Drings: „Ihnen ist schon klar: So unterschiedlich unsere Ansichten und Vorgehensweisen auch sein mögen – Wir sitzen im selben Boot. Wir wollten uns beide Totalo nur vom Hals halten und haben uns mit der gleichen Strategie ganz tief in die Scheiße geritten.“
So ein offenes Wort hätte Sherlock dem alten Griesgram gar nicht zugetraut, aber wo er Recht hatte, hatte er Recht und Sherlock musste auch nichts weiter sagen als seinem ungeliebten Weggefährten und Mitverdächtigen zuzuprosten.
Sherlock war Pragmatiker genug: „Vielleicht haben wir sachliche Differenzen, aber im Moment verbinden uns handfeste gemeinsame Interessen. Wir müssen Totalos Mörder finden – am besten bevor noch mehr Porzellan zerbricht.“
Drings nahm einen Schluck aus seinem Glas und lächelte vor sich hin: „Wir haben keine sachlichen Differenzen. Wir arbeiten lediglich mit unterschiedlichen Annahmen und daraus resultierend mit unterschiedlichen Vorgehensmodellen.“
Jetzt war Sherlock baff. Er fühlte sich gerade von Drings überholt. Hatte er da richtig gehört?
„Wie meinen Sie das?“
„Als Vertreter des agilen Projektmanagement verzichten Sie auf eine umfassende Konzeption und Projektplanung, weil Sie heute eh noch nicht alles wissen können und der permanente Wandel und die Änderung der der Anforderungen das natürlichste sind, was es gibt.“
„Und Sie sehen aber weiter, haben die Weisheit mit Löffeln gefressen und planen von Anfang bis Ende alles durch….“
Kaum waren Sherlock diese Worte entfahren, biß er sich auch schon auf die Zunge, hatte Drings ihm nicht zuvor ein Friedensangebot gemacht?
„Nein, ganz so ist es nicht. Geplant wird doch in beiden Welten: meiner wie Ihrer. Lediglich die Planparameter sind andere. Wer plan? Einer oder das Ganze Team. Mit welchem Zeithorizont? Nur einen Sprint entlang oder das ganze Projekt? Mit welcher Planungstiefe? Detailliert oder nur ganz grob? Klar muss ich mich bei einer zentralen Planung ganz anders mit Änderungen rumschlagen als Sie mit Ihrem Backlog, in dem die Änderung quasi schon zum System gehört. Dafür habe ich eine strategische Ausrichtung.“
„Für die sorgt der Product Owner bei uns auch.“
„Punkt für Sie. Aber es gibt Anforderungen z.B. von Zulassungsbehörden, die uns zu einem formalistischeren Ansatz und dessen Dokumentation zwingen. Beispielswiese in der Medizintechnik, der Luftfahrt oder der Automibilindustrie. Da wollen Sie gar nicht mit der Behörden über einzelne Backlogeinträge diskutieren. Und Ihr Product Owner: Darf der GANTT-Charts malen?“
„Ja, darf er, aber die zeige ich meinem Team nicht.“
Beide mussten grinsen.
„Nach dem einen oder anderen Bier scheinen Sie mir weit agiler, als ich vermutet hätte,“ ließ sich Sherlock zu einem Kompliment hinreißen.


Was bisher geschah:

Intro: Klassisch. Agil. – Ein Projektmanagement-Krimi
Teil 1: Ein Workshop in den Bergen
Teil 2: Ein Toter

PM-Krimi (1): Ein Workshop in den Bergen

Sherlock gingen diese Workshops gegen den Strich. Statt mit seinem Team am nächsten Sprint zu arbeiten war er von Phillippo Totalo zu diesem blödsinnigen Workshop auf einer Almhütte in den Bergen verdonnert worden. Das sei wichtig, wegen der digitalen Transformation. Und das ganze Unternehmern müsse agiler werden, sagt so ein Schwachkopf ausgerechnet einem Scrummaster wie Sherlock. Und dann laufen auf der Hütte auch so obskure Gestalten wie dieser Drings rum: stocksteif, als hätte er einen Besen verschluckt, sogar hier oben mit weißem Hemd, immerhin ohne Krawatte und immerhin hatte er sich sogar zu einer Jeans hinreißen lassen. Casual war angesagt.
Eigentlich hieß Drings gar nicht Drings. So hatte ihn ein Entwickler aus Sherlocks Team getauft und alle hatten hinter vorgehaltenen Hand den Namen übernommen. Drings war Doktor der Ingenieurswissenschaften und so was von old school, dass sich Sherlock weigerte Drings richtigen Namen zu merken.
Schon bei Totalos Eröffnung hatte sich schnell rausgestellt, dass Sherlock und Drings die Antipoden dieses Wochenendes bilden würde. Hatte Phillippo, Programmmanager im Konzern, doch über hybrides Projektmanagement referiert. „Wir müssen alle voneinander lernen.“ „Das beste aus zwei Welten.“ Und so weiter – da rollten sowohl Sherlock als auch Drings, Projektmanager vom alten Schlag, mit den Augen.
Zum Aufwärmen und Kennenlernen hatte Phillippo dann zum x-ten Mal die Marshmallow Challenge aufgewärmt. Sherlock hätte kotzen können und und Drings gab sich vermeintlich jovial und souverän.
Im nächsten Themenblock waren alle aufgefordert ihr aktuelles Projekt und dessen Stand vorzustellen. Sherlock hatte über ihre agile Projektplanung referiert und als Drings nach deren Verteilung auf dem Zeitstrahl fragte, hatte Sherlock noch ironisch angemerkt, ob er es als Balkendiagramm darstellen solle und da hatte Phillippo doch eingeworfen: „Warum nicht!“ Das Beste aus beiden Welten.“ Sherlock hatte innerlich ein Messer aufgeklappt und redete jetzt nur mehr Phillippo nach dem Mund. Nicht weil er ihm gefallen wollte, sondern, um mit seinem Team abtauchen zu können und in Ruhe die eh schon schwierige Aufgabe zu bewältigen. Da wollte er ihre Probleme nicht Phillippo und schon gar nicht Drings auf die Nase binden.
Als nächster war Drings an der Reihe. Status-Reporting at its best. Gleich ein paar Ampel-Folien, alles grün natürlich und Drings war in seinem Element
Es folgten ein paar weitere Berichte und schließlich war es Zeit zum Abendesse! Und nach dem Abendessen war Phillippo tot. Mausetot.

 


Was bisher geschah:

Intro: Klassisch. Agil. – Ein Projektmanagement-Krimi

Warum hybrides Projektmanagement Bullshit ist

Klassisches und agiles Projektmanagement sind seit Jahren die Antipoden, warum nicht das Beste aus beiden Welten nehmen und verwursteln? Fertig ist ein hybrides Projektmanagement. Voila!

Nun, das ist Bullshit.

Wer hybrides Projektmanagement predigt hat die grundlegenden Prämissen nicht verstanden. Was Planung und Vorgehensmodell angeht sind beide Ansätze grundverschieden. Ich will das gar nicht am Wasserfallmodell aufhängen, denn den reinen Wasserfall gibt es praktisch gar nicht. Und den hat das klassische Projektmanagement auch nie so gepredigt, wie ihm immer unterstellt wird. Aber für die Projektplanung sind grundlegende Festlegungen wichtig, die in die eine oder die andere Richtung weisen:

Wer plant? – Eine zentrale Planung im Stab oder dezentral im Team.

Mit welchem Planungshorizont? – Je größer der Planungshorizont, desto größer die Komplexität des Plans und desto größer die Auswirkung von Änderungen und Planungsfehlern.

Mit welcher Planungstiefe? – Auch das hat wiederum Auswirkungen bei Änderungen und Fehlern.

So sehr agile Ansätze en vogue sind, kann es Limitationen (Verfügbarkeiten, Spezialistentum, …) oder Vorgaben (z.B. Standards) geben, die nach wie vor einen klassischen Ansatz rechtfertigen. Umgekehrt gibt es kein „nicht-agiles“ Projektmanagement, wie Holger Zimmermann zuletzt zurecht anmerkte.

Also macht dann hybrid nicht doch Sinn?

Nein, denn mit der Festlegung unserer Planprämissen sind wir entweder klassisch oder agil unterwegs. Was nicht ausschließt, dass man auch bei einem klassischen Ansatz auf agile Methoden zurückgreifen kann und umgekehrt im agilen sich auf klassische Projektmanagementtechniken stützen darf. Wo es Sinn macht, natürlich.

High-Level – bei der Produktplanung kann ein Product Owner vielleicht sogar klassisch unterwegs sein. Seine Pläne bleiben aber auch entsprechend auf einem hohen Level, dass ihre Anpassung kein Problem ist. Was er an ein Scrum-Team übergibt muss dann aber entsprechend das Agile unterstützen. Er übergibt nicht den detaillierten Gesamtprojektplan, sondern seine Anforderungen z.B. in Form eines Backlogs, die dann vom Team dezentral detailliert geplant werden.

Mit so einem Verständnis sind klassisch und agil keine Antipoden mehr, sondern bewusste Festlegungen.

Klassisch und agil sind keine Gegner, auch wenn man in der einen oder anderen Diskussion eine Gegnerschaft vermuten könnte. Auf der einen Seite wurzelt die eine oder andere Kritik am klassischen Vorgehen in einem falschen Verständnis von Agilität (und davon gibt es leider immer mehr, je mehr sich „agil“ dem Mainstream nähert) und umgekehrt zeugt ein müdes Lächeln über agile Ansätze von einer ewig gestrigen, bornierten Sicht auf unsere VUCA-Welt mit ihrer Dynamik.

Nur ein hybrides Projektmanagement ist ein zu einfacher Lösungsansatz und deshalb bleibe ich dabei:

Hybrides Projektmanagement ist Bullshit.

 

Dies ist Beitrag #748 auf schlossBlog

 

Themenführung Empathie

In einem ganz besonderem Workshop gebe ich den Reiseführer im Museum für Dokumentationswerkzeuge in Dokumentswana (wem das jetzt spanisch vorkommt, dem empfehle ich unser demnächst erscheinendes Buch Business Visualisierung).

Die Links für die Themenführung „Empathie“ gibt es hier:

Agiles Projektmanagement

Auf LinkedIn-Learning ist gerade unser neues Video-Training „Agiles Projektmanagement“ erschienen. Eine kleine Schnupperprobe gibt es hier:

Was heißt eigentlich agil? aus Agiles Projektmanagement von Christian Botta und Bernhard Schloß

Das Training ist in sich völlig eigenständig, aber als Ergänzung zu unserer 12-teiligen Projektmanagement-Reihe gedacht. In der hatten wir zwar auch agile Themen behandelt, aber den Bogen noch weiter gespannt. Hier wollen Christian und ich den Fokus auf Agilität legen, auf die Ideen und Konzepte, auf Scrum als Platzhirsch unter den agilen Frameworks, auf Werkzeuge agilen Vorgehens, aber auch einen Ausblick geben auf agile Konzepte, die noch weit über das Projektmanagement hinaus gehen.

Konzernkommunikation & Agilität

Konzernkommunikation über Agilität hat mitunter eine unfreiwillig komische Note:

„Die Unit XYZ bekommt ein agiles Mindset“

Autsch, man bekommt also ein Mindset verordnet, dabei hat man das oder entwickelt es, aber per order di mufti.

Stirnrunzeln.

Ebenfalls sehr beliebt: euphorische Begeisterungselogen.

Hallo Kollegen, vielleicht mal eine Retrospektive in den eigenen Reihen gefällig?

Agilität ist gut, aber kein Wundermittel. Und so ein unkritischer, verkäuferischer Umgang mit ihr schadet der Sache mehr als dass es ihr dient.

Vielfalt statt Beliebigkeit

Wir dürfen Vielfalt nicht mit Beliebigkeit verwechseln. Meinungs- und Methodenvielfalt sind eine Bereicherung. Beliebigkeit nicht.

Wie weit müssen wir vor dieser Frage agiles und klassisches Projektmanagement voneinander abgrenzen?

Agiles Projektmanagement ist ein scharfes, effektives Werkzeug im Umgang mit nicht oder nur schwer planbaren Zusammenhängen – im Umgang mit Unsicherheit, aber wenn wir es ohne Sinn und Verstand einsetzen ist es auch nur ein beliebiges Tool und führt zu einer Beliebigkeit der Ergebnisse.

Klassisches Projektmanagement ist hingegen stark von einer initialen Planung getrieben.

Ich durfte jüngst Zeuge einer agilen Planung werden: Das 1-Personen Entwicklerteam haben wir anhand der Anforderungen aus einem Feinkonzept in einem GANTT-Chart geplant – das war noch nicht einmal falsch, aber warum musste das Etikett agil daran kleben?

Es gibt Spezialisierung, Sachzwänge und sequentielle Abhängigkeiten.

Ein lieber Kollege wollte einmal einen agilen Versuchsballon starten und einen Proof of Concept agil durchziehen. Im Konzernumfeld war leider eine exakte Aufgabenteilung vorgegeben – vordefinierte Silos: Infrastruktur, Application Management, …

Wenn es obendrein technische Abhängigkeiten gibt wird man nicht um eine sequentielle Planung herum kommen. Da hilft kein Sprint. Da bleibt vielleicht ein Timeboxing, aber das kann keine sequentiellen Abhängigkeiten aushebeln.

Ich habe sequentielle Planungen gesehen, die sehr gut funktioniert haben: Beim Go-Live von Großprojekten. Zu einem Zeitpunkt, wo die wirklichen Probleme längst gelöst waren – und zwar agil (auch wenn das keiner so genannt hat). Da wurden dann Abhängigkeiten konsequent ausgearbeitet, berücksichtigt und akribisch umgesetzt. Ohne Akzeptanzprobleme.

Mein lieber Kollege Thomas Mathoi würde jetzt darauf verweisen, dass es z.B. im Baumanagement Sachzwänge gibt, die uns zu einer sequentiellen Planung zwingen, wie die Abstimmung verschiedener Gewerke.  Da hat er natürlich Recht – die Frage ist nur: auf welcher Planungesebene? Natürlich muss die Mauer erst stehen, bevor sie verputzt wird und dann der Maler anrückt. Aber muss ich planen ob der Maler rechts oben oder links unten anfängt? In welchem Maß müssen die Gewerke im Vorfeld geplant werden oder können von den Handwerkern auf einer Baustellenbesprechung eigenverantwortlich modifiziert werden. Kein Maler käme auf die Idee eine noch nicht vorhandene Mauer streichen zu wollen… Und wenn die Dinge aus dem Ruder laufen, z.B. weil eine Wasserleitung angebohrt wurde oder Material nicht rechtzeitig eintrifft, kann improvisiert werden – und das ist gut so.

Die Methodenwahl: klassisch oder agil sollte also bewusst und kontextspezifisch erfolgen und nicht beliebig.

Die Frage, welches Vorgehensmodell momentan in unserem Kontext am sinnvollsten ist, kann man versuchen mit dem Stacey-Matrix bzw. dem Cynefin-Modell (auf dem die Stacey-Matrix aufsetzt) zu beantworten.

Die beiden Modelle erlauben uns in einer ersten Annäherung zu erkennen, wann welche Vorgehensweise sinnvoll ist.

Das Cynefin-Modell unterscheidet 4 Domänen:

  • einfach
  • kompliziert
  • komplex
  • chaotisch

Bei einfach und kompliziert können wir klassisch planen, bei komplex agil, denn wir wissen nicht wirklich, was die Konsequenzen unseres Handeln sind. Im Chaotischen versuchen wir zunächst mit agilen Strategien Land zu gewinnen um ins Komplexe oder Komplizierte zu gelangen.

Aus diesen Modellen können wir also sogar Handlungsstrategien ableiten.

Das führt uns zurück zu unserer Ausgangsfrage nach Vielfalt und Beliebigkeit.

Ich kann mich nicht losgelöst vom konkreten Kontext für klassisch oder agil entscheiden und nicht losgelöst von der Domäne in der ich mich gerade befinde.

Ich plädiere also für ein bewusstes sowohl als auch. Nicht für Beliebigkeit. Und nicht für eine willkürliche Vermischung.

Zwar können wir einzelne PM-Werkzeuge hybrid einsetzen, nicht aber unseren PM-Ansatz, denn hinter klassisch und agil verbergen sich grundlegende Annahmen, die mit dem Cynefin-Modell verknüpft sind (und die agilen Werte möchte ich dabei sogar noch außen vor lassen):

  • Annahmen bzgl. Planbarkeit und Änderungen
  • Annahmen bzgl. Planungstiefe und Planungshorizont
  • gezielte zentrale vs. dezentrale Planung & Steuerung
  • Strategien zum Umgang mit Unsicherheit

Je nach Domäne in der wir uns zu einem Zeitpunkt X befinden, können sich diese Annahmen auch verändern.

Gewusst wo und wofür. Das ist die Frage. Und dann konsequent umgesetzt.

Ein erstes Modell ist vielleicht einfach, die Verfeinerung ist schon kompliziert und erfordert eine detaillierte Planung und Umsetzung. Passiert dann Unerwartetes, müssen wir agil reagieren (und darauf sollten wir vorbereitet sein, weil normalerweise immer auch etwas Unerwartetes passieren kann).

Unter Umständen braucht auch agiles Vorgehen Orientierung an komplizierten Modellen, wenn wir nichts besseres greifbar haben. Auf dieser Basis planen wir Produkt oder Release, aber nicht die einzelne Iteration und natürlich hat eine Iterationsplanung wiederum eine Rückwirkung auf Release und Produkt.

Die Wahl unseres Vorgehens ist also abhängig von Kontext und Situation – und nicht von Ideologien.

Lasst uns unnötige Grabenkämpfe im Projektmanagement beerdigen und uns auf konkrete Problemstellungen konzentrieren.

In diesem Sinn ist Vielfalt befruchtend, aber Beliebigkeit bringt uns nicht weiter. Wir müssen bewusst über unsere Prämissen entscheiden. Und das kontextspezifisch.

 

Der Post #732 auf schlossBlog ist mein Beitrag zur Blogparade des PM-Camp Berlins 2017.

Dieser Post wurde insbesondere angeregt von einigen Diskussionen auf dem PM-Camp MUC. Versuchen wir doch den PM-Camp übergreifenden Brückenschlag.

Security im agilen Kontext

Diese Tage kam ich in der Diskussion mit einem Kunden auf die Berücksichtigung von Security Requirements in einem agilen Kontext.

Hintergrund war, dass bislang Security vor allem für den Betrieb und für die Produktsicherheit thematisiert wird, aber Sicherheitsaspekte in der Entwicklung und in einer Projektphase noch eher stiefmütterlich behandelt werden. Auf der anderen Seite finden agile Vorgehensweisen immer weiter Einzug in die Unternehmen und die Ausgangsfrage des Kunden war, wie man Sicherheitsbelange im agilen Kontext berücksichtigen kann.

Für die Projektsicht gibt es vor allem zwei Themenstränge (und dabei müssen wir noch nicht mal zwischen agil und klassisch unterscheiden):

  • Die Sicherheit im Projekt
  • Die Entwicklung der Sicherheit für Produkt und Betrieb

Bei letzterem Punkt könnte ich mir unterschiedliche Strategien vorstellen:

  • Ein stufenweiser Hochlauf, bei dem systematisch das Sicherheitsniveau angehoben wird. (Anfangs mit einer Sandbox, dann Aufbau einer Entwicklungsumgebung, erst noch ohne Daten, dann nur mit einem Teilset der Daten, bis hin zur vollumfänglichen Produktion)
  • Vorgabe von Leitplanken (im Qualitätsmanagement gibt es dafür das Control Chart als Werkzeug).

Grundsätzlich würde ich Security-Anforderungen im Normalfall den nicht-funktionalen Anforderungen zuordnen.

Agile SW-Entwicklung fokussiert tendenziell auf funktionalen Anforderungen. Werden dabei wichtige nicht-funktionale Anforderungen vergessen, so kann dies eine Schwäche agilen Vorgehens sein.

Im Wesentlichen finden sich drei Ansätze zur Berücksichtigung von Security Requirements im agilen Kontext:

  • Eigene nicht-funktionale Einträge ins Backlog (beispielsweise eigene User Stories. Ein Kollege hat mir berichtete mir, dass er ein eigenes Backlog für Security Anforderungen aufgebaut hat.)
  • Berücksichtigung nicht-funktionaler Anforderungen als Constraints
  • Berücksichtigung als Kriterien im Definition of Done

Wenn die Vorgaben für Security oder nicht-funktionale Anforderungen allerdings zu sehr formalisiert werden, dann birgt das bereits einen kulturellen Konflikt: Ein formaler Prozess entspricht jetzt nicht ganz den agilen Vorstellungen von eigenverantwortlichem Handeln, d.h. auch da bräuchte es klar definierten Handlungsspielraum für das Team.

Maturity Ansätze fand ich zur Berücksichtigung von Security Anforderungen nicht hilfreich. Da finden sich  CMMI-Adaptionen auf agile Vorgehensweisen. Thematisiert wird aber das Vorgehensmodell an sich und nicht die Berücksichtigung nicht-funktionaler oder sicherheitsrelevanter Anforderungen.

Beitrag #723 auf schlossBlog

Agile Coaches in Großunternehmen

Diese Tage wurde ich zufällig Ohrenzeuge einer kleinen Gruppe von Agile Coaches in einem Großunternehmen.

Erst sprachen sie ihre Einführungsfolien durch („Da sollten wir noch auf die agilen Werte eingehen.“). Das Ganze from the scratch weil agiles Vorgehen #Neuland und so, aber groß im Kommen.

Dann war Mittag und ich durfte einem anderen Gespräch der agile Coaches folgen: „Bist du jetzt schon Senior oder noch Junior? Und wie sieht es mit deiner Zertifizierung aus?“

Klar solches Hierarchie- und Statusdenken ist voll agil.

Steht bestimmt auch im agilen Manifest… Zertifikate vor gesundem Menschenverstand.

Agiles Projektmanagement ohne ein entsprechendes Mindset ist vollkommen sinnlos.

Mit dem richtigen Mindset ist schon fast wieder die Vorgehensweise egal.

Jedes Projekt braucht Agilität. Aber die erreicht man nicht durch die Einführung von agilem Projektmanagement, sondern durch eine entsprechende Einstellung und entsprechende Verhaltenswesien. Aus diesen resultiert dann (vielleicht) wieder ein agiles Projektmanagement oder aber ein open-minded klassisches Vorgehen.

Sinnfrei eingeführtes agiles PM ist genauso bürokratischer Mist, wie jede andere ohne Verstand eingeführte Methode. Mag die Methode an sich noch so gut sein.

Beitrag #721 auf schlossBlog



bernhardschloss.de