The agile Bookshelf: Software Estimation Without Guessing

Bild: Wikimedia Commons / Abhi Sharma - CC BY 2.0

Angesichts der Bedeutung die das Schätzen von Aufwänden in praktisch jedem Softwareentwicklungs-Vorhaben hat (egal on agil oder nicht agil) ist es verwunderlich, dass es kaum bekannte Literatur zu dem Thema gibt. Agile Estimating and Planning von Mike Cohn und Software Estimation: Demystifying the Black Art von Steve McConnell gelten zwar als Standard-Werke, sind aber schon fast 20 Jahre alt. Mittlerweile gibt es aber auch wieder aktuelle Literatur: Software Estimation Without Guessing von George Dinwiddie ist ein lesenswerter Versuch den aktuellen Sachstand zusammenzufassen.

Ein erstes Ausrufezeichen setzt das Buch direkt zu Beginn, indem es Story Points, Planning Poker und Durchsatz (NoEstimates), also die wesentlichen "agilen Schätztechniken", die den Grossteil aller Texte zu diesem Thema ausmachen, auf nur zwei Seiten abhandelt. Es wird deutlich, dass diese Klassiker zwar gewürdigt werden sollen, dass sie aber nur an der Oberfläche des Themas kratzen, das in den folgenden Kapiteln deutlich tiefgreifender behandelt wird.

Diese Behandlung beginnt mit der grundlegenden Frage warum Aufwandsschätzungen überhaupt nötig sind. Um zu wissen wie lange es dauert ist dabei nur eine Antwort, zu der noch weitere kommen: Um zu wissen ob eine Umsetzung überhaupt planbar ist, ob sie wirtschaftlich ist, und welches Budget für sie eingeplant werden sollte sind die anderen. Das scheint alles banal, wird aber in der Realität immer wieder nicht bedacht wenn gefragt wird warum überhaupt geschätzt werden soll.

Die folgenden Kapitel arbeiten sich durch viele Aspekte die zwar nicht alle genuin neu sind, erschliessen diese aber immer wieder mit neuen Aspekten. Z.B. werden Relationale Schätzungen nicht nur erklärt, es wird auch aufgezeigt, dass sie durch kognitive Dissonanzen und Phänomene der Gestalt-Psycholgie verfälscht werden können und daher mit einer gewissen Vorsicht behandelt werden müssen, um nicht eine irreführende Wirkung zu haben.

Ebenfalls mit unerwarteter Tiefe wird die Dekomposition (das Kleinschneiden von Anforderungen) behandelt. Nicht etwa weil es sich dabei um eine Schätztechnik handelt oder auf einer beruht, sondern weil sie die Anforderungspakete kleiner und damit verständlicher und besser schätzbar macht. Es werden dafür verschiedene Dekompositionstechniken aufgeführt und erklärt, einschliesslich der mit ihnen verbundenen Vor- und Nachteile.

Auch weitere Aspekte die erst auf den zweiten Blick mit Aufwandsschätzungen zu tun haben werden erörtert. Dass z.B. Planungsfortschritte und die verbleibende Zeit bis zu Meilensteinen oder Deadlines ebenfalls nur (bedingt zuverlässige) Schätzungen sind wird zu oft vergessen, von Dinwiddie aber deutlich hervorgehoben - ein Blickwinkel-Wechsel der das Potential hat viele Diskussionen um Aufwandsschätzungen grundlegend zu verändern.

Es gibt aber auch bekanntere Elemente die im Buch rekapituliert werden. Unter "Model-Based Estimation" werden zum Beispiel verschiedene mehr oder weniger bewährte Werkzeuge zusammengefasst. Function Points, Velocity, Cycle Time, lineare Fortschreibung, Burn Up-Charts, Burn Down-Charts, Kumulative Flussdiagramme und viele weitere Konzepte und Praktiken die bei Schätzungen und Planungen helfen können werden vorgestellt und erklärt.

Besonders nützlich für agiles Arbeiten sind die Kapitel in denen es darum geht, wie man in einer Umgebung vorgehen kann, in der ständige Veränderungen eine genaue Schätzungen und Planungen verhindern. Zum einen nämlich durch ständige Überprüfungen und Korrekturen älterer Schätzwerte, zum anderen dadurch, dass Fehlschätzungen zum Ausgangspunkt von Identifizierungen von zukünftig zu vermeidenden falschen und zu optimistischen Annahmen werden.

Zuletzt wird auch die menschliche Dimension behandelt. Dass sowohl die Schätzprozesse selbst als auch der Umgang mit falschen Einschätzungen und ihren Folgen stark von sozialen Dynamiken geprägt werden dürfte jedem klar sein, der schon einmal im Softwareentwicklungsumfeld gearbeitet hat. Das letzte Kapitel des Buches ist ganz diesem Thema gewidmet, dessen Auswirkungen in der Realität immer wieder deutlich unterschätzt werden.

