Der Prozess

Die Klitsche
Es gab eine mittelständische Softwarefirma namens L. Sagen wir, die Firma hatte 40 Mitarbeiter: 38 Leute, die gearbeitet haben und 2 Chefs. Von den 38 arbeitsamen Leuten waren 35 Entwickler. Die Entscheidungswege waren kurz und chaotisch, so dass sich die Arbeitsamen beschwerten, sie würden auf Zuruf arbeiten. Was Gestern noch galt, war Morgen schon Geschichte; neue Module entstanden binnen weniger Wochen und Zeitdruck war allgegenwärtig. "Ach wie schön wäre es doch", dachten die Arbeitstiere, "wäre alles strukturierter und geplanter".

Man sollte sich vorsehen, was man wünscht, sagt ein Sprichwort. Es könnte in Erfüllung gehen.

Verkauft
Die mittelständische Firma wurde an eine Firma S. verkauft und war jetzt Teil einer großen Familie. Die neuen Schwestern und Brüder, Omas und Opas überschwemmten den Standort des neuen Familienmitglieds. "Wie innovativ und effizient hier alles ist", sagten sie, "wie unbürokratisch und engagiert. Ihr solltet euch diesen Spirit erhalten." Dann wurde der Standort auf den neusten Stand der Managementprozesse gebracht. Es wurden Gruppenleiter, Projektleiter und Teilprojektleiter eingeführt. Sowie ein Qualitätsbeauftragter. Die Ameisen -Verzeihung: Arbeitsamen- bekamen hübsche neue Aufgaben wie Flurbeauftragte, Brandschutzhelfer und Ersthelfer. Es wurde ein Betriebsrat gewählt und der wiederum bestimmte (Frauen-/ Auszubildende-/ Behinderte-) Beauftragte.

Zu den neuen Brüdern und Schwestern gesellten sich auch neue Väter und Mütter. Die brachten viele Visionen mit - warum die sich diese Visionen nicht vom Arzt behandeln ließen, war nicht ganz klar. Diese Visionen wurden nicht auf Steintafeln präsentiert - man war ja modern - sondern auf Powerpoint-Folien. Und kam man bei den Steintafeln noch mit 100 Wörtern aus (vermutlich weil es so mühsam war, Steintafeln zu behauen), so waren es bei den Folien jetzt 100 Seiten. "Großes kommt auf euch zu!" riefen die neuen Väter und Mütter und die Zugekauften murmelten "OK, wir machen Platz". Dieses "Große" war eine Steigerung des Umsatzes um 400% binnen 5 Jahren. Um das "Große"zu fördern, dachten sich die neuen Mütter und Väter des Standorts Innovationsprojekte aus. Viel, sehr viel Geld wurde in diese Innovationsprojekte gesteckt.

Zum Beispiel sollten die Datenbestände in völlig neuem Stil gespeichert werden: effizienter, geplanter. Hieß ein Datenfeld früher "Rohr_Innendurchmesser" so war der Name jetzt Y000A23716b, was Datentechnisch viel hübscher war. Die neuen Daten waren inkompatibel, natürlich, zu früheren Versionen. Wo gehobelt wird, da fallen Späne.

"Die Kunden sollen ihre Gigabyte an firmenspezifischen, wettbewerbsrelevanten und gesetzlich kontrollierten Daten wegschmeissen, um auf eigene Kosten auf einen neuen Standard umzusteigen?" fragten die zugekauften Entwickler.
"Genau" sagten die neuen Vordenker mit AT-Verträgen.
"Hm", sagten die zugekauften Entwickler. Was die Vordenker als Zustimmung werteten.

Ein anderes Innovationsprojekt war eine Neuentwicklung der kompletten Software. Die Bestandssoftware war softwaretechnisch veraltet, fanden die Vordenker, und stellten 3 Entwickler ab. Die sollten in 5 Jahren die neue Software Marktreif haben, während die restlichen 32 Entwickler an der alten Software weiterarbeiten würden.

