Von der Bildung zum vernetzten Denken

Sie haben die sechs Fragestellungen im Vorfeld zu diesem Beitrag nicht gesehen? Hier finden Sie eine Zusammenfassung. Es ist empfehlenswert, sich diese vor dem Lesen des folgenden Textes anzuschauen.

Vom vernetzten Denken wird in der heutigen Zeit viel gesprochen. Doch wer kann es wirklich? Und wer wendet es an?

Bildung ist die Antwort auf Komplexität

Fälschlicherweise wird Bildung heute oft synonym mit Wissen oder Intellekt verstanden. Bildung fusst jedoch gleichberechtigt auf den Elementarkompetenzen von Wissen, Denken und Kommunikation. Mit dem Ziel, den Menschen zu einer Persönlichkeit zu formen.

Wissen umfasst dabei Fakten, als deklaratives Wissen. Denken versteht sich als die Fähigkeit mit unterschiedlichen Strategien durch Erkenntnisgewinn zur Problemlösung zu kommen und umfasst auch Aspekte wie das Interpretieren und Beschreiben. Kommunikation schliesslich kann in diesem Kontext einerseits als Fähigkeit verstanden werden, das eigene Wissen und Denken transparent zu machen. Andererseits auch als die Fähigkeit, sich hinsichtlich des Wissens und insbesondere des Denkens in eine andere Person hineinzuversetzen.

Die sechs Denkaufgaben zeigen, dass man mit Wissen als deklaratives Wissen alleine nur ungenügend vernetzt denken kann. Vernetzt denken versteht sich als Prozess, mit Hilfe von Wissen, Denken und Kommunikation Zusammenhänge zu erkennen, welche als solche noch nicht faktenbasiert im Hirn abrufbar sind. Entsprechend kann vernetztes Denken nicht auswendig gelernt werden.

Schauen wir uns die Denkaufgaben im Einzelnen an.

Natürlich ist es nicht unnütz, wenn man sich noch an das Pascal’sche Dreieck aus der Grundschule erinnert und entsprechend weiss, was es ist. Hilfreicher in der Anwendung ist jedoch, wenn man den Link vom Binomialkoeffizienten über die Binomialverteilung hin zu Algorithmen machen kann, die in der Datenklassifikation u.a. für maschinelle Lernverfahren zur Anwendung kommen.

Als Manager sollte man sich auch in den gängigen Verteilfunktionen auskennen, wenn man den Einsatz maschineller Lernverfahren propagiert. Um zur Erkenntnis zu kommen, dass bei den heutigen maschinellen Lernverfahren nicht die Algorithmen an sich lernen, sondern die Verteilung durch neue Daten (hoffentlich) verbessert wird.

Wenn Sie das Grundprinzip der asymmetrischen Verschlüsselung von RSA kennen gehören Sie zu einer Minderheit. Hut ab, wenn Sie dieses anhand zweier unterschiedlicher Primzahlen und dem Modulo rechnen als solches zu erkennen vermögen.

Wenn Sie sich jetzt noch bewusst sind, wo dieses Verfahren der Verschlüsselung heut zu Tage überall eingesetzt wird und wie wichtig es für die Digitalisierung ist – dann spreche ich von vernetztem Denken. Digitalisierung ohne Verschlüsselung ist undenkbar. Wer als Manager von Digitalisierung spricht, sollte auch Grundkenntnisse in der Verschlüsselung und digitalen Signaturen haben.

Die Zahlen-Buchstaben-Kombination 706584c27a35 sagt Ihnen nichts, Sie wenden aber Scrum im Team an? Vielleicht ein Grund, ein kleines Stück tiefer in die Zahlenwelt zu tauchen und sich mit polyadischen Zahlensystemen auseinander zu setzen. Neben Binär gibt es ein weiteres in der Informatik gängiges, nämlich Hexadezimal. Die Umrechnung auf Dezimal (auch ein polyadisches Zahlensystem) bringt Ihnen bei genauer Betrachtung den gekürzten Anfang der bekannten Fibonacci-Zahlen an die Oberfläche: 1 2 3 5 8 13 21 34 55 89. Der Link zu Scrum, als Mass der Komplexität im Planning Poker, klingt nun naheliegend.

