Too busy to improve – die Mär von dem guten Team und agiles Teamwork

Von Never Code Alone
0 Kommentar

Gute Teams lösen im agilen Teamwork aktuelle Herausforderungen und bringen sich dabei gegenseitig auch noch alles bei. Mit ganz viel Spaß und Leidenschaft. Bei der agilen Softwareentwicklung steht das Team im Vordergrund. So wird es in den vollmundigen IT Stellenausschreibungen versprochen. Im Job Interview als höchstes Gut verkauft. Und auch sonst wird ein besonders hoher Wert darauf gelegt. „Hier wird niemand alleine gelassen, das zeigt sich bei uns schon im Onboarding Prozess.“…“Das Buddy-Prinzip.“. Also alles ganz Never Code Alone, aber da hätte ich den Laden ja gar nicht gründen müssen. Ein persönlicher Rückblick, der sich nach einer aktuellen Umfrage, leider inhaltlich nicht geändert hat.

Legacy Projekte – einer steckt bis zum Hals im Sumpf und das Team denkt: „toll ein anderer macht’s.“

Web Development Projekte sind komplex. Und im Laufe ihrer Zeit auch zunehmend chaotisch. Das liegt am schnellen Wachstum in der Anfangsphase. In einem solchen Ökosystem sind meistens das lokale Setup, der Deployment Prozess und alles weitere auch nicht standardisiert. Es läuft einfach. Wie kleine Wunder. In solchen Arbeitsumgebungen ist leider nichts einfach, leichtgewichtig, automatisiert, agil oder macht Spaß. Genau hier ist echtes Teamwork gefragt, damit man in dem Legacy Code Dschungel nicht verloren geht. Das sind genau die Projekte, deren Unterhalt so teuer wird, dass sie in einen technologischen Stillstand fallen. Trotzdem wird in diesem Kontext sehr oft weiter gespart und nicht investiert. Agentur und Kunde oder auch das eigene Team sind hier in einer Zweckbeziehung.

Gesetzliche Anforderungen, abgelaufene PHP Versionen oder auch einfach neue Feature Requests müssen hier weiter ausgeliefert werden. Eine Herkulesaufgabe. Hier kümmert sich dann einer um alles. Der hat längst die sozialen Kontakte im eignen Team geblockt, wird nur im Daily gesehen, ist immer extrem busy und hat keine Zeit seinen potentiellen Helfern zu erklären, was da überhaupt passiert. Dinge werden hier „dreckig angeflanscht, mit der heißen Nadel gestrickt und einfach nur noch hingerotzt.“Das klang auf der Stellenausschreibung und der Internetseite irgendwie ganz anders. Abgesehen von den gesundheitlichen Risiken des Mitarbeiters, ist das auch ein großes Business Risiko. Stichwort Bus Factor.

Wer fragt ist der dumme oder es ist zumindest unangenehm – wenn die Arbeit auf einmal keinen Spaß mehr macht

Ich kenne das nur zu gut. Allerdings habe ich lange vor meiner Zeit gelernt zu Fragen und Zuzuhören. Es ist keine Schande, etwas nicht so zu wissen. Erst recht im IT-Sektor. Jeden Tag kommen hier deutlich mehr Fragen auf, als jemals von mir beantwortet werden könnten. Aber auch ich kenne die unangenehmen Situationen nur zu gut und finde übrigens, dass das Homeoffice die Barrieren deutlich erhöht hat. Weil der soziale Kontakt ja praktisch erzwungen werden muss. Man geht ja nicht mal mehr gemeinsam Essen, sieht sich nicht. Oft haben genau die Kollegen ja auch ihre Kamera ausgestaltet.

Die erste Challenge ist ja, ein Projekt aufzusetzen. Hier ist man auf Hilfe und auch Zusammenarbeit angewiesen. Ein Onboarding Prozess. Dafür wird leider sehr oft keine Zeit zur Verfügung gestellt. Für den etablierten Developer bedeutet das vor allem zusätzlichen Stress. Und dabei muss er der neuen Fachkraft noch motiviert und mit guter Laune begegnen. Zeit für die Vorbereitung und Struktur dieses Onboardings sind auch nicht eingeplant. 1 zu 1 Situationen passen hier vielleicht auch gar nicht zur Persönlichkeit des Lead Developers. Schwierig, aber leider doch sehr häufig.

Fehlenden Dokumentation, keine Slack Time und kein Training für die eigenen Skills

Die Außendarstellung eines Unternehmens kann leider sehr stark von dem tatsächlichen inneren Zustand stark abweichen. Ein Thema hier, welches jetzt nicht weiter ausgeführt wird, sind Werte und Visionen. Sind die auf der Internetseite nicht vorhanden, ist schon mal Vorsicht geboten. Wie sie erreicht, geschützt und entstanden sind, sind sehr gute Fragen für Bewerber in IT Stellenausschreibungen. Stark im Argen liegt das ganze in sogenannten Dauerkulturen. Hier wird, wie der Name schon sagt, sehr stark mit Druck gearbeitet. In der Folge passiert das Gegenteil von nachhaltiger Softwareentwicklung. Kurzfristige Ziele werden hier in der kürzesten Zeit erreicht, ohne Wert auf die Langfristigkeit oder Zukunftsfähigkeit des Projekts zu legen. Das zu erreichen erfordert Know-how bei den MitarbeiterInnen des Development Teams. Nur damit wird man in die Lage versetzt, professionell zu arbeiten. Alles andere ist Stümperei, die sich vor allem durch Kesselflicker auszeichnet.

