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

Warum erfreuen sich Konzepte wie Visuelles Denken, Design Thinking oder Werkzeuge wie Canvas immer mehr Beliebtheit?

Nun: Sie bringen Empathie zurück in unsere Unternehmen.

Empathie bezeichnet die Fähigkeit und Bereitschaft, Empfindungen, Gedanken, Emotionen, Motive und Persönlichkeitsmerkmale einer anderen Person zu erkennen und zu verstehen (Wikipedia). Egal ob bezüglich unserer Mitarbeiter, unserer Kunden, Konkurrenten oder anderer Stakeholder.

Beispielsweise mit einer Empathy Map können wir uns das Empfinden einer Person vor Augen führen.

Das Scientific Management von Taylor ist alt, aber Management by Objectives und amerikanisches Management Denken haben sich in den letzten Jahren immer mehr durchgesetzt.

Was auf der Strecke geblieben ist, sind einfühlsames Denken und gesunder Menschenverstand.

Visuelles Denken und Prozesse wie Design Thinking sprechen auch unsere emotionale Intelligenz an.

Haben wir zuletzt einseitig auf die eine Seite geschielt, dann verspricht ein Schielen auf die andere Seite verblüffende Einsichten und Erkenntnisgewinn.

Einseitige Gefühlsduselei ist natürlich genau derselbe Quatsch, wie blinder Rationalismus. Ein konsequentes Management by Objectives – ohne Sinn und Verstand – führt selbstverständlich genauso ins Verderben, wie wenn wir unseren Namen tanzen…

Man kann diesen Schalter aber nicht steuern. Man kann nicht wählen: 10% Gefühl, 90% Kalkül. Es ist immer ein sowohl als auch.

Und wer an den Werten von Zielvorgaben oder Command & Control blind festhält wird nie wirklich Empathie entwickeln.

Beitrag #717 auf schlossBlog

Zur im vorletzten Beitrag vorgestellten Context Map gibt es jetzt auch ein eigenes Erklärvideo.

Die Downloads zum Template gibt es hier:

Context-Map DIN A4
Context-Map DIN A3
Context-Map DIN A2
Context-Map DIN A1
Context-Map DIN A0

Beitrag #714 auf schlossBlog

Jedes Projekt, jede Aufgabe ist kontext- und situationsspezifisch. Entsprechend von zentraler Bedeutung sind Kontext- und Umweltanalyse. Als Freund von Graphic Facilitation ziehe ich dafür gerne Vorlagen wie die Context Map von The Groove oder in einem betriebswirtschaftlichen Umfeld die Branchenanalyse nach Michael E. Porter heran:

Was mir bisher gefehlt hat ist eine frei verwendbare Vorlage und so entstand meine eigene Fassung einer Context Map, die ich hier gerne teilen möchte und die unter Creative Commons Lizenz jedem zur Nutzung frei steht (pdf-Downloads finden sich am Ende des Artikels):

Unser Ausgangspunkt ist zunächst eine Blackbox. Das kann ein Projekt sein, eine Aufgabe, eine Dienstleistung, eine Problemstellung, ein Prozess,…

Unterzieht man unsere Blackbox einer einfachen Prozessbetrachtung, so wird es Input-Faktoren geben, also Dinge, die direkt in die Blackbox eingehen oder sie bestimmen und Output-Faktoren auf der anderen Seite. Wenn ich mit Porter ein Produkt analysieren würde, dann könnten links die Lieferanten und rechts die Kunden stehen, aber das Schema ist bewusst abstrakt und somit vielseitig einsetzbar.