Sowohl für Einsteiger als auch für "fortgeschrittene Agilisten" ist Software Estimation Without Guessing zu empfehlen, bei jedem Wissensstand kann man aus ihm noch etwas mitnehmen. Sogar für Leser ohne Bezug zu den agilen Frameworks lohnt es sich, viele der enthaltenen Informationen und Erkenntnisse lassen sich auch auf andere Vorgehensweisen übertragen. Wie man hundertprozentig zutreffende Aufwandsschätzungen machen kann wird man zwar in diesem Buch nicht lernen, man wird aber verstehen warum es sie nicht geben kann und wie man ihnen möglichst nahe kommt.

Wie man ein Daily Scrum / Daily Stand-Up durchführt

Bild: Unsplash / Parabol - Lizenz

Neben den Retrospektiven sind die Daily Scrums oder Daily Stand-Ups diejenigen Meetings die am stärksten mit den agilen Frameworks verbunden werden. Durch die Kombination aus täglicher Taktung und kurzer Dauer sind sie ideal für das Arbeiten in einer sich schnell ändernden Umgebung geeignet, egal ob im Rahmen von Scrum, Extreme Programming oder einer anderen Methodik. Wie sie im Einzelnen abzulaufen haben ist zwar kaum reguliert, um so den Teams Freiraum zur Ausgestaltung zu geben, es gibt aber Good Practices, und zwar diese hier.

Status-Berichte

Bei fortgeschrittenen Teams eher verpöhnt, für solche die ihre Arbeitsweise gerade umstellen ein Anfang. Statt nur eine ungefähre Ahnung davon zu haben woran die Kollegen arbeiten gibt es jetzt ein tägliches Update jedes Team-Mitglieds. Das kann sichtbar machen wo es vorangeht, wo Verzögerungen zu erwarten sind, wo Hilfe benötigt wird und wo Missverständnisse bestehen. Das Risiko ist, dass das von einem Austausch im Team zu einem Bericht an den Vorgesetzten oder den Product Owner werden kann.

Aus- und Überlastungs-Berichte

Eine Variante die vor allem bei Teams anzutreffen ist die in kleinteiligen Support- oder Service-Jobs arbeiten. Falls hier eine Aufgabe umfangreicher oder langwieriger wird als gedacht kann im Daily um Unterstützung gebeten werden oder Arbeit kann umverteilt werden. Dort wo in Sprints oder Iterationen oder im Pull-Prinzip aus einem Backlog gearbeitet wird eher unüblich.

Die alten drei Fragen aus Scrum

"Was habe ich gestern gemacht?", Was habe ich heute vor?" und "Was hält mich gerade von der Arbeit ab?" sind eine Ausdifferenzierung des Statusberichts, deren Nutzung es möglich macht Focus zu bewahren und die in Scrum vorgegebenen 15 Minuten Meeting-Dauer nicht zu überschreiten. Trotz weiter Verbreitung sind sie aber mittlerweile aus dem offiziellen Teil von Scrum gestrichen worden.

Die neuen drei Fragen aus Scrum

"Was habe ich gestern gemacht um am Sprint-Ziel zu arbeiten?", Was habe ich heute vor um am Sprint-Ziel zu arbeiten?" und "Was hält mich gerade von der Arbeit am Sprint-Ziel ab?" waren eine Weiterentwicklung der drei Fragen, deren Ziel es war die gemeinsame Arbeit an übergreifenden Themen zu fördern. Sie haben sich (vermutlich auch wegen der sperrigen Formulierung) nicht durchgesetzt und sind ebenfalls wieder aus dem Scrum Guide verschwunden.

"Walking the Board"

Ein Ansatz um komplett von personenbezogenen Berichten wegzukommen. Die Arbeit ist auf einem Board visualisiert und wird der Priorität nach durchgegangen, wobei nur Fortschritte und Hindernisse diskutiert werden und nicht individuelle Beiträge. Setzt voraus, dass wirklich alles woran gerade gearbeitet wird auf dem Board visualisiert wird, auch wenn es kleinere Tätigkeiten sind.

Fortschritts-Messung

Hierbei wird der Fortschritt bei der Erreichung eines (Sprint-)Ziels oder der Fertigstellung eines Liefergegenstandes in den Mittelpunkt gestellt, häufig durch die Aktualisierung eines Burn Up- oder Burn Down-Charts oder das Abhaken auf einer To Do-Liste. Gegebenenfalls kann damit auch ein Soll-Ist-Vergleich zwischen Plan und tatsächlichem Fortschritt stattfinden.

Ergebnis- oder Nutzungs-Check