Das Beispiel zeigt, vernetztes Denken ist nicht immer nur zwei Themen miteinander zu verknüpfen. Zuerst mussten Sie wissen was ein QR-Code ist und wie man ihn auslesen kann. Dann brauchten Sie die Idee des hexadezimalen Zahlensystems. Schliesslich mussten Sie die Fibonacci-Zahlen erkennen um den Link zu Scrum machen zu können. Manchmal muss auch ein Manager etwas tiefer tauchen um anschliessend auf hoher Flughöhe die grösseren Zusammenhänge sehen zu können.

Goldbaren und Performance? Welche Performance überhaupt? Es ist nicht immer notwendig die Lösung einer Fragestellung bis ins Detail zu kennen, um den Zusammenhang zu sehen. Manchmal muss man das Rätsel aber zuerst richtig lösen um darauf kommen zu können.

Legen Sie (in einer Messung) vom ersten Zwerg einen Goldbaren, vom zweiten Zwerg zwei Goldbaren, vom dritten Zwerg drei Goldbaren u.s.w. auf die Waage. Das Gesamtgewicht wird leider nicht exakt 28 kg sein, da Sie ja betrogen werden. Ist es ein Gramm zu leicht, betrügt der erste Zwerg. Sind es zwei Gramm die fehlen, der zweite Zwerg. Fehlen drei Gramm ist es der dritte Zwerg u.s.w.

Und der Link zur Performance? Eine Messung ist eine Recheneinheit. Die jeweilige Anzahl Goldbaren pro Zwerg ein effizient möglicher Sortieralgorithmus. Mit intelligenten Lösungsalgorithmen können Sie viel performantere Software schreiben. Seien Sie sich bewusst, dass es oftmals möglich ist, teure Rechenoperationen einzusparen, wenn das Problem grundsätzlich anders gelöst wird. In der Realität haben Sie meist nicht 7 Zwerge, sondern Hunderttausende oder Millionen von «Zwergen».

Obwohl Speicher heute günstig sind, sparen Sie mit Algorithmen wie dem obigen auch noch (Arbeits-) Speicher.

Für Sie ist Prolog ein Vorwort, eine Einleitung, erkennen aber im Code-Beispiel das Sudoku—Spiel? Gut gemacht. Richtig vernetzt denken Sie aber erst dann, wenn Sie auch wissen, welche Art von Problemen Sie mit einer deklarativen Programmiersprache, wie eben Prolog, gegenüber imperativen Sprachen, wie bspw. Java, wesentlich schneller lösen können. Mit imperativen Sprachen brauchen Sie ein Vielfaches an Code-Zeilen und mehr Testaufwand um ein Sudoku zu implementieren, weil Sie den Lösungsweg selbst finden und schreiben müssen. In Prolog als deklarativ und logische Programmiersprache müssen Sie für ein Sudoku nur das Problem beschreiben (können). Zugegeben, das ist manchmal schon schwer genug.

Es ist von Vorteil, wenn Sie als Manager davon überzeugt sind, dass die richtige Technologiewahl für das jeweilige Problem von Bedeutung sein kann. Ihre Entwickler sind künftig unter Umständen einiges effizienter unterwegs.

Mehr als ein Visum pro Tag machen Sie nicht, kennen aber trotzdem den Plural davon? Sie haben zwar nur einen in Ihrer Firma, wissen aber trotzdem was Kodizes sind? Sie kennen sich mit (ursprünglichen) Fremdwörtern und deren Anwendung in der deutschen Sprache aus, das ist hilfreich. Doch können das die anderen Mitarbeiter in Ihrem Team auch? Verstehen alle die Fremd- und Fachwörter und haben dasselbe Verständnis davon? Vernetzt denken Sie, wenn Sie sich der Notwendigkeit einer gemeinsamen Sprache in einer Firma, Abteilung, Projekt u.s.w. bewusst sind. Wenn Sie wissen, dass sprachliche Missverständnisse in unpassenden Lösungen enden können.

