Warum es nicht besser wird

Neulich im Hochseilgarten: Einweisung in Gurt und Sicherungsanlage ausschließlich in großer Gruppe. Viele Personen werden gleichzeitig eingewiesen, dann wandern viele Personen gleichzeitig zu einem Hochseilparcours, dann warten viele-1 Personen, dass sie mit der ersten Station beginnen können.

Es staut sich überall: Vor der Einweisung solange, bis mit der großen Gruppe begonnen wird, vor dem Hochseilparcours und auch noch im Hochseilparcours auf den Plattformen zwischen den Stationen.

Überall Nadelöhre, Flaschenhälse, Engpässe. Manche davon unvermeidlich: aus Sicherheitsgründen darf zu jeder Zeit nur eine Person eine Station absolvieren. Andere aber selbstgemacht: das Warten vor der Einweisung und beim Einstieg in die Parcours.

Doch warum wird das nicht besser? Denn das war nicht nur am letzten Wochenende so, sondern auch schon vor zwei Jahren. Es kommt nur schwer zu einem Fluss der Besucher durch die Stationen. Meist stockt es – auch wenn der Hochseilgarten noch nicht ausgelastet ist.

Das ist für mich als Besucher nervig. Den Hochseilgarten als Organisation scheint es aber nicht zu stören. Dort konzentriert man sich auf lokale Effizienz statt globalen Fluss. Es ist wichtiger, dass Mitarbeiter die Einweisung nicht so häufig machen, statt dass die Besucher nach Ankunft flüssig in die erste Station einsteigen können.

Denn nichts anderes soll ja die Einweisung großer Gruppen bewirken, als dass man dabei Personal-Zeit spart. Sie dauert immer gleich lang, egal ob sie für 2 oder 20 gemacht wird. Dann doch besser für 20, oder?

 

Neulich im Restaurant: Da sitzen Kollege Stefan Lieser und ich in der Schweiz an einem sehr lauen Sommerabend an der murmelnden Limat draußen beim Italiener. Die Bedienung ist zuvorkommend, die Bestellung wird zügig aufgenommen, das Essen wird bald gebracht – aber beim Bezahlen dauert es lange, sehr lange. Die Bedienung vergisst uns, die Bedienung vergisst, dass wir mit Karte bezahlen wollen, die Bedienung kann mit dem Kartenlesegerät nicht recht umgehen. So war es am ersten Tag und so war es am zweiten Tag. Da erlaube ich mir anzunehmen, dass es sonst nicht anders ist. Warum ist das aber so?

Als Gast bin ich an Aufmerksamkeit während meines gesamten Besuchs interessiert. Nicht nur möchte ich bald mein Essen haben, ich will auch gehen können, wenn ich gehen will.

Aus Restaurantsicht ist das jedoch anders. Die Organisation interessiert sich für mich anscheinend nur solange sie noch Umsatz machen kann. Das ist ja vorbei, wenn ich zahlen will. Also muss sie uns keine Aufmerksamkeit mehr schenken. Glaubt sie. Anscheinend.

Und wieder ist das eine lokale Optimierung. Die Bedienung denkt nur für den Moment. In dem hat sie soviel Umsatz gemacht, wie sie kann. Weiteren Aufwand in uns zu investieren, könnte bedeuten, andere Gäste, die noch länger bleiben wollen, zu vernachlässigen.

Wenn sie allerdings über den Moment hinaus blickte, würde sie erkennen, dass selbst eine zügige Abwicklung des Bezahlens vorteilhaft für das Geschäft sein kann. Erstens wäre der Tisch wieder frei für neue Gäste. Zweitens – und viel wichtiger – wären wir rundum zufrieden, würden das Restaurant in guter Erinnerung behalten, keinen solchen Blogeintrag schreiben und schließlich gern wiederkommen.

Neulich beim Arzt:Ich rufe an, um einen Termin zu bekommen. Aber ich komme nur in die Warteschleife und am Ende nur zum Anrufbeantworter. Das mache ich zwei Mal ohne Nachricht - und wünsche mir beim dritten Mal doch einen Rückruf.

Man ruft zurück, erreicht mich aber gerade nicht. Also wähle ich wieder den Arzt an – und komme in die Warteschleife und bitte wieder um um Rückruf. Denn asynchron kann man mit Arztpraxen keinen Termin abmachen. Die bieten kein Tool auf ihrer Homepage dafür an und wenn ich ihnen einen Doodle-Link schicken würde, schlügen sie die Hände über dem Kopf zusammen. Nein, nein, dass der Patient Terminvorschläge macht, das geht ja gar nicht.

Warum ist das aber so? Dass ich nicht sofort drankomme, wenn ich einfach so in der Praxis auftauche, verstehe ich ja. Aber für einen Termin, dessen Länge ja keiner abschätzen kann und der kaum anders geplant würde, egal, was ich am Telefon sage, für einen solchen Termin, der allen Beteiligten Planungssicherheit gibt, muss ich nun großen Aufwand treiben. Wieder bin ich als Servicenehmer unzufrieden.

Dabei ist das doch ein uraltes Problem. Ärzte können ja nicht überrascht sein von Patientenanfragen. Und auch ihr Fließbandbusiness überrascht nicht einmal mehr mich. Warum ist da die Terminierung so schwierig? (Dass ich dann selbst mit Termin allermeistens immer noch 20-40 Minuten warten muss, will ich hier gar nicht anbringen.)

Wieder ist eine lokale Optimierung im Spiel. Da bin ich mir sicher. Diesmal verstehe ich sie aber nicht. Denn gerade an einer Terminvereinbarung als Einstieg bzw. Fortführung einer Behandlung, also einer Reihe von Umsätzen, sollte den Arzt doch sehr interessieren. Sie könnte fast schon als seine Visitenkarte angesehen werden. (Naja, dazu müsste dann auch noch der Termin mit max. 5-10 Minuten Verzug verlässlich eingehalten werden. Aber ich will nicht zuviel auf einmal fordern.)

Optimieren da die Sprechstundenhilfe etwas für sich? Vermeiden Sie vielleicht Ärger jetzt, weil sie etwas am Tresen nicht tun, da sie am Telefon hängen, zugunsten von Ärger, den sie gar nicht zu spüren bekommen, weil ich genervt zu einem anderen Arzt gehe? Hm… ich weiß nicht.

Blind für den Servicenehmer

Drei ganz unterschiedliche Erlebnisse für mich als Servicenehmer. Aber drei ähnliche Ergebnisse: mein Durchfluss durch den Service stockt. Allerorten stecke ich im Warten: in der Warteschlange beim Hochseilgarten, im Warten auf die Abrechnung, in der Warteschleife am Telefon.

Für mich ist das nervig. Wie ist das jedoch für die jeweilige Organisation? Ist das aus ihrer Sicht ein bewusst hergestellter Zustand? Sie weiß, dass ich genervt bin, aber ihr ist das egal. Oder weiß sie es, aber es ist ihr nicht egal, doch sie hat keine Ahnung, wie sie es besser machen könnte? Oder weiß sie es nicht, doch wenn sie es wüsste, wäre es ihr nicht egal? Hm… keine Ahnung.