Ein ganz wesentlicher Faktor für professionelle Entwicklung ist Dokumentation. Erst dadurch wird Know-how teilbar, das Team im Onboarding Prozess skalierbar und Standards als Grundlage für Innovationen geschaffen. Das ist ebenfalls ein sehr gutes Thema für ein Job Interview. Eine bloße Absicht, das Thema in Zukunft anzugehen, ist hier leider auch nur ein Lippenbekenntnis. Dazu kommen interne Workshops, Pair Programming und Slack Time, um überhaupt über den Tellerrand zu schauen. Wenn aber für nichts von all dem Zeit ist, arbeitet man bis zum Umfallen und hat keine Zeit mehr für Zwischenmenschlichkeit, dann ist man too busy to improve. Das wird ernste gesundheitliche Folgen haben. Denn unter Druck entstehen leider auch nur Diamanten und keine besseren Mitarbeiter.

Wir suchen händeringend neue Mitarbeiter haben aber keine Zeit für das Onboarding

Innovationen können unterschiedliche Ziele haben. Unter anderem den Onboarding Prozess für neue Web DeveloperInnen. Chaos ist schwer zugänglich und schreckt ab. Fehlende Transparenz ist eine ganz schlechte Grundlage für ein neues Arbeitsverhältnis. Agil ohne Testing funktioniert nicht. Hier teilt sich vor allem die Agenturlandschaft in zwei große Lager. Das eine Lager lebt nach der Devise „Der Kunde zahlt das nicht“. Hier gilt „Sparen, koste es was es wolle“. Ein großes Problem, dass sich leider insgesamt auf den IT Standort Deutschland auswirkt. Im anderen Lager gibt es Dinge wie „Wartungsverträge“. Die schließen Updates, zuverlässige Infrastruktur und auch die Weiterbildung der Mitarbeiter ein. Hier gibt es auch echte Deployments und keine Billig Hosting Lösungen auf die statische File kopiert werden.

In beiden Lagern unterscheiden sich die Onboarding Prozesse sehr stark. Sowohl menschlich als auch technologisch. Das will ich hier jetzt im einzelnen gar nicht alles aufführen. Im zweiten Lager wird mit Standards gearbeitet. Den Innovationen werden hier wertgeschätzt und bringen alle im Kosmos der Softwareentwicklung weiter. Im ersten Lager gibt es keine Wertschätzung für gute Arbeit, sondern hier ist die IT einfach nur „teuer“ und will ständig neue Dinge für Sachen die heute funktionieren. Also warum sollten sie das morgen nicht mehr tun? Auch das sind gute Themen für ein Kennenlerngespräch und bitte liebe gute Arbeitgeber, packt Dinge auf die ihr stolz seid bitte in eure Blogs und verlinkt die in euren Stellenausschreibungen.

#NCADiscussion Kunde vs Coder
#NCADiscussion Kunde vs Coder

Fazit zum Thema innovative Arbeitgeber in der IT und Onboarding Prozesse

Aktuell wird viel Energie benötigt, damit BewerberInnen gefunden werden können und am ersten Arbeitstag im neuen Job starten. Die wollen, so weiß ich es auch aus eigener Erfahrung, in Projekten starten, etwas bewegen und „liefern“. Alles, was diesem Ziel im Wege steht, verursacht Frust. Wenn im Vorfeld falsche Versprechen in Vorstellungsgesprächen waren, kann das sogar schweren seelischen Schaden anrichten. Auch das kenne ich leider aus meinen persönlichen Erfahrungen.

Der wichtigste Prozess auf dem Weg zu diesem sehr einfach klingenden Ziel ist der technologische Onboarding Prozess. Optimal ist der standardisiert und für alle Projekte gleich. Im ungünstigsten Fall ist er technisch komplett überholt, langsam und sehr instabil. In jedem Fall benötigt er eine sehr gute Dokumentation, damit er leicht und ressourcenschonend durchgeführt werden kann. Muss man hier bei neuen Arbeitgebern um Hilfe bitten, die dann als „nervig“ angesehen werden, ist das eine totale Katastrophe. Um solche ständigen Herausforderungen und Innovationen kann sich nur ein gutes Team kümmern, das gemeinsam Probleme löst und für alle Beteiligten in den Projekten vereinfacht. Wertschätzung führt hier zu Innovationen.

0 Kommentar

Tutorials und Top Posts

Gib uns Feedback

Diese Seite benutzt Cookies. Ein Akzeptieren hilft uns die Seite zu verbessern. Ok Mehr dazu