Viel Spass beim vernetzten Denken auf den Grundlagen der Bildung!
Ronny Fuchs

Was hat das mit ... zu tun - die Übersicht

Was hat das mit Projektmanagement zu tun?

Was hat das mit Effizienz zu tun?

Was hat das mit Performance zu tun?

Was hat das mit Scrum zu tun?

Was hat das mit Digitalisierung zu tun?

Was hat das mit maschinellem Lernen zu tun?

Bitcoin in Schweizer Franken: Kein (Compliance-) Problem für Banken?

Quelle: By FlippyFlink - Own work, CC BY-SA 4.0

https://commons.wikimedia.org/w/index.php?curid=62255825

Crypto-Currencies wie Bitcoin boomen. Dabei sind auch Firmen die mit Crypto-Currencies bezahlt werden darauf angewiesen, diese zwischendurch in eine Landeswährung zu tauschen, bspw. in Schweizer Franken.

Banken sind verpflichtet, die Herkunft der Gelder die sie entgegen nehmen zu kennen und bei Verdacht genau abzuklären was die wirtschaftlichen Hintergründe sind. Crypto-Currencies wie Bitcoin sind dabei Fluch und Segen zu gleich.

Segen

Der Segen ist, dass alle Transaktionen in Bitcoin für alle transparent sind. Jede je in Bitcoin gemachte Transaktion ist persistiert. Das ist ein fundamentaler Teil der Konzeptes. Bei jedem Compliance-Verantwortlichen sollten an dieser Stelle die Augen leuchten. Wow! Endlich ein transparentes System, bei dem die Transaktion inhärent verfügbar ist, auf Knopfdruck. Nun leider war es das auch schon mit dem Segen.

Fluch

Die Transaktionen sind transparent, für jeden. Nur die an der Transaktion Beteiligten sind zwar nicht anonym, aber pseudonym. Und wenn jemand für jeden Bitcoin, resp. für jede Transaktion einen neuen Schlüssel verwendet, und die Transaktion dann auch noch über ein öffentliches Netz mit Wegwerf-Hardware macht, dann kommt die Pseudonymisierung faktisch einer Anonymisierung gleich. In dem Fall ist es praktisch unmöglich, einen Beteiligten an einer Transaktion zu identifizieren. Der Aufwand das zu erreichen, ist relativ hoch, es ist mühsam. Menschen die nichts zu verstecken haben, werden sich das nicht antun. Wenn diese einmal Steuern mit Bitcoin bezahlen werden, wird man von denen herausfinden können, wie viel Steuern sie bezahlen. Der Datenschutz in Bitcoin ist ein anderes Thema. Aber der Kriminelle wird sich diese Mühe machen und somit meist anonym bleiben.

Da kommt der Fluch für die Banken ins Spiel. Nehmen wir folgendes Beispiel:

Der Firmenkunde A, nennen wir sie Entitiy AG, hat USD und braucht Schweizer Franken um eine Rechnung zu bezahlen. Dazu verkauft sie die USD der Bank und bekommt Schweizer Franken. Die Transaktion ist rein intern, Compliance wird sich für diesen Tausch kaum interessieren.

Jetzt braucht die Entitiy AG aber Schweizer Franken und hat dafür viele Bitcoins. Sie verkauft nun auf einer Online-Börse einer anderen Person Bitcoins und diese andere Person überweist der Entity AG die Schweizer Franken. Dieser Geldeingang taucht nun auf dem Compliance-Radar auf. Was klärt nun Compliance ab, bezüglich der Herkunft der Mittel? Reicht es, wenn die Bank einfach dokumentiert: Geld stammt von Verkauf von Bitcoins? Thema abgeschlossen?

