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.

Auf dem PMCampMUC habe ich dieses Jahr zwei Session initiiert:

• Visuelles Projektmanagement
• und eine Cynefin-Betrachtung im Life Cycle  (angeregt von Ralfs Frage, wie agil im Bauprojektmanagement aussehen kann).

Cynefin im Lifecycle – schöne Session mit @schlossblog und @RalfSiegfried #PMCampMUC pic.twitter.com/50Y18LFw7j

— Visual Braindump (@VisualBraindump) 1. Juli 2017

Der Wirtschaftsteil der Süddeutschen Zeitung hat dieses Wochenende einen Aufreisser: „Die Abarbeiter –  Alle beantworten ständig E-Mails oder sitzen in Konferenzen, zentrale Aufgaben erledigen sie irgendwann dazwischen. Das macht unproduktiv und unglücklich. Trotzdem wird konzentrierte Arbeit immer seltener.“

Ertappt.

Hoffentlich merkt das keiner, dass ich genau in diese Falle getappt bin.

Die Wahrscheinlichkeit ist gering, denn die anderen sitzen in derselben Falle.

Natürlich war ich auch am Wochenende aktiv.

Und am Freitag bin ich 100km durch den Hauptferienverkehr hin und zurückgefahren um 10 min produktiv zu sein.

Slow down.

Sonst funktioniert es nur, wenn wir uns alle von der Bildfläche tragen lassen wollen.

Und wie immer: Weniger ist mehr!

Sich zurücknehmen hilft.

Digitalisierung ist wieder eines dieser unsäglichen Buzzwords, das wie so oft unreflektiert gehypt wird. Ich halte es obendrein für ein sehr gefährliches Buzzword, weil es den Fokus falsch setzt: Technik vor Geschäftsmodell. Dabei ist doch die Technik primär Mittel zum Zweck. Selbstverständlich können neue Techniken zu disruptiven Entwicklungen in Geschäftsmodellen führen, aber dennoch sollte man das Pferd nicht von hinten aufziehen.

Und um ehrlich zu sein: Die Werkzeuge der Digitalisierung sind nicht wirklich neu, sie sind nur weitaus mächtiger und allgegenwärtiger geworden. Aber welche Werkzeuge/Möglichkeiten sind das?

(1) Messen, Steuern, Regeln
Nun, wirklich nichts Neues in unserer längst digitalisierten Welt. Zugegeben: Die Auswertungsmöglichkeiten sind gewachsen, womit wir schon beim zweiten Punkt wären:

(2) Business Intelligence
Mit den zunehmend vorhandenen digitalen Daten (1) und mächtigeren Auswertungsmöglichkeiten der eigenen Daten oder selbst der Daten anderer, selbst unserer Mitbewerber (Comptetitive Intelligence) sind die Möglichkeiten der Business Intelligence gewachsen, aber neu sind sie bei Weitem nicht, allerdings in der Kombination mit…

(3) Big Data
…ergeben sich neue Erkenntnisse – auch wenn diese mitunter überschätzt werden. Die Vielzahl der heute verfügbaren Daten lässt uns elementare Grundsätze der Datenverarbeitung immer wieder vergessen: Nach wie vor gilt: Garbage in, Garbage out. Wir müssen also wissen, was wir messen und das nächste Dilemma liefert uns die Scheingenauigkeit: Messungen bis auf drei Kommastellen suggerieren Exaktheit und Wahrheit, nicht-messbare oder nicht gemessene aber relevante Einflussgrößen fliegen hingegen aus unseren Modellen hinaus und wir wundern uns dann, warum unsere Modelle nicht funktionieren. Hier ist weniger oft mehr. Ich plädiere an den gesunden Menschenverstand: Wenn auswerten, dann müssen wir auch wissen was und wo unsere Modellgrenzen liegen.

Kommen wir zu den mehr technologischen Aspekten hinter der Digitalisierung:

(4) Vernetzung
Auch in der Industrie ist Digitalisierung nichts Neues. Computer-gesteuerte Maschinen gibt es seit langem, was aber zunehmend steigt ist der Grad der Vernetzung. Damit hängen Maschinen oder ganze Produktionslinien plötzlich im Internet. Der Kühlschrank kann plötzlich selber bestellen, aber meine Produktionsmaschine ist plötzlich auch anfällig für einen Virenbefall á la Stuxnet. Mit der Vernetzung steigt die Komplexität und die wechselseitige Abhängigkeit.

