Interview
12.06.2023, 00:00 Uhr
„Keine Angst, etwas falsch zu machen“
Wir machen jetzt agil, sagte der Chef, und das Chaos war perfekt. Welche Voraussetzungen erfüllt sein müssen.
Kaum hängt das Manifest für Agile Softwareentwicklung an der Wand, schon arbeitet ein Team auch nach dessen Regeln. Das wäre zwar schön, aber nein, so ist es leider nicht. Vielmehr bedarf es einiger grundlegender Voraussetzungen, damit der Schritt hin zur Agilität auch funktioniert.
Wenn der Schritt aber so vollzogen ist, dass er alle Projektbeteiligten mitnimmt, wird der Output besser und die Ergebnisse kommen schneller. Das Wichtigste ist aber, dass sich die Mitarbeiter besser fühlen. dotnetpro sprach mit Oliver Schröter, Entwicklungsleiter von DPS BS, wann Agilität funktioniert und wann nicht und warum der Punkt Eigenverantwortlichkeit so wichtig ist.
dotnetpro: Oliver, lange Zeit hast du als Programmierer gearbeitet. Inzwischen aber programmierst du keine Zeile Code mehr. Wann und vor allem warum hast du dich entschieden, dass Menschen spannender sind als Technik?
Oliver Schröter: So ganz genau weiß ich es nicht mehr. Ich glaube, es war um 2010. Ich habe immer mehr Verantwortung bekommen bei Sage, zuerst als Teammanager und später als Entwicklungsleiter. Was mir aufgefallen ist: Die Entwickler vertiefen sich in ihre Aufgaben und verlieren dann den Blick auf all das, was um sie herum ist. Programmierer sind halt so. Die tauchen ab in einen Tunnel, weil es einfach Spaß macht und cool ist, was man macht.
Oliver Schröter
Oliver war lange Entwicklungsleiter bei der Sage GmbH im
Bereich HR Deutschland und für über 50 Entwickler zuständig. Seit Kurzem arbeitet er bei der DPS BS und hat unter anderem die Aufgabe, die Entwicklung agiler zu machen. dotnetpro sprach mit ihm über Agilität im Unternehmen.
Bereich HR Deutschland und für über 50 Entwickler zuständig. Seit Kurzem arbeitet er bei der DPS BS und hat unter anderem die Aufgabe, die Entwicklung agiler zu machen. dotnetpro sprach mit ihm über Agilität im Unternehmen.
Mir war es aber wichtig zu sehen, dass das in die richtige Richtung läuft und anständig passiert. Dazu braucht man den Blick von außen, viel Zeit, muss zuhören und neugierig auf die Leute sein. Das reizte mich. Deshalb habe ich beschlossen, das Programmieren sein zu lassen und mich voll auf die Belange der Leute zu konzentrieren. Ich habe gemerkt, dass ich Menschen ganz gut einschätzen kann.
Ich wollte eine Umgebung für die Leute schaffen, in der sie das, was sie umtreibt, gut ausführen können. Sie sollten nicht getrieben sein, sondern sich als Forscher verstehen.
Wer aber forscht, kann nicht sagen, ob und wann es einen Durchbruch gibt.
Ich durfte damals immer ein Lastenheft unterschreiben und musste Buße tun, wenn wir all die Anforderungen nicht geschafft haben. Die Zeiten darin waren natürlich vollkommen falsch eingeschätzt. Schließlich dauert es grundsätzlich länger, als man am Anfang annimmt.
Ich habe damals für mich beschlossen, dass ich meine Mitarbeiter schützen will. Sie sollen den Freiraum haben, ihre Forschungsaufgaben richtig gut zu machen.
Ich sehe mich also in erster Linie nicht als Manager oder Personaler, sondern als Enabler. Ich will meinen Mitarbeitern ermöglichen, dass sie ihre Arbeit bestmöglich erfüllen können und von allem befreit sind, was sie davon abhält. Sei es die Frage, wie kommt die Krankmeldung jetzt an die richtige Abteilung oder warum ist der Rechner so langsam.
Würdest du bestätigen, dass Entwickler gewisse Eigenheiten haben?
Schröter: Oh ja! Das ist jetzt vielleicht ein bisschen pauschalisierend, aber tendenziell sind sie ein wenig introvertiert – etwas nerdig. Ich kann das nicht zu 100 Prozent bestätigen, denn jeder bringt ja auch seine eigene Persönlichkeit mit, aber zu 70 Prozent stimmt das wohl.
Viele Entwickler tendieren dazu, sich in ihrer Arbeit zu verlieren und nicht zu merken, wenn sie zu viel entwickeln oder zu tief einsteigen. Diese Mitarbeiter muss man vor sich selbst schützen.
Ist das nicht mit jedem Spezialisten so? Oder sind Entwickler noch mal ein ganz speziellen Schlag Mensch?
Schröter: Ich glaube, Entwickler sind trotz aller Eigenheiten kein spezieller Schlag Mensch. Jeder Mensch hat seine eigenen Wehwehchen, die Dinge, die er für sich als wichtig erachtet. Entwickler haben aufgrund der Anforderungen eine logische Denkweise.
Aber der Mensch besteht nicht nur aus Coding allein. Und hier gibt es Unterschiede. Wie tickt er denn? Macht er lieber Dinge fertig oder hat er Ideen und lässt andere fertig machen? Kann er gut im Team arbeiten oder ist er eher ein Einzelkämpfer? Das Einzige, was sie meiner Meinung nach gemeinsam haben, ist, dass sie sehr ruhig sind.
Du führst bei der DPS Business Solutions Scrum ein. Jeder versteht unter Scrum etwas anderes. Worauf kommt es dir besonders an?
Schröter: Da muss ich berichtigen. Ich will nicht Scrum einführen, sondern eine agile Arbeitsweise. Scrum ist nicht gleich agil. Es gibt so viele agile Methoden, zum Beispiel Kanban, das Safe Framework für große Unternehmen und so weiter und man sollte immer überlegen, was für die jeweiligen Anforderungen richtig ist.
Was ich jetzt wieder neu erfahren durfte: Scrum ist im Projektgeschäft nicht sinnvoll. Bei einem Projekt will ich nächste Woche ein Ergebnis haben und nicht erst einen Sprint planen, der dann in ein paar Wochen fertig ist.
Wichtig sind allerdings die Werte nach dem agilen Manifest. Und damit kommen wir zu einem zentralen Punkt: Wer Scrum einführt, arbeitet nicht automatisch agil. Scrum ist für mich ein Regelwerk, an das man sich möglichst halten sollte. Aber es ist nur ein Framework. Das alleine wird Agilität nicht ermöglichen. Agilität kommt durch eine Veränderung im Mindset – bei den Mitarbeitern, beim Management. Alle sollten das tragen. Dann gelingt es.
Was bedeutet denn Agilität für Geschäftsführer?
Schröter: Das ist eine gute Frage! Agilität sollte vom Management getragen werden – vielleicht sogar Top-down. Und man muss mit den Konsequenzen leben können.
Wenn agil gearbeitet wird, heißt das, dass nicht mehr von oben nach unten agiert wird. Es gibt dann keinen Entwicklungsleiter mehr, der den Mitarbeitern sagt, was sie zu tun haben und wie lange sie dafür brauchen dürfen.
Niemand sagt mehr, dass es eine Stunde dauert, und dann sind es drei. Auch Fehler sind zugelassen. Am besten ist es, wenn die ganze Firma agil denkt und arbeitet.
Am Ende geht es darum, dass die Mitarbeiter motiviert sind, weil es ihre Ziele sind, die sie erreichen wollen und sie dafür verantwortlich sind.
Die meisten Manager sind sehr ungeduldig. Der Wechsel des Mindsets hin zu Agilität braucht Zeit. Ein Team muss sich erst finden. Das ist eine große Herausforderung für das Management!
Geschäftsführer geben gerne Ziele vor und manche stehen sprichwörtlich mit der Stoppuhr neben den Entwicklern und fordern mehr Output. Warum scheitert dieser Ansatz deiner Meinung nach?
Schröter: Die Aufgaben sind meist zu groß, es wird nicht ordentlich geplant und oft ist nicht mal genau klar, was gemacht werden soll. Das muss scheitern. Top-down kennt nur einen, der bestimmt, und das reicht eben nicht.
Das Ziel ist – und ich habe das selbst auch so erlebt – dass die Teams nach einiger Zeit eigenständig werden, sich selbst organisieren, sich unterstützen, die Arbeiten, die im Backlog stehen, gezielter angehen – als Team, nicht mehr allein. Es wird Inselwissen abgebaut.
Ein Team kann sich viel besser motivieren – gegenseitig motivieren. Wenn man alleine in seiner Kammer sitzt, fällt es oftmals schwer zu sehen, was man falsch macht, wo Dinge vielleicht schieflaufen. Im Team erklärt man es den anderen und die anderen denken mit.
Das Team ist dafür verantwortlich, in zwei Wochen ein Ziel zu erreichen. Wenn sie es nicht schaffen, auch nicht schlimm. Es ist schließlich auch Forschung.
Beim Top-down-Ansatz kommt der Druck von oben. Was verändert sich, wenn der Druck plötzlich aus dem Team heraus kommt?
Schröter: Es ist nicht mehr der Chef, der mir mein Gehalt bezahlt, sondern es sind meine Freunde/Kollegen, mit denen ich jeden Tag zu tun habe. Denen muss ich Rechenschaft ablegen.
Ist das nicht umso peinlicher?
Schröter: Es muss nicht peinlich sein. Kritik sollte sowieso nicht peinlich sein. Es geht aber eher darum, die anderen im Team nicht zu enttäuschen. Beim Chef, der mit der Stoppuhr danebensteht, empfinde ich einfach nur Druck und versuche das zu erreichen, was er will. Notfalls mache ich es schludrig, nur damit es irgendwie funktioniert. Manche können bei so einem Druck nicht mal mehr richtig nachdenken.
Stellt man sich im Team nicht auf das Mittelmaß ein, statt sich am Besten zu orientieren? Wie entstehen aus deiner Sicht in einem Team Innovation und Fortbildung?
Schröter: Ein Aspekt der agilen Arbeitsweise ist die Reflexion. Einmal im Sprint kommt der Zeitpunkt, an dem man sich eine Stunde mit den Teammitgliedern hinsetzt und darüber spricht, was gut und was nicht so gut lief. Man ist ständig dabei, den Prozess und sich selbst zu verbessern. Man spricht offen miteinander, weil es meine Kollegen sind.
Ich kann auch mal meine Meinung sagen, ohne Angst zu haben, dass mein Chef mich nicht mehr mag. Die Teammitglieder schauen gemeinsam, was nicht passt. Widmet sich jemand zum Beispiel immer zu viel seinem Handy, ist die Retrospektive genau der Zeitpunkt, wo das Team das anspricht und eine Lösung schafft, mit der alle leben können. Das muss nicht ein kompletter Verzicht auf das Handy sein. Es geht eher darum, dass das Team die Lösung trägt und neue Regeln findet. Am Ende sollte man mit dem, was man tut, zufrieden sein und ein gemeinsames Ziel erreichen.
Woran erkennst du, ob jemand wirklich nicht will oder nicht geeignet ist, im Team zu entwickeln?
Schröter: Wie überall gibt es die, die mit solchen Methoden nicht klarkommen. Das kann unterschiedlichste Gründe haben. Wie erkennt man diese Leute? Ganz einfach: Sie funktionieren nicht im Team. Ständig gibt es Querelen oder sie sagen selbst, dass sie damit nicht klarkommen. Ich würde nie in der Anfangsphase auf alles hören, was da kommt. Die meisten sind skeptisch, weil wieder was Neues passiert. Und viele Fragen stehen im Raum: Wer hat denn jetzt den Hut auf und so weiter?
Aber genau das soll Agilität abschaffen: dass jemand den Hut aufhat. Am Anfang also nicht hinhören. Spüren ja, aber nicht darauf eingehen, sondern einfach mal ausprobieren. Wenn man dann nach drei bis vier Monaten merkt, dass immer noch Störfaktoren da sind oder die Leute das offen verkünden, dann sollte man darüber nachdenken, was diese Leute machen. Dann ist es an der Zeit, die Strukturen zu verändern, indem man Mitglieder aus einem Team in ein anderes übernimmt.
Es gibt noch das andere Extrem: den supernetten Kollegen, der im Team beliebt ist, aber die eigene Arbeit nicht voranbringt.
Schröter: Menschen zu etwas zu zwingen, was sie nicht wollen oder können, erzeugt immer nur noch mehr Gegenwehr. In so einem Fall stellt sich die Frage, ob das Teammitglied diese Arbeit weiter machen sollte. So böse es klingt, aber dann ist es vielleicht nicht das Richtige für ihn oder sie. Vielleicht passt er oder sie dann besser in eine andere Abteilung. Ein kleiner Prozentteil wird nach der Einführung sagen „Ich will das so nicht“ und kündigt.
Nach den negativen Beispielen: Du kennst sicher auch Teams, bei denen Veränderungen gelungen sind?
Schröter: 2013 habe ich Agilität für mein Team eingeführt. Zuerst habe ich es falsch gemacht: Ich habe mir nur das, was ich für sinnvoll erachtet habe, herausgepickt. Das hat so nicht funktioniert. Aber dann habe ich mich quasi nach Lehrbuch als Chef aus dem Team herausgezogen. Klar wusste ich alles besser – so meinte ich zumindest. Aber im Endeffekt war ich als Chef sowieso nur dazu da, die Verantwortung zu übernehmen, wenn etwas schiefging.
Genau das will die Agilität aber eben nicht: Es gibt keinen Schuldigen! Aus Fehlern lernt man. Fehler sind sogar gewollt. Nur an Fehlern kann man wachsen. Nur wenn man einen Fehler macht, kann man sich verbessern. Wenn alles läuft, wie will man dann vorankommen? Man denkt ja, alles läuft super, warum soll ich was ändern? Wer immer tut, was er schon kann, bleibt immer das, was er schon ist. Das Leben ist Weiterentwicklung und Lernen. Die Agilität auch.
Ich habe also meine Leute mal machen lassen. Und war erstaunt, wie gut der Output war. Man muss nicht jedes Problem zum eigenen machen. Die Leute haben oft bessere Ideen, weil sie viel näher am Thema sind.
Wenn es um Veränderung geht, dann kommen Ziele ins Spiel. Kann es zu Konflikten zwischen den Zielen der Firma und denen des einzelnen Mitarbeiters kommen?
Schröter: Sind wir mal ehrlich: Die meisten sind in der Firma, weil sie Geld verdienen wollen. Wenn es gut läuft, sind sie irgendwann so motiviert, dass sie nicht mehr über das Geld nachdenken. Das ist dann positiver Nebeneffekt. Sie haben einfach Spaß an der Arbeit.
Geld kann niemals der Antrieb sein. Wir wissen ja, dass eine Gehaltserhöhung nur kurzfristig motivierend wirkt. Viel besser ist es, wenn das Geldverdienen noch Megaspaß macht. Dann fallen das Ziel der Firma und das persönliche zusammen.
Hat man Agilität eingefügt, steigert sich die Produktivität. Der Krankenstand sinkt und es werden geilere Produkte gebaut. Die Firma verdient mehr Geld. Also profitieren am Ende alle davon.
Orientieren sich dann die Business-Ziele am Team? Also bestimmt das Team die Ziele des Unternehmens?
Schröter: Nein, niemals! Wenn meine Entwickler etwas anderes wollen als die Firma, dann stimmt etwas beim Recruiting nicht. Wollen die Entwickler eines Herstellers von Finanzsoftware zum Beispiel eigentlich viel lieber Spiele programmieren, dann kann das nicht gutgehen.
Die Ziele und die Strategie kommen vom Management. Die Mitarbeiterinnen und Mitarbeiter sollten das Firmenziel nicht nur kennen, sondern es auch unterstützen.
Den Entwicklerinnen und Entwicklern sollte klar sein, auf welches Ziel sie hinarbeiten: Was ist das langfristige Ziel, was ist die kurzfristige Strategie und wie zahle ich mit dem, was ich tue, darauf ein?
Nicht vergessen darf man auch, dass die Mitarbeiterinnen und Mitarbeiter einen wichtigen Grund dafür haben wollen, warum sie das tun, was sie tun. Auch wenn es eine blöde Arbeit ist, die sie eigentlich nicht machen wollen. Aber wenn sie sehen, wo das hinführt und warum sie das machen, dann akzeptieren sie auch die drögen Tätigkeiten viel besser.
Welchen Tipp würdest du am Schluss konkret den Lesern der dotnetpro geben: Was wäre der nächste kleine Schritt in Richtung Agilität?
Schröter: Das kommt natürlich auf die Rolle an. Aber man sollte keine Angst haben, etwas zu verändern. Und man sollte darauf vertrauen, dass jeder Mitarbeiter es eigentlich besser könnte und will, wenn man ihm nur den Freiraum dafür gibt. Es ist alles eine Frage des Vertrauens.
Das Interview führte dotnetpro-Autor und DPS-BS-Entwicklungsleiter Bernhard Pichler.
Dokumente
Artikel als PDF herunterladen