"Die drei Kollegen sollen in 5 Jahren die komplette Software neu schreiben, während wir anderen 32 Entwickler an der alten Software weiterarbeiten?" fragten die zugekauften Entwickler.
"Genau", sagte die neue intellektuelle Speerspitze des Standorts, "das wirkt vielleicht sportlich, aber wenn man ein paar überflüssige alte Zöpfe abschneidet, dann geht das schon."
"Hm hm", sagten die zugekauften Entwickler. Was die Vordenker als begeisterte Zustimmung werteten.

PLM
Der neue Entwicklungsprozess nannte sich "PLM", was so viel bedeutet wie "Vorher festlegen, was in der nächsten Software-Version drin sein soll". Und festzulegen gab es viel. Der PLM-Prozess erforderte ein Anforderungsdokument mit hunderten Seiten, Protokolle, Besprechungen, Prozess-Schulungen. Was dazu führte, dass in Folge die Neuentwicklung von Funktionen auf etwa die Häfte zusammenschrumpfte. Allerdings sanken auch die neuen Fehlereinträge um die Hälfte, was allgemein als großer Erfolg betrachtet wurde. Funktionen die nicht entwickelt werden, können eben auch keine Fehler haben.

Langsam aber sicher wurde alles am Standort geplanter. Strukturierter. Traf man früher in den Zeiten des Mittelständlers die Entwickler oft um 20:00 noch im Büro an, so waren jetzt die Büros um spätestens 18:00 leer. Was auch daran lag, dass allen Mitarbeitern die gesetzlichen Arbeitszeit-Vorschriften eingebleut wurden und dass niemand allein auf einer Etage arbeiten durfte. Es mussten auch abends immer mindestens zwei Kollegen anwesend sein, weil sonst im Falle eines Herzstillstands ja niemand für die Erstversorgung anwesend wäre.
Statt spontaner Besprechung im Türrahmen wurden JourFix und Dailies eingeführt: das sind Termine, bei denen man sich gegenseitig versichert, wie hart jeder arbeiten würde. Die Kommunikation professionalisierte sich.
- Hörte man früher eher Aussagen wie (bei Zustimmung) "Super Idee" oder (bei Ablehnung) "Die Anforderung ist inhaltlich unsinnig und technisch nicht lösbar"
- So war es jetzt eher etwas wie (bei Umsetzung) "Den Sinn diskutiere ich nicht, das wurde so entschieden" und (bei Ablehnung) "Ist mir egal, was das bringt, dafür habe ich keinen Arbeitsauftrag".

Die neuen Prozesse begannen zu wirken. War es früher einen Monat Verzug, den man bei der Freigabe hatte, so war es jetzt nur noch vier Wochen. "Drei Bestandteile hat die PLM-Versionsplanung", lernten die Zugekauften, "Ressourcen, Anforderungen und Termin". Da die Ressourcen und der Termin heilige Kühe und im voraus festgelegt seien, könne man bei unverhersehbaren Ereignissen (wie Weihnachten oder Urlaubszeit) nur an den Anforderungen schrauben. Also lieber ein paar Funktionen streichen und dafür Budget und Zeitplan einhalten. Deswegen strich man bei der nächsten Version der Software einen Teil der Funktionen und kam so auf einen neuen Bestwert von nur 28 Tagen Verzug.

Visionen und Innovationen
Erinnern wir uns an die vorhergesagte Steigerung des Umsatzes um 400%? Inzwischen waren 5 Jahre vergangen und der Umsatz war wie zuvor. Allerdings waren die Kosten um 400% gestiegen. Es gab gesittete Gespräche, ob das auch zählen würde; sowohl für als auch gegen diese Auslegung gab es gute Argumente. Die Innovationsprojekte waren umgesetzt und die Kunden ignorierten sie. Aus irgendeinem unklaren Grund waren die Kunden nicht bereit, ihre Altdatenbestände ersatzlos wegzuschmeissen, um komplett bei Null neu anzufangen. Die neuen Vordenker mit den vergoldeten Gehaltschecks machten sich viele Gedanken darüber, warum die Kunden derart unkooperativ waren.