(5) Virtualisierung
Unser Bild vom Computer ist noch stark geprägt von der physischen Entität eines Rechners, sei es unser Notebook, ein Desktop-PC oder ein Server. Aber zumindest in der Server-Welt haben sich Virtualisierungskonzepte längst durchgesetzt, da ordert man in einem Rechenzentrum nicht mehr (oder nur noch in besonderen Fällen) einen physischen Rechner, sondern stattdessen eine virtuelle Instanz. Zunehmend passiert die Virtualisierung auch nicht mehr im eigenen Haus, sondern wird ausgelagert in die…

(6) Cloud
Große Cloud-Anbieter, wie Microsoft, Google oder Amazon bieten Skalierungsmöglichkeiten, die man selbst nur schwer gewährleisten kann und wenn es denn sein muss, dann in einer Private-Cloud.

Aus all dem ergibt sich eine rasante…
…(7) Beschleunigung.

Alle 7 Aspekte bergen Chancen und Risiken. Natürlich ist es sinnvoll zu prüfen inwieweit sie für bestehende Geschäftsmodelle relevant sind und ob sich neue Türen öffnen. Diesen Fragen muss man sich aber immer stellen und nicht erst wenn irgendwelche Jünger ihre Digitalisierungssandalen in die Luft halten.

Und auch mit den Grenzen und Problemen der Digitalisierung müssen wir uns beschäftigen: Die Komplexität steigt und es entstehen neue Abhängigkeiten. Einem Kind würde man vorsichtshalber nicht seine Kreditkarte anvertrauen, dem Kühlschrank, den ein Wildfremder programmiert hat schon…

Lasst die Kirche im Dorf und macht eure Hausaufgaben, die ihr immer schon gemacht haben müsstet, dann ist Digitalisierung nur alter Wein in neuen Schläuchen. Zugegeben – vielleicht ist der Wein gereift, aber neu ist er wirklich nicht.

Beitrag #729 auf schlossBlog
Ein Vorgehensmodell zur Digitalisierung in KMUs gab es bereits in #693

Mit einer auf dem Kopf stehenden Pyramide lassen sich schematisch die Anforderungen (Englisch: Requirements) an ein Produkt, System oder einen Prozess darstellen. Die Pyramidenform ergibt sich aus der Priorisierung der einzelnen Anforderungen. Es wird vermutlich wenige besonders wichtige Anforderungen, aber sehr viele „nette“ Zusatzanforderungen geben – auf die möglicherweise sogar verzichtet werden kann ohne die Grundeigenschaften des Systems zu gefährden.

Grundsätzlich können zwei Arten von Anforderungen unterschieden werden: funktionale und nichtfunktionale Anforderungen.

Funnktionale Anforderungen legen fest, was ein System tun soll. Nichtfunktionale Anforderungen spiegeln eher Qualitätseigenschaften und Randbedingungen wieder. Solche können z.B. Zuverlässigkeit, Look & Feel, Benutzbarkeit, Leistung und Effizienz, Betrieb und Umgebungsbedingungen, Wartbarkeit, Änderbarkeit, Sicherheitsanforderungen, Korrektheit, Flexibilität oder Skalierbarkeit sein.

In der Darstellung hier, werden die nichtfunktionalen Anforderungen noch einmal gebündelt in relativ systemnahe Anforderungen, wie beispielsweise das Handling und die Benutzerführung, Sicherheitanforderungen oder Security-Requirements und sonstige nichtfunktionale Anforderungen.
 

Im Eifer des Gefechts meiner aktuellen Projekte wäre beinahe eine Buchveröffentlichung untergegangen:

Für den ersten Band „Beteiligungsprozesse erfolgreich planen“ der Reihe „Methodenhandbuch Bürgerbeteiligung“ durfte ich einen ausführlichen Artikel zur Stakeholderanalyse beitragen. Die Interpretation von Projekten (und ihrem Umfeld) als soziale Systeme lassen sich natürlich auch auf den öffentlichen Raum übertragen. Mit Konzepten wie der Stakeholderanalyse hat man dann ein Werkzeug, das auch in diesem Kontext genutzt werden kann. Die Stakehholderanalyse ist eine auf Interessen und Interessensgruppen fokussierte Form der Umweltanalyse.