Es gibt zwei Blickwinkel auf die Fragestellung der Sorgfaltspflicht der Bank in diesem Fall. Die Bank muss zumindest plausibilisieren, ob die Firma aus legalen Geschäften so viele Bitcoins haben kann und ob dies wirtschaftlich für die Firma einen Sinn ergibt. Das ist ganz analog, wie wenn die Entitiy AG eine Immobilie verkauft hätte für die sie Schweizer Franken erhält. Als nächstes stellt sich dann die Fragen, auch wieder analog einer Immobilie als Beispiel, ob der Käufer die Mittel legal erwirtschaftet hat. Schliesslich will oder muss die Bank ja wissen, ob die Gelder die bei ihr eingegangen sind, legaler Herkunft sind. Soweit so identisch wie bis anhin.

Nun stellt sich bei Bitcoin aber die Frage, ob die Sorgfaltspflicht der Bank nicht noch einen Schritt weitergehen muss oder sollte. Denn die Bank hat hier die Möglichkeit, die Herkunft der Bitcoin selber und automatisch in der Blockchain bis zum Mining zurückzuverfolgen. Reicht es also, wenn die Bank dokumentiert: "Geld stammt aus Verkauf Bitcoin"?

Die Frage geht nun weiter und direkt in das Know Your Customer-Konzept (KYC). Wenn die Bank weiss, dass der Kunde Bitcoin besitzt, verkauft (gegen eine Landes-Währung) und das Geld dann bei der Bank eingeht, müsste sie nicht den öffentlichen Schlüssel oder die Schlüssel (Mehrzahl) des Kunden kennen, damit sie die damit verbundenen Transaktionen abklären kann?

Was geschieht, wenn die Bank herausfindet, dass ein Teil der verkauften Bitcoins irgendwann einmal an einer Transaktion beteiligt waren, die der Finanzierung eines Verbrechen diente?

Ein weiteres Spannungsfeld eröffnet sich beim Thema Steuern. Wenn die Bank weiss, wie viele Bitcoin ein Kunde hat (weil sie deren Schlüssel kennt), muss sie dann mit dem Kunden abklären, wie er dies hinsichtlich Versteuerung macht? Alle Dienstleistungen ohne MWSt abrechnen und sich in Bitcoins zahlen lassen und dann hin und wieder die Bitcoins verkaufen und sich die Schweizer Franken auf das Bankkonto vergüten lassen ist kaum eine legale Geschäftspraxis.

Fazit

Die Bank hat drei Optionen, wenn sie Kunden hat die Crypto-Currencies wie Bitcoin haben als Geschäftsmodell, und/oder sich Veräusserungen von solchen auf das Bankkonto vergüten lassen.

1) Sie schliesst beide Augen und argumentiert, dass sie der Heruntergrund der Gelder (Bitcoins) nichts angehen muss. Sie schreibt einfach "Verkaufserlös Bitcoin" im AML-Monitoring.

2) Sie hat ein klares Konzept, wann sie wie weit geht bei der Analyse. Wie viel Transparenz sie vom Kunden verlangen muss, um den Hintergrund abklären zu können. Dazu gehört es bspw. festzulegen, wie viele Transaktionen der betroffenen Bitcoins in der Vergangenheit in die Analyse mit einbezogen werden sollen. Dazu gehört es auch, dass der Kunde Beteiligte an Transaktionen offenlegen muss, damit die Kette überhaupt hinsichtlich der Pseudonymisierung vernünftig transparent gemacht werden kann. Schliesslich braucht es da von der Bank entsprechende Software um die Analysen überhaupt erst machen zu können.

3) Als dritte Option, bietet die Bank Geschäftsbeziehungen von solchen Firmen (oder auch Privaten) gar nicht an, resp. beendet diese, wenn solche Fälle auftreten/bekannt werden.

Egal für welche Variante sich eine Bank entscheidet: Sie muss einen bewussten Entscheid fällen und die Variante sauber umsetzen.