Die eigentlich Umweltanalyse erfolgt in zwei Sphären oberhalb unserer Kernbetrachtung. Externe Einflüsse können wir auf einer Mikro- und einer Makroebene unterscheiden. Auf der Makroebene würden sich etwa globale Entwicklungen, technische oder volkswirtschaftliche Entwicklungen niederschlagen, diese können sich aber möglicherweise auch auf einer Mikroebene auswirken, z.B. in einem lokalen Bebauungsplan, dem Staudamm vor Ort oder der lokalen Infrastruktur. Die Darstellung verzichtet bewusst auf eine Festlegung der Kategorien einer solchen Betrachtung. Die Anzahl der „Tortenstücke“ ist willkürlich. In der Context Map von The Groove werden beispielsweise politische Faktoren und Trends, Umweltklima und klimatische Trends, technologische Faktoren, Unsicherheiten und Kundenbedürfnisse als Kategorien genannt.

Neben dieser „abstrakt, globalen“ Umweltbetrachtung können wir aber auch unseren Kernprozess noch einer näheren Untersuchung unterziehen, denn Input, der Betrachtungsgegenstand selbst (Blackbox) und Output unterliegen ihrerseits konkreten Entwicklungen und Einflüssen, was im Schema jeweils mit „Disruption & Change“ dargestellt wird. Das können kleine Veränderungen und Einflüsse sein, aber auch grundsätzliche Regeländerungen und disruptive Entwicklungen.

Die Einsatzmöglichkeiten dieser Context Map sind vielseitig. Das Schema selbst ist abstrakt und muss erst von Fall zu Fall befüllt werden, aber bitte nicht als plumpes Formular, sondern als Faciltitation-Technik. (Mehr dazu im Beitrag Canvas-Kritik.)

Hier noch die pdf-Vorlagen der Kontext-Map in verschiedenen Formaten:

• Context-Map DIN A4
• Context-Map DIN A3
• Context-Map DIN A2
• Context-Map DIN A1
• Context-Map DIN A0

Viel Erfolg beim beim praktischen Einsatz dieses Templates!

Beitrag #712 auf schlossBlog

Auf die Lektüre von Frederic Laloux Reinventing Organizations (Amazon Affiliate Link) war ich schon eine Weile gespannt, hatte ich doch einige wohlwollende Kommentare und Reviews aufgeschnappt. Leider waren meine Erwartungen zu hoch.

Einerseits liefert Laloux eine „entwicklungspsychologische“ Betrachtung für die Theorie der Organisationen, andererseits stolpert er auch gerade über diese Entwicklungslinie.

Entlang eines Farbcodes von rot (impulsive-red), gelb (conformist-amber), einem orange der modernen Industrieorganisation (achievement-orange), dem postmodernen grün (pluralistic-green) bis hin zu einem seegrün (teal) für die nächste Stufe, zeigt er Organisationsmodelle für verschiedene menschliche Bewusstseinstufen auf. Auch wenn er wiederholt darauf hinweist, dass er diese Stufen nicht als wertend verstanden haben will, bleibt diese Konnotation dennoch im Raum stehen. Die Unterscheidung von green und teal scheint mir darüber hinaus eher dem Neuigkeitswert geschuldet als der Sache. Unternehmen wie SEMCO wären historisch grün, von der Sache her aber schon seegrün.

Die jeweiligen Modelle seziert und beschreibt er klug anhand einer Reihe von Fallstudien. Die Fallstudien in bester angelsächsischer Tradition machen das Werk zu einem Märchenbuch. Die Lektüre erinnerte mich etwas an amerikanische Management-Literatur der 90er. Aus heutiger Sicht hat da die ein oder andere Success Story mittlerweile einen faden Beigeschmack und Laloux wird es nicht anders ergehen. Bei seinem Beispiel AES muss er selbst schon zurückrudern. Er weiß auch, dass diese Fallstudien eher anekdotenhaft sind und keine statistische Validität genießen und weist selbst darauf hin.

Abschließend gibt er praktische Tipps für die Gründung bzw. Transformation zu einer TEAL-Organisation.