Stakeholdermanagement, in: Hrsg.: Peter Patze-Diordiychuk, Jürgen Smettan, Paul Renner, Tanja Föhr, Methodenhandbuch Bürgerbeteiligung – Beteiligungsprozesse erfolgreich planen, München 2017 (Amazon)

Neben der #Projektaxt empfiehlt sich auch der sensible Einsatz der #Brechstange in der täglichen Projektarbeit. pic.twitter.com/WiqRux8xBS

— Bernhard Schloß (@schlossblog) 21. Mai 2017

Das Thema Fehler und Fehlerkultur hat mich jüngst über mehrere Wege eingeholt: Zum Einen bei der Erstellung unseres Qualitätsmanagementtrainings für die LinkedIn Learning Projektmanagement Reihe und zum Anderen über eine Diskussion ausgelöst durch einen Blogpost von Marcus Raitner gefolgt von einigen Repliken, u.a. von Stephan List auf dem Toolblog.

Was mir gar nicht gefällt ist die Verquickung der Begriffe Fehler und Scheitern. Während ein Fehler ganz neutral lediglich ein Ergebnis darstellt, das so weder erwartet noch gewollt war, birgt Scheitern eine stark persönlich wertende Konotation: Eine negative Wertung über die Leistungserbringung und den Leistungserbringer. Insofern würde ich gerne Marcus These („Scheitern erlauben – Fehler abschaffen“) etwas provokant auf den Kopf stellen:

Fehler erlauben – Scheitern abschaffen!

Ganz klar: Es geht nicht um unnötige und fahrlässige Fehler, aber es geht um Fehlerkultur. Es geht um einen konstruktiven Umgang mit Fehlern. Aktuelles Negativbeispiel ist wieder das Dieselgate und der desaströse Umgang damit in Politik und den betroffenen Firmen.

Aber was ist dann eine Fehlerkultur? Was macht eine (positive) Fehlerkultur aus?

(1) Akzeptanz von Fehlern
Fehler passieren. Ob wir wollen oder nicht. Dafür ist unsere Welt viel zu komplex, als dass wir alles kontrollieren könnten. Es ist sinnlos das zu negieren, vielmehr sollten wir den konstruktiven Umgang mit Fehlern suchen.

(2) Keine Schulddebatten
Beim konstruktiven Umgang mit Fehlern geht es nicht um die Schuldfrage, sondern um Lösungen. Es geht nicht um willfährigen, vorauseilenden Gehorsam, der nur auf das achtet, was vermeintlich erwartet wird, sondern um eine ehrliche und sachliche Auseinandersetzung.

(3) Transparenz
Wir brauchen selbstverständlich im Team Transparenz über unsere Fehler und Probleme. Das ist natürlich nur möglich, wenn niemand negative Konsequenzen aus seiner Ehrlichlkeit fürchten muss. Hier schließt sich der Kreis zur Schulddebatte. Es geht eben nicht um Fingerpointing auf Personen, sondern um Sachlichkeit.

(4) Fehlervermeidung kein Selbstzweck
Natürlich wollen wir keine unnötigen Fehler, aber Fehlervermeidung darf auch nicht zur Selbstzensur werden. Wir brauchen Handlungs- und Experimentierfreiräume um Lernen zu können und voran zu kommen. Das Negativbeispiel hier ist der Sprachenschüler, der seinen Mund nicht aufkriegt aus Angst einen Fehler zu machen und damit grandios an seinem Ziel – der Kommunikation – scheitert (upps, jetzt habe ich selbst von Scheitern gesprochen), statt mit Händen und Füßen zu kommunizieren und sein eigentliches Ziel zu erreichen. Die Fehlervermeidung an sich ist nicht das Ziel, sondern (in diesem Fall) die Kommunikation, aber das wird mitunter vergessen.

Wir brauchen also einen entspannteren Umgang mit Fehlern, aber keinen leichtfertigen, einen sachlichen und ganz bewussten.

Und auf die Energieverschwendung für Eitelkeiten und Schulddebatten können wir im Sinne des Teams gerne verzichten.

Christian hat über unserer Trainer-Tätigkeit für LinekedIn Learning/video2brain getweetet.

Und ich kann nur sagen: Mit Dir jederzeit wieder!

Trainer bei LinkedIn https://t.co/CgcmxdOm7f via @visualbraindump

— Bernhard Schloß (@schlossblog) May 6, 2017

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