Die drei Kollegen für die Neuentwicklung der Software hatten nach 5 Jahren vielversprechende Powerpoint-Folien erstellt. In den Folien wurde auf 20 Seiten elegant erläutert, warum 3 Softwareentwickler für 5 Jahre nicht genügten, um 400 Mannjahre Softwareentwicklung nachzubauen. "Hübsch", sagten die Vordenker, "aber eigentlich wollten wir die fertige Software haben." Und weiter sagten sie: "Wir können doch nicht alles selbst machen, die Entwickler müssen die neuen Ideen schon auch mittragen".

Es kam die Frage auf, wer damals das viele Geld in die Innovationsprojekte gesteckt hatte, wer für diese Entscheidung eigentlich verantwortlich war. Die Vordenker, die Väter und Mütter schauten sich um... "Niemand", sagten sie dann, "hat das entschieden. Oder zumindest ist uns nicht nachzuweisen, dass wir das waren."

"Das ist komisch, weil doch eigentlich alles schriftlich bestätigt werden muss?" fragten die zugekauften Ameisen.
"Das gilt nur für die Arbeitsebene", sagten die Visionen-Träger, "auf unserer Ebene ist Schriftlichkeit nur hinderlich. Auf unserer Ebene zählt das COMMITMENT - Besprechungsprotokolle und ähnliches wären nur Zeitverschwendung".

Scrum
Nach der erfolgreichen Einführung des PLM-Prozesses sollte die Effizienz noch weiter gesteigert werden. Die nächste evolutionäre Stufe der Managementprozesse wurde geboren: "Agile Scrum-Entwicklung". Dabei sollten kleine Gruppen gebildet werden. Jede Gruppe sollte genau die Leute umfassen, die zu einem Thema auch etwas Sinnvolles beizutragen hatten und dann sollte die Gruppe sich selbstverantwortlich organisieren. "Das ist hübsch", dachte so mancher, "jetzt habe ich einen Namen für etwas, was wir früher von ganz allein gemacht haben". Als Scrum eingeführt wurde, gab es einige wichtige Weiterentwicklungen des Prozesses. Ab sofort galt nicht nur Arbeit als Arbeit. Auch über Arbeit reden galt als Arbeit. Außerdem galt das Verwalten des Redens über Arbeit als Arbeit. Die Anzahl der Dailies, Plannings, Reviews, Retros und Backlog-Refinments stieg gewaltig. Gemäß neuer Definition stieg damit auch die geleistete Arbeit gewaltig an. Die Anzahl der entwickelten neuen Funktionen nahm spiegelbildlich ab. Die wenigen bisher noch produktiven Entwickler wurden zu "Scrum-Mastern" ernannt: deren Aufgabe war es, den Kollegen beizubringen, wie man Arbeitet.

Natürlich behielten alle bisherigen Gruppenleiter, Projektleiter, Teilprojektleiter, Beauftragten, Architekten, Product owner, Solution Manager, Improvement projects-Experten, Workforce-Leiter und Versionsmanager ihre Jobs.

Die neue Organisation war dadurch hochgradig gut mit lenkender Intelligenz ausgestattet. In jeder freien Ecke des Standortgebäudes waren Leute damit beschäftigt, über das Produkt und die Produktentwicklung nachzudenken. Es gab jetzt ungefähr 55 Entwickler und etwa 85 Leute, die mit Powerpointfolien und COMMITMENTS beschäftigt waren. All diese Intelligenz musste selbstredend Informiert und Kommuniziert werden. Das erforderte viele Besprechungen, in denen all die Vordenker sich gegenseitig ihre Vordenke vorstellten und Chefs ihre Chefs informierten, damit die ihre Chefs auf den neusten Stand bringen konnten. Viele der Vordenker wusste nicht mehr aus noch ein, weil der Terminkalender mit Besprechungen vollgepflastert war. Dramatische Szenen spielten sich ab, wenn solche Vorgesetzten mal Wochen auf Kur waren und nach der Rückkehr feststellten, dass niemand ihre Abwesenheit bemerkt hatte.