Was mir viel zu kurz kommt, ist die Berücksichtigung des jeweiligen Kontext. Die Wahl des „richtigen“ Organisationsmodells zu einem bestimmten Zeitpunkt für eine bestimmte Aufgabe bleibt auf der Strecke und wird reduziert auf wenige theoretische – wenig praktische – Ausführungen, wie seine Pinguin-Metapher: Der Pinguin kommt an Land eher tollpatschig daher, überzeugt im Wasser aber als herausragender Schwimmer.

Laloux verwendet einen sehr traditionellen Organisationsbegriff. Er geht von einer formalen Organisation, einem Unternehmen aus. Informelle Organisationen, Netzwerke bleiben unberücksichtigt, obwohl diese keine neue Erscheinungsform sind, wenn man beispielsweise an Lieferketten entlang der Wertschöpfungskette denkt, Just in Time-Produktion, von Digitalisierung oder Industrie 4.0 ganz zu schweigen.

Das Buch ist klug genug und facettenreich, so dass ich die Lektüre nicht bereue, aber die Euphorie anderer Rezensenten (z.B. Klaus Stulle auf MW-online) teile ich beim besten Willen nicht.

Frederic Laloux, Reinventing organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness, Brüssel 2014

Beitrag #706 auf schlossBlog

Compliance, die Einhaltung rechtlicher und eigener verbindlicher Vorgaben und Richtlinien, scheint doch so einfach, tja wären doch unsere Regelungen widerspruchsfrei und aufeinander abgestimmt.

Und dann leben wir auch noch in einer globalisierten Welt, wo wir dann auch noch die Compliance in den verschiedenen betroffenen Rechtsräumen brauchen – ich meine jetzt nicht unterschiedliche Fachgebiete, sondern geografisch einzelne Länder mit ihren eigenen Rechtssystemen. Welcher Rechtsraum ist für unseren konkreten Geschäftsvorfall relevant? Bzw. welche Rechtsräume sind relevant? Die direkt betroffenen? Also wenn wir einen deutsch-ägyptischen Geschäftsfall anschauen: deutsches Recht und ägyptisches Recht? Was ist mit der Transitstrecke? Oh Mist, US-Recht beansprucht für sich weltweite Gültigkeit, verpflichtet „US-Persons“ und das sind nicht nur US-Staatsbürger, sondern beispielsweise auch Greencard-Inhaber oder Geschäftsreisende, die sich in USA aufhalten, und nimmt sie in die Pflicht. Wenn auch noch US-Technologie davon betroffen ist, weil die verwendeten Schrauben auf einer US-Drehbank gefertigt wurden, dann mal viel Spaß. Und wir haben noch nicht geschaut, ob nicht auch das nordkoreanisches Recht Anforderungen an unseren konkreten Vorgang richtet. Dessen Relevanz haben wir womöglich gedanklich ausgeblendet. Ein Abwägungsprozess – nicht Compliance.

Einen weiteren Abwägungsprozess liefert uns die Verhältnismässigkeit der Mittel. Denken wir an Informationssicherheit und fehlerfreie Programmierung. Mit absolutem Anspruch vollkommen unsinnige Zielsetzungen, weil wer 100%-ige IT-Sicherheit verspricht oder fehlerfreie Programme von der Materie keine Ahnung hat oder ein Blender ist. Ob wir wollen oder nicht kommen wir um Abwägung und einen Risiko-basierten Ansatz nicht herum. Wir müssen ein sinnvolles Sicherheitsniveau definieren und verfolgen. Und auch hier wieder bewusst abwägen.

Die Abwägung unterhöhlt elementare Grundprinzipien beispielsweise im Datenschutz, wo sich selbst staatliche Hüter der Domäne, die sonst alle Betroffenen mit aller Härte in Ihre Schranken verweisen, z.B. gegenüber Lobbyisten der Versicherungswirtschaft in die Knie gehen, selbst wenn es um die Auswertung besonderer personenbezogenen Daten geht.

Compliance ist zweifellos ein weites Feld. Ein schwammiges noch dazu.