Aus meiner Sicht ist die erste Variante die schlechteste von allen. Denn die Crypto-Währungen vergessen nie. Die Transaktionen sind im Internet ewig gespeichert. Das bedeutet ein grosses Risiko für die Bank. Denn niemand weiss, was alles für Auswertungen und Transparenz möglich ist in 5 oder 10 Jahren. Stellt dann bspw. eine US-Behörde fest, dass eine Bank über Jahre bewusst Gelder aus Transaktionen mit Bitcoins, die (teilweise) aus einem Verbrechen stammten oder gegen die Interessen der USA gerichtet waren (bspw. Steuerhinterziehung, US-Clearing-Umgehung etc.), entgegen nahm, dann wird es womöglich ein "US-Programm" 2.0 geben für gewisse Banken. Und der grosse Vorteil für die USA (oder wen auch immer): Die Bank oder die Schweiz müssen gar nicht kooperieren, es ist alles im Internet plus SWIFT- und/oder SIC-Netzwerk verfügbar, was man wissen muss.

Die Banken tun also gut daran, den Entscheid bewusst und mit Weitsicht zu fällen und sich bei Variante zwei mit dem notwendigen Know-how, der notwendigen Software und den notwendigen Ressourcen auszustatten.

Update:
Interessanter Bericht: Link
Offenbar agieren auch die US-Korrespondenzbanken äusserst vorsichtig.

CORE-Banking oder Kundenschnittstelle?

Quelle: Wikipedia.org

Die Rolle der IT wird für Banken immer wichtiger. Viele Banken haben denn inzwischen auch eigene Software-Entwickler angestellt. Auch wenn die Bank keine Tradition in der Software-Entwicklung hat.

Wenn sich eine Bank entscheidet selber Software zu entwickeln, dann stellt sich auch die Frage, wo es denn sinnvoll ist, selber zu entwickeln.

Die alte Frage nach Make or Buy - die Frage nach Standardsoftware einkaufen, oder individuell entwickeln, lässt sich längst nicht mehr so schwarz/weiss formulieren.

Alles komplett selber entwickeln kann niemand, auch die ganz grossen nicht - es rechnet sich einfach nicht. Die Vorteile von Standardkomponenten sind betriebswirtschaftlich zu gross. Aber nur auf Standardsoftware setzen? Dadurch wird sich eine Bank künftig zu wenig differenzieren können - first oder late mover nur mit Standardsoftware? Kaum vorstellbar.

Die Frage ist daher nicht ob selber entwickelt werden soll, sondern was.

Im Detail hängt dies natürlich von den individuellen Stärken der Mitarbeiter ab und nicht zuletzt vom Geschäftsmodell.

Wenn die Bank einen Spezialisten für Namensabgleiche hat, kann es unter Umständen interessant sein, die diesbezügliche Software selber zu entwickeln. Hat die Bank keine eigene Expertise, wird es sich kaum lohnen dieses aufzubauen und selber eine solche Software zu entwickeln. Ist eine Bank hauptsächlich im Bereich Zahlungsverkehr oder Konsumkredite tätig, so wird der Entscheid der Eigenentwicklung auch anders ausfallen, als bei einer normalen Retailbank.

Auf einer etwas abstrakteren Ebenen lässt sich aber durchaus allgemein diskutieren, wo der Fokus einer Eigenentwicklung unter Umständen sinnvoller ist.

CORE bei CORE-Bankingsystemen steht für Centralized Online Realt-time Exchange. Als der Begriff mit einer neuen Generation von solchen Bank-IT-Systemen aufkam, war zentral und realtime tatsächlich neu. Heute würde man diese beschriebenen Eigenschaften vielen verschiedenen Systemen/System-Architekturen geben. Neue Trends wie IoT oder Blockchain gehen weg von "centralized", aber der "Online-Realtime-Charakter bleibt.

Die Frage, was den zu einem CORE-Banking-System dazu gehört und was nicht, ist so alt wie der Begriff selber.

