I'm a coder - Das erste Mal Team-Lead
Über die letzten eineinhalb Jahre habe ich mein erstes professionelles Projekt geleitet und heute möchte ein kleines Fazit ziehen. Vielleicht ist für den einen oder anderen ein hilfreicher Tipp dabei oder vielleicht habt ihr Tipps, wie man in diesem Bereich noch besser werden kann. Über Kommentare freue ich mich wie gewohnt sehr.
Ich bin gerne ein Entwickler, soll heißen ich schreibe wirklich gerne Code, doch auf der anderen Seite koordiniere und plane ich tatsächlich auch recht gerne. Letztes ist glaub ich extrem wichtig wenn es darum geht ein Team und ein Projekt zu leiten. Denn sofern man keine Ambitionen in diesen Bereichen hat, sollte man lieber bei der reinen Entwicklung bleiben. Grund dafür ist die massive Verschiebung der Aufgaben und die entsprechend veränderte Zeitverteilung. Sofern einem dann der Verwaltungsteil gar nicht gefällt, wird man vermutlich schnell unzufrieden sein.
Wie erwähnt finde ich aber durchaus Gefallen daran und war froh mit dem genannten Team arbeiten zu dürfen. In Retrospektive denke ich damit steht und fällt generell alles, also ob das Team allgemein und menschlich funktioniert. Erst darauf kann man dann auf professioneller Ebene etwas aufbauen. Wir hatten das Glück das es passte und mit einer recht guten Wissensverteilung (2x Android, 2x iOS, 1x Testing) konnten wir eine Flutter App entwickeln, welche mit genügend Platform-Background versorgt wurde.
Neben täglichen Standups gab es viele Ad-Hoc Meetings und Gespräche, dafür aber wenige geplante Meetings. Lediglich Retros und Teamübergreifende Meetings fanden geplant regelmäßig statt. Dadurch blockierten wir nicht unnötig Zeitslots und waren meist sogar noch etwas schneller darin Dinge zu klären. So kam es öfters vor, dass zwei Entwickler etwas besprechen wollten, aber spontan ein dritter dazu kam und man eine kleine Brainstorming Runde macht. Dieser Ablauf war für uns als eher kleines Team passend und meiner Meinung nach sehr effektiv.
Im Allgemeinen würde ich sagen, dass eine Politik des offenen Ohres hier das Beste ist. Soll heißen, dass jeder jeden ansprechen kann und man vielleicht keine Antwort binnen 2 Minuten erwartet, aber dass sich jeder verantwortlich dafür fühlt in einer angemessenen Zeit zu antworten. Vor allem aber ist es okay einfach mal eben etwas zu fragen, egal ob es um Hilfe oder eine Meinung geht. Das genannte Konzept sollte übrigens auch auf die technische Entscheidungsfindung angewendet werden. Soll heißen egal ob man Team-Lead, Entwickler oder der Anführer der Kotlin-Götter ist, jeder sollte zuhören und die eigenen Ansätze nicht als absolute Wahrheit ansehen. Auf diese Art verbessern sich alle Teammitglieder, der Code wird qualitativ hochwertiger und das Miteinander wird gestärkt.
Hat man nun ein gutes Team zur Hand, welches offen miteinander auf Augenhöhe unkompliziert kommuniziert, hat man eine sehr gute Basis um einiges zu reißen. Doch wie bereits erwähnt muss man den Management-Part mögen oder es wird schnell problematisch. Ich persönlich hatte neben meiner eigentlichen Team-Lead Rolle noch diverse Koordinationsaufgaben, da das Projekt nicht nur mein Team betraf. Es gab zusätzlich noch Backend Komponenten, Server Interaktionen und auch mehrere Services, welche zwischen verschiedenen Komponenten vermittelten. In all diesen Bereichen war ich mehr oder weniger involviert, was sowohl die API, wie auch das Testing oder generelle Ideen anging. Zusätzlich will eine App ja auch getestet werden, also gab es noch diverse Interaktionen mit der QA (Qualitätssicherung). Entsprechend reduzierte sich meine Entwicklungszeit noch weit mehr als ich initial erwartete.
Alles in allem freue ich mich trotzdem darüber die Chance wahrgenommen zu haben und vor allem darüber das es generell wirklich gut lief. Natürlich gab es Hochs und Tiefs, aber basierend auf unserer Arbeit und dem Feedback des Teams kann man wohl sagen, dass das Ganze durchaus erfolgreich war. Zu Flutter als Platform für professionelle Apps wird übrigens in den nächsten Tagen auch noch ein recht umfangreicher Beitrag folgen.