Wenn wir mit Compliance-Anforderungen konfrontiert sind, ist die Definition geeigneter Prozesse unsere einzige Chance Transparenz in die Abläufe und Abwägungen  zu bringen und Verantwortung wahr zu nehmen.

Ein echtes Dilemma.

Das Compliance-Dilemma.

Beitrag #701 auf schlossBlog

Digitalisierung ist das neue Buzzword.

Wir müssen unsere Prozesse digitalisieren! Auch im Mittelstand.

Wie kann man das Thema Digitalisierung in einem KMU in sechs Schritten angehen?

Hier eine kurze Skizze:

1. Definition von Geschäfts- und Digitalisierungsstrategie
2. Bestandsaufnahme/Inventur
3. Analyse und Anforderungsdefinition
4. Produktauswahl
5. Umsetzungsplan
6. Implementierung

Der erste Schritt klingt akademisch und wichtigtuerisch, ist er aber nicht. Und man kann ihn auch knapp und pragmatisch machen, aber entscheidend ist, dass man sich bewusst wird, was man mit der Digitalisierung erreichen will und wie das zum eigenen Unternehmen und den eigenen Zielen passt.

Es gibt eine alte IBM-Werbung aus den 90ern, in der der eine dem anderen aus der Zeitung vorliest: „Hier steht, wir müssen ins Internet.“ – „Warum?“ – „Das steht hier nicht.“

Übertragen auf die Digitalisierung geht es genau um die Frage dieses Warum. Geht es darum die Maschinen zu vernetzen und in die Cloud zu bringen (z.B. um Updates zu installieren, Rechenleistung oder Speicher aus der Cloud zu beziehen), geht es um den Datenaustausch und Kommunikation mit den Kunden, geht es um Remote-Zugriff auf den Maschinenpark (z.B. zu Monitoring oder Wartungszwecken), …

Bestandsaufnahme/Inventur der eigenen Prozesse, Anwendungen und IT-Infrastruktur hat man im Idealfall bereits in der Schublade. Das hat noch gar nichts mit der Digitalisierung zu tun, sondern ist die Basis systematischer IT-Prozesse in einem Unternehmen. Je nach Voraussetzung kann da aber beliebig viel Arbeit dahinter stecken.

Wenn ich die Informationen aus den ersten beiden Schritten habe, kann ich sie im dritten zusammenbringen, Lücken und Handlungsbedarf identifizieren. Vielleicht gibt es aber auch Inseln, die man ausbauen und erweitern kann. Das Ganze aber vor dem Hintergrund des eigenen Geschäftsmodells und nicht weil irgendjemand sagt, man müsse jetzt digitalisieren.

Aus dem dritten Schritt weiß ich, ob ich die Maschinen in ein eigenes Sondernetz packe, ob sie eine Internetverbindung brauchen, welche funktionalen Anforderungen ich habe und wieweit ich meine Gesamtarchitektur integrieren möchte oder vielleicht sogar bewusst segmentieren (damit niemand aus dem Internet auf meine Maschinensteuerung kommt…). Jetzt kann ich schauen mit welchen Produkten ich das umsetzen kann.

Habe ich Produkte und Umsetzung, kann ich anfangen die Umsetzung konkret zu planen.

Und schließlich die Digitalisierung umsetzen.

Beitrag #693 auf schlossBlog

Der Vermittler GULP hat seine Datenbank ausgewertet und festgestellt wie und wo die Nachfrage nach agilem Projektmanagement zunimmt:

Und so sieht es mit der regionalen Verteilung der Nachfragen aus:

Der Projektvermittler GULP hat unter seinen IT-Freelancern eine Umfrage über die Einsatzunternehmen der Freiberufler durchgeführt. Demnach kommen die externen Experten überwiegend in Großunternehmen zum Einsatz.

Anscheinend gibt es durchaus eine Hemmschwelle in KMUs beim Einsatz externer Spezialisten. Wenn man die Bedeutung des Mittelstands in der deutschen Wirtschaft berücksichtigt steckt hier noch ein gewaltiges Potential.