Mehr und mehr macht sich im Markt die Meinung breit, dass das CORE-Banking-System die zentrale Auftrags- und Buchungsmaschine im Hintergrund ist. Die Diskussion, welche Teilsystem denn nun dazugehören sollen und welche nicht, würde hier zuweit führen.

Es gibt aber vermehrt einen Konsens, dass die eigentliche Kundenschnittstelle, also alle Systeme die der Endkunde zu Gesicht bekommt, eigentlich nicht zum CORE-Bankingsystem als solches gehört. Dazu gehört  sicher das klassische E-Banking, Mobile-Banking, Bezahl-Apps, Personal Finance Manager-Applikationen, Berechnungs-Tools etc.

Wenn wir das Bild haben, dass es zwischen dem CORE-Bankingsystem - der zuverlässigen zentralen Auftrags- und Buchungsmaschine - und den Kundenapplikationen einen Unterschied gibt, dann können wir die Frage stellen: Soll eine Bank am CORE-Bankingsystem und deren Funktionen selber programmieren, oder an den Kundenapplikationen. Sollen externe Entwicklungsaufträge eher für CORE-Funktionen an Dritte vergeben werden, oder für Funktionen der Kundenapplikation?

Wenn wir zurück zur Frage der betriebswirtschaftlichen Leistung kommen, werden wir feststellen, dass CORE-Funktionen für die meisten Banken gleich sein werden. Ein Auftrag bei der Bank A wird nicht massgeblich anders abgewickelt als bei der Bank B. Eben so wenig unterscheidet sich die Zinsrechnung der Bank A von jener der Bank B. Selbst bei den Gebühren sind die Unterschiede nicht derart gross, als dass sie nicht in einem generischen Modell modelliert werden könnten (auch wenn gewisse Banker hier vielleicht leicht anderer Meinung sind). Eine Bank wird sich dadurch kaum je von der Konkurrenz unterscheiden können. Anders sieht es bei den Kundenapplikationen aus. Hier geht es um das Kundenerlebnis und darum, auch im digitalen Bereich den individuellen Fussabdruck hinterlassen zu können.

Mit Standardsoftware im Endkundenbereich wird sich eine Bank kaum massgeblich von der Konkurrenz abgrenzen können. Auch Time-to-Market wird schwierig, wenn man auf den Standardsoftware-Anbieter warten muss.

Auf Grund des möglichen USP und den betriebswirtschaftlichen Überlegungen wird es sich für eine Bank in aller Regel mehr lohnen, die Kundenschnittstelle mit eigenen Software-Entwicklern zu beherrschen als die dargelegten CORE-Banking-Funktionen. Zumal es im Endkundenbereich ohnehin keine fertige Standardsoftware für alle Kanäle gibt. Da braucht es ohnehin immer noch individuelle Entwicklungsaufträge. Umso mehr stellt sich die Frage, weshalb nicht gleich (fast) alles selber entwickeln im Endkundenbereich.

In der Schweiz sind bereits mehrere Banken (teils seit längerem) so aufgeteilt. Diese Aufteilung lässt sich auch schön im Bimodalen-Modell von Gartner modellieren. Im Mod1 mehrheitlich die (robusten, etablierten) CORE-Funktionen von Standardanbietern und im Mod2 mehrheitlich die flexiblere Eigenentwicklung im Endkundenbereich.

Das kommt auch der Compliance entgegen. Werden Compliance relevante Aspekte im robusten Mod1  (für mehrheitlich Aufsichts- und Strafrechtliche Themen) umgesetzt und bei vielen Banken eingesetzt, erhöht dies die Sicherheit und das Vertrauen. Compliance relevante Aspekte in der Kundenschnittstelle beziehen sich dann mehrheitlich auf das zivilrechtliche vertragliche Verhältnis mit dem Kunden. Dort muss Compliance ohnehin die sauber Umsetzung unter Berücksichtigung der bankindividuellen Verträge sicherstellen. 