Bietet sich dort an wo tägliche Updates ausgespielt, A/B-Tests gemacht oder mit häufigem Nutzer-Feedback gearbeitet wird (z.B. von Onsite-Customern). Im Daily kann basierend darauf besprochen werden welche neuen Features gut oder schlecht angenommen werden oder wie stabil sie funktionieren um dann die anstehenden Kurzfrist-Ziele anzupassen oder zu repriorisieren.

Heads-Up

Eine Variante die u.a. dort anzutreffen ist wo sich ein Grossteil der Kommunikation in Kleingruppen ausserhalb des Dailies abspielt (was nicht per se schlimm ist). Der Termin dient jetzt nicht mehr dem Informationsaustausch und der gegenseitigen Koordination sondern der Sensibilisierung für entdeckte Probleme von übergreifender Bedeutung, die nicht im Tagesbetrieb untergehen sollen.

Lessons Learned

Ebenfalls eine Variante für Teams bei denen sich ein Grossteil der Kommunikation in Kleingruppen ausserhalb des Dailies abspielt, und gewissermassen das Gegenstück zur letzten. Im Mittelpunkt stehen hier aber nicht Probleme sondern neue Erkenntnisse, Möglichkeiten und Chancen, die der ganzen Gruppe bewusst gemacht werden sollen um sie ggf. in die weitere Arbeit aufzunehmen. Macht vor allem in einem Discovery-lastigen Umfeld Sinn

Und noch weitere

Die Liste wäre vermutlich noch endlos erweiterbar, da viele Teams mit der Zeit mit neuen und angepassten Formaten experimentieren. Was in der Realität ausserdem vorkommt sind Kombinationen der genannten Typen, immer wieder anzutreffen sind z.B. die drei Fragen mit anschliessender Aktualisierung des Burndown Charts oder "Walk the Board"-Dailies an deren Ende die Frage steht ob jemand noch von besonderen Vorfällen oder Erkenntnissen aus seiner gestrigen Arbeit berichten möchte.

Am Ende kann jedes Team sein Daily gestalten wie es will, das gehört zur Selbstorganisation dazu. Nur eines sollte man nicht machen: stundenlange Meetings die nur ein- oder zweimal pro Woche stattfinden Daily nennen. Das ist Quatsch.

Wir haben gewonnen!

Bild: Pixabay / Klimkin - Lizenz

Es gibt da ein Ereignis das viel zu selten erwähnt wird. Eines das für die "agile Bewegung" zentral ist, die die gesamte IT-Branche verändert hat (und gerade anfängt andere umzukrempeln) und das auf absehbare Zeit nicht mehr umkehrbar ist. Worum es geht? Darum, dass wir gewonnen haben. Wir, das sind die Anhänger der agilen Frameworks und Vorgehensweisen, und gewonnen haben wir den Kampf gegen Wasserfall-Vorgehen und Gross-Releases.

Ich weiss, dass sich das nicht für jeden so anfühlt, die Anzeichen dafür sind aber offensichtlich. Auf unseren Handys und Tablets aktualisieren sich täglich irgendwelche Apps, manche davon wöchentlich. Die Betriebssysteme unserer Computer und Mobiltelefone werden durch regelmässige Updates erweitert, in Webanwendungen sind A/B-Tests und die Optimierung auf unser Nutzerverhalten selbstverständlich geworden, Embedded Software erhält ständige Over the Air-Updates.

Auch das Übergreifen auf andere Branchen hat erkennbar begonnen. Bank- und Versicherungsprodukte, Flugzeuge, Autos, Raketen und sogar ganze Fabriken werden iterativ-incrementell, mit Prototypen und kurzen Feedbackzyklen gebaut - und das bereits deutlich länger als die meisten glauben würden. Selbst wenn hier vieles noch am Anfang steht ist nicht mehr zu übersehen, dass mehr und mehr aus den agilen Methoden und Praktiken erfolgreich übernommen und eingesetzt wird.

Ebenfalls unübersehbar ist, dass die gläserne Decke durchbrochen wurde, Agile ist jetzt auch ein Management-Thema. Vorbei ist die Zeit in der auf Management-Konferenzen über "die in den Kellern hausenden agilen Entwicklerteams" gelacht wurde, mittlerweile gibt es kaum noch eine Firma in der das Management nicht zumindest in Teilbereichen das Ziel ausgegeben hat agil zu werden, und das quer durch alle Branchen und Grössen.

Nicht zuletzt ist ein gigantischer "agiler Arbeitsmarkt" entstanden. Product Owner, Scrum Master, Agile Coaches, DevOps Engineers und agilitäts-affine Entwickler und Tester werden überall gesucht, agile Methodenerfahrungen werden von Bewerbern und Recruitern als Aufwertungen der Lebensläufe verstanden und immer mehr Stellenausschreibungen verweisen direkt oder indirekt darauf, dass agiles Arbeiten nicht nur möglich sondern explizit vorgesehen und gewollt ist.

