[de] Agile Tod, 24 July 2015

Viele Unternehmen haben sich in den letzten Jahren vorgenommen agil zu werden. Hierbei stellt sich oft die Frage, was ist tatsächlich agil? Der englische Begriff Diffusion beschreibt eine Problematik, welche ich immer häufiger sehe. Bedingt durch “Enterprise Agile” und dem möglichen Profit haben sich die wildesten Konstrukte gebildet, welche agil sein sollen. Doch was macht diese Konstrukte agil?

Klassisches Agentur Agil

Der Agile Productowner

Moderne Produktowner sind gerne agil. Sie haben die Macht, können alles jederzeit umwerfen und müssen sich auf nichts festlegen. Die agile Softwareentwicklung lebt davon, dass Anforderungen nicht bekannt sind und wenn sich sowie immer alles ändert, dann kann man auch gleich das Entwicklerteam an die hand nehmen und wöchentlich Anforderungen in das Projekt kippen. Der Productowner ist technisch nicht so versiert, diskutiert aber gerne mit, schätzt Tickets und erklärt den Entwicklern, dass die Anforderungen doch nur harmlos sind. Geübt verbreitet er unmut und suggeriert dem Entwicklerteam, es müsste härter arbeiten, damit mehr (sehr sehr wichtige) Features in das System kommen. Schließlich hat der Productowner bei einem so tollen Team, dritten Stakeholdern schon viele Zugeständnisse und Versprechungen gemacht.

Der Agile Entwickler

Dem agilen Softwareentwickler ist bewusst, dass im nächsten, spätestens im übernächsten Sprint der Produktowner wieder alles einreißt

• schließlich ist nichts beständig. Und wenn dem so ist, dann ists halt das Problem vom Produktowner, er wird schon irgendwann drauf kommen, dass das keine gute Idee sein kann. Der agile Entwickler ist gut darin, dieses Wissen nicht groß zu kommunizieren, schließlich ist der Produktowner entweder der Kunde (der immer recht hat) oder technisch so unversiert, dass es ja eh nichts bringt, Hand in Hand mit ihm zusammen zu arbeiten. Mit dem Scrum-Master möchte man sich schon garnicht anlegen, schließlich weiß er ja wie “Enterprise Agil” funktioniert. Um weiterhin agil zu bleiben, wird also Anforderung an Anforderung geklatscht, dass System wird so immer ein wenig fragiler, merken tuts jedoch erstmal eh keiner. Außerdem sagt die arbeitsweise ja, es müsse agil und damit schnell gehen - demnach ist für mehr keine Zeit. Der Productowner muss es nur irgendwie abnehmen.

Der Agile Scrum-Master

Der Scrum-Master kann nur richtig liegen und wenn nicht, dann spielt er halt seine Position als “Master” aus. Er steuert was gesagt werden darf, was nicht. Als Manager ist er darin geübt. Er macht die Regeln. Das gelingt besonders gut, weil der Scrum Master selbst keine Verantwortung trägt, schließlich ist es nur seine Aufgabe zu schauen, dass die Entwickler besonders agil sind. Er hat sich nur darum zu kümmern, dass möglichst schnell möglichst agile Änderungen, irgendwie in die Software integriert werden. Wenn das nicht klappt, dann ist es das Entwicklerteam halt schuld.

Die Agile Personalführung

In einem agilen Team kann man nicht sonderlich aufsteigen, demnach bleiben die Personalkosten gering. Jeder macht halt das was er kann. Wer nicht ausreichend agil ist und nicht ohne nachzufragen Kundenwünsche implementiert, ist nicht gut fürs Klima. Das funktioniert schon irgendwie! - und wenns nicht auf Dauer funktioniert, bezahlt wurde ja Sprint für Sprint.

Warum geht das gut?

Die große Frage, die man sich nun stellen könnte ist ja, warum geht das gut? Warum sind so viele Firmen so erfolgreich damit? Ein Großteil der Projekte welche von Agenturen “erfolgreich” umgesetzt werden, sind klein. Mit kleinen Projekten meine ich, dass diese über einige Monate laufen.

Unter hochdruck (wie der Begriff Sprint so nett suggeriert) schaffen die Entwickler eine halbwegs brauchbare Lösung und der Kunde ist zufrieden.

Laufen die Projekte länger oder es entstehen doch mal ernsthafte Anforderungen an die Software, so läuft man halt in Probleme. Bei einfachen Agenturprojekten ist das dann halt die Dunkelziffer von Projekten, die nicht gut liefen.