Pseudo-Agile Softwareentwicklung: Zeit für ein Meta-Manifest (Teil 1)

Quelle: Wikipedia.org

Heute sagt eine Mehrzahl von Firmen von sich, dass sie sogenannt "agil" Software entwickeln. In Bezug auf den kompletten Software-Entwicklungsprozess handelt es sich aber in aller Regel um eine Pseudo-Agilität. So geben den bei Umfragen auch immer mehr Firmen an, dass sie nicht so ganz genau wissen, nach welcher Methode sie entwickeln.

Diese Pseudo-Agilität äussert sich etwa darin, dass meist nur die Software-Entwickler selber agile arbeiten. Der Auftraggeber und die Fachvertreter in der Regel nicht oder nur ungenügend. Oder es gibt trotz agilem Vorgehen einen Endtermin mit klaren Abnahmekriterien.

Diese Pseudo-Agilität hat zwei Ursachen:
1] Meist kennen nur die Software-Entwickler selber das agile Vorgehen und können sich mit diesem auch identifizieren. Andere Stakeholder schätzen zwar die Flexibilität, wollen die Nachteile aber trotzdem nicht akzeptieren.

2] Das agile Manifest hat einzelne Prinzipien, die sich so in der Praxis meist nicht 1:1 so umsetzen lassen.

Die Prinzipien vom agilen Manifest:

1] Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software:
Sicher ein wichtiger Aspekt. Wobei es hier nicht nur einfach um die Zufriedenstellung geht. Es ist vor allem auch eine vertrauensbildende Massnahme.

2] Agile Prozesse nutzen Veränderungen (auch spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden:
Das wäre zwar schön, ist aber leider in der Realität ein Stück weit ein Feigenblatt des Manifests. Durch eine Änderung der Anforderung müsste allenfalls eine komplett andere Architektur der Software gewählt werden. Und alle bis dahin entwickelten Iterationen müssten gegeben falls nochmals entwickelt werden. Diese Zeit hat in der Praxis aber niemand - resp. will sich niemand nehmen und auch nicht bezahlen. Die Änderungen werden also in der Praxis mit den bereits vorhandenen Mitteln umgesetzt. Ob dies mittel- bis langfristig ein Wettbewerbsvorteil bringt, bleibt offen.

3] Lieferung von funktionierender Software in regelmässigen, kurzen Zeitspannen:
Ein guter Punkt, der zwei Aspekte abdeckt: Er dient auch der Stärkung des Vertrauens in die Entwicklung wie der Punkt 1. Weiter dient er auch der Motivation der Entwickler. Lauffähige Software motiviert mehr, auch wenn sie nur klein ist, als eine Menge Code wo man noch nicht weiss, ob er läuft.

4] Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes:
Ein guter Punkt - der leider in der Praxis längst nicht bei allen Projekten möglich ist. Gerade die echten wichtigen Fachexperten sind häufig im Tagesgeschäft. Dort werden sie gebraucht weil sie wichtig sind und deshalb sind sie auch Fachexperten. Ein Fachexperte der immer Zeit hat, ist wahrscheinlich kein echter Experte.

5] Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt werden:
Wichtiger Punkt. Gehört aber eher zu den allgemeinen Führungsaufgaben. Dies betrifft längst nicht nur die Software-Entwicklung oder ein agiles Vorgehen.

6] Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht:
Persönliche Kommunikation ist sehr wichtig und für grössere Projekte über eine längere Zeit nicht komplett ersetzbar. Dennoch bieten die neuen Technologien von Video-Telefonie/-Konferenzen und die Teilung von Inhalten hier effiziente Möglichkeiten.

7] Als wichtigstes Fortschrittsmass gilt die Funktionsfähigkeit der Software:
Das ist ein kleiner Trugschluss im agilen Manifest. Gerade zusammen mit Punkt 2] lässt sich der Fortschritt kaum messen. In der aktuellen Iteration hat man viele lauffähige Funktionen - und im nächsten Schritt muss man sie auf Grund von Veränderungen umschreiben und ergänzen. Damit lässt sich kaum ein Fortschritt messen. Es zeigt sich, dass gar nicht alle Prinzipien gleichermassen angewendet werden können.