Natürlich bedeutet das nicht, dass bereits alles perfekt läuft, es gibt noch viel, viel zu tun. Aber der Durchbruch ist geschafft. Angesichts zahlreicher erfolgreicher Beispiele kann niemand mehr behaupten, die ganze Idee der agilen Produktentwicklung wäre Unsinn, sie würde in bestimmten Branchen, Grössenordnungen oder Ländern, bzw. Kulturen nicht funktionieren. Dort wo das noch versucht wird sind es letzte Rückzugsgefechte, im Mainstream sagt das fast niemand mehr.

Auch die zunehmenden Versuche unter dem Label von hybridem Vorgehen oder schwergewichtigen Skalierungsframeworks möglichst viel von der alten Management-Welt in die Zukunft zu retten sind nichts was Sorgen machen sollte. Die Deutungshohheit über das was agil ist liegt nicht bei Managern oder Unternehmensberatern sondern in der agilen Community, die auch wenig Scheu hat Cargo Cult beim Namen zu nennen und mit den Füssen abzustimmen.

Sogar der Existenz des berüchtigten agil-industriellen Komplexes kann man noch Gutes abgewinnen. Selbst wenn seine Beauftragung meistens nur zu oberflächlichen Verbesserungen führt (und seine Zertifizierungen weitgehend wertlos sind) kann er eine erste Tür öffnen, indem er sichtbar werden lässt welche Themen, Frameworks und Praktiken es überhaupt gibt (so dass man sich im Folgenden selbst in sie einarbeiten kann) und indem er ihre Akzeptanz in Management und HR erhöht.

Woher auch immer es kommt, all diese in Summe doch bemerkenswerten Fortschritte der Agilisierung werden viel zu selten und zu leise gefeiert. Es liegt an uns dass zu ändern. Wir sind weiter gekommen als vor 20 Jahren irgendjemand zu träumen gewagt hätte, es lässt sich nicht mehr zurückdrehen und wir haben noch viele Etappensiege vor uns. In diesem Sinne - Hasta la agilidad siempre!

Standardsoftware

Bild: Wikimedia Commons / Bengt Oberger - CC BY-SA 4.0

Wer in seiner Firma agile Software-Entwicklung einführen will wird an verschiedenen, zum Teil unerwarteten Stellen Hürden antreffen. Eine davon sind die eingesetzten Anwendungen selbst, genauer gesagt eine spezielle Kategorie davon - die Rede ist von Standard-Software. Dort wo sie anzutreffen ist kommt es schlagartig zu Konflikten mit dem agilen Vorgehen, deren man sich bewusst sein sollte, wenn man nicht unschön überrascht werden will.

Zunächst eine kurze Erklärung: unter Standard-Software versteht man Anwendungen, die einen klar definierten Anwendungsbereich abdecken und fertig programmiert erworben werden können. Wer sie kauft will sich selbst den Entwicklungsaufwand ersparen und stattdessen ein sofort nutzbares Produkt haben, das nur noch installiert werden muss. Bekannte Hersteller von Standard-Softwares sind z.B. SAP, Microsoft, Adobe oder Salesforce.

Das damit verbundene Risiko ist, dass die erworbene Standard-Software nicht (oder nicht mehr) den Wünschen und Bedürfnissen der Anwender entspricht. Bis zu einem gewissen Grad liegt das in der Natur der Sache: es sollen möglicht viele Menschen oder Unternehmen als Käufer in Frage kommen, weshalb auf einzelfallspezifische Bedürfnisse nicht eingegangen werden kann. Das in der Agilität essenzielle Inspect & Adapt findet beim Hersteller daher nur noch sehr eingeschränkt statt.

Aber auch beim Kunden wird der agile Arbeitsmodus eingeschränkt. Theoretisch könnte die gekaufte Software zwar bei Bedarf angepasst werden (man spricht dann vom Customizing), allerdings geht dadurch die so genannte Updatefähigkeit verloren - neue Funktionen, Aktualisierungen und Bugfixes des Herstellers würden die Anpassungen überschreiben, weshalb sie entweder zeitaufwändig angepasst werden müssen oder sogar ganz auf sie verzichtet wird.

Ein weiterer, oft unterschätzter Aspekt ist der, dass Standard-Software im Normalfall als so genannter Big Bang Release eingeführt wird, also alles auf einmal. Da sie in einem bereits fertigen Zustand eingekauft wird ist das auch naheliegend, allerdings ist man dadurch gezwungen die Risiken von Gross-Releases in Kauf zu nehmen: Unübersichtlichkeit, Fehleranfälligkeit, Aufwändigkeit und Vernetztheit, was dann meistens durch eine möglichst detaillierte und dadurch schwerfällige Planung kompensiert werden soll.