Aber vielleicht ist das auch nicht so wichtig. Denn was zählt ist, dass die Organisation existiert. Sie kann es sich offensichtlich leisten, dass ich genervt bin. Zumindest im Augenblick. Glaubt sie.

Sie ist quasi sehbehindert, leidet darunter aber nicht. Denn sie zeigt mir nicht, dass sie meine Frustration wahrnimmt oder gar bedauert. Das erinnert mich an Rindenblindheit (Blindsight): Dabei ist der Patient blind, bemerkt es aber nicht unbedingt.

Qualität außerhalb des Zwecks

Ist solche “Sehbehinderung” kritikwürdig? Aus meiner ganz persönlichen Servicenehmersicht natürlich. Aber wenn ich mal einen Schritt zurücktrete, mal versuche die Situationen neutral zu sehen, nicht in Bezug auf mich zu werten… dann sehe ich Ursache und Wirkung.

Die Wirkung ist, dass Servicenehmer in Warteschlangen stecken. Und was ist die Ursache?

Ich glaube, der Grund für die Warteschlangen, die die Organisationen nicht zu bedauern scheinen, liegt im Zweck der Organisationen. Der ist so formuliert, dass Warteschlangen für Servicenehmer davon keine Abweichung darstellen. Die Warteschlangen sind unterhalb des Radars des Organisationszwecks.

Beispiel Hochseilgarten:

Wenn der Zweck des Hochseilgartens wäre “Menschen ein naturnahes Hochseilgarten-Erlebnis bieten, bei dem sie sicher selbstbestimmt vorankommen”, dann wären die Warteschlangen auf dem Radar. Denn zu einem selbstbestimmten Vorankommen gehört nicht nur, dass ich entsprechend meinem Selbstvertrauen Stationen durchlaufe, sondern auch dass ich nicht in Warteschlangen gezwungen werde.

So ist der Zweck aber bestimmt nicht definiert. Stattdessen – da bin ich mir sicher – steckt im Zweck das Geldverdienen drin. Er lautet also vielleicht “Heute Geld verdienen mit einem Hochseilgarten-Erlebnis”.

Ganz bewusst habe ich aus dieser Zweckdefinition sogar die Sicherheit rausgelassen. Denn die muss nicht drin stehen, wenn das Geld darin vorkommt. Sie ergibt sich sozusagen, weil es mit dem Geldverdienen schnell vorbei sein kann, sobald die Sicherheit nicht berücksichtigt wird.

Der Unterschied zwischen den beiden Zwecken liegt also darin, dass der eine Qualitätsmerkmale enthält und der andere nicht.

Ich glaube, die Warteschlangen sind eine Folge dessen, dass die Organisationen in ihrem Zweck mehr auf Funktionalität und aufs Geld achten, als auf Qualität. Qualität ist sozusagen nur ein notwendiges Übel, damit über die Funktionalität das ersehnte Geld reinkommt. Solange das passiert, ist die Qualität egal. Um die kümmert man sich erst wieder, wenn es beim Geld stockt.

Das ist ein legitimer Ansatz. Vielleicht ist das auch ein ökonomisch sinnvoller, zumindest verständlicher Ansatz. Kurzfristig allemal.

Mich als Servicenehmer befriedigt er allerdings nicht.

Zweck braucht Werte

Wenn meine Diagnose in die richtige Richtung gehen sollte, dann finde ich das zunächst persönlich frustrierend. Darüber hinaus glaube ich aber auch, dass sich Unternehmen keinen Gefallen tun, wenn Sie Ihren Zweck ohne Qualitätsansprüche formulieren. Und sogar, wenn zu diesen Qualitäten nicht “flüssige und verlässliche Beantwortung der Servicenachfrage” gehört.

Früher, ja, früher mag es ohne gegangen sein. Da herrschte Mangel allerorten. Jeder war froh, wenn er als Servicenehmer überhaupt irgendwie und irgendwann bedient wurde. Der Kunde war Bittsteller. Nicht anders ist es ja zu erklären, dass er heute als König ausgerufen wird. Diese krasse Bewertung macht nur Sinn als Gegenentwurf zu einem vormalig konträren Zustand.

Es ist so ähnlich wie bei der Post: Früher hieß es beim Telefon “Fasse dich kurz!”, dann hieß es “Ruf mal wieder an!” Mal steckte der Mangel in der Infrastruktur, dann in der Zahl der Servicenehmer.

Irgendwo ist also immer Mangel. Früher bei den Angeboten. Aus der Zeit stammen die husch-husch formulierten Zwecke vieler Unternehmen. Doch heute ist der Mangel eben nicht mehr bei den Angeboten, sondern bei den Kunden. Die vielen, vielen Angebote dürstet es nach den knappen Kunden.

Kein Angebot kann sich damit mehr sicher sein, dass es nachhaltig ein Bedürfnis erfüllt. Es mag heute ein Bedürfnis erfüllen – doch was ist morgen? Da hat das Bedürfnis des Publikums womöglich schon wieder gewechselt.

Es gibt inzwischen viele Hochseilgärten selbst in/um Hamburg, es gibt schon lange Unmengen an Restaurants und auch Ärzte gibt es genügend in Hamburg. Keines der Unternehmen kann es sich also eigentlich erlauben, die Qualität nicht im Zweck festgeschrieben zu haben. Und damit meine ich nicht nur die essenzielle Qualität in Bezug auf das Produkt – hohe Plattformen und sicherer Parcours beim Hochseilgarten oder moderne Diagnose und Therapie beim Arzt –, sondern auch die “ambiente” Qualität, das Drumherum.

Zu den ambienten Qualitäten gehören dann aber nicht nur schicke Praxisräume oder freundliche Kellner, sondern eben auch… Flüssigkeit in der Bedienung meiner Nachfrage. Denn Flüssigkeit schont die ultimativ knappe Ressource der Kunden.

Die Zukunft gehört der Zeit

Platte Befriedigung ist out. Fundamentale Löcher müssen nicht mehr gestopft werden. Seit wir aus dem Mangel heraus sind, geht es um etwas anderes. Als Kunden müssen wir nicht mehr um wenige Angebote kämpfen. Umgekehrt können sich die vielen Angebote nicht mehr wie Herrschaften den Kunden gegenüber verhalten.

Wer heute Kundschaft nicht nur anziehen, sondern auch halten will, der muss ihr daher mit Respekt begegnen. Dazu gehört für mich im Kern die Rücksicht auf das wertvollste, das Kunden haben: Zeit.

“Zeit ist Geld” ist der Leitspruch von Generation von Unternehmern. Die Frage ist heute allerdings, wessen Zeit damit gemeint ist. Bisher war es die der Unternehmen. Ich glaube aber, dass es in Zukunft die der Kunden sein sollte.

Unter genügend ähnlichen guten Angeboten gewinnt das, welches mit meiner Zeit als Servicenehmer am respektvollsten umgeht. An der Zeit hängen meine Aufmerksamkeit und mein Geld.

Wer mir das Gefühl vermittelt, insgesamt “eine gute Zeit” während der Nutzung seiner Angebote zu haben, der gewinnt.

Der Umgang mit der Zeit des Kunden gehört damit für mich ausdrücklich in den Zweck jedes Unternehmens. Solange das nicht der Fall ist, wird es nicht besser in den genannten Fällen.

