AGILE INTERVIEW

FUNDSTÜCK:

Immer wieder finde ich auf meinem Rechner Interessantes. Jetzt war es die Abschrift eines Interviews, das ich ungefähr 2013 einem Studenten der Universität St. Gallen als Teil seiner Masterarbeit gegeben habe – im Rahmen seiner Masterarbeit.

Vor allem ging es um die „agile Veränderung“ in den Unternehmen. Schwerpunkte waren auch „agile contracting“ und das agile manifesto.

Das ganze Projekt unterlag strengen Vertraulichkeitsregeln, so wurden die Namen von Unternehmen und Personen in der Niederschrift ausgeblendet und deren Namen anonymisiert durch Abkürzungen wie [Unternehmensname x] , [Person y], dabei waren x und y natürliche Zahlen {1, 2, 3 …}. Ich hoffe, ich gefährde die Vertraulichkeit nicht, wenn ich erwähne, dass die von mir genannten Unternehmen HighTecs der IT (deutsche wie Siemens oder Nixdorf oder amerikanische wie HP, DEC, IBM, Google, Intel, Apple, Microsoft …) waren. Also die üblichen Verdächtigen bei den Personen.

Ich war der Interviewte und wurde als Experte für IOT bezeichnet, weil ich Gründer und Vorstandsvorsitzender der InterFace AG (einem Dienstleister und Produktentwickler der IT-Branche im Bereich SW-Entwicklung) war. Wie der Kontakt entstand, weiß ich nicht mehr. Entweder über die Hochschule St. Gallen, da habe ich regelmäßig bei RISE – Dr. Simon Grand Workshops partizipiert habe oder an über die TUM, dort hatte ich studiert und hatte verschiedene Kontakte zu verschiedenen Lehrstühlen oder auch Institutionen wie unternehmerTUM. Damals hatte ich auch über pm-Camp den Ruf, ein Protagonist der agilen Welt zu sein.

Das Interview wurde mündlich über  Telefon geführt und transkribiert. Es gab keine Folien oder Bilder, das einzige Hilfsmittel war ein Interviewleitfaden namens V3.0, den wir beide vorliegen vorliegen hatten.

Beim Lesen der Niederschrift ist mir aufgefallen, dass es technische und sprachliche Verständnisprobleme und auch Fehler gab, die bei der Verschriftung entstanden sind. Ich habe mir erlaubt, diese auszubessern und Versprecher oder schlampige Formulierungen zu korrigieren. Dabei habe ich versucht, den authentischen Charakter des Interviews zu erhalten. Und habe einige redundante Stellen zu kürzen.

Den Namen des Studenten der Hochschule St. Gallen, der das Interview geführt und organisiert hat, habe ich dann durch INTERVIEWER ersetzt, ich als der Interviewte bekam in der Abschrift den Titel Experte Iota zugewiesen :-).

Eingangs stellte mir der INTERVIEWER noch kurz das Thema seiner Masterarbeit vor, verwies auf die Anforderungen des Datenschutzes und dass er das Gespräch Aufzeichnung mitschneiden und beim Verschriften „anonymisiert“ würden.

Beginn der Aufzeichnung:

INTERVIEWER:
„Dann würde ich eben beginnen mit diesen Warm-Up-Fragen. Da geht es
darum: Ich möchte ich agile Projekte – was wird denn eigentlich agil realisiert, was nicht oder wo wird agil eingesetzt – bzw. dann auch die Experten ein bisschen kategorisieren und einteilen und da würde ich dann mit der ersten Frage beginnen und zwar:
Welche Position haben Sie denn bei dem Unternehmen, bei dem Sie aktuell angestellt sind inne?“
Experte Iota;
„Also ich habe die Fragen auch vor mir, das ist ganz praktisch. Ich bin Vorstandsvorsitzender der  [Unternehmensname 1] ( = InterFace AG), habe das Unternehmen gegründet und bin Mehrheitsaktionär“
(Anmerkung: bei [Unternehmensname 1] habe ich die Anonymisierung wieder entfernt).
INTERVIEWER:
„Und in Ihrer Tätigkeit, bzw. seitdem Sie dieses Unternehmen gegründet haben, wie lange sind Sie da schon mit der Thematik von agilen Projekten vertraut?“
Experte Iota:
„Also ich würde sagen, ich war schon vor der Gründung des Unternehmens ziemlich agil, da hat man die Projekte noch gar nicht agil genannt, trotzdem haben wir so gearbeitet, wie man es heute als agil bezeichnet.“
INTERVIEWER:
„Und vor wie vielen Jahren war das ungefähr? Das agile Manifest ist ja 2001
sozusagen entwickelt worden…“
Experte Iota:
„Also ich würde sagen, wir sind da schon deutlich früher dran gewesen. Wir sind ja 1983 gegründet worden, und meine Projekte davor bei Siemens und Softlab habe ich auch schon agil durchgeführt.Das liegt auch daran, dass ich ein Software’ler und die InterFace ein Unix Unternehmen war. So war ich öfters in den USA auf einer Uniforum (Fachmesse für UNIX), Eigentlich war UNIX schon agil wie auch die Software-Entwicklung und da gab es durchaus schon Vorläufer von Agilität. Da wurde schon lange vor 2001 agiles Gedankengut ausgetauscht und gestreut. Das agile Manifest, das war damals noch gar nicht bekannt (gab es ja auch gar nicht). Also ich würde sagen, wir (ich und meine Software-Freunde waren schon von vor 35 Jahren ziemlich agil.
(Anmerkung: Beim Interview war ich 63, das war 2013 – agil waren wir schon seit 1977 – also war das tatsächlich 36 Jahre vor dem Interview)
INTERVIEWER:
„Okay. Grundsätzlich welche Erfahrungen haben Sie denn über diese sehr lange Zeit mit agilen Projekten und mit dieser agilen Vorgehensweise gemacht?“
Experte Iota:
„Vielleicht…es gibt ein bisschen Missverständnisse im Kontext mit agil. Da
sollte man unbedingt auch als unternehmerisches oder organisatorisches Leitbild von
Selbstorganisation und Selbstbestimmung von Teams reden. Das hat witziger Weise der Hans Ulrich – Hans Ulrich ist der Gründer des St. Gallener Management Modells – schon  1982 in einem Aufsatz mit dem Titel „Acht Thesen zum Management“ geschrieben.

Da hat Hans Ulrich acht sehr agile Sätze zum Nutzen von Selbstorganisation und Selbstbestimmtheit in Teams für Unternehmer und Organisatoren geschrieben.
INTERVIEWER:
„Ja gerne.“
Experte Iota:
(Literaturhinweis Hier findet man u.a den zitierten Aufsatz von Hans Ulrich in einem Reader von RISE  Institut von St. Gallen).
„Und in so fern geht es beim agilen sehr stark um die Menschen. Es geht auch um eine Hierarchiefrage. Also es geht um ein neues Führungsverständnis. Um Eigenverantwortung, Selbstorganisation und den „bottom up“-Ansatz. Es geht nicht nur um Methoden, es ist eine Kultur, so würde ich sagen, wenn das nützlich ist.“
INTERVIEWER:
„Ja. Und welche Erfahrungen haben Sie dann mit dieser Herangehensweise –
auch mit diesem organisatorischen Ansatz – gemacht im Unternehmen?“
Experte Iota:
„Natürlich habe ich nur die besten Erfahrungen gemacht, weil sonst wärde ich es ja nicht so begeistert von Agilität. Nein, aber ohne Spaß: die größten Projekte kurz nach
der Gründung war ja die Softwareprodukte HIT und CLOU, die sehr erfolgreich wurden.
Die liefen allerdings noch ohne Grafik, weil Grafik damals technisch im professionellen Bereich der Datenverarbeitung noch nicht verbreitet. Moderne IT lief auf DEC-Terminals (Unix raw-mode, also VT100-kompatiblen) Geräten und da kann man, glaube ich, ohne rot zu werden sagen, dass wir bessere Produkte mit vielleicht 20 Leuten  entwickelt haben wie unsere großen Konkurrenten [Unternehmensname 2], die damals mit viel, viel mehr Menschen und auch ganz anderen Ressourcen als wir hatten, gescheitert sind. Ich glaube, wenn man Teams agil und selbstorganisiert entwickeln lässt, durchaus methodengestützt, aber vor allem mit dem richtigen Qualitätsbewusstsein und -verständnis gestattet, kann man einen großen Wettbewerbsvorteil erzielen sozusagen, der so weit führt, dass dasselbe Projekt – das anders geführt scheitert – am Markt gewinnt. Gerade im IT-Bereich gibt es sehr viele Projekte, die scheitern, bitter scheitern.“
INTERVIEWER:
„Okay dann würde ich auf das Beispielprojekt zu sprechen kommen, welches
Sie sich ausgesucht haben. Worum ging es denn in diesem Beispielprojekt?“
Experte Iota:
„Ich spreche gerne über dieses Phänomen. Ich kenne viele Projekte, besonders komplett unagile, die oft scheitern. Und ich kenne agile Projekt, bei denen mit einem verblüffend kleinen Team Großartiges, ja oft Einzigartiges schaffen wurde.“
INTERVIEWER:
„Ja gerne. Wie gesagt worum ging es in diesem Projekt? Was war das Ziel
dieses Softwareprodukt?“
Experte Iota:
„Das Ziel war ein Produkt zu schaffen im Rahmen der Unternehmensgründung, das gewährleistet, dass die Einnahmen nicht nur über den Verkauf von Dienstleistung (fachliche Arbeit in Mannstunden oder -Tagen verrechnet), sondern durch Lizenzen passiert. Also es war eine kommerzielle Produktidee, die wir realisieren wollten, weil ein Produkt halt in der damaligen Annahme sehr viel leichter und besser skalierbar ist als Dienstleistung. Wir haben klein angefangen, aber groß – also visionär – gedacht. Am Anfang ging es eigentlich nur um eine einfach zu nutzende elektronische Schreibmaschine auf einem Unix-System. Und daraus ist dann ein richtig großes System geworden inklusive automatischer Generierung von Dokumenten, einer Programmiersprache für Textbausteine usw. Das klingt heute zwar altmodisch, aber ich glaube es ist ein tolles System. Und der Erfolg bei Behörden und in der Wirtschaft gab uns recht.“
INTERVIEWER:
„Und wie kam es jetzt eben zu dieser Entscheidung, dass das Projekt in so einer agilen, flexiblen Herangehensweise realisiert wurde?“
Experte Iota:
„Ich glaube nicht, dass das damals eine bewusste Entscheidung war. Das
Problem war, die beiden Unternehmer – das waren mein Partner [Person 1] und ich – waren einfach überzeugt, dass ein agiles Vorgehen mit gewissen Rahmenbedingungen eigentlich die einzige Chance ist, wenn man als kleines Unternehmen mit wenig Ressourcen und ohne großartige Finanzierung erfolgreich ein Produkt entwickeln will. Ich kann da keinen, zumindest damals wäre es ein Unsinn gewesen, „richtigen Plan“ machen. Abgesehen davon, dass man keinen Heller dafür bekommen hätte, einen großen Masterplan zu entwickeln, wie soll ich sagen, und alle UseCases eines solchen Themas in ARIS oder so etwas hineinstecken. Wir haben ja echtes Neuland betreten. Und wenn Sie Neuland betreten, werden Sie sich mit klassischen Methoden schwer tun.“
INTERVIEWER:
„Ja. Wie lange dauerte dieses Projekt in etwa?“
Experte Iota:
„Also ich würde sagen die große Phase der Entwicklung und des Erfolges, die hat bis zu 20 Jahre gedauert. Das war eine richtige Produktentwicklung über deutlich mehr als ein Jahrzehnt, über zwei Jahrzehnte.“
INTERVIEWER:
„Dann ist es wahrscheinlich auch sehr schwierig, sag ich mal, den wirklichen Umfang ausgedrückt in Personentagen, in Budget zu nennen, weil es einfach so ein extrem langer Zeitraum war.“
Experte Iota:
„Also wir haben die Lines-of-Code immer wieder gezählt (besser von den Rechnern zählen lassen). Es waren sehr, sehr viele Lines-of-Codes. Es waren schon ein großes System. Ich weiß nicht ob Ihnen Datenbanken wie Informix was sagt?“
INTERVIEWER:
„Nein, ehrlich gesagt nicht.“
Experte Iota:
„Informix war lange Jahre das mächtige Konkurrenzprodukt im Unix-Bereich von Oracle bzw. IBM. Wir waren von Lines-of-Code ähnlich groß. Also wir hatten schon ein sehr  mächtiges Projekt. Das hat auch sehr viele Lizenzen und sehr viel Wartungsgebühren
eingespielt und die Subprodukte waren natürlich dann die Versionen und Ergänzungen. Man hat also ein Produkt, da gibt es ja jedes halbe Jahr ein neues Release und da kamen ergänzende Subprodukte mit besonderen Funktionen und Features dazu. Daraus wurde ine ganze System-Familie!“
INTERVIEWER:
„Wie sah dann die Projektorganisation aus? Vielleicht können wir auch mal ein bisschen vorweg greifen? Das Projekt hat ja angefangen, bevor konkrete agile Methoden wie SCRUM, Extreme Programming, etc. entwickelt wurden.“
Experte Iota:
„Das ist aber nicht ganz richtig. Extreme Programming ist schon sehr früh
gemacht worden. Das ist ja auch nicht entwickelt worden, sondern eher entstanden. Da habe ich sogar schon bei einem alten Areitgeber [Unternehmensname 2] praktiziert. So Begriffe wie das vier Augen-Prinzip oder  der Begriff Craftmanship gab es schon früh. Aber mehr im „Untergrund“, da wo richtig programmiert wurde. Craftmanship beschreibt am besten was SW-Entwicklung ausmacht, es ist der schönste Begriff für eine gute Softwaretechnologie. Andere Qualitäten sind, dass man halt wirklich nur kommentiert, was sinnvoll ist und nicht beliebig viel Narrative schreibt, sondern wirklich präzise und sparsam kommentiert. Auch kommentieren ist eine Kunst, die man verantwortungsbewußt einsetzen muss. Sonst ’sieht man den Wald vor lauter Bäumen nicht mehr‘.
Das vier-Augen-Prinzip und so Sachen wie Code-reading, alles das, was im Umfeld von Extreme Programming gemacht wurde, war für manche Menschen ganz selbstverständlich. Eigentlich war es ein großes Glück für uns, das endlich, was wie schon immer gemacht hatten, plötzlich allgemeine Anerkennung gefunden und sich in der Literatur wieder gefunden hat. Insofern, ich glaube viele Sachen, die da beschrieben werden, die kommen einfach aus gemeinsamer Erfahrung. Das ist nicht so, dass jemand „extreme programming“ oder „SCRUM“ erfunden hätte.
Aber ich kann kurz erzählen, wie es bei uns die Organisation funktioniert hat: Da waren im Prinzip drei Menschen, die für die Entwicklung eine besondere Verantwortung hatten. einer  der drei Menschen war ich. Meine damalige Rolle würde man in heutigen Worten als ‚Product Owner‘ bezeichnen. Ich hatte irgendwie das Gefühl zu wissen, wie man vernünftig (menschenwürdig) Text erstellen sollte. Dazu hatte ich auch ein Papier geschrieben, wie ich mir so ein ideales Text-editing vorstellen würde.
Ich war auch fürs Kaufmännische zuständig. Der zweite war mein Partner, der [Person 1] (=Wolf). Wolf war ein Unix-Guru und SW-Crack. Er war Nerd, Hacker und Missionar. Er hat den Menschen klar gemacht, was Qualität bedeutet. Er hat den Menschen auch klar gemacht, was Teamarbeit bedeutet. Er hat den Menschen klar gemacht, dass man beides – Qualität und Teamarbeit – nicht für die InterFace [Unternehmensname 1], also das Unternehmen und auch nicht für den Kunden, sondern zuerst einmal für sich selbst macht!? Und dass die Qualität an sich etwas Selbstverständliches ist. Man braucht sie am Markt und um auf sein Werk stolz sein zu können. Das war Wolf.
Und die dritte Rolle, das war eigentlich mehr so eine Hauptfeldwebel-Rolle. Sie wurde von einer Frau (Heidi), unserer Assistentin, ganz von selbst übernommen. Sie war für den Rest zuständig, (so eine Art „Mutter der Kompanie“ 🙂 ), die unter anderem geschaut hat, dass die Leute auch gearbeitet haben. Denn Wolf und ich waren ja tagsüber beim Kunden, um Geld für unser Unternehmen zu verdienen.
Damals gab es die ersten Computerspiele. Wir hatten die neuesten Rechner von SUN  im Unternehmen, auf denen die neuen Spiele liefen. Also wenn die Leute zum programmieren kamen, dann kam es vor, dass plötzlich die ganze Firma ein neues Spiel gespielt hat, vormittags und nachmittags – und bis spät in die Nacht. Die Leute spielten, an Stelle zu arbeiten. Heidi hat dann dafür gesorgt, dass spätestens am dritten Tag damit Schluss war.
Sie hat aber auch darauf geachtet, dass es den Leuten gut ging, auch wenn sie mal nicht so gut darauf waren Und wie auch den Wolf  [Person 1] würde ich sie heute auch als personalen SCRUM-Manager bezeichnen. Sie hat die Interessen der Teams auch bei mir durchgesetzt. Sie wußte, wie man mit Menschen umgeht und was diese gebraucht haben. Welche Schutzmaßnahmen fürs Team wichtig waren. Und die beiden haben die Menschen vor dem Außen und auch vor sich selbst geschützt. Genauso haben sie dafür gesorgt, dass die Ressourcen gepasst haben. Zum Beispiel haben wir damals einen Rechner gebraucht, sonst hätte die Arbeit darunter gelitten. Dieser Rechner hatte den damals für uns unvorstellbaren Listenpreis von 283000 DM. Und beide haben bei mir durchgesetzt, dass wir diesen Rechner gekauft haben, obwohl das für uns eine riesige Investition war. Der Rechner war damals  nach weniger als zwei Jahren völlig überholt, weil komplett veraltet. Aber uns drei war die Anschaffung wichtig. Und wir hatten Recht. Heute würde man uns als Product Owner und SCRUM Manager bezeichnen.
An gewisse Regeln haben wir uns gehalten. Ich meine, das waren anstrengende Zeiten damals. Die Projekte waren hoch komplex. Man mußte die Produkt so bauen, dass man nie den Grund unter den Füßen verlor. Das hiess, man musste sicher stellen, dass am Freitag immer wieder alles stabil lief. Das würde man heute als Sprints bezeichnen. Aus dem Freitag wurde dann vielleicht der Sonntag Mittag oder der Montag, aber am Montag früh hatte man eine Version, die wieder stabil gelaufen ist. Für uns war das damals eine Selbstverständlichkeit. Es war aber in der Branche nicht die Regel, sonder eher die Ausnahme. Bei der großem Konkurrenz kannte ich Krisen, da lief ein Produkt mehr als ein halbes Jahr nicht mehr. Die mussten Monat um Monat ihre Entwicklung zurücksetzen, um wieder sichern Boden zu gewinnen. Und haben dadurch Zeitjahre verloren.

Wir haben am Montag uns agil wieder überlegt, was wir als Nächstes machen würden. Und den uns den nächsten Sprint vorgenommen. Das Ganze war, das ist mir eben auch so wahnsinnig wichtig, sehr stark selbstorganisiert, wie z.B.bei Kanban. Dazu gab es also im Team Gespräche, wo sich die drei Führungs-Personen, die ich bezeichnet habe, sehr zurückgehalten haben, Wenn es darum ging, wer welche Aufgabe übernimmt. Die haben im Team selber entschieden, wer was macht. Das ist in höchstem Maß agil. Das habe ich oft erlebt, dass das ganz anders gemacht wurde, als ich es mir vorgestellt hatte. Da gab es Fälle, wo einer gesagt hat, hey das interessiert mich, ich kann das zwar nicht, aber ich will es lernen, weil ich das machen möchte. Und so hat man sich im Team auf Augenhöhe optimiert und natürlich haben wir damals auch sehr viel mit Metaplan (bekannte Planungsmethode) gearbeitet: Wir haben vieles täglich ganz selbstverständlich gemacht, was heute als Kanban für teueres Geld gelehrt und zertifiziert wird. Das war unser Erfolgsrezept. Das habe ich auch versucht –  immer, wenn ich irgendwo wirken durfte –  durchzuziehen.“
INTERVIEWER:
„Jetzt haben Sie auch schon Ihre Rolle sehr ausführlich beschrieben für dieses Projekt. Gab es jetzt für dieses Vorhaben irgendwie einen Vertrag? Also es war jetzt kein, ich sag mal, kein konkreter Auftraggeber da, der einen Auftragnehmer beauftragt hat…“
Experte Iota:
„Der Auftraggeber waren wir selber und der Vertrag – und die Wette – war natürlich, dass das
Produkt durch Lizenzen mehr Geld einspielt, als wir für die Erstellung ausgeben mussten. Aber wenn wir jetzt zum Vertrag gehen, ich meine die Entwicklung, die hat ihre Geschichte. Und ich weiß nicht, ob Sie Begriffe kennen, die ichmal gerne ansprechen würde, wie eine „Impact Map“ oder „User Stories“. Ja?“
INTERVIEWER:
„Also User Stories sagen mir etwas, aber die Impact Map muss ich zugeben kenne ich nicht.“
Experte Iota:
„Das macht ja nichts, ich mein, das habe ich auch erst vor kurzem erfahren. Man versucht halt immer die Dinge anfassbar und verständlich zu beschreiben. Und visualisiert sie, um die wirklich wichtigen Punkte raus zu arbeiten. Und zum Beispiel nehmen wir ruhig die User Stories: Wenn Sie ein Projekt in starke User-Stories zerlegen, dann sie klar machen, was gebraucht wird. Ich hatte ja früher erlebt, dass Fachabteilungen ihre Produktvisionen komplett in ARIS formal und detailliert spezifiziert haben. Und dann haben sie festgestellt, dass sie mehr als 50 Prozent falsch vorgestellt hatten und letztendlich gemerkt, das brauchen sie gar nicht. Und das, das sie gebraucht hätten, wurde vergessen. Das war dann natürlich ein wahnsinniger und verlorener Aufwand. Und man kann solche Effekte durch kluge Visualisierung der relevanten User-Stories vermeiden. Und wenn Sie jetzt dann als, sage ich mal, Softwareunternehmen im Auftrag arbeiten, dann werden Sie merken, dass ein paar User-Stories gibt, die sind klar. Da weiß ich, was die Beschreibung der selbigen kostet und ich weiß auch was die Implementierung kostet, ich weiß was eine belastbare
Architektur dafür kostet. Aber es gibt user-Stories, die sind nicht klar. Da weiß man eben
nicht, wie viel Aufwand das bedeuten wird. Das ist eigentlich immer und in jedem Projekt so, das Sie einen gewissen Forschungsanteil haben. Denn der Kunde will etwas bewegen. Weil er innovative Dinge haben will. Und da habe ich immer den Try&Error-Anteile. Und jetzt gibt es zum Beispiel agile Vertragsmethoden, von denen ich jetzt nur gehört habe, die wir vielleicht damals in unserem Eigenvertrag implizit auch angewendet hätten, dass man eben sagt, diese spezielle User-Story wird sozusagen im Einzelauftrag mit einem Gummiband beschrieben, auch vom Aufwand her – will sagen – preislich. Und da gibt es durchaus Unternehmen, die das sehr erfolgreich machen. Die Voraussetzung ist natürlich, dass es eine Vertrauensbasis auf Augenhöhe gibt zwischen Kunde und Lieferant. Also wenn Sie mit einem konservativen Kaufmann eines großen deutschen Unternehmens ein agiles contracting vorschlagen, dann brauchen Sie schon einen ganz, ganz besonderen Gesprächspartner und der wird große Schwierigkeiten haben, so etwas im Konzern durchzusetzen. Aber im Mittelstand mit innovativen Firmen ist das durchaus möglich, dass man sagt, als Beispiel jetzt nur, die User-Story Nummer 5 bekommt einen Tagessatz von 500 bis 2000 € und man legt dann im Projekt fest, also quasi, welche Zahl angemessen ist. Das nimmt das Risiko für beide Seiten raus, erfordert aber eine Vertrauensbasis. Also agiles contracting halte ich für ein ganz wichtiges Thema für die Zukunft. Es ist aber kulturell noch nicht so üblich bei uns. Aber da geht es dann darum die Vergütung, sage ich mal, halbwegs gerecht und fair zu gestalten.“
INTERVIEWER:
„Wobei es natürlich ein sehr interessantes Thema ist, muss ich sagen. Sie sind jetzt mein neunter Interviewpartner und ich kam ja aufgrund des Interviewleitfadens auch immer wieder auf das Thema Vertrag zu sprechen und da haben mir auch einige
Interviewpartner gesagt, ja es ist einfach schwierig zu sagen, wie soll denn wirklich ein agiler
Vertrag aufgebaut sein. Also die haben gesagt, ja gut okay bisher, weil einfach
Erfahrungswerte fehlen, weil das Agile in dem Sinne noch relativ neu ist, machen wir den
Vertrag nach wie vor so, wie für ein ganz klassisches Projekt, auch zum Teil auf Festpreisbasis.“
Experte Iota:
„Das ist aber falsch. Das ist bestimmt der falsche Weg. Ich meine, ich bin sehr oft auch mit
agilen Menschen zusammen. Da gibt es eine Bewegung PM-Camp, die ich selbst mit
gegründet habe, da wird viel über „agile contracting“ gesprochen. Eigentlich ist der Fehler klar, wir tun ja so, als ob die Projekte keinen Forschungsanteil hätten. Jetzt denken wir mal als extremes Beispiel an den Flug zum Mond. Da hat jeder gesagt, das ist ein Forschungsprojekt. Und man kann natürlich planen, in dem man „Teile und herrsche“ praktiziert,  ja? Und man kann natürlich die Module versuchen raus zu arbeiten, wo man sagt, das haben wir im Griff, das wissen wir. Die kann ich, wenn ich so eine Map habe, einfärben und sagen, die sind grün. Und da kann ich ganz konservativ contracten. Und projektabhängig wird der grüne Anteil höher oder niedriger sein. Es wird Projekte geben, die sind zu 90% grün oder vielleicht sogar zu 95%. Dann muss ich mich nur noch um die 5% kümmern. Das ist ein Ansatz. Ich bin nicht sicher, ob das der alleinversprechende, alleinseligmachende Ansatz ist, aber es ist ein Ansatz. Da kann man dem Kunden sagen, schau her, 90% kann ich im Festpreis machen, da bist du auf der sicheren Seite, je nachdem, wie groß der innovative Anteil ist. Aber hier, hier habe ich kritische Module. Ich vergleiche das gerne mit Edison und seiner Glühlampe. Ich weiß nicht, ob ich 10 oder 20 oder 50 Fäden ausprobieren muss oder 1000, bis es läuft, aber muss das agil kontraktiert werden und lass uns beide auf dieses Thema das Augenmerk richten und bitte begreife, dass da im Budget Luft drinnen sein muss. Wenn der dann sagt, ja huch, dann will ich kein elektrisches Licht haben, ja dann nimmt man es halt raus, dann wird aber das Produkt oder Projekt, was auch immer, verlieren, weil am Schluss ist es altmodischer als die alte Lösung. Aber das könnte auch wieder, wenn man an SCRUM denkt die typischen Aufgaben des Owners sein, des Product Owners.
Aber ich meine, dass da die Methoden kommen müssen. SCRUM ist ja wunderbar und wird immer komplexer und administrierter, aber da ist noch Luft zur Verbesserung, ganz klar.“
INTERVIEWER: „Wenn ich jetzt Ihre Ausführungen richtig verstanden habe, sehen Sie einen agilen Vertrag sozusagen als eine Art Hybridform, die zum Einen aus fixen, festen
Bestandteilen besteht, für die ich sage okay, für die kann ich einen Festpreis machen, das
sind 80% der Anforderungen oder User-Stories, die wir erarbeitet haben…“
Experte Iota:
„80% ist jetzt, also man hat eine willkürliche Zahl. Das ist oftmals ganz
verblüffend…“
INTERVIEWER: „Jaja. Die 80% war auch nur eine willkürliche Zahl gewählt als Beispiel von mir, ja?“
Experte Iota:
„Genau.“
INTERVIEWER:
„Und den Rest, den wir nicht fest machen können, da müssen wir dann einfach auf mit dem Budget flexibel bleiben und sagen, das machen wir vielleicht wirklich auf Basis von Time&Material, um im Jargon zu bleiben. Dass man sagt, das ist wirklich
variabel und je nachdem was wir für einen Aufwand dafür investieren müssen in der
Entwicklung, das müsste halt dann der Auftraggeber dann bezahlen dafür.“
Experte Iota:
„Richtig. Aber der Auftragnehmer ist komplett integriert, muss auch immer im Dialog dabei
sein, damit er das auch miterlebt. Und das ist eigentlich immer so in der Praxis: alle großen Projekte, die ich erfolgreich gesehen habe, da waren von der Fachabteilung schon bemerkenswerte Persönlichkeiten, die genau wussten, was sie wollen und die auch ein Gefühl hatten, was die IT leisten kann. Wenn man solche Leute hat, ist es schon einfacher. Es gibt ganz viele Projekte, da fehlen solche Leute und die gehen dann meistens schief, aber mein Erfahrungswert . Und wenn ich jetzt natürlich so einen Kunden habe, der auch stark und mächtig ist auf der Seite der Auftraggeberorganisation, dann kann ich mit dem agil contracten. Eigentlich ist muss man nur dem gesunden Menschenverstand folgen, das ist meine Aussage. Man sollte ein bisschen mehr nachdenken und nichts Unmögliches verlangen. Und dabei fair bleiben. Nehmen Sie zum Beispiel den Hans Ulrich, den
ich sehr empfehle zu lesen, den Aufsatz von 1982, der da diese acht Thesen zum
Management entwickelt hat. Eine These heißt „Zukunft ist unvorhersehbar“. Und agil heißt eigentlich nur zu akzeptieren, dass die Zukunft tatsächlich unvorhersehbar ist  – und sonst nichts. Die alten Projektmanager taten so, als ob sie die Zukunft vorhersehen könnten. Das hat nicht geklappt und  haben sie geschwindelt, wenn {es} irgendwo kritisch geworden ist, oder sind gescheitert.
Das sehen Sie in vielen Projekten. Ich hab ja vorhin von Impact Map gesprochen. Da gibt
es ganz tolle Dinge, ich weiß nicht ob Sie das buzzword  von Turnaround-Projektmanagement kennen…“
INTERVIEWER:
„Nein.“
Experte Iota:
„Das ist sehr agil. Ich weiß das auch nur, weil ich sehr viel unterwegs bin und
dann oft Menschen treffe, die mich beeindrucken und da merkt man dann, wie wertvoll
eine Impact Map ist, die dann im Projekt klarmacht den Beteiligten, was eigentlich wichtig ist
und was unwichtig ist. Wir reden immer von Projekten. In dem Fall eher IT-Projekte, so hab
ich es verstanden.“
INTERVIEWER:
„Ja.“
Experte Iota:
„Aber eigentlich sind IT-Projekte auch nur eine Sonderform, eine komplexe
Sonderform, besonders komplex meine ich sogar, als andere Projekte.“
INTERVIEWER:
„Ich habe es auch versucht…also in den Interviews bin ich auch relativ flexibel gewesen. Ich habe jetzt auch schon über Outsourcing-Projekte bzw. Organisationsprojekte geredet die auch agil durchgeführt wurden aufgrund der Tatsache, das die Laufzeit sehr lange war, das die Rahmenbedingungen vollkommen unbekannt waren und dass auch beispielsweise bei einem Projekt, da ging es um die Post-Merger-Integration von einem Mineralölkonzern…“
Experte Iota:
„Ja.“
INTERVIEWER:
„Und da wurde die Organisation aufgebaut über drei Jahre hinweg, aber zum Zeitpunkt, wie das Projekt gestartet ist, welches Unternehmensmodell oder Konzernmodell dann letzten Endes dieses aufgekaufte Mineralölunternehmen einsetzen, umsetzen wird und aufgrund dessen haben sie gesagt, müssen wir agil vorgehen, weil wir einfach sehr viele Umweltparameter nicht bestimmen können. Also wie gesagt ich habe mich nicht zu stark auf reine IT-Projekte fokussiert in meiner Arbeit. Gut dann würde ich wieder auf die Fragen zurückkommen. Jetzt war es ja so, das Auftraggeber, Auftragnehmer eigentlich im Endeffekt dasselbe Unternehmen war. Aber um ein bisschen allgemeiner…“
Experte Iota:
„Ich kenne viele andere Projekte auch, nur ich habe selten so einen großen Mehrwert erlebtt, weil am Schluss hat [Unternehmensname 2] und weitere uns in Lizenz vertrieben,
weil die eigenen Produkte mit ganz anderen Ressourcen, also wirklich 150 Leute und eine
riesen Produktplanung und alle gescheitert sind. Wir können auch über andere Projekte reden, aber da war das so, da ist mir das besonders klar geworden.“
INTERVIEWER:
„Wir können gerne bei dem Beispiel bleiben, aber…“
Experte Iota:
„Aber ich wollte noch etwas anderes sagen, was Sie ja erwähnt haben, Sie
reden ja von Veränderung. Und ich glaube… ich hab da viel nachgedacht darüber und auch viel gelernt von anderen Menschen. Wir Manager haben ja eigentlich nur eine Aufgabe, die
Veränderung zu organisieren. Und das ist für natürlich ein Problem, weil ein Unternehmen am meisten Geld verdient, wenn das Unternehmen in einer gewissen stabilen Phase ist, ja? Jetzt haben Sie immer das Problem, dass wenn das Unternehmen stabil ist, verdienen Sie Geld. Schwierig ist, wenn es instabil wird. Aber wenn Sie es nicht verändern dann geht es kaputt. Das ist ein großer Spagat. Sie verstehen, was ich meine?“
INTERVIEWER: „
Ja.“
Experte Iota:
„Und in Projekten ist es genau so. Sie müssen eigentlich immer neben dem Stabilen arbeiten und was ich jetzt eigentlich sagen wollte zu Ihren Gedanken: Sie haben davor von Organisation gesprochen. Das Problem ist aber, Sie haben heute viele Dimensionen, die sich relativ schnell verändern. Das geht los beispielsweise bei der Technologie, wenn ich mir überlege noch vor fünf Jahren… ich habe jetzt gerade hier jetzt neben mir mein [Unternehmensname 3] [Produktname 2] an der Hand, was damit geht, das ist gar nicht so lange her, dass so etwas geht. Und Sie haben aber auch andere Veränderungen im gesellschaftlichen Bereich. Die Menschen stehen meines Erachtens nach alte Dinge völlig in Frage und machen Dinge, die sehr verblüffend sind. Ich habe jetzt wieder auch in der Arbeitswelt gesprochen, wie die Leute jetzt plötzlich Home-Office machen und so etwas. Das war früher unvorstellbar -nicht zuletzt aus Misstrauen. Ich wollte sagen, Sie haben viele Dimensionen der Veränderung, das heißt, es wird immer schwieriger. Früher da hatten Sie 20, 30 Jahre eine klare Hierarchie im Unternehmen, bei der [Unternehmensname 2] zum Beispiel. Das ist weg. Und deswegen ist es noch notwendiger, dass man, oder noch unsinniger, wenn man nicht agil arbeitet. Also es gibt wirklich viele Dimensionen, die wir gar nicht wahrnehmen, die sich beschleunigt haben, warum auch immer. Ich will das weder positiv noch negativ werten. Die Veränderung ist einfach da, Und da gibt es auch Untersuchungen von Menschen, wieviel an einem Tag ein Mensch Information aufnehmen muss. Da gibt es Leute, die sagen, an einem Tag bekommt man heute so viel wie früher in einem Jahr. Auch das hat Folgen. Ich will nur sagen, es tut sehr gut, wenn wir ein bisschen agiler werden , weil sonst kapieren wir nicht mehr, was läuft und machen nur Quatsch. Aber das war jetzt eine Werbung für das Agile und auch die ganzen schönen kleinen Teile wie SCRUM, Kanban und manches mehr. Aber machen wir mit  ihren Fragen weiter.“
INTERVIEWER:
„Ja. Was ich noch sagen wollte, dass Sie ein gutes Beispiel gebracht haben:
[Unternehmensname 3] [Produktname 2]. Gerade bei [Unternehmensname 3] merkt man
meiner Meinung nach die immer kürzer werdenden Produktlebenszyklen bzw.
Innovationszyklen, dass neue Produkte, neue Releases so schnell hintereinander erfolgen.
Und das sind auch Dinge…“
Experte Iota:
„Schauen Sie [Unternehmensname 4] an…“
INTERVIEWER:
„…die ich im Projekt berücksichtigen muss. Wenn ich ein langes Projekt habe und da will ich irgendein Produkt einsetzen. Wenn ich es dann in zwei Jahren einführe, da gibt es dann, um auf das Beispiel, um auf den teueren Rechner zurückzukommen, der dann nach zwei Jahren schon wieder veraltet war. Und heute gilt das noch viel mehr eben und das ist auch ein Grund, wie Sie richtig sagen, dass man agiler arbeiten sollte…“
Experte Iota:
„Oder muss.“
INTERVIEWER:
„Oder muss, ja.“
Experte Iota:
„Man muss, wenn man nicht scheitern will. Wenn ich in einem Fluss mit reißendem Wasser schwimmen will, dann ist es gut, wenn ich mich dne Strömungen anpasse. Und ich versuche, ich sag mal, stromaufwärts geht ja eh nicht, aber so zuschwimmen, ich muss den Weg im Wasser gut wählen.“
INTERVIEWER: „Gut dann würde ich wieder auf die Fragen zurückkommen. Wie gesagt, wir waren jetzt eben vorher bei der Beziehung und da möchte ich in dem Fall allgemein bleiben, weil wir ja über das schöne Projekt von Ihnen reden. Wie beeinflusst denn eigentlich das Vertrauen den Vertrag und die Vertragsgestaltung? Wenn ich wirklich sage, ich habe wirklich Auftraggeber, Auftragnehmer, die sind wirklich zwei unabhängige Unternehmen, sage ich jetzt mal und die angenommen eine Geschäftsbeziehung seit über 10 Jahre laufen haben. Wird durch diese Beziehung, durch das vorhandene Vertrauen, der Vertrag  in irgendeiner Weise beeinflusst?“
Experte Iota:
„Das ist eine ganz gute Frage. Im Prinzip natürlich ja. Aber, das aber ist ja das, das weiß ich jetzt nicht, reden Sie von großen oder von kleinen Unternehmen.“
INTERVIEWER:
„Ich habe ein Interview geführt mit einem Softwarehersteller, der ausschließlich kleinere und mittlere Unternehmen bedient, aber ich habe auch an sehr große Beratungshäuser und Konzerne gedacht.“
Experte Iota:
„Ich möchte zwei Dinge sagen: Wir haben als Kunden sehr große Unternehmen und große Behörden aber auch kleine? Bei den großen Behörden ist es mittlerweile eine Tragik, weil dieses Verfahren der Ausschreibungen ist eigentlich genau alles andere als agil. Das ist eigentlich das Ende von Agilität. Ich weiß gar nicht, wie das weitergehen soll. Weil Sie müssen bei Teilnahme einen gigantisch hohen Aufwand erbringen. Und zwar nicht nur Sie, sondern alle Teilnehmer. Das zusammen wird sehr sehr hoch. Da geht es wirklich um Mann-Monate bis Mannjahrzehnte allein für die Ausschreibung und Angebotserstellungen. Und dann sollen die Anbieter möglichst noch einen verbindlichen Preis angeben. Das funktioniert natürlich nicht und deswegen haben wir auch so viele Katastrophen im öffentlichen Bereich, gerade bei IT-Projekten.
Bei großen Unternehmen ist es ein anderes Problem. Die haben entpersonalisierte Systeme geschaffen, die sie lähmen. Die könnten zwar frei vergeben, haben aber dermaßen viele Prozesse und Mechanismen etabliert. Das fängt an bei den Kaufleuten, die oft selbst outgesourct sind, so  gar nicht mehr das Wohl des Unternehmens, sag ich mal,
eines großen Automobilhersteller im Auge haben, sondern nur ihren Auftrag, Kosten zu
sparen, nachgehen. Mit der Kostenersparnis werden sie dann noch entlohnt. Und es gibt einen legal service, der Forderungen stellt und schwer erfüllbare AGBs formuliert. Aber darauf wird bestanden, weil der Ausschreibende absolut auf der sicheren Seite sein will. Das heißt, Sie kämpfen durchaus, aber das ist eine böse Kritik von mir, gegen entpersonalisierte Systeme. Die armen Leute der Fachabteilung, die dafür sorgen, dass das Werk läuft, sage ich mal, das die IT funktioniert, damit die Autos vom Band purzeln, die haben eigentlich das große Problem, dass sie zwischen diesen Mächten kämpfen. Und da ist Vertrauen ganz, ganz wichtig. Und es gibt ein Grund- oder Pauschalvertrauen: wenn man mal bei einem seriösen Konzern ein „preferred supplier“ ist, dann ist das ein riesengroßer Vertrauensvorschuss. Das liegt vielleicht ein wenig an der Organisation. Das ist formales Vertrauen. Das ist eine andere Ebene, eine andere Qualität von Vertrauen. Oft ist es ein Schattenvertrauen, weil es gibt Unternehmen, die das Vertrauen haben, es aber nicht verdient haben. Die Welt hat sich in einer systemischen Art und Weise verändert. Das ist aber mehr ein philosophisches Thema.
Ich glaube, beim Vertrieb fängt es an: ohne Vertrauen von Mensch zu Mensch, dass der andere was kann und nicht bescheißt, werden Sie als Unternehmer oder Verkäufer keinen Erfolg haben. Das ist mein persönlicher Glaube und meine Hoffnung. Es gibt aber Beispiele, die es widerlegen, wo das wirklich zu gehen scheint. Die Frage ist wohl, wie nachhaltig ist das Ganze und da gibt es auch negative Beispiele, die sehr, sehr lange funktionieren.
Ich glaube, dass in Unternehmen angstfreie Räume sehr wichtig sind, das nächste Thema, das Sie noch nicht angesprochen haben, ist ja Wissensmanagement. Leute sollen ja Wissen teilen. Ganz wichtig im Unternehmen. Aber wer will denn sein Wissen teilen, wenn er Angst dabei hat, sich selber zu schaden? Weil wenn er das Wissen nicht teilt, mit seinem Wissen einen Vorteil bewahren kann und seine Position sichert. Sie verstehen, was ich meine?“
INTERVIEWER:
„Ja.“
Experte Iota:
„Also wie gesagt, agiles Denken heißt auch, Wissen teilen. Das Widerspricht dem persönlichen Eigeninteresse. Der agile Auftrag ist, dass das Team kameradschaftlich zusammenarbeitet und sein Wissen teilt und man dann gemeinsam die besten Entscheidungen trifft. Das kann ich aber nicht machen, wenn ich mein Wissen nicht teile.
Es läuft immer auf die Kultur im Unternehmen hinaus. Kultur muss man halt leben,
die muss man entwickeln. Die kann man nicht synthetisch herbeizwingen. Die kann man auch nicht als Plakat im Aufzug aufhängen, was viele Konzerne ja machen.“
INTERVIEWER:
„Das ist ein sehr wichtiger Aspekt, das ist auch wieder…“
Experte Iota:
„Diese wunderbaren Sachen der Zukunft erfordern einen großen Veränderungsprozess. Und da hoffe ich sogar, dass wir in Europa, wobei die USA da auch ganz gut ist, einen Vorteil haben, der uns einen Wettbewerbsvorteil verschaffen kann.“
INTERVIEWER:
„Wobei eben Kultur auch ein sehr wichtiges Stichwort ist. Ich habe auch immer wieder in den Interviews gemerkt, dass die Experten darüber gesprochen haben, dass einfach zu manchen Unternehmen eine agile Vorgehensweise nicht passt, weil sie einfach nicht…“
Experte Iota: „Schauen Sie sich die Unternehmen an, was dann mit ihnen passiert. Das sind genau die Unternehmen, die sich in einem Trichter befinden, der zugeht. Stellen Sie sich mal vor, ich soll ja keine Namen nennen, aber die Großen deutschen Namen wie [Unternehmensname 2], ja? Was war [Unternehmensname 2] für eine Macht. Die hatten die besten Kaufleute der Welt. Die hatten einen Wahnsinnsvertrieb, der in jedem Land der Erde gut vertreten war. Die hatten meines Erachtens die besten Ingenieure der Welt. Die hatten eine Bank mit Kapital ohne Ende hinter sich. Und jetzt schauen wir mal, wie [Unternehmensname 2] die letzten 20 Jahre sich entwickelt hat, Konnte es sein Leben erweitern? Oder hat sie es reduziert. Ihre Umsätze, ihre Gewinne, die Anzahl der Menschen, die dort arbeiten, die Themen, die sie bearbeiten. Da ist nicht mehr viel übrig geblieben. Und die Sorge ist, dass als nächstes das Thema „Smart City“, das ist der größte Bereich bei [Unternehmensname 2] mit 70.000 Menschen langfristig auch  runtergeht. Und das sind die Firmen, die halt nicht agil arbeiten können. Und dann vergleichen Sie das mit einem [Unternehmensname 4] oder einem [Unternehmensname 5]. [Unternehmensname 5] ist zum Beispiel hoch hierarchisch augestellt. [Unternehmensname 4] ist deutlich mehr vernetzt aus meiner Betrachtung, aber beide sind sehr, sehr agil. Und dann schauen Sie mal womit die angefangen haben: mit einer verrückten Idee und dann ein wenig Venture Capital. Also was die alles geschafft haben oder auch die Anzahl der Mitarbeiter, die dafür arbeiten, die dafür begeistert arbeiten – ich rede jetzt nicht von den Menschen, die vielleicht irgendwo im Logistikbereich schlecht behandelt werden wie, sondern von den „Wissensarbeitern“. Wir reden ja in dem Interview – das müssen wir uns bewußt machen – überwiegend von Wissensarbeitern. Also von Menschen die früher weiße steife Kragenhemden und Krawatten
an hatten. Und ich glaube, dass agiles Arbeiten ist bei jedem Handwerksberuf zwingend
notwendig ist. Wahrscheinlich auch in Teams, die Akkord arbeiten. Aber das ist jetzt wieder Philosophie. Ich will aber nur sagen, man kann schon sagen, agil passt zu vielen Firmen nicht, aber bitte dann hinschauen, wie die Firmen sich hätten entwickeln können. Prüfen welche Möglichkeiten sie gehabt hätten,. Was sie aus ihren Möglichkeiten gemacht haben? Und da rede ich eben von alten Unternehmen, wo es immer schmäler wird. Ein Unternehmen ähnelt einem menschlichen Leben. Stellen Sie sich vor Ihr eigenes Leben. Da wollen Sie auch Ihr Leben eher entfalten in vielen Dimensionen. Musisch…in allem möglichen Dimensionen, wollen Sie Ihr personales Leben eher entfalten als reduzieren, ja. Und ich behaupte, die Firmen – es wird immer Ausnahmen geben – die Firmen, zu denen agil nicht passt, sind mittlerweile dabei gezwungener Maßen von außen, ihr Leben zu reduzieren. Immer weniger zu machen. Natürlich hat so eine Firma immer noch eine große Kraft und die kann immer noch tolle Ergebnisse an den Börsen haben, aber man muss ja reinschauen: die Kennwerte wie Kultur, wie Stimmung der Mitarbeiter, wie Betreten neuer Märkte. Ich weiß nicht, wie viel neue Märkte die klassischen deutschen Märkte, die eher so zusammengehen, betreten haben. [Unternehmensname 6], das ist ja auch ein toller Lieferant, ein toller Kunde von uns, versuchen wir jetzt mit dem [Produktname 3], mit einem enormen Kraftakt, endlich einmal einen neuen Markt zu betreten. Ob das gelingen wird wissen wir alle nicht, haben wir alle Angst davor, dass es nicht gelingen wird. Ich will nur sagen, agil passt nicht heißt, der Baum ist nicht mehr flexibel und stirbt bald ab. Bald kann in 20 Jahren sein, das ist ja vollkommen egal. [Unternehmensname 2] hat ja, wie viel, 125 Jahre oder mehr auf dem Buckel. Die Evolution malt weiter, sage ich.“
INTERVIEWER: „Das heißt, für Sie ist Agilität auch ein wesentlicher Erfolgsfaktor. Also ein
Faktor, der wirklich dazu beiträgt, dass ein Unternehmen wirtschaftlichen Erfolg hat.“
Experte Iota: „So ist es.“
INTERVIEWER: „Okay. Dann würde ich jetzt mal auf den Vertrag allgemein zu sprechen
kommen. Wir haben ja vorher schon angesprochen, dass eine Vertrauensbasis Einfluss auf den Vertrag hat. Auch hier ist es besser, wenn wir etwas allgemeiner bleiben. Wie sollte denn aus. Ihrer Sicht ein agiler Vertrag aufgebaut sein? Also welche Regelungen sollten in einem
wirklichen agilen Vertrag enthalten sein?“
Experte Iota: „Also wir müssen ja unterscheiden: dieser alte Dienstleistungsvertrag, wo,
wenn ich 100 Stunden arbeite, ich 100 Stunden bezahlt bekomme ist ja relativ agil. Nur, da
gibt es eben die Sorgen, vielleicht auch zu Recht, von den Kunden, dass sie dann einen
Nachteil haben, weil sie auch die Fehler mit bezahlen müssen und so etwas, die gemacht
werden. Ich habe ja gesagt, Projekte mit hohem Innovations-Anteil, Forschungsanteil werden
zwangsläufig auch Fehler haben, also Kosten, die verloren sind. Und ich glaube schon, um
beiden Seiten Sicherheit zu geben, dass da durchaus – Beispiel sauber, präzise Service Level
Agreements, sind eine Möglichkeit, saubere Services zu definieren. Aber das ist dann
eigentlich dasselbe, wie ich vorher erzählt habe über die Softwareentwicklung. Da werden ja
auch gewisse Dinge ausgeklammert, weil man weiß, die kann ich eben nicht zum festen Preis
anbieten. Das ist bei jedem Autokauf so. Wenn Sie da ein rundum sorglos Paket erwerben,
sind Dinge ausgeklammert. Und das ist vernünftiger Schritt auch zur Agilität, dass man halt
sagt, wir klammern Dinge aus, die werden besonders behandelt. Und jetzt geht es {darum},
was heißt besonders. Und wenn Sie das so machen wollen, dass kein Schaden oder für beide
gemeinsam der minimalste Schaden entsteht, dann müssen Sie halt phantasievolle Lösungen
erfinden. Und die werden, die gehen nur, wenn man Vertrauen hat, das ist eigentlich die
Aussage, die ich gemacht habe. Aber wenn ich weiß, einer ist ein super Handwerker, ein
Softwarehandwerker zum Beispiel und ich weiß, dass der nie Quatsch macht und ich weiß,
dass der auch so viel Zivilcourage hat, dass, wenn ich als Auftraggeber Quatsch von ihm will,
mir zu sagen, du das ist Quatsch, das mache ich nicht, dann ist die agilste Bezahlung
vielleicht die Zeiteinheit. Aber das ist ja wieder Vertrauen eigentlich. Dann wissen die
beiden…der Eine muss wissen, der Lieferant, also der Handwerker, der was arbeitet, muss
wissen, die anderen wollen mir nichts Böses. Die akzeptieren, dass ich eine Marge mache,
dass ich mein Gehalt verdiene. Wenn der Andere jetzt natürlich darauf lauert, dass er den
Einen nach Indien möglichst austauschen will, ja dann fängt es halt an. Es ist so
komplex, das möchte ich damit sagen.“
Fabian Ehn: „Ja. Und genauso ist es halt natürlich, weil Sie eben das Stichwort Vertrauen
angesprochen haben, ist es ja immer so, dass die größte Sorge bei diesem Time&Material, bei
diesem flexiblen Bezahlmodell ist, dass der Auftragnehmer sozusagen mehr liefert oder mehr
Aufwand reinsteckt, als eigentlich notwendig ist, was dann dazu führt, dass er dann den
eigenen Preis in die Höhe treibt und somit mehr Marge macht. Und da denke ich und das
haben auch andere Interviewpartner gesagt, zu sehen, also dieses Vertrauen zu haben und zu
sagen, okay man richtet sich auf eine wirklich langfristige, erfolgreiche Partnerschaft,
Zusammenarbeit aus und nicht auf einen kurzfristigen wirtschaftlichen Erfolg.“
Experte Iota: „Und da gibt es wieder eine ganz einfache Antwort, die aber in unserer Welt
völlig verdorben ist. Ich glaube Unternehmensführung sollte immer von Klarheit und
Transparenz bestimmt sein. Das heißt, ich bin ein großer Freund von open books. Dann muss
man sich nur noch unterhalten, welche Marge angemessen ist. Wenn mir mein Kunde
zugesteht, wenn die [Unternehmensname 1] sage ich mal, 8% Rendite macht, das ist in
Ordnung. Dann ist eigentlich alles ganz einfach. Dann kann man alles rechnen. Dann mache
ich nur Transparenz, Sie wissen ja die Diskussion mit Geheimdiensten und so weiter, ich
meine, man sollte eigentlich alles transparent machen, {das} ist meine radikale Meinung,
dann hätten wir viele Probleme nicht. Ich mache das auch so. Ich schreibe alles im Internet,
was ich so denke und fühle. Es gibt kaum etwas, was ich verheimliche, weil es mir vielleicht
peinlich ist oder so. Und ich stelle fest, es ist eigentlich der beste Weg. Aber ich habe auch
von Augenhöhe geredet ja. Und wenn Sie halt eine 100 Mann Firma sind und das andere ist
ein 200000 Mann Konzern, dann ist es halt sehr schwierig die Augenhöhe sicherzustellen.
Und da gibt es, ich bin ja schon über 60, verblüffende Erlebnisse, die ich früher hatte, wo man so etwas wie Fairness kannte, die ich heute nicht mehr so sehe. Also auf Augenhöhe – der Wille von beiden Seiten, miteinander fair umzugehen. Da ist eine ganz kurze Anekdote: wir haben mal in den Anfangszeiten versucht bei [Unternehmensname 2] unser Textsystem auch für Kommunikationsgeräte zu verkaufen und wir hatten einen super Partner da und viel
investiert, um das zu stippen, dass das auf eine kleine Box passt ganz toll. Und dann wurde
das Projekt eingestellt. Und da haben wir gesagt, schade, da haben wir viel gelernt, haben ein
kleines Produkt, das wir nicht brauchen. Und dann ruft mich zwei Wochen später der
Kaufmann von [Unternehmensname 2] an und fragt ich, wie viele Aufwände hatten Sie denn
damit. Und dann sage ich noch zu dem, wieso wollen Sie denn das wissen, das geht Sie doch
gar nichts an ja… und dann entschuldigt er sich und sagt, er möchte es deswegen
wissen, weil er uns die Hälfte der Ausgaben erstatten will. Das ist so eine Anekdote, die
erzähle ich bei [Unternehmensname 2] so ab und zu und bekomme dann schallendes
Gelächter, wie die Zeit damals war du wie es heute ist. Das ist Vertrauensbasis, wenn man
weiß, der andere will einen nicht ausnutzen, sondern der will haben, dass man liebt, weil man
auch davon profitiert. Aber das geht heute anders. Vielleicht muss es anders gehen, ich weiß
es nicht, das kann ich nicht beurteilen.“
INTERVIEWER: „Grundsätzlich, wo sehen Sie denn Widerstände, die sich gegen eine agile
Arbeitsweise regen? Dazu muss ich vielleicht auch ein Bisschen weiter ausholen: ich war im
Zuge meiner Masterarbeit in Zürich bei der SAP und habe da an einem
Projektmanagementworkshop zu SCRUM teilgenommen und da kam eben auch das Thema
Widerstände gegen agile Projekte und agiles Vorgehen. Und da wurde als ein wichtiger
Aspekt der Kontrollverlust genannt, also dass Auftraggeber sagen, wenn ein Projekt agil
realisiert wird, dann verliere ich Handhabe, Kontrolle über den Auftragnehmer. Dazu meine
Frage: Wie sehen Sie diesen Aspekt des Kontrollverlusts oder grundsätzlich, wo sehen Sie
Widerstände?“
Experte Iota: „Also das ist ja genau das, was ich jetzt gesagt habe. Das ergänzt sich
hervorragend. Wenn ich kein Vertrauen habe, habe ich Angst vor Kontrollverlust. Also da
passt schon etwas zusammen, würde ich sagen. Das Zweite ist das: ich glaube man könnte es
auch erweitern. Erstens geht es ja nicht um (Wort nicht verstanden), es geht um Chefs und
Abteilungen oder so etwas. Und endlich sind wir wieder bei meinen einleitenden Worten,
dieses so wahnsinnig wichtige Thema von Selbstorganisation und Selbstbestimmung von
Teams. Ganz früher hat man das übrigens Subsidiaritätsprinzip genannt. Fälle Entscheidungen
in hierarchischen so weit unten, dass es halt ausreicht. Also sobald man ein hierarchisches
System hat, so einen wunderschönen Baum mit 10 Ebenen und es kommt von Unten ein
Input, der eine Entscheidung erfordert, dann soll von unten nach oben, der erste, der es kann, entscheiden und den oberen gar nicht mit belästigen. Das nennt man Subsidiarität, wurde früher sehr viel gelehrt, dass das eine gute Sache wäre. Mittlerweile haben wir ja ganz andere Modelle. Plötzlich geht es ja um vernetzte Systeme. Und es gibt’s da viele auch Anzeichen, die ich jetzt nicht einmal werten will. Wenn ich jetzt Unternehmen berate, ich bin ja Programmierer eigentlich ursprünglich, Architekt. Und ich bin immer ein großer Freund von Design Pattern, weil ich kann nichts Neues entwickeln, wenn ich es nie gemacht habe. Wenn ich aber mir einen Apple anschaue und die Apple-Sourcen habe, so war das früher vor vielen Jahrzehnten, dann kann ich es entwickeln, weil ich es begreife und weil
ich viel abschauen und was verbessern kann und so weiter. Und ich habe es vorhin gesagt:
warum geht man nicht in den Unternehmen hin, die gut funktionieren und schaut sich den ihre Führungsarbeit und Projektmanagementarbeit einfach als ein Designpattern an? Das heißt, ich muss halt ein paar Kumpel von [Unternehmensname 4] einladen und sagen, hey, wie macht es ihr denn. Ich habe die Kumpel bei [Unternehmensname 4]. Ich weiß das. Jetzt, wenn ich aber einer [Unternehmensname 2] vorschlage, ich bringe euch Leute von [Unternehmensname 4] dann sehe ich blankes Entsetzen in den Augen. Also die Leute haben…Kontrollverlust ist ein gutes Wort, aber die haben noch mehr Angst vielleicht und da ist Konkurs dabei, vor einer Kultur, die sie überrollt. Vielleicht ein ganz kleines Beispiel wenn ich auf einem Barcamp bin oder PM-Camp, dann sehe ich oft Leute, die sind vielleicht fälschlicher Weise da. Und dann geht einer raus und sagt, hey auf unserem Barcamp sind wir alle per du, hat jemand was dagegen und bitte viel twittern. Dann werden die bleich und sagen was, duzen und twittern. Das ist ein ganz triviales Beispiel. Das ist so. Bitte nie solche Beispiele jetzt ernst nehmen. Also nur um Dinge klar zu machen, bringe ich diese Beispiele.“
INTERVIEWER: „Ja. Ich verstehe auf jeden Fall, dass Sie sagen, dass manche Unternehmen,
auch große Unternehmen, eben Angst vor kulturellen Veränderungen haben. Dass die einfach so sehr in ihren Arbeitsweisen, in ihrem Denken verankert sind, um bei dem Beispiel
[Unternehmensname 4] und [Unternehmensname 2] zu bleiben: Wenn Sie jetzt dem
[Unternehmensname 2]-Manager sagen, ich bringe jetzt den von [Unternehmensname 4],
damit er sich mal anschaut, was machen wir anders, warum sind wir nicht so erfolgreich, dass eben dann die, also die Leute von [Unternehmensname 2] in ihrem Denken, in ihrer Kultur verankert sind, dass sie sich nicht verändern wollen oder können oder auch Angst vor dieser Veränderung haben.“
Experte Iota: „Das haben Sie jetzt sehr schön formuliert. Und vielleicht noch ein Hinweis:
die deutschen Universitäten waren eigentlich früher freie Stätten. Mittlerweile, die
Professoren die ich kenne, leiden genauso unter Vergängelung und bürokratischer Regelung.
Ich kenne viele Professoren, die kommen zu mir und sagen, weißt {du} ich habe gar keine
Chance mehr, meine Kraft in das hinein zu investieren, wo ich es hinmöchte, sprich
Forschung, Lehre und die Menschen. Das ist ein Prozess der findet statt und ich glaube dass
der viel Qualität wegnimmt. Und warum macht man die Gängelung der Professoren in
Deutschland? Weil es ein paar schwarze Schafe vielleicht mal gab, die locker gelebt haben
und jetzt ist das Misstrauen da und jetzt geht es los mit diesen ganzen balanced score cards
und Messprozessen und so weiter du so weiter. Nur damit ich nicht falsch verstanden werde,
ich bin sehr wohl auch für Dinge wie Refa du so etwas. Ich bin dafür zu messen und
Schwächen rauszufinden, aber auch das muss wieder in die Kultur integriert sein. Eigentlich
müssten alle Menschen in so einem Unternehmen und ich glaube [Unternehmensname 4]
gelingt das, müssen daran glauben, dass sie alle gemeinsam an einem kontinuierlichen
Verbesserungsprozess wirken. Mit verschiedenen Methoden, mit verschiedenen Tricks. Aber
es geht nicht darum, einzelne Projekte aufzusetzen, die Dinge besser machen, sondern es geht gemeinsam. Das ist so das. Und da haben die ohne jeden Zweifel Angst.“
INTERVIEWER: „Jetzt vielleicht noch eine Frage, die ein Bisschen reißerisch ist: wäre es aus Ihrer Sicht besser, egal was das für ein Projekt ist, immer agil zu arbeiten, immer agil
vorzugehen?“
Experte Iota: „Also ich glaube es wäre immer besser agil zu arbeiten, weil dann kommen die Leute, die ich auch gut kenne von der [Unternehmensname 7] und sagen, ja aber dieser
[Produktname 4], der ist so komplex, da kann man nicht agil arbeiten. Und das halte ich für
Quatsch. Wobei das ist wieder ein bisschen Impact Matrix. Das kann gut sein, eine Impact
Map, wenn man macht, denkt man, ich brauche das Teil ja gar nicht. Ich brauche eine Drohne, als Beispiel. Es ist verblüffend, wenn man die Dinge kritisch an geht, in der Tradition der Aufklärung sage ich mal, ja so philosophisch gesehen, durch eine Impact Matrix, dann kommt plötzlich raus, das Zeug braucht man ja gar nicht. Wir brauchen etwas ganz anderes. Also es fängt schon beim Requirement Engineering an. Da werden schon die Sünden gemacht. Und wenn es dogmatisch ist. Militär ist ein gutes Beispiel: Das Dogma ist, wir brauchen den [Produktname 4], obwohl vielleicht die neuen Feinde mit dem [Produktname 4] gar nicht mehr bekämpft werden können, ich will jetzt da die Drohnendiskussion nicht mit rein bringen… also wie gesagt es fängt ganz vorne schon mit an. Beispiel Stuttgart 21: Braucht man das wirklich. Das ist die erste Frage, die muss man klären. Und wenn man es braucht, welche Schäden verursacht man und welchen Nutzen und so weiter. Das sind alles so typische Sachen einer Impact Map und da muss man schon agil anfangen. Wenn ich schon dogmatisch anfange, sagen wir mal, ich würde jetzt sagen, alle deutschen Bahnhöfe müssen unter die Erde … das ist ja eine Aussage, kann man ja machen. Was ich sagen wollte, agiles Vorgehen kann einen schon sehr früh vor Kosten oder vor falschen Entscheidungen bewahren.“
INTERVIEWER:
„Ja gibt es auch diesen Ausspruch, ich weiß jetzt nicht mehr genau, das war einer von den Urhebern des agilen Manifests, der hat gesagt: fail early, fail cheap.“
Experte Iota:
„Genau.“
INTERVIEWER:
„Und das ist eben genau dieser Aspekt, dass {ich durch} das Agile schon früh erkenne, das läuft nicht so ganz und nicht erst später, wie es bei klassischen IT-Projekten der Fall ist, dass ich dann in der Testphase einen Fehler entdecke oder dann eine
Anforderungsänderung realisieren muss, wo ich dann das 100 bis 200-fache Betrag zahle.“
Experte Iota:
„An der ETH Zürich gibt es einen [Person 2]. Der ist ein Professor und Roboterspezialist.
Und der war jahrelang, so wie ich das gesehen habe, ein belächelter Außenseiter, weil der
gesagt hat, wir müssen Roboter ganz anders bauen. Also nicht solche Monster wie
[Unternehmensname 7] die baut…sehr lesenswerte Bücher hat der auch geschrieben. Und das ist für mich ein agiles Vorgehen. Vielleicht muss ein Roboter ganz anders aussehen, nur ich weiß es gar nicht. Und ich glaube auch, nehmen wir an, wir würden ein schönen open source Auto entwickeln, da gibt es ja Beispiele dafür. Da gibt es ja diesen Ralley Fighter in den USA, Topcoder, die haben halt Verrückte entwickelt, die unbedingt Ralleys fahren wollen. Also wenn wir beide in so einem {Projekt} drinnen wären, wir würden unser ideales Auto konzipieren. Da könnte etwas ganz anderes rauskommen, als heute auf den Straßen fährt. Also ich will nur sagen, agiles Vorgehen ist schon gut. Auch in der frühen Phase. Es kann natürlich schon sein, dass man zu so absurden Dingen kommt, wie [Produktname 4], wo es vielleicht, glaube ich zwar nicht, wahrscheinlich geht es dann auch agil besser und das Ding wird billiger und leichter und schöner, aber wo man sich einbildet, agil geht nicht. Andererseits das NASA-Projekt war total hierarchisch so wie [Unternehmensname 5], aber war hochgradig agil. Und heute sagt man, man ist sich nicht mehr sicher, ob man den Flug zum Mond noch mal schaffen würde bemannt. Das sind auch spannende Aussagen so etwas. Also ich will nur sagen, man muss sauber trennen: Hierarchisch schließt agil nicht aus, aber das geht ein bisschen auch in das Wirtschaftliche. Da gibt es dann auch Motivationsthemen aus der Betriebswirtschaftslehre und so etwas. Vielleicht da noch ein Hinweis dazu: im dritten Reich, wie da die deutsche Wirtschaft Krieg geführt hat, die war alles andere als agil. Die war total hierarchisch, aber trotzdem sehr, sehr erfolgreich, aber vielleicht hätte man bei einem agilen Vorgehen keinen Krieg geführt, Sie wissen was ich meine.“
INTERVIEWER:
„Ja.“
Experte Iota:
„Da hätte man sich Geld gespart und viel Schaden. Aber das ist jetzt hier überzogen. Ich provoziere jetzt ein wenig.“
INTERVIEWER:
„Jaja klar. Dan würde ich auf den Fragenkatalog mal wieder zurückkommen.“
Experte Iota:
„Gerne. Ich muss übrigens um 12 Uhr weg, weil es jetzt schon 11 Uhr ist…“
INTERVIEWER:
„Ja aber ich denke, das müssten wir jetzt…“
Experte Iota:
„Also Sie können auch immer wieder nachfragen, wenn Sie Lust haben…aber
gehen wir zurück.“
INTERVIEWER:
„Genau. Wodurch unterscheidet sich denn jetzt eigentlich ein agiler Vertrag von einem klassischen Vertrag? Was ich jetzt gerade in meinem vorletzten Interview sehr
interessant gefunden habe: da hat der Interviewpartner gesagt, in einem agilen Vertrag ist es
ganz besonders wichtig, das Vorgehen zu beschreiben. Die hatten eine Mischung aus SCRUM
und eXtreme Programming verwendet…“
Experte Iota:
„Das finde ich sehr gut“
INTERVIEWER:
„Wie schaut dieses Vorgehen aus, welche Rollen ergeben sich daraus für uns alsAuftragnehmer, aber auch für den Auftraggeber und an welche Verantwortlichkeiten ist das gebunden. Ist das ein Punkt, den Sie, wenn Sie jetzt Verträge haben mit einem Kunden, dass Sie auch Ihre Vorgehensweise im Projekt beschreiben im Vertrag?“
Experte Iota:
„Ich finde es ganz wichtig und ich versuche mal zu begründen, warum man es
so machen sollte: eigentlich müssten Sie fairerweise im Vertrag Dinge ausklammern. Sie
müssten sagen, das kann man kontraktieren, Vertrag heißt ja man verpflichtet sich zu etwas
und dann bekommt man was dafür. Und dann müsste man sagen, aber a, b, c, d … können wir heute nicht kontraktieren, weil uns das Wissen fehlt. Das heißt, wir haben ein Problem, weil wenn sie ein Auto kaufen und einer sagt, ja das Auto können Sie haben, aber den Motor,
denn können wir noch nicht kontraktieren – wieder nur ein Beispiel, man darf nehmen die Beispiele nicht so wörtlich, weil sie meistens nur dazu dienen, eine Aussage anschaulich zu machen – dann würde ich das Auto nicht kaufen. Und jetzt finde ich, das was Sie gesagt haben, ist eigentlich ein Trick. Das sehe ich wirklich so. Es ist ein Trick im positiven Sinne,
um Probleme zu lösen, weil man halt, so wie ich vorher gesagt habe, eine User-Story nicht
kontraktieren kann, dass man das Vorgehen beschreibt, wie man das anpackt und dadurch
auch eine Öffnung reinbringt, aber das mit dem Bewusstsein, da ist ein Problem. Es gibt vielleicht einen Lösungskanal. Aber den wissen wir noch nicht, und können es auch noch gar nicht wissen. Ich finde absolut wichtig dass immer da, wo man etwas nicht kontraktieren kann, das sich auch klar macht. Das ist so, weil wenn ich hier einen roten Kugelschreiber habe und der ist rot, und ich sage, wir wollen einen Vertrag, machen.
Porto und Papier für den Vertrag kann ich anbieten. Auch den Rest für den Kugelschreiber oder irgend so etwas. Aber wenn das Rote, was ich schreiben will nicht so einfach , dann ist es weiß ich nicht was eine gültige kosten wird Beschreibung. Und da kommt
wieder das Vertrauen ins Spiel, weil man nur das gemeinsame Vorgehen regeln kann.
Dann ist ein konstruktiver und kooperativer Dialog notwendig, den man gemeinsam formulieren und bepreisen muss. Das ist erst möglich, wenn man Meilensteine erreicht hat. Also: Man muss Meilensteine definieren und formulieren,
an denen man berichtet und könnte dann gemeinsam beschließen, wie man gemeinsam weiter macht. Also so verstehe ich Kontraktieren eines Vorgangs.“
INTERVIEWER:
„Jetzt haben Sie ein interessantes Stichwort gebracht, nämlich sie haben gesagt, der Auftragnehmer berichtet an den Auftraggeber. In den Interviews, die ich geführt habe, da war es so, die hatten nie eine 100 prozentig reine agile Projektorganisation, sondern die hatten immer auch klassische Elemente mit drinnen wie einen Projektlenkungsausschuss, wie nicht nur Meetings in den Sprint-Teams – bleiben wir jetzt am Beispiel SCRUM, daily SCRUM-Meetings, das war fest – aber die hatten natürlich dann auch Meetings über Teilprojektleiter, Programmleiter und dann Steering Committee Meetings. Genau dasselbe mit den Berichten.“
Experte Iota:
„So jetzt treffen Sie einen ganz schmerzhaften Punkt bei mir. Was mich immer
im Berufsleben am meisten demotiviert hat, waren die sinnlosen Meetings in allen möglichen
Boards. Deswegen ist auch SCRUM, dieses sich besser nicht hinsetzen sondern im Stehen meeten, im Meeting haptisch arbeiten, schnelle Entscheidungen fällen, ganz etwas anderes, einfach toll. Ich glaube, das ist so eine persönliche Annahme, die ich
aus meiner Erfahrung heraus habe, dass jedes Meeting …sagen wir das mal so: es wird umso schlimmer je mehr Personen dabei sind. Und das gilt für die Politik wie Wirtschaft und so und Gesellschaft. Ich glaube der Fortschritt, und da sind wir wieder beim eXtreme Programming, findet immer Peer-to-Peer statt, oder zumindest in sehr kleinen Runden. Eigentlich sollte man gar nicht meeten, weil das nur Zeit kaputt  macht. Man sollte nur Peer-to-Peer und in kleinen Teams arbeiten. In einem solchen Person-zu-Person-Meeting unter  vier Augen (auf jeden Fall ohne Siegen wollen, Eitelkeit, Machtanspruch, Rechthaberei … Aber diese Meetings erfordern eine gutes Miteinander. Es ist so einfach, Kommunikation ist ein schweres Thema. Und wenn wir beide uns aufeinander konzentrieren
und wir übereinander informiert sind…ich hab da mal die Eselsbrücke W-E-I-B: W für Werte, E für Erwartungen, I für Interessen und das B für Bedürfnisse. Wenn ich also einen
Gesprächspartner habe und ich weiß welches WEIB der hat in dem Sinne, ich kenne seine
Emotionen, dann kann ich für gegen mein Problem kämpfen und er kann für sein Problem kämpfen. Besonders wenn wir herausfinden, dass wir ein gemeinsames Problem haben, können wir ein gemeinsames Ziel finden. Wenn ich jetzt ein Meeting habe mit 5 Leuten, die alle andere WEIBs haben, andere Interessen, andere Bedürfnisse, dann wird die Kommunikativ schwierig, ja. Das Meeting fängt an, sich im Kreis zu drehen. Und ich glaube, dass diese vier-, acht- oder 12-Stundenmeetings, wo ich drinnen war, die hätte man durch
kleine Peer-to-Peer-Runde vorher, die vielleicht mal eine oder zwei Stunden gedauert, wo manin aller Kürze und Knappheit sich einmal klar macht, was man will, die Entscheidungsfindung positiv beeinflussen. Stellen Sie sich einmal einen
Selektionsprozess vor, Sie sind ein Unternehmen, dass verkauft Abenteuer und Sie
haben 10 Abteilungen, die Abenteuer erfindem! Sie müssem sich aber dreieinigen. Weil Ihre Ressourcen endlich sind. Das ist so eine klassische Entscheidungssituation. Sie können nur drei ins Programm aufnehmen, das heißt, Sie müssen sieben streichen. Und das sind so die Schwierigkeiten eines Meeting. Also ich glaube wirklich, diese Meeting-Unkultur und die hat zugenommen in der Wirtschaft und ich weiß gar nicht, wie das funktioniert, mag mit Exchange und solchen Kalendern zusammenhängen, dass jeder sich beim nächsten einen freien Slot schnappt und sich da reinpresst. Die müsste man dringend zurück{drehen}. Im Agilen wird die zurückgedreht, im Agilen wird gearbeitet und nicht sinnlos gemeetet. Ich habe einmal einen [Unternehmensname 2]-Programmierer, der eine schwere Straftat
begangen hat, im Gefängnis in Stadelheim betreut. Der Mann war von einer
Effizienz, die war wirklich einen deutlichen Faktor höher, also eher so 5 als wie er bei
[Unternehmensname 2] gearbeitet hat. Er ist natürlich gut geführt worden, ich habe ihm die
jeweiligen Arbeitspakete gebracht, aber der war so produktiv, weil er im Gefängnis – das ist jetzt makaber, aber es ist halt so – keine Störungen durch unnötige Meetings hatte. Und dieses Managementmeeting sind mir ein Dorn im Auge. In agilen Teams will ich keine mechanistische Rollenverteilung und Spezialisierung à la Tayor. Ich meine jeder , jeder Mensch muss im Unternehmen muß am Erfolg verantworten mitarbeiten und mitwirken. Und es wird sein, wenn ich so einen List der notwendigen Fähigkeiten aufmale, dass dann vielleicht der eine aufgrund seines Talents mehr Configuration Management macht oder mehr Quality Management oder mehr Projektmanagement. Das sollte sich im Team „natürlich“ ergeben. Und das ergibt sich im agilen Unternehmen. Manche Qualitäten – wie Verantwortung fürs Projekt muss in jedem drin sein. Und das ist jedem, um am
Beispiel zu bleiben, der [Person 1] hat es halt wirklich geschafft und klar gemacht, du machst
die Qualität für dich zuerst einmal.  Nur wenn dein Modul toll ist und das von deinem Partner rechts nicht fertig wird, hilfst es Dir auch nichts. Also gutes Projektmanagement, also nicht dieses tayloristische, muss immer Team-basiert sein und wird in guten Teams immer
bottom up passieren.  [Unternehmensname 4] zum Beispiel, haben es
umgedreht, da schaffen die Ingenieure an. Und eigentlich sollte jeder Mitarbeiter bei [Unternehmensname 4]  programmieren können. Die haben früher einen Marketing-Chef
nicht eingestellt, der nicht programmieren konnte. Das fand ich sehr gut. Also bitte, die Leute
sollten alle mitarbeiten im Projekt, an dem, was die Aufgabe ist und nicht anonyme, entpersonalisierte Psychologen und Projektmanager oder gar funktionale Systemagenten sein. Das geht schief und da könnte ich auch viele Beispiele bringen. Das geht dann gut, wenn der sich reinarbeitet in die das zentrale Thema, in den Projekten „hands-on“ macht und im Team sagt, hey du, da helfe ich dir, das Skript schreibe ich noch nebenher für Dich. Aber dieses tayloristische Prinzip (der eine programmiert, der andere plant, designt, testet und verkauft) ist meines Erachtens mittlerweile überholt, auch weil den Menschen nicht-hierarchischen und vernetzte Organisationsform bevorzugen. Und sie dürfen eines nicht vergessen: wir sind dabei und das wird noch schreckliche haben, den gesamten Innendienst wegzurationalisieren. Wenn Sie bei einem Unternehmen wie [Unternehmensname 8] arbeiten und bei vielen anderen mittlerweile schon, dann haben Sie
auch als Mitarbeiter nur noch  Selbst-Service. Ob Reisekostenabrechnung oder was auch immer, da gibt es eine App dafür. Die müssen Sie ausfüllen, dann bekommen Sie ihr Geld. Wenn nicht, bekommen Sie kein Geld. So einfach ist das. Wenn ich zu blöd bin meine Reisekosten – das ist auch nur ein einfaches Beispiel, das geht viel weiter – nicht ausfülle, bekomme ich kein Geld. Und viele machen das auch, weil es ihnen zu blöd ist. Solche Leute gibt es. Die verdienen halt sehr gut, weil sie viel Zeug verkaufen. Der ganze Innendienst wird
verschwinden, weil ich brauche den nicht mehr. Aber manchen konzentrieren sich dann in der Arbeit auf das Ausfüllen ihrer Reisekostenabrechnug. Also ich will nur eines sagen, es gibt immer mehr Verpflichtungen, die mache dann am Feierabend, da löse ich solche Dinge und das kommt in einer Konsequenz, da sind wir erst am Anfang. Das bei all den schönen Versicherungen, bei den ganzen Palästen werden Leute ohne Ende freigesetzt werden, die bisher im Innendienst waren. Und die bringen nichts und werden abgeschafft. Jetzt sind wir beim Außendienst, der ja den Umsatz bringt. Entschuldigung, was haben Sie gefrag, was war das nochmal, ?“
INTERVIEWER:
„Ich habe über die Meetings {und} die Projektorganisation gesprochen, dass die in den meisten Projekten nicht 100 prozentig agil ist.“
Experte Iota:
„Genau. Es gibt bald nichts mehr zum Meeten. Es gibt Entscheidungen, aber klar sind, weil sie Regeln und Prozessen folgen. Was will ich da noch viel meeten. Aber trotzdem gibt es immer mehr Meetings. Weil alles – hausgemacht – immer komplizierter wird. Die sogeannten Steering-Meetings und -Commitees haben mich wahnsinnig geärgert. Die schätzen und schätzen doch of tnur. Wenn ich hier so etwas Kritisches habe, dann verteile ich
zuerst einmal so Haft-Zettel und dann tun wir die Wände vollpflastern und schieben die Zettel hin und her. Und erinnere, dass wir an einem Strang ziehen müssen und unser Feind das Problem ist. In fremden Meetings erlebe immer wieder ich, dass irgendwelche an dem Tisch zu Feinde werden. Ich meine, dass diese großen Steuerungsmeetings tödlich, weil nicht zukunftsorientiert sind. Und sind wir ehrlich, ich erlebe ja kein Meeting mehr, wo nicht die Hälfte zu spät kommt. Meistens, weil die Teilnehmer in einem anderen Meeting war. Und die andere Hälfte, die langweilt sich und holt ihre Smartphones raus und tippt rum. Also ich will nur sagen grauenhaft, grauenhaft. Aber das war früher ähnlich. Also die Menschen, die ich am meisten bewundert haben, das waren wirklich [Person 3] bei [Unternehmensname 2] und andere, die dann in so ein Mammutmeeting reinkamen und gesagt haben, ich habe hier nichts verloren, ich gehe wieder, gebt mir Bescheid, wenn ihr am Punkt seid. Also Meeting-Unkultur hat im agilen Raum nichts verloren. Weil wenn, dann feiert man. Das finde ich gut, dass man sich mittags am Kaffeeautomaten trifft, dass man sagt, hey super Sprint ist gut gelaufen, machen wir eine Party, Bier, Leberkäse, vegetarisch, was auch immer, alles in Ordnung. Also bitte feiern und nicht meeten.“
INTERVIEWER:
„Okay. Das ist ein wirklich interessanter Punkt. Jetzt wie stehen Sie denn eigentlich zum Thema Kontrolle im Projekt? Wenn ich ein agles Projekt habe, brauche ich dann, weil in diesen Meetings wird ja auch immer ein Stück weit mit kontrolliert, macht der
seinen Fortschritt, arbeitet der richtig etc. Genauso mit dem Berichtswesen, den Reports, die
abgegeben werden müssen regelmäßig. Das wird ja zum Teil alles detailliert, minutiös im
Vertrag festgeschrieben. Wie stehen Sie denn zu diesen Kontrollmechanismen im Grunde
genommen? Das heißt, wie kontrollieren Sie Ihre Projekte? Bzw. wie kontrolliert der
Auftraggeber den Auftragnehmer in einem agilen Projekt und braucht man eigentlich irgend
welche zusätzlichen Kontrollmechanismen als die, die ein agiles Vorgehen ohnehin schon
liefert, dadurch dass der Auftraggeber so eng mit dem Auftragnehmer zusammenarbeitet, eben dass die Leute von der Fachabteilung im Team integriert sind?“
Experte Iota:
„Also jetzt haben Sie wieder eine sehr schwierige Frage gestellt. Ich persönlich glaube, ohne Kontrolle geht es nicht. Ich meine und das haben wir auch gemacht, man muss irgendwie schauen, was rauskommt. Das was Sie so erzählt haben, so viel präzise im Vertrag drinnen steht, minutiös halte ich für Blödsinn, weil Zukunft ist nicht vorhersagbar. Zur Zeit ist das Wort „Kontrolle“ das Problem. Da ist also die Empfehlung von vorhin, lieber das Vorgehen beschreiben, nach meiner Meinung besser. Jetzt zu dem Thema: das Problem ist ja das. Man sagt immer, es gibt Worte und es gibt einen Schatten von Worten. Und Kontrolle ist
schon fast der Schatten von einem guten Wort. Ich weiß nicht was das gute Wort ist, es könnte Review sein. Wenn ich, ich muss die Dinge reviewen und ich muss sie, glaube ich, um
schneller ans Ziel zu kommen, messen. Da habe ich ja vorhin das Wort Refa erwähnt, das ich
gar nicht so blöd fand. Refa, da misst man zum Beispiel die Wege zwischen den Maschinen
und die Arbeitsabläufe und dann entdeckt man halt Schwachstellen. Hat aber nichts mit
Kontrolle zu tun. Das ist eigentlich im Geiste der kontinuierlichen Verbesserung, einverstanden?“
INTERVIEWER:
„Ja.“
Experte Iota:
„Thema zwei: Review. Ich glaube, weil halt, der eine ist besser, der andere ist schlechter, der andere lernt noch und so weiter, ich muss schauen, was passiert. Ich glaube
wieder am besten sind Peer-to-Peer-Reviews, die man auch durchaus mischen sollte, das ist ja auch eine Form von dem schlechten Schatten Kontrolle und da muss man auch Folgen,
Konsequenzen ziehen. Wenn ich ein agiles Team habe und da ist ein Programmierer drin, der
macht einen super Eindruck und alle sind begeistert von dem, aber der produziert nur Scheiß, dann muss ich ihn rausnehmen. Vielleicht finde ich eine andere Aufgabe für ihn, vielleicht ist er im testen ganz gut oder irgendetwas anderes oder im Brotzeit holen, völlig egal. Die Frage ist nur, wie man die Reviews macht wiederum. Und da bin ich jetzt wieder ein großer Anhänger {davon}, was wir Craftmenship nennen, da gibt es übrigens auch berühmte Söhne der TU München, die da Unternehmen mit gegründet haben, die sehr erfolgreich sind. Da gibt es sogar ein Video bei mir im YouTube-Channel dazu. Zum Einen [Person 4] ist das, die sagt da wieder auf hohes Vertrauen, wie schafft man das? Es gibt immer Meister und Lehrling. Vielleicht nicht immer in der Schwarz-Weiß-Färbung, manchmal ist der Meister nur leicht überlegen dem Lehrling, oder er ist in manchen Dimensionen überlegen und wo anders unterlegen, wie auch immer. Das Wort ist schon blöd überlegen und unterlegen. Da ist es halt ratsam, dass vielleicht zuerst der Lehrling den Meister reviewed. Also ich meine ohne Kontrolle kommt man nicht aus, aber die Kontrolle muss man anders gestalten. Eben dass das Vertrauensverhältnis nicht grundsätzlich kaputt geht. Und das kann man organisieren und wenn ich ein Meister bin und ich hole mir 5 Schüler und zerfetze denen ihren Codes, dann kann man sich vorstellen, dass das schlecht ist. Wenn ich mir einen Schüler hole und dem zuerst einmal meinen Code zeige, dann wird er mir auch sagen, hey du, das hätte ich aber besser gemacht, dann werde ich sagen, super, guter Hinweis. Das mache ich das nächste Mal. Anschließend aber kann ich dem sagen oder ich muss dem vielleicht gar nichts mehr sagen, weil er schon kapiert hat, wenn der seinen eigenen Code wieder sieht, was er falsch gemacht hat. Und so meine ich, geht es um eine Art konstruktive Kontrolle im agilen Raum. Habe ich das jetzt verständlich ausgedrückt?“
INTERVIEWER:
„Ja auf jeden Fall. Ich kann jetzt eben auf meine Erfahrungen, auf die
Ergebnisse, die ich aus den anderen Interviews herausgezogen habe zurückreifen. Da hat auch ein Interviewpartner gesagt, reine Kontrolle, um der Kontrolle willen, dass zum Zeitpunkt X ein Report erstellt wird, macht keinen Sinn, sondern ich muss konstruktiv damit arbeiten können. Der Report, der ist wichtig, aber es muss kein Report sein, der wird durchgelesen, passt, verschwindet in der Schublade, sondern muss wirklich ein Arbeitsdokument sein.“
Experte Iota:
„Aber das darf ich jetzt noch unterstreichen. Wie reporte ich jemandem. Es gibt
Unternehmen, da gibt es ja wunderbare Gruppen in Google Plus, da ist Reporting gestrichen,
weil Reporting automatisch erfolgt. Aber das Peer-to-Peer-Review ist da ganz groß. Natürlich muss man Strategien entwickeln, dass man das nicht so macht, dass die großen Fische
durchschlüpfen, sage ich mal. Aber das würde ich wirklich unter Quality-Engineering hier
dann verstehen. Und natürlich habe ich irgendwo, so wie ich ein Quality-Engineering habe,
muss ich auch irgendwo ein Effizienzengineering machen. Aber das sind ganz neue Begriffe.
{Man} muss natürlich Dinge finden. Damit meine ich jetzt nicht die Trial & Error Dinge, wo
ich weiß, dass das unter Umständen nicht effizient ist, sondern da meine ich die Dinge, wo die normale Handwerkliche Arbeit nicht effizient ist. Und natürlich hilft es nichts, wenn einer das Holz, das er drechselt noch 17 Mal poliert, damit es besonders schön ist, wenn ich es nur ein Mal poliert haben will. Aber das ist meines Erachtens in agilen Projekten, fällt diese Art, das ist ja auch die negative Seite von ich sag mal (Wort nicht verstanden), dass man auf das Team auch einen großen Gruppendruck auflegt. Das ist ja durchaus etwas, wo man auch  kritisch sogar sein kann. Ein agiles Team wird sich in hohem Maße selbst kontrollieren und da kann es dann durchaus auch zu Burn-Outs kommen, weil dann plötzlich Gruppenprozesse entstehen, die unerwünscht sind. Das wäre wieder meines Erachtens {nach} die Aufgabe des SCRUMMasters zu erkennen, wenn man nach SCRUM arbeitet und dem entgegen zu wirken, wenn man so Rollen vergeben will. Aber es ist ganz klar. Agile Teams haben einen riesen
Gruppendruck, weil irgendwo gibt es auch immer Kohle dahinter. Und viele Teams die
arbeiten so, dass wenn das Projekt erfolgreich ist, wird die Kohle verteilt, die man dafür
bekommt und die Kohle wird sogar von vielen Teams frei verteilt. Das heißt, die dürfen das
Geld unter sich so verteilen, das ist durchaus agil, normal. Nur, was das an einem
Gruppendruck auch implizieren kann, es gibt ja immer zwei Seiten: Gold und Gold, das nicht
glänzt sozusagen. Insofern, ich glaube, Kontrolle findet automatisch statt und was man
organisieren muss, ist der Review. Da gibt es eben verschiedene Dimensionen, Quality,
Effizienz und so weiter.“
INTERVIEWER
„Sind dann eigentlich zusätzliche Kontrollmechanismen, die ich irgendwie
vertraglich definiere, bleiben wir beim Beispiel Reporting und Meeting, ist das dann
überhaupt im Sinn des agilen oder beeinträchtigt das eine agile Arbeitsweise nur?“
Experte Iota:
„Also ich würde da ein bisschen ausweichend antworten. Meine Sorge ist, dass
es fast immer beeinträchtigt. Ich glaube wirklich, ich habe ja vorher von Klarheit gesprochen.
Klarheit ist so ein ganz hoher Wert sowohl in der Unternehmensführung, in einer Familie,
überall. Und wenn es gelingt diese Klarheit herzustellen, zum Beispiel bei unserem Produkt
damals mussten alle Entwickler in einer gewissen zyklischen Reihenfolge zum Kunden gehen
und dadurch ist die Klarheit entstanden. {Man} hat gradiert, was eigentlich Sache ist. {Die}
haben tolle Sachen gradiert und mit zurückgebracht. Die Kunst ist die Klarheit herzustellen.
Das könnte Aufgabe des Product Owners sein bei einer SCRUM-Interpretation. Und wenn ich eine Klarheit und Transparenz habe, die auch kommuniziert wird und ich meine, wir haben doch wunderbare Social Media Werkzeuge mittlerweile. Wenn ich, ich meine, ich habe ja viele Projekte mit Freunden, wo ich etwas mache, ja warum nutze ich die nicht, das verstehe ich auch nicht. Warum habe ich nicht eine Google Plus Gruppe, Community, wo man eben die Sachen reinschreibt, die einem auffallen. Ich garantiere, das ist auch einmal eine Peer-to-PeerKommunikation, weil ich schreibe etwas rein und einer liest und er schreibt was dazu und ein Anderer liest und schreibt was dazu. Das ist ja eigentlich keine Gruppenkommunikation auch, wenn es eine Community ist. Und ich glaube, das sind so kleine Werkzeuge, die die Methoden unterstützen können. Da merke ich halt, so Google-Geschichten, das ist ein Werkzeug, das man anfassen kann. So eine Google Plus Gruppe, die auch frei sein darf. Das ist etwas ganz wichtiges. Auch Wikis und so etwas, da darf kein Wächter drum sitzen. Da muss jeder aus dem agilen Team seine Bedenken und Sorgen einbringen können. Und ich glaube, das sind dann bessere…stellen wir uns von wir hätten so eine Google-Gruppe von soeinem Bahnhof und dann schreibt der rein, du die eine Weiche, die knirscht oder so oder ähnliches, das ist viel besser als wenn, das klingt jetzt ein bisschen utopisch, aber wenn eineralle vier Wochen die Weichen anschaut. Da kann ich schnell streiten ist vier Wochen oder ein Jahr oder eine Woche das richtige. Auch wieder ein Beispiel. Also ich glaube, der Kontrolle kommen wir nicht aus, wir verlagern sie in die Teams rein, was vielleicht zu neuen Härten führt, dass der Schwache im Team plötzlich die Prügel abbekommt, du Arschloch hast unsere Prämie ruiniert, hau ab. Da gibt es in Japan tolle Untersuchungen, wie sie da in den Fabriken die Ingenieure abgeschafft hatten und die Teams rote Knöpfe hatten, um zu drücken, wenn das Band quietscht. Wenn das Band quietscht und es geht kaputt und man hat nicht gedrückt verliert man viel Geld, weil das Band dann länger still steht. Wenn man dann zu früh drückt verliert man auch Geld. Dieses Dilemma meine ich jetzt. Die rote Knopf-Geschichte. Also ich glaube, dass wir unsere Welt pervertiert haben im Sinne von Kontrolle, Überwachung, Hierarchie und dass der agile Aufbruch ist einen Teil der Pervertierungen abzuschaffen, wobei aber neue Dinge entstehen werden, die nicht immer optimal sind. Das ist also meine Meinung. Also Ausbeutung ist da auch durchaus sehr gut möglich.“
INTERVIEWER:
„Dann wären wir auch schon beim letzten inhaltlichen, großen inhaltlichen Punkt angelangt. Das wäre dann der Projekterfolg von agilen Projekten ganz allgemein. Wie beeinflusst ein agiles Vorgehen das Ergebnis bzw. den Projekterfolg auch hinsichtlich der Dimensionen Zeit, Budget, Qualität des Produkts oder des Projekts?“
Experte Iota:
„Okay. Oh mei, das ist wieder so eine pauschale Frage. Ich darf sie auf meine
Art und Weise beantworten.“
INTERVIEWER:
„Ja gerne.“
Experte Iota: „Ich glaube das ist ein großer, indirekter Wert. Ich habe ja vorher gesagt,
managen heißt, Veränderungen zu bewirken. Aus heutiger Sicht, wenn es darum geht führen
zu definieren, meine ich die Aufgabe des Führenden ist, das habe ich, glaube ich, schon mal
erwähnt, so im Prinzip Voraussetzungen zu schaffen, dass in der Gegend, wo er wirkt, sich
das personale Leben der Menschen die da mitwirken eher mehrt, eher erweitert, denn
reduziert wird. Das ist eine ganz andere Führungsdefinition. Ich glaube, wenn mir das gelingt, wenn ich ein Team habe mit 20, 50, 100, 200 Leuten, völlig egal, und ich schaffe eine
Umgebung, in der diese Menschen merken, hey, hier können wir uns entwickeln, hier können
wir uns entfalten und das schaffe ich mit agilem Vorgehen, weil das ist nachvollziehbar. Da
muss auch immer ein Bisschen das große Wort der Sinnhaftigkeit mit im Raum stehen. Ich
weiß nicht, ob sie das letzte brandeins gelesen haben … hallo?“
INTERVIEWER:
„Ja ich bin noch da.“
Experte Iota:
„Wenn Sie das letzte brandeins gelesen haben im Mai, nein Juni war es. Da
war eine große Überschrift „Montags fühle ich mich immer zum Kotzen“ oder so ähnlich.
Und da gibt es so Zahlen, dass 87% der Deutschen ungern in die Arbeit gehen mittlerweile.
Das hat sich signifikant verschlechtert und die Meinung der Experten, die ich schätze, ist die,
dass die Motivationslage gefallen ist und zwar deswegen, weil man keine Sinnhaftigkeit mehr
sieht. Zum Beispiel Shareholder Value ist für mich als Angestellter macht es keinen Sinn.
Wenn mein Vorstand erklärt, wir müssen an der Börse 25% Rendite haben, damit der Kurs
nicht fällt, das ist nicht {das}, was mich motiviert als Mitarbeiter. Und ich glaube diese
Sinnentleerung, die ja scheinbar in vielen Bereichen stattfindet, die darf nicht im
Unternehmen stattfinden und ich glaube agiles Vorgehen kann auch diesen Effekt mit
bewirken, weil die Leute merken, es macht einen Sinn. Und dann ist es, glaube ich ein riesen
Vorteil.“
INTERVIEWER:
„Ja so wie ich das verstehe, vertreten Sie auch die Ansicht, dass eine agile
Arbeitsweise, sei es jetzt allgemein oder im Projekt, den Mitarbeitern die Möglichkeit gibt
sich selbst eben zu entfalten, zu entwickeln und dass sie auch die Sinnhaftigkeit ihrer
Tätigkeit sehen und erkennen.“
Experte Iota:
„Das fängt schon bei dem Mitspracherecht an. Wenn man morgens, natürlich
muss man auch mal in den sauren Apfel beißen, aber wenn morgens die Arbeiten verteilt
werden und ich habe das 10 Mal und ich kann das ganz toll, weil ich der große QueueManager bin und ich kann Queues schreiben besser als jeder andere und ich sage meinem Team, du ich möchte mal keine Queue schreiben, ich möchte einen Dispatcher schreiben, lasst mich das mal machen, dann kann man das ganz kurz diskutieren. Dann gibt es schnell eine Entscheidung. Entweder wird gesagt okay, du darfst das machen oder man sagt, ne du, dieses Mal ist es ganz wichtig, du musst noch einmal einen Queue-Manager schreiben, aber beim nächsten Mal nicht mehr. Und wenn man ein Recht hat mitzubestimmen, das ist ja immer, wenn ich von Selbstbestimmung und Selbstorganisation rede, wenn ich eine Chance habe, mitzubestimmen was ich machen muss, aber auch, wenn ich nicht machen darf, was ich machen will, die einen Sinn macht, die ich akzeptieren kann, dann ist das doch besser als wenn ich da irgendwie so als Zahnrädchen einer Maschine rumsitze. Und auch natürlich wird ein guter sagen, ja dann probiere es doch mal, können wir das Risiko eingehen. Meistens führt das einfach zu gutem Fortschritt. Natürlich hängt der sich doppelt rein. Natürlich liest der noch Nachts seine Bücher und so etwas
Naja was ich sagen wollte, ist nichts anderes: Menschen sind leistungsfähiger, wenn sie merken, sie machen Fortschritt, sie dürfen Neues ausprobieren, sie können das aber abstimmen im Rahmen des Verträglichen ja.
INTERVIEWER:
Okay. Sie haben jetzt sicher in Ihrer sehr langen Zeit, in der Sie Erfahrungen gesammelt haben mit agilen Projekten auch Projekte gesehen, die gescheitert sind. Woran scheitern denn agile Projekte? Also was sind die Gründe, warum so ein Projekt nicht erfolgreich abgeschlossen werden kann?“
Experte Iota:
„Also ich persönlich habe ein Projekt, das agil Geführt wurde, noch nie scheitern gesehen, Und selbst wenn es abgebrochen wurde, ich mein, das ist ja das nächste Problem. Eigentlich müssen Sie sich vorher schon überlegen, was schließt das Projekt ein. Das macht ja auch keiner. Ich muss ja eigentlich Sollbruchstellen definieren oder mir zumindest vorbehalten. Es kann sein, dass ich merke, das Projekt ist sinnlos. Und wenn erkannt wird, dass das Projekt sinnlos ist und es einstellt, ist es ein gutes Projekt. Wenn ich jetzt aber ein Projekt unbedingt brauche, weil es einen Sinn macht und machbar ist, dann darf es doch nicht scheitern. Die Agilität muss einen Wert erzeugen.“
INTERVIEWER:
„Jetzt würde mich interessieren, was auch in den Interviews des Öfteren erwähnt wurde, war das Risiko bei einer agilen Entwicklung, dass am Ende etwas ganz anderes rauskommt, was man sich am Anfang vorgestellt hat…“
Experte Iota:
„Das ist aber kein Risiko. Das ist ja die Hoffnung.“
INTERVIEWER:
„Okay, das sehen Sie positiv? Das wurde von den Interviewpartnern als eher negativ gesehen und dann auch als quasi gescheitertes Projekt bezeichnet, wenn am Anfang, wenn ich sage, ich möchte ein bestimmtes System haben, was einfach ein bestimmtest Ziel hat und dann am Ende kommt ein System raus, was dieses Ziel gar nicht erfüllt. Ist das in Ihren Augen dann ein gescheitertes Projekt oder ist das trotzdem ein erfolgreiches, abgeschlossenes Projekt?“
Experte Iota:
„Im Gegenteil. Ich halte die Anforderung, das es funktionieren, muss für fragwürdig. Das sind vielleicht Sprüche, aber der Weg ist das Ziel. Was ich Fachabteilungen gesehen habe, die so einen Schwachsinn spezifiziert haben, gerade bei Automatisierung von IT, weil die in der alten Denke verhaftet waren von Aktenordnern und Papier und Durchschlägen und so weiter und jetzt sollen die sich vorstellen, wie das mit einer App funktioniert. Das gelingt doch meistens gar nicht. Früher haben wir etwas gemacht, schon vor Jahren, das hat Rapid Prototyping geheißen. Und oft haben die Leute den Prototypen gesehen und sagen, hey das wollen wir ja gar nicht, obwohl der genau das gemacht hat, was die aufgeschrieben haben. Ja das ist eine Methode, die war vielleicht vor 20 Jahren sehr beliebt. Rapid Prototyping.“
INTERVIEWER:
„Also ich hab das, muss ich dazu sagen, vor einem Jahr an der Uni angewandt, da habe ich Entwicklungspraktikum gemacht mit der [Unternehmensname 9] zusammen, da mussten wir einen Prototypen für einen Mobilitätsdienst zu entwickeln. Da haben wir dann auch sehr schnell angefangen einen evolutionären Prototypen zu haben, wo wir das Interface erstellt haben und so ein paar Funktionalitäten rein, ohne dass das im Hintergrund ausprogrammiert ist und da haben wir dann auch in regelmäßigen Abständen vor unseren Betreuern und den Leuten von [Unternehmensname 9] präsentiert. Die haben auch immer ihr Feedback gegeben: das wäre schön wenn man das so macht, kann man das nicht so…und ich fand diese Methode sehr interessant. Das steckt ja auch dahinter bei diesem Rapid Prototyping, dass ich das immer wieder anpasse, aber…“
Experte Iota:
„Sie dürfen nur nicht in die Gefahr rein laufen, dass Sie vor lauter Veränderungen kein Ende finden. Und da helfen diese User-Stories, dass Sie eben wirklich sauber und da ist die Impact Map ganz gut, dass Sie wirklich sauber das trennen, was notwendig ist, nur das machen und den Rest dann irgendwo im Backlog reinschreiben oder wo anders aufheben, aber eigentlich ignorieren mit der kleinen Einschränkung, dass eine Architektur immer so gut sein muss, dass sie, wie soll ich sagen, ausbaufähig ist. Oder aber noch besser eine Architektur, die so, klein ist, dass man sie notfalls durch ein anderes System austauscht. Dass es also nichts kostet zu sagen, hey übrigens…Datenbanken waren ein großer Fortschritt nicht? Sobald ich eine Datenbank hatte, war ich schon mal von der Architektur sehr flexibel. Zum Beispiel mit einer Zwischenschicht wie Hybernate oder so etwas und schon habe ich viele Voraussetzungen geschaffen, das Ding auch dann lernend weiterzuentwickeln. Aber schauen Sie, es ist wirklich so, da kenne ich viele Projekte. Wenn Sie die Fakten zusammentrommeln und die machen irgendeine Automatisierungsstufe und entwickeln irgendeinen Prozess, der früher händisch erfolgt oder remote (mit batch) erfolgt ist, den machen Sie dann als App neu, dann bekommen Sie eine Masse von wirklich dann Use Cases. Und es ist wirklich immer so, die werden dann runterimplementiert, ganz gewissenhaft, ganz toll, in sich konsistent mit Aris oder anderem Werkzeug und das, was benutzt wird im System, ist halt ein Drittel der Funktionen. Und Sie vergessen immer wahnsinnig viel, weil Sie plötzlich sehen, hey in dem neuen System passieren ganz andere Fehler als vorher. Und das Schlimme ist das: die Anwender – da habe ich auch so ein tolles Beispiel mal erlebt – die wollten vom ersten Tag an Mandantenfähigkeit haben, weil sie die Idee hatten, dann können sie es politisch besser durchsetzen, weil man das noch für etwas anderes brauchen könnte. Und da war die Kunst des Beraters zu sagen, bitte wir legen die Mandantensicherheit rechts an die Wand, wir bauen eine Architektur, dass man einfach eine andere Datenbank nimmt, dann ist es halt ein zweiter…oder irgendwie so etwas, aber lass uns keine Sekunde darüber nachdenken und lass uns auf die wichtigen Kernprozesse konzentrieren. Und das müssen die gescheit machen und dann lernen die am System. Das ist ja alles so altmodisch. Die Quick Wins. Erst einmal so die Quick Wins bauen und dann lernen. Und wie gesagt, ich meine, wenn ich eine Website mache für etwas, was eigentlich jeder auf dem Handy haben will, dann bin ich der Entwicklung nicht gefolgt.“
INTERVIEWER:
„Das heißt beim agilen Projekt ist es im Endeffekt so, der Kunde bekommt das, was er wirklich braucht, was einen wirklichen Mehrwert liefert und nicht einfach nur das, was im Lasten und Pflichtenheft spezifiziert ist.“
Experte Iota:
„Genau so ist es.“
INTERVIEWER:
„Warum werden dann nicht heutzutage alle Projekte agil gemacht?“
Experte Iota:
„Das ist eine gute Frage. Nein ich glaube, es ist eine Kulturfrage. Was ich
vorher gesagt habe: warum gehen noch so viele Menschen mit Anzug und Krawatte in die
Firmen? Ein Freund von mir, das ist der [Person 5], der hatte das Softwarehaus
[Unternehmensname 10], ein tolles Softwarehaus in der Schweiz gegründet und erfolgreich gemacht, dann wollte er seine Führungsmethoden bei der [Unternehmensname 11], einem großen Schweizer Konzern im Finanzbereich, ausprobieren und unter Beweis stellen. Dann hat er alle – er war der CIO, also vom Unternehmer in die Rolle eines angestellten Top-Manager, der sein Unternehmen [Unternehmensname 10] verkauft hat, um nicht
Interessenskonflikte zu bekommen, so stinkreich geworden, aber er wollte noch einmal etwas
ausprobieren. Da hat er alle 2000 Programmierer der [Unternehmensname 11] einberufen in
einen großen Saal in der Schweiz, und hat gesagt, „Freunde, Ihr seid Programmierer und keine Banker, jetzt legt mal eure Krawatten ab. Weil beimProgrammierer stört die Krawatte bloß beim Denken“. Der [Person 5] hat immer zu solchen Schau-Effekten geneigt, das war so sein Stil. Aber warum erzähle ich das? Ich sitze jetzt mit einer kurzen Hose im
Büro am Telefon. Das mache ich seit drei Jahren im Sommer konsequent so. Ich habe mich so beschissen gefühlt noch vor 5 Jahren, dass ich mit einer kurzen Hose ins Büro gehe bei dem Wetter. Die Mädels haben alle Kleider an, dass man ihre Beine sieht . Ich will nur sagen: Kulturelle Veränderung braucht halt seine Zeit und wenn man Evolution liest, dann sagt man, es muss halt eine Generation aussterben und in 50 Jahren macht man es dann agil.
Das ist wie die Autofahrer.  Warum fahren noch so viele Leute Auto? Das ist auch ein Quatsch, sage ich.“
INTERVIEWER:
„Das heißt, Sie würde das Agile auch als quasi einen Lernprozess bezeichnen, dass die Auftraggeber, wie Auftragnehmer erst lernen müssen, was bedeutet es denn eigentlich agil zu arbeiten, welche Vorteile bringt das. Und dann wird sich das auch nach und nach in Zukunft weiter durchsetzen.“
Experte Iota:
„Und auch da gibt es die noch die alten Sprüche, dass die schnellen Firmen die alten auffressen werden und so etwas. Und sie zeigen, dass es passiert. Das sehen wir doch an den
Beispielen.“
INTERVIEWER:
„Das wäre es dann von meiner Seite. Ich bedanke mich wirklich sehr herzlich für Ihre Zeit. Es war wirklich ein sehr interessantes Gespräch.“
Experte Iota:
„Ging mir genauso! Gern geschehen.“

Ende der Aufzeichnung.

Wenn ich an diesem Text arbeite und ihn weiter glätte und verbessere, dann wird mir klar, dass dieses „kleine Interview“ zu meiner intimen Lebensbeichte geworden ist, in dem ich sehr emotional versucht habe, mein Denken und Handeln als AGILER Unternehmer zu erzählen. Danke fürs Lesen!

RMD