Was durch diese Übersicht klar wird: Agilität und Standard-Software sind eine schwierige Kombination. Man kann zwar agile Arbeitsweisen einführen um bestimmte Arbeiten flexibler und schneller zu machen, etwa Customizing, Bugfixing und das Einspielen von Updates, der Einsatz eines agilen Frameworks in Reinform würde aber schnell zu so weitreichenden Änderungen führen, dass vom Produkt-Standard, und damit von den eigentlichen Vorteilen von Standard-Software nicht mehr viel übrig bleibt.

Es lässt sich daher als Faustregel formulieren: dort wo viele Standard-Softwares im Einsatz sind wird es agile Softwareentwicklung nur eingeschränkt geben können, auch wenn das jeweilige Unternehmen es gerne anders hätte. Das ist zwar eine unangenehme Erkenntnis, es ist aber auch eine der man sich möglichst früh stellen sollte. Findet das nicht statt wird es schon bald zu Enttäuschungen und Frustration kommen, die noch deutlich unangenehmer werden können.

Modern Mindfulness & Modern Agile?

Mit diesem Talk hole ich mich gewissermassen selbst aus meiner Komfortzone, denn die Gleichsetzung von Agilität und Mindfulness (Achtsamkeit) löst in mir eigentlich spontanen Widerspruch aus. Das eine ist (im der Form in der es heute verstanden wird) etwas Systemisches, das andere eher etwas vor allem Personenbezogenes. Von daher habe ich bisher immer gesagt, dass Mindfulness zwar etwas Gutes ist, aber unabhängig von und ohne grosse Verbindung zur Agilität, und dass die Vermischung der beiden nur zu einer Verwässerung und Konfusion dieser Konzepte führt. Was Markus Wittwer herausarbeitet sind aber durchaus nachvollziehbare Parallelen: das Herstellen von Focus, das Maximieren von sinnhaften Aspekten der (eigenen) Tätigkeiten, die Bewältigung von Komplexität und der gelassene Umgang mit Veränderungen sind bei beiden zentrale Elemente. Zwar ist der Kontext ein anderer, aber die Herangehensweise ist vergleichbar.

Eine zweite, auch in diesem Vortrag genannte, Dimension ist, dass mittlerweile sowohl Agilität als auch Mindfulness von den Vermarktungs- und Beratungs-Unternehmen so umgestaltet werden, dass sie durch Verkürzung und Vereinfachung besser verkaufbar, dafür aber auch wirkungsloser werden. Eine eher unschöne Parallele.

Team-Charta

Bild: Wikimedia Commons / Hrvatski Sabor - Public Domain

Fragt man agil arbeitende Teams woran sie sich in ihrer täglichen Arbeit ausrichten gibt es als Antwort meistens die bekannten Klassiker: den Scrum- oder Kanban-Guide (oder die Entsprechung in der jeweils angewandten Methode), die dazugehörenden Werte und grundlegende Regeln wie z.B. die Definition of Done. Viele Teams haben darüber hinaus aber noch ein weiteres Dokument: die Team-Charta (auch Team Charter, Team Agreements oder Ähnliches).

Das derartige Chartas weit verbreitet sind liegt an der Natur der agilen Frameworks. Bewusst geben sie nur einen groben Rahmen vor, der dann von jedem Team mit unterschiedlichen Konventionen, Abläufen oder Quality Gates ausgestaltet werden kann. Dass das nicht versehentlich in nicht zielführender Weise geschieht soll durch die jeweiligen Werte sichergestellt werden, zu denen sich die Ausgestaltung in keinem Widerspruch befinden soll.

Die Meetings in dem die meisten dieser Ausgestaltungen stattfinden sind normalerweise die jeweiligen Retrospektiven, Kaizen-Events, o.Ä. Das hat den Vorteil, dass diese selbstgegebenen Regeln und Vereinbarungen immer aktuell gehalten werden können, der Nachteil ist aber, dass es schnell unübersichtlich werden kann. Zu wissen was wann in welchem Termin beschlossen wurde wird mit der Zeit (und dem wachsenden Umfang) immer schwieriger. 

Um diesem Problem zu begegnen kann es Sinn machen die selbstgegebenen Regeln und Vereinbarungen in einem einzigen zentralen Dokument festzuhalten, das dann immer wieder aktualisiert werden kann. Genau dieses Dokument ist es, dass dann als Team-Charta bezeichnet wird. Idealerweise ist es an einem zentralen Ort zu finden, z.B. an der Wand des Team-Raums, auf der Intranet-Startseite des Teams oder weit oben im jeweiligen Ordner-Baum.

Beispiele für Inhalte einer solchen Team-Charta sind der Umgang mit Pünktlichkeit und Timeboxing (kann gerade bei Teammitgliedern mit unterschiedlichen kulturellen Hintergründen sehr hilfreich sein), die Festlegung ob im Zweifel Dokumentation oder Kommunikation wichtiger sind, Vereinbarungen über Präsenz-Tage, meeting- und störungsfrei zu haltende Uhrzeiten, Verhaltensregeln für Meetings und Konfliktsituationen und vieles mehr.