Aber wenn er da angekommen ist, dann verschwinden die Warteschlangen beim Hochseilgarten, im Restaurant und beim Arzt. Und wenn sie nicht verschwinden sollten, dann wird zumindest mit mir als Kunde anders in Bezug darauf umgegangen.

Vielleicht finde ich die Warteschlange beim Hochseilgarten – falls sie wirklich, wirklich nicht zu vermeiden sind - ja gar nicht mehr so schlimm, wenn man mich währenddessen zu einem Kaffee einlädt? :-)

 

PS: Was das für die Softwarebranche bedeutet sollte klar sein. Nicht nur Performance und Skalierbarkeit der Software sind wichtig. Es gilt vielmehr, schlechte Usability und die vielen Gründe für Supportanrufe auch als Zeitfresser zu erkennen.

Jede Entscheidung der Entwicklung, die Kunde oder Anwender Zeit kostet, widerspricht einem Unternehmenszweck, der sich respektvollen Umgang mit der Zeit seiner Servicenehmer auf die Fahne geschrieben hat.

Event-Based Components mit Ruby

Zunehmend bin ich begeistert von dem, was so in der Softwarewelt passiert – aber erst spät in der .NET Welt ankommt. .NET ist immer noch cool – aber was mal leading edge war, fühlt sich für mich immer behäbiger an. Microsoft ist ein Flaschenhals (geworden) und schon gar nicht führend in vielen Aspekten der Softwareentwicklung.

Mono bringt manchmal Erleichterung, zum Beispiel beim Thema Infrastruktur in der Cloud oder iOS Programmierung. Doch noch mehr weitet sich der Horizont mit anderen Plattformen. Deshalb habe ich jetzt mal einen Vorstoß in Richtung Ruby gewagt.

• F# ist interessant, reizvoll, verlockend… aber am Ende doch zu Microsoft. In der weiten, weiten Welt passiert damit zu wenig.
• Java ist keine Option. Dazu bedarf es kaum einer Erklärung, oder?
• Python ist mir inzwischen schon zu alt.
• Scala mag ein würdiger Java-Nachfolger und hochaktuell sein, aber fühlt sich für mich immer noch zu instabil an. Bleeding edge will ich mir nicht antun. Dafür habe ich keine Zeit.
• Clojure ist mir ebenfalls noch zu blutig.

Was bleibt ist, ist aus meiner Sicht Ruby. Es mag schon einen Hauch in die Jahre gekommen zu sein. Clojure is the new exciting kid on the block. Aber für mich ist Ruby gerade gut abgehangen. Tools und Technologien sind stabil, scheint mir.

Auf meinem Macbook Air ist Ruby schon installiert. Da kann ich auf der Kommandozeile mit einer REPL rumspielen. Zusätzlich habe ich mir RubyMine von JetBrains installiert. Das ist ne solide IDE für meine Zwecke.

Also bin ich jetzt im Lern- und Bastelmodus. Eine neue Welt kennenlernen. In kleinen Schritten. Aber natürlich nicht ohne Flow-Design!

Wenn schon ein Ausflug auf eine neue Plattform, dann muss ich Flow-Design Entwürfe dort leicht umsetzen können. Geht das mit Ruby? Ja, das geht. Hier das Listing der Implementation eines ganz einfachen Flows:

Ich habe den Flow bewusst mit Event-Based Components realisiert, um ein Gefühl für den Unterschied zu C# zu bekommen. Ich bin begeistert! Das macht Laune mit Ruby. Es geht ganz einfach, wie Sie sehen.

Nach ein paar Stunden zugebracht mit der Lektüre von Ruby Büchern und Rumspielen mit der IDE ist mein derzeitiges Urteil: Ruby fühlt sich schlank an und bietet manches, was ich lange in C# vermisst habe, z.B. geschachtelte Funktionen.

Wenn das so weitergeht, dann kann es sein, dass Sie hier im Blog ab und an Ruby-Code zu lesen bekommen :-)

Architekturbewusstsein verkörpern

Gibt es wirklich keine Zukunft für Software-Architekten? Ilker Cetinkaya hat in seinem Blog-Artikel so geurteilt.

Wohlgemerkt meint er die Rolle bzw. Position des Software-Architekten, nicht den Aspekt Software-Architektur. Im Gegenteil!

"[Ich empfinde] es als absolut notwendig, die Aufgaben der Architektur nicht auf Positionen oder Personen zu restriktieren, sondern sie als allgemeines Aufgabenfeld in der Software-Entwicklung zu betrachten."

"Schlußendlich sollte es in einem agilen Team meiner Auffassung nach das Ziel sein, auch die Aufgaben der Architektur gemeinschaftlich im Team umzusetzen. "

Ich finde Ilkers Beitrag besonnen. Sein Standpunkt gefällt mir. Ich sehe es grundsätzlich genauso. Deshalb ist mir auch wichtig, mit einem Training wie dem für Agile Architektur Entwickler zu adressieren. Wenn alle zusammensitzen und Architektur planen, kommen mehr Ideen zusammen, das geteilte Verständnis für die Architektur steigt und das gemeinsame Verantwortungsgefühl für das Ergebnis ist höher.

Nichts schlimmer als Astronautenarchitekten, die keinen Bezug zur Entwicklung mehr haben. Nichts konfliktträchtiger als Architekturen, die nach dem Motto "friss oder stirb" über einen Organisationszaun den Entwicklern vor die Tastaturen gekippt werden. Die Entfremdung zwischen Architektur und Anforderungen und Code lauert überall.

Und dennoch... Ein bisschen zucke ich noch bei Ilkers Ergebnis. Weil ich fühle, dass was Ilker beschreibt, für mich an den Persönlichkeiten und Kompetenzen der real existierenden Entwickler vorbeigeht. Ich zucke, weil ich eine Differenz zwischen Wollen und Können sehe.

Viele wollen das, was Ilker beschreibt. Es klingt in der Sache richtig und es hat Appeal für die Persönlichkeit vieler Entwickler, die pragmatisch sind und sich nicht lange mit Organisation aufhalten wollen. Sie sind sensibel für die Verluste, die Distanz zwischen den Beteiligten erzeugen kann.

In meiner Beratungs- und Trainingspraxis sehe ich dann allerdings, dass eben nicht alle Entwickler gleich sind. Sie unterscheiden sich in ihrer technischen Kompetenz, sie unterscheiden sich in ihrer Methodenkompetenz, sie unterscheiden sich in ihrem Charakter und in ihren Bedürfnissen. Und das ist ja auch gut so. Teams, die gemischt zusammengesetzt sind, liefern bessere Ergebnisse.

Verschiedenartigkeit ist grundsätzlich zu begrüßen - sie führt aber auch zu Konflikten und es bleiben blinde Flecken. Wie wird das kompensiert? Wer führt Konflikte zu einem Ergebnis? Wer leuchtet blinde Flecken aus?

Für die Konflikte gibt es Moderatoren. Das weiß inzwischen jeder. Die können aus einer Gruppe kommen oder von außen. Sie stellen sicher, dass Gruppentreffen eine zielführende Form haben. Moderator ist gewöhnlich 1 Person. Dass eine Gruppe sich selbst durch gleich verteilte "Eingriffe" aller Mitglieder moderiert, ist eher selten. Meist gibt es einen de facto Moderator, der nicht mal ausgebildet sein muss. Dennoch erkennt ihn die Gruppe an.