Es geht also gut, weil man im Team einen Müllberg geschaffen hat, der nicht umgekippt ist, bevor man nichts mehr drauf werfen konnte.

Will ich das verhindern?

Es hört sich schrechlich an, aber bei genauer Betrachtung scheint es ja zu funktionieren. Viele Agenturen sind damit so erfolgreich, dass sie blind ein solches “Scrum” für die Lösung aller Probleme halten. Es funktioniert, wenn man keine ernsthafte Software bauen möchte.

Sollte es mal nicht funktionieren, hat das Management die Möglichkeit Scrum Coaches und Berater zu kaufen. Um das zu verwirklichen, wurden die agilen Werte so weit verkompliziert, dass diese gewaltige Schulungen und kostspielige Investitionen erfordern.

Wie baue ich ernsthafte Software mit agilen Methoden?

Vor einiger Zeit haben sich einige sehr kluge Köpfe zusammengesetzt und ein Agiles Manifest entwickelt, welches dabei unterstützen soll, die agilen Werte zu verstehen und zu leben.

Ich würde empfehlen sich mit dem Agilen Manifest auseinander zu setzen, sich einzugestehen, dass ein Team professionell, ehrlich und erfahren sein muss, damit Agil wirklich funktioniert.

Wer ist Schuld?

Ich glaube garnicht dass die Frage ist, wer wirklich Schuld an der Entwicklung hat, die Frage ist primär, wer hat die Möglichkeit davor zu bewahren und nutzt diese nicht? Das Agile Manifest wurde primär von Software Entwicklern verfasst, dies liegt darin begründet, dass Entwickler in der Lage sind Anforderungen zu sehen und die Entwicklung dieser Anforderungen zu verfolgen. Der Entwickler spürt solche Probleme deutlich schneller und intensiver.

Werden solche Probleme ignoriert ist es grob fahrlässig. Entwickler werden dafür bezahlt, Probleme zu lösen, Probleme sind positiv, ohne diese gäbe es wohl keine interessanten Aufgaben, womöglich sogar garkeine Aufgaben.

Die Aufgabe eines agilen Teams ist es möglichst schnell Value zu schaffen, wenn dem irgendwas im Wege steht, muss das Entwicklerteam diese Probleme beseitigen.

Der Manager Scrum Master

In selbstorganisierten Teams gibt es keinen Manager, wenn man dies auf die realität überträgt, stellt man sich die Frage, was tun mit den bestehenden Management? Die Antwort ist oft, dieses als Scrum Master einzusetzen. Ich habe oft erlebt, dass dies nicht besonders klug ist. Manager sind es gewohnt zu managen, intuitiv leidet ein selbstorganisiertes Team unter einem Manager, besonders kritisch wird es hier, da Managern schlicht das technische Wissen fehlt. Dies ist maximal schlecht für die Kommunikation im Team. Manager haben recht zu haben, müssen mitdiskutieren und werden schnell in die Situation gewzungen, ihren Job zu verteidigen. Ich habe die Erfahrung gemacht, dass ein standard Entwicklerteam schlicht von den rhetorischen Fähigkeiten und dem Auftreten eines halbwegs geübten Manager eingeschüchtert werden kann.

Das ist keinesfalls ein Problem des Managers, in wirklichkeit liegt dies daran, dass das Entwicklerteam unprofessionell ist. Ein professionelles Entwicklerteam kämpft für technisch korrekte und richtige Entscheidungen.

Alles ist gut Mentalität

Wenn es in Projekten darum geht, Probleme zu lösen, muss es möglich sein, diese offen zu kommunizieren. Konstruktives Feedback ist idr. nicht nur positiv.

Oft wird versucht, künstlich Probleme zu ignorieren. Dies schafft wirkliche Probleme.

Probleme zu lösen sollte positiv sein, Probleme ansprechen auch. Es ist wichtig zu verstehen, dass nur gelöste probleme gute Probleme sind :)

Was Hilft?

Ich habe mich lange damit beschäftigt, warum ich in Agenturen oft solche Konstellationen antreffe. Hier muss man sich natürlich die Frage stellen, an welchen Rädern man hier drehen müsste, damit das Team nicht nur denkt agil zu sein, sondern auch die agilen Werte und damit die agilen Vorteile lebt.

Der Productowner ist oft nicht in der Lage diese Problematik zu erkennen. Der Scrum Master ist entweder völlig Überfordert oder verteidigt bewusst und effizient seine Daseinsberechtigung als Manager.

Es ist die Aufgabe der Entwickler sich professionell zu verhalten. Im großen und ganzen fasst dies das Buch “The Clean Coder” zusammen. Lesen lohnt sich.