8] Einhalten eines gleichmässigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung:
Das wünscht sich jeder Fabrik-Manager. Ist aber eine Illusion. Gerade Softwareware-Entwickler in der kreativen Phase haben ein unregelmässiges Arbeitstempo. Auch sind die Auftraggeber und Benutzer meist nicht zu 100 % für ein Projekt zur Verfügung. Entsprechend können auch sie in aller Regel kein gleichmässiges Arbeitstempo erbringen.

9] Ständiges Augenmerk auf technische Exzellenz und gutes Design:
Ein sehr guter Vorsatz. Wie in Punkt 2] schon erwähnt würde dies aber dazu führen, dass man häufiger wieder ganz von vorne beginnen müsste. Das macht niemand. Die technische Exzellenz und das gute Design werden daher in der Praxis bei notwendigen Änderungen schön gefärbt. Man versucht so viel wie möglich mit der bereits entwickelten Lösung/Architektur zu realisieren.

10] Einfachheit ist essenziell:
Das ist ein weites Prinzip mit viel Spielraum für Interpretation. So in der Form in der Praxis wenig hilfreich.

11] Selbstorganisation der Teams bei Planung und Umsetzung:
Wäre ein schöner Ansatz, der in der Praxis aber selten funktioniert. Häufig alleine aus dem Grund, dass nicht alle Stakeholder nur dem Team angehören. Über deren Ressourcen lässt sich dann nicht einfach so verfügen, auch nicht über die Fachverantwortlichen als Beispiel. Das Prinzip reduziert sich dabei in der Praxis meist auf die Software-Entwickler selber. Auch kann in der Realität häufig nicht selbstbestimmt über Test-Ressourcen etc. verfügt werden. Diese müssen ordentlich geplant und bestellt werden.

12] Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung:
Guter Ansatz, der natürlich nicht nur für Software-Entwicklung gelten sollte. Als Team ist es in der Praxis meist deshalb nicht ganz einfach umsetzbar, weil die Teams als ganzes von Projekt zu Projekt nicht so stabil sind. Die Teams werden je nach Anforderungen und Themen jeweils (teilweise) neu zusammen gesetzt. Auch hier gilt. dass sich das Prinzip in der Praxis meist nur auf die Software-Entwickler selber bezieht.

Zwischenfazit:

Das agile Manifest kommt von Software-Entwickler und betrifft in erster Linie auch nur Software-Entwickler. Es ist aber auch für diese kaum möglich, allen Prinzipien gleichermassen gerecht zu werden. Es gibt potentielle inhärente Zielkonflikte. An einer Software-Entwicklung sind jedoch verschiedene Parteien beteiligt. Das Vorhaben der Software-Entwicklung als Ganzes mit allen Beteiligten, lässt sich daher kaum rein agil wie proklamiert umsetzen.

Braucht es ein Meta-Manifest?

Die Welt da draussen ist komplexer als einfache Methoden. Wo Menschen sind, gibt es Meinungen, Standpunkte und persönliche Interessen. Häufig wird mit einem Software-Projekt nicht nur das Ziel der Software selber verfolgt. Und das ist auch richtig so. Software soll Mittel zum Zweck sein. Aber welcher Zweck soll erfüllt werden? Nicht selten spielen Business-Strategien und Taktiken eine wichtige Rolle. All diese Themen sind im agilen Manifest überhaupt nicht adressiert.

Es stellt sich daher die Frage: Brauchen wir ein Meta-Manifest? Ein Manifest, wo andere Stakeholder und Betroffene als Software-Entwickler auch angesprochen werden? Ein Manifest, dass den ganzen Prozess der Software-Entwicklung abdeckt? Ein Manifest das Hinweise gibt, wie mit Zielkonflikten innerhalb der Prinzipien umzugehen ist?