Dieses Muster ist akzeptiert. Im besten Fall dominiert dieser Moderator die Gruppe nicht, sondern kann eine Balance halten zwischen seinem Mitgliedsstatus und seiner Moderatorenrolle. Er ist nur temporär Erster unter Gleichen in Bezug auf eine Aufgabe.

Ein Moderator verkörpert den Aspekt "Kommunikationsform", ohne dessen Berücksichtigung das Ergebnis einer Besprechung schnell suboptimal ausfällt.

Ich denke auch, wir können uns darauf einigen, dass nicht jeder die Rolle eines Moderators gleich gerne und/oder gut ausfüllt - selbst wenn der Aspekt allen Gruppenmitgliedern wichtig ist. Es braucht dafür eben eine gewisse Kompetenz.

Und wer leuchtet blinde Flecken aus? Die gibt es ja unweigerlich und sei es nur temporär. Wenn die Diskussion hoch her geht, dann fällt der eine oder andere Aspekt gern mal unter den Tisch. Ein Übriges tut dann das Tagesgeschäft mit seinem Druck in Richtung bestimmter Aspekte - und Ignoranz gegenüber anderen.

Einer dieser Aspekte ist aus meiner Sicht die Architektur. Architektur ist ein nicht-funktionaler Aspekt der Softwareentwicklung. Und darüber hinaus auch noch einer, dessen Qualität nicht so schnell zu einem Feedback vom Kunden führt. Wenn die Performance der Software nicht stimmt oder die Usability, dann sagt steht der Kunde sehr schnell auf der Matte. Rückkopplungszeit Stunden oder Tage.

Wenn aber die Architektur nicht stimmt... dann ist die Rückkopplungszeit Wochen, Monate oder gar Jahre. (Ja, ich glaube, man kann nicht-funktionale Anforderungen wie Performancelimits erfüllen, auch wenn die Architektur suboptimal ist. Das passiert sogar häufig.)

Weil nun die Rückkopplung bei der Architektur vergleichsweise lange auf sich warten lässt, fällt sie leicht unter den Tisch. Manager haben dafür oft wenig Sinn. Sie sind es aber, die sich letztlich durchsetzen. Jedenfalls normalerweise. Heute noch ;-)

Bei gegebener schlechter Ausbildung in puncto Softwareentwurf - das schließt für mich Architektur ein - und gegebenem Tagesgeschäftfokus ist für mich die Realität von Teamsitzungen, dass Architektur schnell zu einem blinden Fleck wird. Nicht sofort, nicht immer, aber tendenziell.

Dazu kommt, dass die Kompetenzen, die für den Entwurf von Software-Architektur nötig sind, nicht gleich verteilt sind bei Entwicklern. Es ist damit wie mit den Moderatorenkompetenzen. Das ist also ganz natürlich.

Und daraus leite ich nun wiederum ab, dass es wichtig ist, darauf zu achten, dass der Aspekt Software-Architektur verlässlich verkörpert wird.

Wie diese Verkörperung aussieht, ist mir egal. Es muss keine Position eines Software-Architekten geben. Es muss auch niemand zwangsläufig fix die Rolle eines Software-Architekten innehaben. An irgendwem muss das Thema jedoch hängen, glaube ich. Und zwar nicht am ganzen Team, sondern an einer Untermenge.

Alle sind mit der Plattform und der Domäne und hoffentlich Clean Code Developer ;-) vertraut. Jenseits dessen beginnen dann allerdings die Unterschiede. Es ist immer so, dass einer die GUI-Technologie besser beherrscht als andere. Und eine kann besser mit dem Build-Tool umgehen als andere. Und manche fühlen sich eher zum Umgang mit Datenbanken hingezogen als andere.

Genauso denkt eine konzeptioneller als andere. Und einem ist das big picture wichtiger als anderen.

Ich glaube, diese ganz selbstverständlichen Unterschiede sollten wir nicht leugnen. Wir sollten auch nicht glauben, sie wegschleifen oder auffüllen zu können. Dafür geht gerade das Thema Software-Architektur zu sehr an Persönlichkeitsmerkmale, die schon früh geprägt werden.

Um also nicht davon überrascht zu werden, dass das kollektive Kümmern um Architektur irgendwie nicht funktioniert hat, sollte jedes Teams schauen, dass es möglichst schnell herausfindet, wie es den Aspekt Architektur am besten verkörpert.

Manchmal mag es einen Entwickler geben, der sich den Schuh anzieht - und die anderen sind froh drüber, dass er sie beim Thema an die Hand nimmt. Manchmal mag es eine kleine Gruppe innerhalb des Teams sein. Oder vielleicht rotiert die Aufgabe durch das Team, so dass bei jeder Besprechung ein anderer das "Architektur-Gewissen" ist?

Eine andere Verkörperung muss natürlich in der Zeit stattfinden. Sie muss für alle Entwickler fester Bestandteil ihrer Wochenkalender sein. Das ist der erste Schritt.

In Summe helfen Experimente. Solange die dafür sorgen, dass die Verkörperung der Architektur nicht in eine außerkörperliche Erfahrung ;-) umschlägt, d.h. abhebt und entfremdet von Code und Anforderungen, solange ist alles erlaubt.

Software-Architektur geht alle an. Da bin ich ganz dabei. Allerdings möchte ich daraus ungern eine zwingende Form ableiten: weder eine Position des Software-Architekten, noch die komplette Abwesenheit jeder Rolle oder anderer Form von Kompetenzkonzentration oder Interessenverteilung. Architekturbewusstsein verkörpern, in geeigneter Form, darum geht es.

Solange am Ende das ganze Team ein solides Verständnis der Architektur hat und sie mitträgt, ist alles gut.

Es geht um Organisationsgesundheit

Was soll das eigentlich mit der Beratung, dem Coaching, dem Training? Das frage ich mich immer öfter. Was will ich damit bewirken? Worum geht es dabei in den Softwareteams? Erneuten Anstoß für diese Überlegungen hat mir ein Zahnarztbesuch vor einiger Zeit gegeben.

Dass ein Training WPF Kompetenz aufbaut oder Clean Code Developer Prinzipien vermittelt oder das Scrum-Rad ins Rollen bringt… das ist offensichtlich, aber nicht, was ich meine. Mir geht es um etwas, das dahinter steht. Denn: Warum soll aufgebaut, vermittelt, ins Rollen gebracht werden?

Ein Begriff fällt mir dazu dann immer wieder ein: Zweck. WPF, CCD, Scrum, TFS, .NET 4.5, XMPP, NoSql sind Mittel des Aspektes Softwareentwicklung in einer Organisation, damit die ihren Zweck erfüllen kann.

Nehmen wir als Beispiel ein kleines Softwarehaus. Das arbeitet seit 6 Jahren mit .NET, vorher mit VB. Erst hat der Chef selbst programmiert, jetzt hat er 6 Entwickler (die natürlich auch Support machen), dazu noch einen Mitarbeiter im Vertrieb und noch jemanden fürs Büro.

Was ist der Zweck dieses Unternehmens?

