In einer anderen Firma gab es ITIL. ... Anfangs gut, später grausame Erfahrung für jeden Entwickler.
Ich finde es schön, dass hier gleich deutlich gezeigt wird, woran die meisten solcher Prozesse in der Praxis scheitern. Der einfache Grund für dieses Beispiel besteht darin, dass ITIL sich zur Softwareentwicklung verhält wie Äpfel zu Eiern (anders als bei Birnen kannst Du da nicht mal Obstsalat draus gewinnen).
Wenn der IT-Betrieb auf ITIL gesetzt hätte, dann wäre abzuwarten ob und wie das mit einem Buch geklappt hätte (wahrscheinlich würde man auch hier scheitern, kann aber sicher auch vom Buch abhängen ;-)).
Meiner Meinung nach sieht man hier etwas, das man nicht selten findet, da hat jmd. ein cooles neues Buzzword aber nicht die Idee dahinter verstanden. Einen Prozess kann man einführen, solange der nicht gelebt wird, wird man scheitern. Das gilt für ITIL, Cobit, Grundschutz/ISO 27001, Scrum, XP usw. gleichermaßen.
Damit ein Prozess gelebt wird sind verschiedene Punkte wichtig, es fängt jedoch damit an, dass man den Sinn verstanden hat. Es geht in keinem der Prozesse darum sich Vorschriften zu unterwerfen und die stupide 1:1 umzusetzen. In meiner ITIL Schulung wurde vom Vortragenden z.B. mehrfach darauf verwiesen, dass ITIL (und kein anderer Prozess) einem vom Mitdenken befreien. Zentral ist also weiterhin der Verstand der beteiligten.
Für die Softwareentwicklung ist ein Prozess wie ITIL einfach völlig ungeeignet, während Scrum sich hier deutlich eher anbietet. Aber auch hier muss man schauen, die Qualitätssicherung oder das Erstellen von Fachkonzepten lassen sich nicht unbedingt sinnvoll in ein Scrum gießen, auch sollte das Projekt bestimmen welche Technik gut zur Umsetzung geeignet ist und nicht umgekehrt.
Für die meisten Prozesse gilt, dass man einfach realistisch rangehen lernen muss. Am Anfang ist die Motivation hoch und jeder erwartet schon kurzfristig eine Verbesserung. Gibt es aber so gut wie nirgends. Auch wird gerne der Fehler gemacht, dass man erstmal nur ein paar wenige Ressourcen zugesteht und wenn's gut läuft, dann kann man ja immer noch nachlegen.
Dem steht aber gegenüber, dass etwas neu eingeführt wird, es fehlt an Expertenwissen und den hohen Erwartungen folgt erstmal Veränderung (der Mensch ist aber eher ein Gewohnheitstier). Erfahrungsgemäß sind viele Leute bei einem Konsequenten ITIL z.B. anfänglich negativ überrascht, wenn man plötzlich das Incident Management bemühen muss. Vorher ging man zu Klaus-Erwin, der hat sich auch immer gekümmert, das geht dann plötzlich nicht mehr.
Auch was die vielen Boards angeht, die gibt es so nicht, man hat das CAB und das ist auch gut so. Das entscheidet über Änderungen und muss dabei einfach die Risiken abschätzen. Ganz wichtig, das CAB darf auch Vorautorisieren und das wird in der Praxis auch gemacht!
Mit mindestens einem halben Jahr darf man eigentlich bei fast allen Prozessen dauern, bis die mal anlaufen. Bei Grundschutz oder ISO 27001 Zertifizierungen spricht man sogar eher von einem Jahr oder mehr (deshalb gibt es beim Grundschutz auch die Zwischenzertifizierung). Und für den Verantwortlichen werden das belastende Monate sein, den (häufig falschen) Erwartungen folgt anfänglich Frust.
Eine gute Umsetzung führt dazu, dass diese Phase nicht lange anhält, dass sie komplett ausbleibt ist aber eher selten. Denn natürlich muss man sich erstmal an die Änderungen gewöhnen und die verinnerlichen, hat Fragen und muss ggf. auch mal länger auf eine Antwort warten. Wurde aber der Prozess passend ausgewählt (ITIL für SW-Entwicklung kann nicht klappen) und wird der richtig motiviert und etabliert, dann stellen sich auch die Vorteile ein. So kann z.B. ITIL tatsächlich das Leben vereinfachen, weil es eine klare Rollenverteilung gibt. Viel zu gerne machen gerade ITler vieles zu ihren Problemen, ohne dass dem so ist, aber das ist ein anderes Thema.
Zu guter letzt, das positiv Beispiel überrascht mich wenig. Bei 3-4 Entwicklern wird jede Entscheidung (fast automatisch) gelebt. Da werden sicher alle zusammengesessen und sich gemeinsam für eine Lösung entschieden haben. Die Beteiligten haben vielleicht den Prozess auf Anhieb verstanden und wussten, dass die anderen nicht beeindruckt sind, wenn man ständig betont, dass man jetzt "Scrum" oder "XP" oder "HAST_DU_NICHT_GESEHEN" macht.
Letzteres wird gerne einem übergeordneten Management unterstellt (in bestimmten Schichten sind Buzzwords wichtiger als die Technik dahinter zu verstehen).
Aber hier muss ich auch eine Lanze für gutes Management (das gibt es tatsächlich auch) brechen, bei 3-4 Personen gestaltet sich die Schwierigkeit ganz anders, als bei 30-40 Personen (oder gar 300-400 Personen). Je größer die Teams sind, um so mehr Struktur und Overhead ist nötig um die Arbeit überhaupt noch koordinieren zu können.
Aber auch hier ist es nicht damit getan einen populären oder gut klingenden Prozess zu suchen und zu sagen, so, machen wir. Vielmehr muss der Kern erfasst und gelebt werden (durch alle Mitarbeiter). Die Kunst besteht ja gerade darin, dass der Mehrwert auch bei den Leuten ankommt und sich auch für sie zeigt. Und wie bereits gesagt, man darf nicht den Verstand zu Gunsten des Prozesses abschalten! Ein Prozess wird wie jedes Werkzeug zu dem Ziel ausgesucht das man erreichen möchte, niemals sollte in Prozess/Werkzeug das Ziel vorgeben.