Abzuraten ist von Inhalten die bereits an anderen Stellen festgehalten sind, etwa von Produkt- oder Mehrwert-Definitionen (gehört eher in Produktvision/Produktziel), von Vereinbarungen zu technischen und Qualitäts-Standards (gehört eher in Definition of Done/Policies) oder von Liefergegenständen und Lieferdaten (gehört eher in Product Roadmap/Product Backlog). Bestenfalls entsteht dadurch redundante Datenhaltung, schlimmstenfalls entstehen Widersprüche und Unklarheit.

Um es nachvollziehbar zu machen - eine derartige Team-Charta könnte so aussehen:

Wichtig bei Team-Chartas ist, dass es sich um lebende Dokumente handeln soll, die regelmässig aktualisiert, erweitert und wieder verschlankt werden sollten. Besonders das Letzte ist etwas das häufig vergessen wird, dabei aber von hoher Wichtigkeit ist - sobald die selbstgegebenen Regeln und Vereinbarungen in Summe zu umfangreich werden wird es schwer sie im Gedächtnis zu behalten und übersichtlich darzustellen. Auch hier gilt: im Zweifel ist weniger mehr.

Zuletzt noch ein Tipp aus der Praxis: in vielen Leitfäden wird neu zusammengestellen Teams empfohlen eine Team-Charta zu erstellen bevor die gemeinsame Zusammenarbeit beginnt. Das ist gut gemeint, führt aber selten zu guten Ergebnissen, da die Teammitglieder sich zu diesem Zeitpunkt noch gar nicht gut genug kennen können um zu wissen an welchen Stellen es wichtig ist, sich auf bestimmte Dinge zu einigen. Die Einigungen gehen dann oft am Bedarf vorbei.

Bessere Erfahrungen habe ich damit gemacht nach einem oder zwei Sprints oder Monaten zu fragen ob eine Team-Charta überhaupt gewünscht ist und erst dann die Inhalte zu erarbeiten. Normalerweise hat sich bis dahin herauskristallisiert ob Regelungsbedarf besteht, und wenn ja welcher. So ist das Ergebnis wesentlich bedarfsgerechter und die Akzeptanz und Nutzung wesentlich besser.

Solicitud de Número de Identidad de Extranjero (NIE) y Certificados (LO 4/2000 y RD 557/2011)

Es gibt sie, diese wirklich schlimmen Situationen in denen man sich hilflos einer alles verlangsamenden Bürokratie ausgeliefert fühlt. In dem jeweiligen Moment ist das vor allem ein Gefühl der Machtlosigkeit, man kann aber auch versuchen Positives daraus zu ziehen: zum Beispiel lässt sich an diesen Fällen gut analysieren welche Faktoren und Mechanismen überhaupt dazu führen, dass die Bürokratie (die ja auch gute Seiten hat) so über die Stränge schlägt. In anderen Kontexten kann man dann vorbeugen.

Der aktuelle Fall ist folgender: für einige zukünftige Vorhaben werde ich in der Lage sein müssen in Spanien Geschäfte abschliessen zu können. Das ist dank der Europäischen Union auch möglich, erfordert aber, dass man sich zuvor eine Ausländeridentifikationsnummer ausstellen lässt, oder wie es im Spanischen heisst eine Número de Identidad de Extranjero, abgekürzt NIE. In Spanien bekommt man die bei der Polizei, im Ausland ist es komplizierter.

Vor der Corona Pandemie konnte man für die NIE einfach ohne Termin das nächste Konsulat aufsuchen. Früher oder später hatte dann dort ein Sachbearbeiter Zeit und zog aus irgendeiner Schublade die entsprechenden Formulare, die man zusammen mit ihm ausfüllen konnte. Mit Corona hat sich das geändert, da (nachvollziehbarerweise) verhindert werden soll, dass sich im Konsulatsgebäude Menschenansammlungen bilden. Man muss sich jetzt online einen Termin geben lassen.

Diese Online-Terminvergabe funktionierte bis in den letzten Winter so: auf der Website des Konsulats fand man nach etwas Suchen die NIE-Themenseite. Sehr deutlich wurde dort darauf hingewiesen, dass die Beantragung nur in Präsenz möglich ist, und dass ein solcher Termin nur durch ein Kalender-artiges Tool gebucht werden könnte, nicht am Telefon oder per Mail. In diesem Tool fand sich aber kein einziger freier Termin. Nicht ein einziger. auch langfristig nicht.