Ich denke nicht, dass die Antwort lautet, "Geld verdienen". Nein, das ist eben nicht der Zweck. Geld ist ebenfalls nur ein Mittel, um den Zweck zu erfüllen. Ein notwendiges Übel.

Ein möglicher Zweck könnte aber sein "CRM-Software für die PR-Branche herstellen". Aus diesem Grund gibt es das Softwarehaus. Das ist seine Bestimmung, mit der es der Inhaber einmal gegründet hat.

Dass "Geld verdienen" nicht zum Zweck gehört, wird Ihnen auch klar, wenn Sie einmal annehmen, dass die Firma immer noch nötig wäre, wenn ein Milliardär auf die Idee käme, sie aus seiner Portokasse einfach so zu finanzieren. Jedes Jahr bekäme der Geschäftsführer einen Scheck über 1.000.000 EUR zugestellt, der es ihm erlaubte, alle Kosten zu decken. Umsatz wäre nicht mehr zu machen. Und dennoch wären weiterhin alle Mitarbeiter nötig; Software würde immer noch geschrieben werden müssen. Denn sonst könnte der Zweck nicht erfüllt werden. Nur könnte die Software dann verschenkt werden.

Leider müssen die meisten Unternehmen ohne einen solchen Mäzen auskommen. Deshalb ist Umsatz nötig. Das bedeutet aber nicht, dass Geld verdienen der Zweck des Unternehmens ist. Der Zwang zum Umsatz ist vielmehr eine zu berücksichtigende Bedingung, unter der der Zweck erfüllt werden muss. Andere Bedingungen sind, dass Software durch Menschen hergestellt wird oder dass sie Marketing braucht, um ihre Anwender zu finden, oder dass jährlich eine Bilanz zu erstellen ist.

Der Zweck von etwas, ist diesem Etwas inhärent. Er gehört zu ihm, klebt an ihm, kommt und geht mit ihm. Deshalb ist auch "Den Lebensunterhalt sichern" kein Unternehmenszweck. Die Formulierung drückt vielmehr aus, dass das Unternehmen von jemandem als Mittel gesehen wird. Damit wird es austauschbar. Wer einen großen Lottogewinn macht, braucht das Unternehmen nicht mehr, um seinen (!) Zweck zu erfüllen.

Mir geht es ja aber eben nicht um den Zweck einer Person (oder ihr Sinnempfinden), sondern um den Zweck einer Organisation. Der kann nur in ihr stecken bzw. aus ihr heraus sich entwickeln.

Nun zurück zur Ausgangsfrage: Was soll das eigentlich mit der Beratung, dem Coaching, dem Training?

Ich denke, dabei geht es immer mehr oder weniger direkt darum, dass eine Organisation ihren Zweck besser erfüllen kann - und zwar im Rahmen gewisser Bedingungen. Innerhalb einer Umwelt bestehend aus einer Vielzahl von Bedingungen soll es der Organisation also besser gehen. Das bedeutet für mich: es geht um Gesundheit.

Ja, genau, mir scheint deshalb, mein Job ist sozusagen der eines Arztes oder Therapeuten für Organisationen.

Damit will ich mir nun keinen besonderen Nimbus andichten und ich brauche weder Kittel noch Stethoskop. Mit der Wahl der Analogie versuche ich lediglich, besser zu verstehen, was Organisationen für Probleme haben und wie die gelindert werden könnten.

Das erste, was aus der Analogie folgt ist - auch wenn es sich nicht schön anhört -, dass, wenn irgendwo der Schuh drückt und "der Berater" gerufen wird… dass dann die Organisation wohl krank ist. Das muss ja nicht immer gleich ein Herzinfarkt sein; Menschen gehen auch mit einem Schnupfen zum Arzt. Aber krank ist eben krank. Die Organisation leidet. Irgendetwas schmerzt - und zwar so sehr, dass man Hilfe sucht.

Aber was ist Krankheit? Oder umgekehrt: Wann ist eine Organisation nicht krank, sondern gesund? Was ist Gesundheit?

Mit der Frage begebe ich mich natürlich in einen Sumpf. Es gibt soviele Definitionen für Gesundheit. Allen voran die der WHO, die so allgemein ist, dass sie mir untauglich erscheint. Denn danach, so scheint mir, kann es keine gesunden Menschen geben:

“Gesundheit ist ein Zustand vollständigen körperlichen, psychischen und sozialen Wohlbefindens und nicht nur das Freisein von Beschwerden und Krankheit.”

Deshalb versuche ich mich einmal an einer eigenen kleinen pragmatischen Definition. Für meine Arbeit als Berater/Coach/Trainer möchte ich ja zumindest eine Chance haben, Gesundheit bei meinen Kunden herzustellen.

Gesundheit braucht Kontext

Zu meinen Gesundheitsbegriff, der ja auch nicht für Menschen, sondern Organisationen gedacht ist, gehört zunächst der Zweck. Gesundheit gibt es nur im Hinblick auf einen Zweck.

Und Gesundheit gibt es nur im Hinblick auf eine Umwelt, d.h. Bedingungen unter denen der Zweck erfüllt werden soll.

Mithin ist Gesundheit ein relativer Begriff. Ob eine Organisation gesund oder krank ist, kann nur beurteilt werden, wenn man Zweck und Umwelt kennt. "Organe" oder Kompetenzen nach einer absoluten Checkliste abzuhaken, kann zu falscher Diagnose führen.

• Analogie Tierwelt: Ist ein Tier krank, wenn es nicht sehen kann? Nicht unbedingt. Wenn es seinen "Lebenszweck" in seiner Umwelt problemlos ohne Sehfähigkeit erfüllen kann, ist es nicht krank, wie der Grottenolm beweist.
• Beispiel Unternehmen: Ist ein Unternehmen krank, wenn es sich nicht mit Social Media auskennt? Nicht unbedingt. Wenn es seinen Zweck in seiner Umwelt problemlos ohne Social Media erfüllen kann, ist es nicht krank. Lebender Beweis ist Schuhmacher Schwartau in meinem Stadtteil in Hamburg.

Gesundheit braucht Funktionstüchtigkeit

Bei gegebenem Zweck in gegebener Umwelt stellt sich natürlich die Frage, ob eine Organisation überhaupt in der Lage ist, ihn zu erfüllen. Kann sie, was immer erforderlich sein mag? Ist die Organisation grundsätzlich funktionstüchtig?

Wenn der Zweck eines Unternehmens Schuhreparatur ist, aber niemand weiß, wie das geht… dann ist das Unternehmen fundamental krank. Ob das eine somatische oder eher eine psychische Krankheit genannt werden sollte, lasse ich mal dahingestellt.

Wenn Schuhmacherkompetenz vorhanden ist, aber das Unternehmen über seine Verhältnisse lebt, also mehr ausgibt als einnimmt… dann ist das Unternehmen ebenfalls krank. Es fehlt ihm die Fähigkeit mit einem Aspekt der Umwelt umzugehen.