Eine typische Besprechungsrunde sah jetzt so aus:
- Optional: Projektleiter
- Teilprojektleiter oder Scrum-Master
- Product owner
- Solution Manager oder Software-Architekt
- Tester
- Redakteur
- Optional: Supportmitarbeiter
- 3 Entwickler

Optimierung
Die Vordenker bemerkten, dass die Kosten etwas zu hoch geworden waren. Sie vermuteten, dass die Personalkosten der Entwickler dafür der Grund seien.

"Wir erlassen eine Nachbesetzungssperre für den deutschen Standort", sagten die Eigentümer der AT-Verträge mit dem nach oben festgelegten Abstandsgebot zur gewöhnlichen Bezahlung laut Tarif, "und stellen statt dessen Entwickler in Indien ein. Das sollte helfen".

"Wer wird denn die indischen Kollegen einarbeiten?" fragten die Kollegen des deutschen Standorts.
"Ihr natürlich", sagten die Vorgesetzten mit der vertraglich fixierten Beschäftigungsgarantie, "wir bauen eure teuren Arbeitsplätze nach und nach ab, ersetzen sie durch indische Neueinstellungen, die noch nie das Produkt gesehen haben und drücken so die Lohnkosten".
"Aber das wird die Produktivität der deutschen Entwickler noch weiter senken, weil die deutschen Entwickler einen Teil ihrer Arbeitszeit für die Schulung der indischen Kollegen aufwenden müssen" bemerkten die deutschen Ameisen.
"Kein Problem. Wenn die Produktivität der deutschen Entwickler sinkt, stellen wir mehr indische Kollegen ein. Das gleicht das aus."
"Hm hm hm" sagten die deutschen Code-Sklaven und die Chefs waren begeistert über so viel Zustimmung.

Golden Card
Aber es gab noch viel mehr innovative Ideen, den Entwicklern ungeahnte Produktivitätsschübe zu ermöglichen.
Ein Scrum Master kam zum Team und bot an, eine Golden Card einzuführen.
"Was ist das?" fragte das Team.
"Das ist ein neues Prozesselement", sagte der Scrum Master, "das euch erlaubt zu arbeiten. Einmal in jedem Sprint (also einen Tag pro zwei Wochen) dürft ihr die Golden Card verwenden und an dem Tag dürft ihr ungestört arbeiten"
"Es soll eine Arbeitserlaubnis als Prozesselement eingeführt werden?" staunten die Entwickler.
"Genau. Wir Scrum Master vermuten, dass die Teams Rückendeckung brauchen, damit sich die Entwickler nicht rechtfertigen müssen, wenn sie arbeiten wollen. Wenn die Entwickler eine solche Golden Card hätten, dann könnten sie wenigstens einen Tag pro zwei Wochen arbeiten, ohne sich dafür entschuldigen zu müssen"

Keine Probleme, sondern Lösungen
Nach 5 Jahren in der neuen, großen Familie mit den vielen Produktivitätssteigerungsprozessvorschriften hoben ein paar der Entwickler den Finger und sagten höflich:
"Die ganzen Vorschriften und Prozesse scheinen eher problematisch zu sein"
"Meckern kann jeder", meinten die xxleiter und yymaster, "was wir brauchen sind Lösungen, nicht Problembeschreibungen"
"Aber wir dachten ihr werdet dafür (extrem gut) bezahlt", wunderten sich die menschlichen Ressourcen von R&D, "dass ihr euch Lösungen für das Große Ganze ausdenkt"
"Aber nicht doch" lächelten die Elite-Mitglieder der großen Familie, "wir sind dafür da, euer Potential zu entfalten. Wir ermöglichen euch, maximal produktiv zu sein."


Und Morgen wird es noch besser. Ganz sicher.