Ich habe dann doch angerufen und landete bei einem sehr freundlichen Menschen, der den Grund erklärte. Da in den jeweils nächsten Wochen alle Termine immer ausgebucht wären würden viele Antragsteller gleich mehrere Termine in der weiteren Zukunft buchen, um dann Auswahl und Flexibilität zu haben. Die meisten würden daher kurz bevor sie stattfinden bestimmt wieder freigegeben, ich sollte einfach immer wieder auf die Seite gehen um einen solchen Moment zu erwichen.

Verärgert aber schicksalsergeben machte ich das, manchmal täglich, manchmal wöchentlich, manchmal mehrfach am Tag. Über mehrere Monate lang, ohne Erfolg. Auch ein weiterer Anruf brachte nichts. Man könne nichts machen, die Termine seien nun mal ausgebucht und man könne schliesslich nicht wissen welcher wirklich wahrgenommen werden würde. Also ging es weiter, bis im Frühling plötzlich etwas Unerwartetes passierte: die NIE-Themenseite war von der Website des Konsulats verschwunden.

Da das gesamte Design der Internet-Präsenz sich verändert hatte war auch klar warum: es hatte ein Relaunch stattgefunden. Kinderkrankheiten sind da normal, also wartete ich ein paar Tage. Es passierte aber nichts. Ein weiterer Anruf bestätigte den Verdacht. Wieder war ein freundlicher und hilfsbereiter Mensch am Apparat, der sich für die Probleme der Umstellung entschuldigte und um Geduld bat, bald würde sicher alles funktionieren. Aber natürlich kam es nicht so, der Link führte weiter zur 404-Seite.

Nach einigem Warten gab es im nächsten Anruf einen rettenden Ratschlag: ich sollte eine Email schreiben, auf die könnte man mit dem Link zur neuen NIE-Seite antworten, die zwar schon länger da wäre, aber über die Navigation nur gefunden werden könnte wenn Spanisch als Sprache eingestellt wäre und man genau wüsste auf welcher Seite man nach welchen Informationen filtern müsste (und über die Suchfunktion gar nicht, die wäre kaputt). Und siehe da, in der Antwortmail war der richtige Link.

Meine Theorie: dass ich dort endlich einen Termin buchen konnte lag daran, dass die meisten Antragsteller diese Seite bis heute nicht finden (oder kein Spanisch sprechen, nur in dieser Sprache gibt es sie). Etwa ein Dreivierteljahr nachdem ich zum ersten mal auf der Website des Konsulats war konnte ich mich auf den Weg machen und mit dem ausgefüllten Formular Solicitud de Número de Identidad de Extranjero (NIE) y Certificados (LO 4/2000 y RD 557/2011) meine Identifikationsnummer beantragen.

Natürlich ist das hier nur eine verkürzte Darstellung der Ereignisse, aus der einige Details weggelassen wurden um die Geschichte kurz zu halten. Aber ich wollte ja nicht nur meine Bürokratie-Erfahrungen beschreiben sondern noch etwas anderes machen. Stellen wir uns die Frage: an welcher Stelle wurden hier vermutlich die Fehler gemacht, durch die ich gefühlt in die Fänge der spanischen Inquisition geraten bin? Wohl an zu vielen, aber hier sind einige offensichtliche:

Der alte, zwar irgendwie funktionierende aber manuell-anachronistische Prozess wurde nicht rechtzeitig um einen neuen, digitalen ergänzt. Ein Klassiker. Es hätte genug Beispiele dafür gegeben wie der gestaltet werden kann und beim Corona-Ausbruch hätte man auf bestehende, online funktionierende Prozesse und Routinen zurückgreifen können. So musste es dann überhastet stattfinden. Ein schönes Beispiel für die Folgen von Modernisierungsrückständen.

Auch die erste digitale Lösung (vor dem Relaunch im Frühling) hatte ihre Probleme, mit der Überlastung der Kundenschnittstelle als vielleicht schwerstem. Ohne die komplette Verbuchung aller Tage der näheren Zukunft hätten die Antragsteller keine Motivation gehabt das System durch mehrfach-Termine auch dauerhaft zu überbuchen. Oder anders betrachtet: wer auch immer diese Prozesse designed hat, er hatte offensichtlich keine Vorstellung von den Verhaltensmustern seiner Kunden (siehe auch hier).

Apropos keine Vorstellung: die fehlte hier anscheinend in Bezug auf Anforderung, Entwicklung und Abnahme von Software. Unterschiedliche Features in unterschiedlichen Sprachen, schwerwiegende Bugs in banalsten Funktionen (wie dem Benutzen der Suchfunktion), fehlende Redirects der alten auf die neuen Internetadressen - ein häufiges Bild in Organisationen die noch nicht erkannt haben, dass sie zu wesentlichen Teilen aus Software bestehen und glauben sie billig outsourcen zu können.