Zur Gesundheit gehört also auch, dass Methoden, Techniken, Werkzeuge in geeigneter Weise bedient werden können. Welche das sind, bestimmen nur Zweck und Umwelt. Es gibt keine Pflicht zu Social Media, Cloud Computing, NoSql, Mobile Clients, Kanban, Selbstorganisation usw. Sie sind lediglich Mittel zur Erfüllung des Zwecks unter bestimmten Bedingungen. Und wenn nicht klar erkennbar ist, wie das eine oder andere Mittel den Zweck befördert oder den Umgang mit Bedingungen verbessert, dann muss es nicht genutzt werden.

Zur Funktionstüchtigkeit gehört natürlich auch, dass die "Organe" eines Unternehmens angemessen verbunden sind. Gesunde Organe verpackt in Transplantationsbehälter nützen nichts. Sie müssen in einem Rahmen, Körper, aufgehängt sein, der ihr Zusammenspiel in Hinsicht auf den Zweck befördert. Auch das ist eine Kompetenz der Organisation, auch das ist wiederum ein "Organ".

Krankheit ist somit nicht notwendig das Problem eines Teiles. Wenn das Schuhreparaturgeschäft nicht läuft und der Schuhmacher sich nicht an Damenschuhe herantraut, dann ist die Diagnose einfach, falls das Geschäft nicht läuft. Hier führt ein Teil zur Krankheit des Ganzen.

Wenn aber Schuhannahme, Schuhreparatur und Reparaturausgabe eigentlich kompetent sind und es trotzdem nicht läuft… dann kann es noch daran liegen, wie sie im Firmenrahmen verdrahtet sind. Falls nämlich die Übergabe der Schuhe zwischen den Funktionen mittels eines großen Haufens geschieht, weil die Geschäftsführung kein Geld für Regale ausgeben will… dann kann es zu unschönen Verzögerungen kommen, weil Aufträge nicht geordnet abgearbeitet werden. Hier führt der Rahmen zur Krankheit des Ganzen.

Ein anderes Beispiel für ein Problem im Rahmenwerk könnte sein, dass der Chef verlangt, dass der Schuhmacher jedes Mal, wenn er eine Reparatur beginnt/beendet, zu ihm in den 4. Stock heraufkommt. Es muss doch kontrolliert werden, dass der Schuhmacher immer beschäftigt ist. Wenn der also nicht alle 15-20 Minuten im 4. Stock zu sehen ist… dann trödelt er. [1]

Aber stopp: Ich habe gesagt, dies sei ein Beispiel für ein Problem. Ist das aber gewiss? Die Regel hört sich nicht zweckförderlich an - doch vielleicht gibt es Bedingungen, unter denen sie nicht schädlich für die Gesundheit des Unternehmens ist. Ich denke, dafür müssen wir offen sein, bis wir Zweck und Bedingungen genau kennen. [2]

Gesundheit braucht Kompensationsfähigkeit

Alles wäre ja gut, wenn Zweck sowie Bedingungen einmal klar gemacht werden könnten, um dann einmal die Funktionstüchtigkeit darauf abzustellen.

So ist die Welt aber nicht. Unternehmen laufen nicht auf Schienen. Die Umwelt ist ständig in Bewegung. Am Zweck mag ein Unternehmen von sich aus festhalten können; doch die Bedingungen, unter denen es ihn erfüllen muss, wandeln sich. Mal gemächlich, mal plötzlich.

Zur Funktionstüchtigkeit muss daher noch eine weitere Eigenschaft kommen: Kompensationsfähigkeit. Und eben die habe ich beim Zahnarztbesuch im Gespräch kennengelernt.

Gesund ist ein System, wenn es Störungen kompensieren kann. Sich verändernde Bedingungen sollten die Zweckerfüllung möglichst nicht sofort kompromittieren.

In dieser Hinsicht finde ich die Definition von Gesundheit der WHO unzureichend. Sie sagt, ich sei gesund, wenn ich in vollständigem Wohlbefinden in meinem Bett liege.

Was aber, wenn ich dann aufstehen will und das nicht kann, weil meine Muskeln atrophiert sind oder mein Kreislauf versagt? Klar, dann bin ich nicht mehr gesund. Ich fühle mich nicht mehr wohl. Aber Sekunden vorher war ich es noch still liegend im Bett?

Kaum. Denn wenn mich ein völlig üblicher Bewegungswunsch über die Grenzen meiner Leistungsfähigkeit bringt, dann kann ich nicht gesund sein. Ein gesunder menschlicher Körper kann den Wechsel von Bettruhe zu Aufstehen kompensieren. Ein gesunder Körper kann auch die plötzliche Anforderung, das Ausrutschen auf einer Bananenschale zu kompensieren, mühelos erfüllen. Ebenso kann ein gesunder Körper eingedrungene Schnupfenviren kompensieren.

Gesundheit ist mehr als die Abwesenheit von Schnupfen. Sie ist die Anwesenheit von Kompensationsfähigkeit - so dass Schnupfen gar nicht erst entsteht.

Krankheit im üblichen Sinn ist also erst die Folge eines vorherigen Mangels an Kompensationsfähigkeit. Für mich beginnt Krankheit im unüblichen Sinn deshalb schon früher. Krank ist ein System schon dann, wenn es Kompensationsfähigkeit nicht aufgebaut hat oder verliert.

Wie viel Kompensationsfähigkeit nötig ist, hängt wieder vom Zweck im Rahmen einer Umwelt ab. Hier müssen Annahmen gemacht werden. Von einem Erwachsenen erwarten Sie zurecht, denke ich, dass er den Sturz über eine Bananenschale kompensieren kann. Ein Sturz aus 10m Höhe jedoch liegt jenseits gesunder Kompensationsfähigkeit.

Hier wird nun der Zweck von Angst deutlich. Sie bewahrt uns vor Situationen, die unsere Kompensationsfähigkeit übersteigen. Wir haben Angst, wenn wir am Rande einer 10m hohen Klippe ohne Brüstung stehen; deshalb vermeiden wir solche Situationen oder sind dann zumindest sehr vorsichtig. Aber wir haben keine Angst, unser Haus zu verlassen - auch wenn es sein kann, dass wir auf dem Bürgersteig auf einer Bananenschale ausrutschen.

Kompensationsfähigkeit bedeutet, Puffer zu haben. Das können physische oder psychische sein. Ein physischer Puffer ist Muskelkraft oder Fett. Ein psychischer ist Humor oder ein religiöser Glaube.

Und bei Unternehmen? Da sind zum Beispiel Geld, Motivation, Lagerbestände oder schlicht Überkapazitäten jeder Art Puffer.

Wo Geld vorhanden ist, da kann eine Umsatzdurststrecke abgepuffert werden. Wo Motivation vorhanden ist, da kann eine Auftragsspitze durch Mehrarbeit abgefedert werden. Wo Lagerbestand vorhanden ist, da kann eine Nachfragespitze ohne Verzögerung befriedigt werden. [3]

Zwischenstand

Bei der Beratung im weitesten Sinne geht es aus meiner Sicht immer um die Gesundheit des Unternehmens. Sie soll verbessert werden. [4]

Diese Analogie hilft mir. Ich finde sie pragmatisch. So liefert mir die Analogie z.B. eine Analysecheckliste. Wenn ein Unternehmen über Probleme klagt, kann ich schauen, wo die liegen:

• Mangelt es an Zweckverständnis?
• Mangelt es an Bedingungsverständnis?
• Mangelt es an der Fähigkeit, Bedingungen zu bewältigen?
• Mangelt es an Funktionstüchtigkeit?
• Mangelt es an Kompensationsfähigkeit?

Und daraus kann ich dann "Therapievorschläge" ableiten.

Ebenso ist die Analogie für mich eine Brille, durch die ich auf Tools, Technologien, Methoden, Konzepte schauen kann. Ich kann sie klassifizieren. Ich kann beurteilen, zu welchem Gesundheitsaspekt sie etwas beitragen. Wird mit WPF die Funktionstüchtigkeit erhöht oder das Zweckverständnis? Trägt Scrum etwas zur Bewältigung von Bedingungen bei oder steigt damit die Kompensationsfähigkeit?

Sicherlich hat jede Analogie ihre Grenzen. Aber derzeit glaube ich noch nicht, dass die bei der Gesundheitsanalogie erreicht sind. Sie scheint mir vielmehr gerade in puncto Kompensationsfähigkeit noch einiges zu bieten. Darüber muss ich weiter nachdenken.

Einstweilen können Sie sich ja mal fragen: Wie gesund ist das Team, das Unternehmen, in dem Sie arbeiten?

Fußnoten

[1] Oder ist es müßig, zwischen Rahmen und darin aufgehängten "Organen" zu unterscheiden? Am Ende sind Rahmen und "Organe" ein Ganzes und gleichberechtigt. Ohne Rahmen kein Ganzes, keine Zweckerfüllung nur durch die "Organe". Und ohne "Organe" nützt der schönste Rahmen auch nichts.

[2] In diesem Zusammenhang fällt mir die Agilität ein. Auch wenn ich meine, dass agile Entwicklung gesundheitsförderlich für viele Softwareentwicklungsorganisationen ist, so muss ich offen dafür sein, Zwecke und Bedingungen kennenzulernen, unter denen das nicht gilt. Deshalb ist es mir wichtig hinter die Fassade von Methoden und Konzepten zu schauen. Ich möchte verstehen, Mittel zur Bewältigung welcher Umweltbedingungen sie sind.

Hype entsteht insofern immer dann, wenn Mittel empfohlen werden ohne Ansehen ihrer Bindung an Zwecke oder Bedingungen.

[3] Nach fest kommt ab. Das kennen Sie als Heimwerker, oder? Ich denke, es gilt aber genauso: nach schlank kommt krank.

Denn wo der Schlankheitswahn im Unternehmen um sich greift, wo gekürzt und beschnitten wird, um Kosten zu reduzieren… da kann Gesundheit unbemerkt in Magersucht umschlagen - und der Patient hat typischerweise keine Krankheitseinsicht. Wo Puffer konsequent verkleinert werden, droht die Kompensationsfähigkeit zu leiden - und damit die Gesundheit. Auch und gerade, wenn doch heute noch alles zu funktionieren scheint.

Die nächste Änderung der Bedingungen kommt gewiss… Dann ist die Frage, ob die Organisation sie kompensieren kann.

[4] Ich bin übrigens nicht der einzige, der sich "im Dienste der Gesundheit von Unternehmen" fühlt. Bob Marshall, dessen Blog Think Different ich sehr schätze, bezeichnet sich schon als Therapeut und denkt über organizational health nach.

In dieselbe Richtung zielt das Buch "The Advantage" von Patrick M. Lencioni.

Und auch das Buch "Working Whole Systems" von Julian Pratt et al., das Organisationen als lebendig beschreibt, geht für mich in dieselbe Richtung.

Agil persönlich definiert

In meiner Kritik an Martin Fowlers Absage an die Wissenschaftlichkeit habe ich anklingen lassen, dass ich selbst eine Definition für Agilität hätte. Darauf bin ich nun ein paar Mal angesprochen worden. Nun muss ich wohl Butter bei die Fische machen und sie einmal beschreiben.

Meine Definition

Also gut… Hier sind meine persönlichen Kriterien für agiles Vorgehen oder eine Haltung der Agilität. Sie sind natürlich nicht rigoros im mathematischen Sinne. Das habe ich auch nicht von Martin Fowler erwartet. Aber ich halte sie für klar genug, um mit ihnen in der Hand an ein Projekt herantreten zu können für eine Prüfung, ob es agil durchgeführt wird.

Inkrementell

Die wesentliche Neuerung, die die Agilität in die Softwareentwicklung aus meiner Sicht gebracht hat, ist das Denken in und die Entwicklung von Durchstichen. Software wird nur in nützlichen Inkrementen ausgeliefert. Agilität liefert “Anforderungsscheiben”, d.h. sie macht vertikale Schnitte durch ein Softwaresystem. Als fertig und somit projektfortschrittsrelevant wird angesehen, was dem Kunden etwas wert ist.

Was war vorher? Vorher war die Entwicklung in Meilensteinen. Zum Begriff Meilenstein gehört aber nicht notwendig der Durchstich. Ein Meilenstein kann auch sein “Datenbankschicht fertig” oder “ESB aufgesetzt”. Solche Infrastrukturbelange mögen irgendwie wichtig sein, ohne Datenbankzugriff oder ESB läuft das Softwaresystem nicht. Allerdings interessieren die den Kunden nicht direkt; sie sind nicht nützlich. Er will seine Aufträge bearbeiten, Planungen durchführen, Ressourcen verwalten usw.

Eine Datenbank oder ein ESB sind einfach keine funktionale und auch keine nicht-funktionale Anforderung. Sie sind Mittel zur Realisierung von Anforderungen. Deshalb sind die für sich genommen nicht wertvoll.

Aus meiner Sicht ist es genau diese Unterscheidung, die Agilität vor allem auszeichnet. Den Blick auf die Erfüllung von Anforderungen zu konzentrieren und sich nicht von Mitteln ablenken zu lassen, das macht Agilität für mich aus.

Lernend

Die zweite Neuerung, die Agilität in die Softwareentwicklung gebracht hat, war aus meiner Sicht die Haltung des ewigen Schülers. Wer agil arbeitet, bewegt sich in einer Lernschleife:

1. Herausfinden, was gewünscht ist
2. Inkrement herstellen
3. Überprüfen, ob das Inkrement für den Kunden akzeptabel ist

In der agilen Softwareentwicklung gibt es also keine Phase, die je abgeschlossen wäre.

Agilität läugnet insofern nicht, dass Softwareentwicklung in sequenziellen Phasen abläuft. Man muss zuerst herausfinden, was gefordert ist, dann muss man die Realisierung planen, dann kann man den Plan implementieren [1] und erst danach kann man die Implementierung überprüfen und schließlich abnehmen lassen.

Aus Sicht der Agilität ist nichts gegen solche Phasen zu sagen. Sie sind sozusagen unterhalb des Radars der Agilität. Deshalb kann man aus meiner Sicht auch nicht mit der Agilität begründen, dass man nicht dokumentiert oder entwirft. Agilität wendet sich nicht dagegen. Es ist ihr schlicht egal. Sie sagt: Mach, was nötig ist, um Inkremente heute und in Zukunft zügig herstellen zu können. Denn nur so kann ihr Anspruch des Lernens erfüllt werden.

Zunächst hatte ich gedacht, dass ein wichtiger Baustein der Agilität Iterationen seien. Inzwischen sind für mich Iterationen allerdings nur noch ein Mittel. Und der wirkliche Baustein der Agilität ist das Lernen. [2] Ebenso sind z.B. Scrum Retrospektiven auch nur ein Mittel, um den Baustein Lernen in ein Projekt zu setzen.

Das bedeutet im Umkehrschluss: Agilität ist dort unnötig, wo nicht gelernt werden muss. Wenn glasklar ist, was zu tun ist, wenn es nur marginale Unwägbarkeiten gibt… dann muss man nicht agil sein.

Agilität ist also kein Ansatz für die Produktion, sondern für jede Form von Entwicklungstätigkeit, sei das “bei den Kreativen” oder bei Ingenieuren.

Unmittelbar

Die dritte Neuerung der Agilität ist dann die Betonung der unmittelbaren Kommunikation. Die, die ein Ergebnis sehen wollen und die, die es herstellen sollen, sitzen im selben Boot. Also ist es wichig im Sinne der Lernschleife und zügiger Inkremente, dass diese Beteiligten möglichst barrierefrei Kontakt haben.

Wie das konkret geschieht, ist der Agilität wieder egal. Aber typische Maßnahmen im Sinne der Unmittelbarheit sind cross-functional Teams und co-location. Auch das Verhältnis ProductOwner zu Entwicklern in Scrum ist dafür Ausdruck.

Informationen sollen fließen, Entscheidungen sollen zügig getroffen werden. Bürokratie jeder Art (Hierarchien, Verträge, Dokumente, Konventionen, …) gehört für die Agilität deshalb auf den Prüfstand. Was nicht unmittelbar dem Ziel “Nützliches Produkt” dient, soll weggeschnitten werden.

Meine Hypothese

Agilität zu definieren ist kein Selbstzweck. Eine Definition macht nur Sinn, wenn daraus etwas abgeleitet wird. Eine Hypothese kommt erst zustande, wenn der Definition auch eine Ergebniserwartung zugeordnet wird.

Aus meiner Sicht lautet die Vorhersage der Agilität:

Wer agil Software entwickelt, der hat größere Chancen, bei gegebenen Budgets (Geld, Zeit, Ressourcen) hohen Nutzen für den Kunden herzustellen.

Oder etwas konkreter: Mit Agilität werden weniger Projekte abgebrochen und die Überziehungen werden geringer und das Supportaufkommen fällt auch nicht so hoch aus.

Natürlich ist diese Vorhersage im Komparativ formuliert. Agilität ist ja als Gegenentwurf zu etwas Bestehendem entstanden. Demgegenüber will sie bessere Ergebnisse liefern. Aber sie ist zumindest so “bescheiden”, sich nicht als das Ende der Fahnenstange zu sehen. Zumindest sollte sie das sein, denke ich. [3]

Zusammenfassung

Das war´s. Mehr gehört für mich derzeit nicht zur Definition von Agilität. Bestimmt ist es weniger, als viele von Ihnen erwartet hätten. Mir reicht es aber. Denn mit diesen Kriterien an der Hand kann ich jedes Projekt, jedes Unternehmen beurteilen. Und Sie können das auch. Dafür muss ich Sie nicht “weihen” ;-)

Gehen Sie einfach diese Checkliste durch:

1. Geht es um ein Entwicklungsvorhaben? Stichwort: Kreativität
2. Wird das Ergebnis inkrementell hergestellt? Stichwort: Durchstiche
3. Wird bewusst lernend vorgegangen? Stichwort: Reflexion
4. Sind die Vorhabenbeteiligten in unmittelbarem Kontakt? Stichwort: Kommunikationsfluss

Wenn jede Frage mit eine Ja beantwortet werden kann, dann liegt grundsätzlich Agilität vor.

So einfach ist das :-) Dazu müssen Sie - aus meiner Sicht - nicht Martin Fowler anrufen und fragen, ob er Agilität erkennt.

Sie können jetzt selbst beurteilen, ob Agilität etwas bringt. Wenn ein Vorhaben inkrementell, lernend und unmittelbar durchgeführt wird, aber sich kein Erfolgsmesswert verbessert… dann nützt ihm Agilität nichts. Dann kann man auch wieder wie früher arbeiten, falls das irgendwelche Vorteile haben sollte. [4]

Und Sie können überlegen, ob gewisse Methoden agil sind oder inwiefern sie der Agilität dienen. Fragen Sie, wie sie das Lernen oder die Unmittelbarheit oder die Lieferung von Inkrementen unterstützen.

Wenn Sie mögen, übernehmen Sie meine Definition von Agilität. Und wenn nicht, dann lassen Sie uns drüber reden, was fehlt. Ich behaupte nicht mal, dass sie gut sei jenseits dessen, dass ich sie für mich praktisch finde. [5] Ich sage nur, dass es überhaupt eine Definition ist und damit das Minimum, was wir von einem Ansatz zur Softwareentwicklung erwarten können.

Fußnoten

[1] Wie umfangreich ein solcher Plan ist, sei dahingestellt. Er mag für Triviales quasi nicht existent sein, so dass die Codierung gleich starten kann. Für anderes mag dann aber durchaus etwas Nachdenken/Entwurf angezeigt. Die Agilität sagt nicht, wieviel Planung nötig ist. Das ist nicht ihr Thema. Sie beschränkt sich auf die Anerkennung von Phasen in der Herstellung von Inkrementen. Wieviele und welche Phasen das sind… ist eine Sache des Herstellungsprozesses. Der sieht für Software anders aus als für ein Auto.

[2] Zu meiner Liste von Agilitätskriterien gehörte zunächst auch noch “Haldenreduziert”. Damit wollte ich dem Aversion gegen “B*UF” (Big {Design, Documentation, …} Up Front) Ausdruck geben. Inzwischen sehe ich es aber so, dass auch das nur eine Folge der Lernwilligkeit ist. Große Halden an Anforderungen, Entwürfen usw. erzeugen einfach Trägheit, die das Lernen behindern. Sie reduzieren die Lernschleifenfrequenz.

[3] Vielleicht ist das unnötig zu erwähnen. Denn wenn Lernen ein Bestandteil der Agilität ist und sie sich so minimal definieren sollte, wie ich das hier zunächst mal nur für mich persönlich tue, dann gibt es erstens daran keinen Zweifel und zweitens steht nicht zu erwarten, dass Agilität dann abgelöst würde. Sie wäre vielmehr der Kern von Weiterentwicklungen.

[4] Selbstverständlich gibt es noch eine andere Möglichkeit: Es könnte sein, dass das mit dem inkrementellen, lernenden und unmittelbaren Arbeiten noch nicht optimal ist. Man kann ja besser oder schlechter inkrementell vorgehen usw. Kritik an der Implementation von Agilität darf also sein. Da gibt es Interpretationsspielraum. Und damit gibt es Raum für die Entwicklung der Agilität. Es können sich ja über die Zeit Best Practices herauskristalisieren, die dann in die Definition von Agilität einfließen.

[5] Allerdings impliziere ich, dass meine Definition in Linie steht mit dem agilen Manifest und beliebten Methoden der Agilisten. Das ist für mich ein Hinweis auf eine gewisse Grundqualität.