Was in solchen Kontexten dazukommt: offensichtlich wurde beim Systemdesign nicht nur das Nutzer-Verhalten nicht berücksichtigt, auch die Expertise der eigenen Mitarbeiter wurde nicht einbezogen, weshalb diese trotz bestem Willen machtlos zusehen mussten wie ihre Kunden in kafkaesken Warte- und Nicht-Bearbeitungsschleifen festhingen, die ihnen trotz offensichtlicher Unzulänglichkeit von irgendwelchen Systemworkflows aufgezwungen wurden.

Gerade weil dieser Fall so eklatant ist eignet er sich gut um aufzuzeigen wie eigentlich wohlmeinende und hilfsbereite Organisationen in Verhaltensmuster abkippen können, die von ihren Kunden dann als Bürokratie wahrgenommen werden. Die Gründe liegen in der Regel in den Systemen, sowohl den sozialen als auch den technischen. Die Moral von der Geschichte kann daher nur lauten regelmässig an denen zu arbeiten.

Kultur

Bild: Unsplash / Richard Tao - Lizenz

Man kann fest davon ausgehen - wann auch immer eine Organisation sich in Richtung New Work, agile Produktentwicklung oder Vergleichbares verändern will wird sehr bald jemand anmerken, dass man dafür auch an der Kultur arbeiten müsste. Das ist auch grundsätzlich richtig, stösst aber schnell auf ein Problem: nur die wenigsten Menschen können beschreiben was sie unter Kultur verstehen. Da ein gemeinsames Verständnis aber die Grundlage der weiteren Schritte ist sollte man es zuerst herstellen.

Der Begriff Kultur definiert sich ursprünglich lediglich durch seine Abgrenzung zu einem anderen: zur Natur. Die Natur ist alles was auch ohne die Existenz Menschen vorhanden wäre, von der Plattentektonik über das Wetter bis hin zu Pflanzen und Tieren. Alle vom Menschen vorgenommenen Veränderungen an der Natur und alle menschlichen Erfindungen und Ideen sind dagegen Kultur, von der Sprache und der Landwirtschaft über die Musik und die Architektur bis hin zur Betriebswirtschaft und Informatik.¹

Aus diesen Beispielen wird klar, dass es die eine einheitliche Kultur nicht gibt. Sie zerfällt in zahllose Subkulturen, die einer geografischen Region, einer historischen Epoche, einer Ethnie, einer Altersgruppe oder einer sozialen Gruppe entsprechen können. Zu der letzten gehören dann u.a. Gruppen mit gleicher Bildung, gleichem Einkommen, gleicher Religion, gleichem Beruf oder gleicher Zugehörigkeit zu einer Firma oder Organisation. Diese zuletzt genannte Subkultur ist die um die es in Change-Prozessen geht.

Eine solche Firmenkultur besteht dann aus verschiedenen Dimensionen. Zum einen den sichtbaren Artefakten wie Architektur, Dresscode und Corporate Design, aber auch Glaubenssätzen wie "ohne Vorschriften würde hier Chaos ausbrechen", Handlungsmaximen wie "im Zweifel eher anrufen als Emails schreiben" oder Gefühlen und Emotionen wie "wir sind hier alle eine grosse Familie". Je nach Einzelfall können noch weitere Dimensionen dazukommen.

All diese Dimensionen sind prägend für die Art wie in einer Firma oder Organisation mit Arbeit und mit den anderen Mitarbeitern umgegangen wird. Herrscht beispielsweise eine Untertanenkultur vor ("ich bin unwissend und machtlos, Veränderungen müssen von anderen kommen") wird ein auf Eigeninitiative und Verantwortungsübernahme basierender Arbeitsmodus kaum funktionieren, in einer Partizipativen Kultur ("ich kann Veränderungen bewirken, aber wenn ich sie will muss ich es selbst tun") dagegen schon.

Was mittlerweile ebenfalls klar geworden sein dürfte: es ist extrem schwierig eine Unternehmenskultur zu verändern, da sie im Wesentlichen in den Köpfen der Menschen existiert. Das heisst nicht, das es nicht ginge, es gibt bekannte Beispiele dafür. Eines des bekanntesten dürfte z.B. das Automobil-Werk im kalifornischen Fremont sein, das nacheinander von GM, Toyota und Tesla betrieben wurde und in der Zeit jeweils eine spürbar andere Firmenkultur (und dadurch bedingte Produktivität) gehabt haben soll.

Wie ein solcher Kulturwandel aussehen könnte ist nochmal eine eigene Geschichte, bevor derartige Schritte angegangen werden ist es aber wie gesagt eine gute Idee sich zuerst ein gemeinsames Verständnis dessen zu erarbeiten was man unter "Kultur" versteht. Erst dann ist es möglich zu überlegen ob sie überhaupt geändert werden kann, und wenn ja wie.

¹Die Beschränkung des Kulturbegriffs auf die "schönen Künste" wie Schauspiel, Musik und Literatur ist lediglich eine alltagssprachliche Verkürzung